为什么要SOA?

　　因为SOA出现前，世界上有Corba组件模型、JAVA组件模型、COM+组件模型、.NET组件模型。其中，CORBA组件模型和JAVA组件模型属于IBM为首那一类阵营(一伙的还有BEA、ORACLE、HP、SUN之类的)，而COM+组件模型和.NET组件模型属于微软这独个一家的，自古两个阵营是表面同行、暗地互掐。

　　IBM当然需要四海一家的解决之道。因为JAVA组件模型老受SUN的牵绊，而且江湖风传EJB已死。CORBA组件模型呢，一直没有当过老大主流流行过。其他两个组件模型都在微软封闭的圈子里，IBM就想在在这四大组件模型之上再加一层组件模型，这样就天下大同了，这就是SCA。

　　有了SCA组件模型，各个异构组件模型现在都被包装成一样的组件了，怎么数据传递?当然就是SDO来帮忙。

　　听说SOA主要优势是整合，但是我们既然有webService了，要SOA干吗?

　　WebService是整合包装统一成WebService协议族的很好的规范，但WebService又不是组件模型。有人问了，你管我是组件不是组件，我给你包装一层webservice，咱们俩能调用就OK了。

　　这就涉及到咱们国家的计算机发展阶段了。因为咱们国家的开发界，N多程序员还停留在双击一下按钮，IDE自动给生成一个onclick事件，然后在里面写东西。很多程序员根本没有意识去主动写函数，程序里的函数都是IDE自动生成的事件处理函数，并非程序员写的自己的函数。连函数都没有主动意识的，怎么会有主动意识去自己编写类，自己编写组件类，大多数程序员在使用系统提供的类库，系统提供的可视化组件。所以，N多程序员就不明白为什么要有SOA组件模型了。

　　世界主流代码开发都已经是编写组件类了，这是业界的发展需求，但我们国内代码开发水平和需求还没有到这个层次，还在onclick。所以我们不理解。

　　如果我们也平时很自然的自己编写组件类，那么我们现在很自然的希望有支持SOA的组件模型，因为这样的组件模型，就可以很通畅的和过去的CORBA组件模型、JAVA组件模型、COM+组件模型、.NET组件模型交互了。如果我们现在还不用SOA组件模型，还在用四大组件模型，以后想异构组件之间交互，还得再开发一层SCA。

　　那SOA就这么简单?就是SCA+SDO?

　　目前国际SOA标准推出的就是这两大标准，SCA和组件SDO。和SOA关联的还有两个东西，一个是BPEL，一个是ESB。SCA是有了统一的组件，SDO是有了统一的组件数据交互，BPEL是让组件之间串联在一起，然后自动运行，就如同我们把一个个的鞭炮拧在一起，然后点燃捻子，鞭炮就全都自己串联着爆炸了，BPEL就是干这个用的。而ESB呢，就如同各个组件，都需要在一个容器中执行，号称组件容器服务器，JBOSS最初的功能就是EJB组件的容器服务器。而ESB呢，当然就是SOA组件的容器服务器了。

　　SOA就这么简单吗?我怎么看书看网站，说是让业务人员和技术人员更好的结合，要用业务角度去看技术，这个话不理解?

　　这是给SOA组件设计师一个设计指导。也就是说，当你要设计一个SOA组件，你要暴露出什么功能，要多达粒度的，可能你这个组件类可以围绕一个主题完成10个功能，但10个功能编写实现比较复杂，你最后内部写代码的时候写成了函数嵌套函数，那么你内部有许多函数了，你到底要暴露出哪些。咱们设计组件类的接口，往往不容易把握粒度的问题。就如同你如果刚刚一开始写面向对象的代码，很容易会滥用对象，设计的对象很多，如果还没有过面向对象开发的程序员，你可能想像不出来为什么会有这种过度使用对象的现象。人就是这样，用的爽了，就容易过度使用。所以什么粒度合适，给指导了，面向业务。从组件类的消费者角度来看，需要暴露出哪些功能。这就有了一方是功能消费调用者，一方是功能输出产生者，那么这个功能输出，用行话就是输出的是服务。

　　SOA就这么简单吗?我看书看网站说，SOA可以使软件灵活，我们现在就是软件代码越来越复杂，功能越来越多，客户需求提出来，我们很难下手修改，修改起来费时间，而且还不知道这块修改了会影响哪块，让软件质量无法稳定，我们正需要SOA，但是SOA是怎么做到这点了，我不理解呀?

　　当然COM+、EJB成为风潮的时候，都说过这个话。你想啊，软件都是一个个封装密闭的组件，把组件连接起来，这当然灵活了。你想想你现在，.NET给你提供了许多可视化组件，也提供了许多非可视化组件，人家就是用组件做成了，你现在开发起来，把组件拖拽下来，设置一下属性，编程一下方法，你现在开发速度快多了吧，如果没有这么多组件，你想你多累。这就是组件的好处与灵活性。SOA组件也是组件，只不过是包装的更高一层的组件，是为了让四大组件模型能统一顺畅调用的，所以你把SOA组件当成.net组件来看待就很明白了。

　　中国现在好多企业都还没有信息化，即使一些很赚钱的行业或垄断国企做了信息化，但都自己封闭起来，和其他企业之间老死不相往来，SOA在中国有用处吗?

　　你用不用SOA组件模型，就如同你用不用.NET组件一样，管整合什么事。你如果只想整合，webservice就可以了。用不用组件式开发，是你自己的事情，如果你想让你的程序变的灵活。你看.net里面那么多组件，给你的开发带来了很多的轻松啊。

　　现在SOA成熟吗?该到应用的时候了吗?

　　成熟不成熟，你得看支持SOA标准的开发工具成熟没成熟，做SOA应用就需要成熟的开发工具。有了能很顺手的SOA组件开发工具，那就看看有没有成熟的SOA组件容器服务器。如果这两项都不错了，就可以开发了。我们当年开发COM+的时候，COM+不成熟，COM+开发工具不成熟，COM容器不成熟，造成线程死锁、并发排队、缓冲池崩溃、内存泄露很多问题，搞的我们很是头疼，最后找来开发工具厂商的人，找来微软，才算弄清问题，原来一方面是微软COM+有问题，一方面开发工具也有问题，白耽误了我们许多时间。不过福兮祸兮，倒是让我对组件模型、WINDOWS基础核心技术思想倒是精进不少。

　　我看你有点误导人。现在企业级开发，实际主流标准就两个，一个是.NET，一个是JAVA。.NET本来就似乎支持WebService第一类的技术，而JAVA是后来才加入WebService的，所以算不得原生结合。况且微软自己自成一套体系，.NET组件模型也很好，我为什么要用SOA组件模型呢?

　　确实这里面也有些商业目的。虽然IBM现在是JAVA领域的领头羊，也在JAVA上建立了一整套产品体系，投资颇大，但毕竟JAVA是出自SUN，所以SUN为了保护自己的利益当然要不让IBM自己主导的很爽了，所以JAVA要推出一项特性，往往时间很慢，而且总需要兼顾各方利益，所以大家都看到，近几年出来的JAVA新特性标准都不尽人意，就是各方利益拉锯的产物，谁也不得罪，就形成了中庸的东西。IBM早就想甩开SUN了，但IBM在JAVA上也投资巨大，如果另起炉灶也不太可能，所以想到这个移花接木的方法，把JAVA架空。出了一个SOA模型，各种语言都可以实现，不仅仅限于JAVA平台上，在SOA的统一架构技术至上，就没有JAVA痕迹了，那就轮到IBM大显身手了，所以OSOA组织，SUN是很靠后才参加的。因为SUN知道，不参加会被甩的更远，现在参加，还能捞点残余。反正最终的命运是要被扫走。

　　SUN的JAVA被IBM正在一步步边缘化，当然投入过深，想抽出来也不容易，但IBM有这个财力也有这个耐心。IBM不断宣称开源，ECLIPSE，IBM支持了很多，让大家在开源世界接纳了IBM，而且IBM近几年一直在推动web2.0，也就是轻巧化的开发。企业级开发，大家一想就头疼，都是大框架大平台很复杂，IBM也知道顾客烦了，现在全世界的IT巨头都在宣称简化IT。呵呵，这些家伙，把东西搞复杂故意建造竞争壁垒的是他们，现在简化IT的还是他们，正反都能卖。