SOA到底是什么?
SOA(Service-Oriented Architecture)的定义是面向服务的架构,就是说将软件按照功能设计成一个个服务,这些服务用标准的方式定义接口、并通过标准的协议进行调用。SOA所定义的接口和调用方式是独立于编程语言和运行平台的,广义上讲SOA可以基于不同的底层技术实现,比如CORBA和Web Services。但CORBA由于过于复杂和臃肿已很少使用,所以目前所说的SOA绝大多数是基于Web Services技术实现。在Web Services的实现方式下,SOA服务的接口用XML进行定义。
在SOA架构下,软件开发从业务流程分析开始,使用组件化业务建模的方法识别和分析各种业务模型,将各种实践融入其中,在这个基础上建立用例,用例直接产生BPEL,这些BPEL则可以被融入一个服务整合框架中,其描述了各种服务的信息,从而把ESB上的各个模块统一起来,形成一个巨大的服务仓。
这样,SOA甚至是所有软件人员的一个梦:将中间层再进行抽离,在中间层作一个跨技术架构的元数据和业务逻辑,使之成为跨技术架构的、可长期继承、并不断积累的企业业务库和最宝贵的信息资产,也就是面向服务的组件库,而且这个服务组件库也可以被其它企业复用,且不依赖于任何一种技术架构。夸张一点说,如果所有软件企业都使用SOA架构,那么世界软件业将会发生彻底的改变。显然,这样一个框架不是一种产品,也不仅仅是一种技术,而是一种解决问题的方法论。
SOA可能应用的两个场景及现有问题
那么,SOA要解决的问题是什么?我认为,从技术本质上讲,SOA可能应用于两个场景:第一种是业务互通互联;第二种是封闭交易系统,即将元数据和业务逻辑抽离,形成可复用。举个例子,在第一种场景中,当不同企业之间的业务需要相互调用,这时就可能采用SOA技术;在第二种场景中,在企业内部需要将系统进行迁移时,利用SOA技术定义的原有数据和业务流程,可以很快完成。
无疑,SOA是一个伟大的思想,它试图定义一个大家(各种软件厂商)都"认"的、都"遵循"的法则,大家都使用这样的方法来进行互联互通,从而实现无界限的联通,以及服务组件库的继承和复用,解放无效和重复劳动。打一个不那么恰当的比喻,就像人类的语言一样。SOA或许就像《圣经》中那个著名的"通天塔"的故事:人们用同一种语言交流产生的威力是如此之大,以至于他们在巴比伦几乎要修成一个"通天塔",直达上帝所在的天庭。
但是,在SOA应用的两个场景中,现存的问题同样也是明显的:
第一种场景:业务互联互通,就是应用系统互联。业务互联,与其说是技术问题,不如讲是业务问题,例如ERP、CRM的异步整合,数据层面整合都不能很好将两个系统整合,SOA仅仅是一种实现工具之一,整合效果并不会好不到那里去。我们可以说,在没有其他选项之前,SOA是一种最"不坏"的方式,但它并不能解决所有的问题,实际上EAI的牵涉面很广,而我们知道,有些问题并不是单纯靠技术就能解决的。
第二种场景:封闭交易系统,缺点是性能慢,而且基于Web Services的交易没有形成明确的规范。使用XML作信息交互比较慢是大家都承认的,性能问题将对SOA的发展造在一定的阻力。同时SOA规范本身没有完善,比如Transaction规范还在不断完善,而且Web Service多年来收效甚微。总的来说,SOA现在还处在一个发展阶段,很多标准还在制定,不同厂商间还存在不兼容的现象,因此SOA还不能说已经是一个成熟的技术,还需要时间的检验,还在"进行中"。当然,金蝶中间件作为JCP组织成员,也会推动SOA规范在J2EE平台上的实现。
SOA(Service-Oriented Architecture)的定义是面向服务的架构,就是说将软件按照功能设计成一个个服务,这些服务用标准的方式定义接口、并通过标准的协议进行调用。SOA所定义的接口和调用方式是独立于编程语言和运行平台的,广义上讲SOA可以基于不同的底层技术实现,比如CORBA和Web Services。但CORBA由于过于复杂和臃肿已很少使用,所以目前所说的SOA绝大多数是基于Web Services技术实现。在Web Services的实现方式下,SOA服务的接口用XML进行定义。
在SOA架构下,软件开发从业务流程分析开始,使用组件化业务建模的方法识别和分析各种业务模型,将各种实践融入其中,在这个基础上建立用例,用例直接产生BPEL,这些BPEL则可以被融入一个服务整合框架中,其描述了各种服务的信息,从而把ESB上的各个模块统一起来,形成一个巨大的服务仓。
这样,SOA甚至是所有软件人员的一个梦:将中间层再进行抽离,在中间层作一个跨技术架构的元数据和业务逻辑,使之成为跨技术架构的、可长期继承、并不断积累的企业业务库和最宝贵的信息资产,也就是面向服务的组件库,而且这个服务组件库也可以被其它企业复用,且不依赖于任何一种技术架构。夸张一点说,如果所有软件企业都使用SOA架构,那么世界软件业将会发生彻底的改变。显然,这样一个框架不是一种产品,也不仅仅是一种技术,而是一种解决问题的方法论。
SOA可能应用的两个场景及现有问题
那么,SOA要解决的问题是什么?我认为,从技术本质上讲,SOA可能应用于两个场景:第一种是业务互通互联;第二种是封闭交易系统,即将元数据和业务逻辑抽离,形成可复用。举个例子,在第一种场景中,当不同企业之间的业务需要相互调用,这时就可能采用SOA技术;在第二种场景中,在企业内部需要将系统进行迁移时,利用SOA技术定义的原有数据和业务流程,可以很快完成。
无疑,SOA是一个伟大的思想,它试图定义一个大家(各种软件厂商)都"认"的、都"遵循"的法则,大家都使用这样的方法来进行互联互通,从而实现无界限的联通,以及服务组件库的继承和复用,解放无效和重复劳动。打一个不那么恰当的比喻,就像人类的语言一样。SOA或许就像《圣经》中那个著名的"通天塔"的故事:人们用同一种语言交流产生的威力是如此之大,以至于他们在巴比伦几乎要修成一个"通天塔",直达上帝所在的天庭。
但是,在SOA应用的两个场景中,现存的问题同样也是明显的:
第一种场景:业务互联互通,就是应用系统互联。业务互联,与其说是技术问题,不如讲是业务问题,例如ERP、CRM的异步整合,数据层面整合都不能很好将两个系统整合,SOA仅仅是一种实现工具之一,整合效果并不会好不到那里去。我们可以说,在没有其他选项之前,SOA是一种最"不坏"的方式,但它并不能解决所有的问题,实际上EAI的牵涉面很广,而我们知道,有些问题并不是单纯靠技术就能解决的。
第二种场景:封闭交易系统,缺点是性能慢,而且基于Web Services的交易没有形成明确的规范。使用XML作信息交互比较慢是大家都承认的,性能问题将对SOA的发展造在一定的阻力。同时SOA规范本身没有完善,比如Transaction规范还在不断完善,而且Web Service多年来收效甚微。总的来说,SOA现在还处在一个发展阶段,很多标准还在制定,不同厂商间还存在不兼容的现象,因此SOA还不能说已经是一个成熟的技术,还需要时间的检验,还在"进行中"。当然,金蝶中间件作为JCP组织成员,也会推动SOA规范在J2EE平台上的实现。