SOA的继续讨论

SOA对于应用集成而言是一个非常非常非常非常重要的东西。
不过，这个和web service并没有关系。soa可以以ws为手段，当然也可以用别的方式。
我们现在正在做一个应用集成的方案。虽然现在只是让合作方自己主导方案的设计，但是最终我肯定要求对方用这种构架。soa解决的是跨应用系统业务流程的问题，以及业务流程变化时应用系统的变化的问题。
整个企业系统的最终组成在我的概念中是大量中等规模的核心组件的有机结合。而这个有机就是指组件间的关系是用流程引擎驱动的。每个组件具备相对独立性和自足性，同时暴露出中等或粗粒度的接口。或者说，一个企业的流程再怎么变，该干的事情还得干。这些该干的东西就是用核心组件实现的。而变的只是流程定义和组合部分，或者说是所谓的胶合层。
或者，soa只是spring的这种清凉组件组合方式在多应用系统上的一种自然延伸。

Socket Client/Server－－》PRC 
RPC＋OO －－》CORBA
RPC＋OO＋java－－》RMI
RPC＋OO＋java＋分布 －－》EJB
RPC＋Internet＋XML－》WebService

就SOA的原始概念来说，任何一个功能，函数，都是一个服务，无论是C语言的函数，还是CORBA IDL中一个接口，还是EJB的一个接口，都是一个服务，SOA把这些东西再扩大化。

当初CORBA也要一统天下，也是SOA，现在提出这个概念，又可以再继续销售些基础软件。

生活要继续，总是要销售新东西让大家消耗的，不提出个EJB什么的，大家怎么去买J2EE，都用Apache＋PHP+MySQL了。IBM不支持Java，大家都用MS了，那些硬件怎么卖呢。：）

从TiGEr.zZ和charon的发言我好像看到了一些吻合点。

例如：




我把TiGEr.zZ的这段话和charon这段话理解成一个意思，不知道对不对？通常我们在单应用系统中也会设计一系列的服务接口，也就是service层。扩展到多应用系统，便如Web Service所描述的。如果要让它更灵活，那么再引入一个类似IOC容器的东东。实际上这些在现有的技术上就是可行的。charon所说的延伸到目前为止也只是一种思想上的延伸吧？因为没有看到SOA提出具体的新技术让开发者更轻松的达到这个延伸的目的。





从讨论看来，Web Service确实已不是重点，只是SOA借助了一些Web Service的特性，例如文本数据、WSDL描述服务接口。但思想上SOA跟Web Service却是有着千丝万缕的关联。



charon的这段话让我想起BPM(Business Process Management？反正就是业务流程管理)。我用过BEA的workshop中的相关功能，通过图形界面定制一个业务处理流程，感觉很棒。现在想到前面TiGEr.zZ提到一个“总线”，让我想到在workshop中完成一个业务流程定义后的那幅图画，起点到终点中间的那根线。唯一的差别在应用范围，我所用到的是在“单应用系统”中，而charon所描述的是在“多应用系统”中。

我好像明白了一些，又感觉更糊涂了，SOA感觉就象一个大杂烩，网罗了很多概念在里面，然后作为架构被公布。或许对于我这种笨技术人员，只有将SOA的一个开发工具和一个完整实现丢在我面前，我才能真正明白那是个什么东西。也或许丢了一个SOA的完整实现在我面前，我能明白它的工作流程，但还是不知道原来这就是SOA。呵呵，我好像经常碰到这样的事情。

个人觉得，经过这些年的IT建设，在企业应用的市场上已经存在了很多的“玩家”，IBM、SUN、HP、ORACLE、BEA、SAP等等，他们在各个行业，尤其是电信，金融建设了大量的应用，而这些应用基本上是一步步的建设的，基本上没有考虑别的玩家和别的应用，现在这些建设得差不多了，是时候将这些系统集成起来，于是Workflow，BPM开始又热起来，为了更好的定义集成，SOA也就应运而生了。

每个业务功能封装为一个Service，无论这些Service是在一个进程，还是多个进程，还是存在于internet上，都可以是表述为一个Service，用一个总控制器来指挥这些Service，按照Service执行的顺序不同，就可以组装更多的业务功能出来。

就象音乐一样，音符是一个个的基本单元，一个曲子就是音符的组装，每首曲子总是那些基本的音符组成，但是能够表达不同的意思。

Servie就好像音符了，曲子就是业务流程了，那么对于BEA来说，他的Workshop就是提供给大家的作曲工具了。

这个和面向组件的概念，总是觉得似曾相识。

icewarmed, 你讲得很有意思. 我觉得你的音乐的比喻很有意思.

不知道 workflow和 SOA 是会是什么关系, 互补, 还是 SOA 已经综合 workflow ?

SOA 是写 乐谱, workflow 也是写乐谱, 这两只手怎么合作?

我的理解，soa是对乐谱中各元素以及乐谱的写法上的一种规定。而流程则是在符合谱曲规范的前提下串接这些元素形成的曲子。流程引擎则是那架钢琴。

我觉得差不多是这个意思。
SOA可以认为类似OO的一种方法，使用这种方法来设计系统，各种系统就有更好的开放性。
更进一步，可以如charon所说，SOA规定出Service定义的方法。这样无论是什么系统，都一统化了，就更有利于Workflow的应用了

SOA思想中并没有提出“流程引擎”，并且我认为SOA只是一种思想，它不可能提出特别贴近技术的概念。

遵循SOA思想的SCA框架就是实实在在技术规范了，目前版本是0.96。在SCA中也没有提出所谓的“流程引擎”，在SCA中Service和Service之间的Reference也只是指明服务之间的引用关系；SCA中的Wire也还是指明Reference和Service(ExternalService)之间的引用关系当然，也就是说，SCA规范中没有说需要作到实现引擎去驱动服务来构建Business Process，SCA规范中重要的就是对服务的管理。

另外，在SCA中扩展的Implemention中是有BEPL Client Implemention的，这可能就是“流程引擎”的实现吧

认同“soa解决的是跨应用系统业务流程的问题，以及业务流程变化时应用系统的变化的问题”
不知老大是否看过m$ .net 3.0的介绍，在年底就要release啦，其中就有解决这两个问题的方案。

m$等不住啦，中国政府对一个统一标准的workflow的渴望非常迫切。
m$ .net 3.0中有一个不错的wf：
你可以很快的做一个演示demo(console)
也可以做一个系统中做一个轻量级的应用
也可以做一个workflow services center，来统一管理

还提供了一个规则引擎库，不同系统之间已经业务流程之间你可以用wcf来沟通，wcf还可以与目前已有的系统中的ws，wse，.net remoting，msmq等方便地沟通。