SOA设计与应用
摘 要：SOA思想的核心根据定义可以拆分为两个重要的内容，一个是根据业务建模和架构设计过程找寻到粗粒度的可重用的服务；其二是这些服务可以组合，可以组装和编排以满意业务流程的需求。前者重点对应的是ESB服务总线，而后者重点对应的BPM和BPEL相关业务能力。本文简要说明SOA简要技术和标准以及通过举例简要介绍SOA在开发中的设计和应用。
关键词：SOA；服务
SOA design and Application
Absrtact: according to the definition, the core of SOA can be divided into two important contents: one is to find coarse-grained reusable services according to business modeling and architecture design process; the other is that these services can be combined, assembled and arranged to meet the needs of business processes. The former focuses on ESB service bus, while the latter focuses on BPM and BPEL related business capabilities. This paper briefly describes the SOA technology and standards, as well as the design and application of SOA in development through examples.
Keywords: SOA; service
0引言
面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构件在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
1 SOA主要技术和标准
根据技术标准在 SOA 中的角色功能，将其分为三大类：服务层次上的信息交互规范、基础通信标准规范、元数据标准规范。根据各种标准规范在SOA 体系中的角色功能，可以将 SOA 协议栈分为 7 层，如图1所示。从底向上，包括传输层、消息层、描述层、管理层、服务组合层、表示层及服务发现注册层，其中除了ebXML和电子商务相关的技术标准（如资源注册的ebRS、消息表示ebMS、外部服务资源编排的WS-CDL等）外，大多数在国内已经得到了相当的应用，如东方通科技的应用集成产品TongIntegrator和应用服务器TongWeb，都支持部分Web服务的相关技术标准，如传输层的SOAP、RMI、SMTP，消息层的SOAP、JMS以及描述层的WSDL协议等。
1.1 WSDL与OWL-S
W3C 组织提出的标准的Web服务描述语言WSDL，它从句法层面对Web服务的功能进行描述，包括4个不同的粒度：数据类型（Data type）、消息（Message）、方法（Operation）和访问端口（PortType）。这只是提供了Web服务的接口描述，对服务的行为约束和属性描述缺乏进一步的支持。
OWL-S是语义Web服务标记语言的标准，它比WSDL更能向用户提供可理解的服务资源的描述形式，提高服务选取与推荐的准确性。语义Web服务的主要方法是利用Ontology来描述Web服务，然后通过这些带有语义信息的描述实现Web服务来实现服务的自动发现，调用和组合。语义Web和Web 服务是语义Web服务的两大支撑技术。OWL-S是连接两大技术的桥梁，目前对语义Web服务标记语言研究最重要的组织就是DARPA组织，其研究组 OWL Services Coalition提出了语义Web服务标记语言OWL-S（原DAML-S）。
语义Web服务及相关标准（OWL-S等）对于Web及Web服务应用的深化具有重要意义，同时也具有很好的发展前景。目前OWL-S等语义Web服务相关标准的应用还主要是研究性、示范性的。
1.2 XML Web服务与ebXML
SOA中的服务，当前多以Web服务技术实现和解释，传统的Web服务及其相关协议，都是以XML为基础进行扩展的，因此我们把它称为XML Web服务。其实，在XML Web服务之前，ebXML已经出现，鉴于此标准复杂而完善，因此它在传统的电子商务领域，用处较广。就具体的内容和定位而言，两者有一定的区别。
1) 消息传输技术
XML Web服务和ebXML都使用SOAP 作为消息传输技术，但是XML Web服务服务定义了松散耦合的协议堆栈，该堆栈由可靠传输 (WS-Reliability) 和 安全 (WS-Security) 的各个规范组成，而ebXML将所有这些功能都融入到自己的消息传递标准和ebMS中，从而使用混合技术。
2) 服务描述和发现
XML Web服务分别使用WSDL和UDDI标准，UDDI注册机制是基于目录的体系结构，其注册内容包括技术模型和业务模型，本身可扩展但目前其注册的内容和描述还不够丰富和完整。
而 ebXML将服务描述和发现机制对应两个标准，一是注册信息模型ebRIM，二是注册服务规范ebRS。ebXML注册机制要比UDDI丰富和完善的多，它的注册机制用途广泛，可以表示范围广泛的数据对象，包括 xml 模式、业务流程描述、ebXML Core Component、UML模型、一般贸易合作伙伴信息及软件组件。为了支持如此多样的数据，使用一个定义良好的信息模型而不是目录，将ebXML注册设计得更像一个数据库。
3) 业务流程协作
基于Web服务的业务流程协作和服务编排，有WS4BPEL、WS-CDL、基于XML的工作流XPDL等，这些基于XML和Web服务的标准都彼此相对独立，甚至是不同的组织制定。
ebXML标准也包含业务流程协作的标准，如ebCPPA、ebBPPS。
总之，ebXML是一个独立的规范集，具有内部一致性，而且不依赖于新兴标准和规范，它的用途主要定位在有特殊要求的电子商务方面，目前，ebXML已被国家确定为国标推荐，但其应用看起来还要有一段路要走。而XML Web服务由于其内容相对简单，技术实现容易，对应的一系列协议栈相对松耦合，因此其在构建SOA的应用中使用越来越广泛。
1.3 SCA与JBI
SCA（Service Component Architecture），即服务组件架构，提供了一种编程模型，可以支持基于SOA的应用程序实现。SCA是一种模型，可以支持实现服务组件的各种技术，连接服务组件的各种存取方法。对于组件，不仅包括不同的编程语言，也包括这些语言使用的框架和环境。对于存取方法SCA合成操作支持各种通讯、服务存取技术，如：WS、MQ、RPC。SCA规范包括了Assemble Model和Client Model两部分。前者约定了如何将异种组件（Java类，BPEL，Web Service）组装并发布成SOA服务，是SCA最大的特点和最核心的概念；后者则约定了如何在异种语言环境中调用SOA服务。通过这两部分的规范，就可以完全解决了服务从服务端到客户端的跨语言、跨环境的问题。
JBI 是Java商业集成（Java Business Integration）的简称。JBI的制订者们认为传统的EAI和B2B解决方案使用非标准的技术，这使得用户往往被锁定到特定的方案和产品提供商上，与此同时，没有任何一个单独的提供商可以覆盖EAI和B2B领域的所有问题。因此他们提出这个标准以期解决这个问题。这个标准定义了一个标准的体系结构允许第三方的组件插入到标准的基础设施上，并且即使这些组件是有不同提供商提供的，它们也可以以一种可预见的和可靠的方式互操作。从高层次上看，JBI 定义了可以从可插入组件构建集成系统的体系结构，这一结构中组件的交互使用一种经过中介的消息交换机制，而这一消息交换模式是基于WSDL 2.0或WSDL 1.1的。
1.4 WS4BPEL与WS-CDL
WS4BPEL，即Web服务业务流程执行语言，它是一种可执行语言，能够与各种促使业务流程自动化的软件系统相兼容。Web服务编制，通过说明性的方式（而不是编程的方式）表达了进行Web服务合成的需求。此标准主要用于组织内部的业务流程管理及服务编排，目前越来越多的BPM产品基于此规范实现。
WS-CDL，即Web Services Choreography Definition Language，Web服务编排定义语言，它定义为在多个交易伙伴之间建立形式化关系，它不要求所有被集成的端点（endpoints）都有Web服务基础设施。此规范更多地用于组织之外的服务与流程编排，目前在国内还不常用。
另外，XPDL也可以用于服务的编排和组合，但它主要用于传统的工作流定义，目前它也是BPM产品实现的重要技术标准。
1.5 JSR168与WSRP
JSR168 是java 规范要求，它为创建portlet建立标准的api，它是为实现porltet、基于java的门户服务器和其他web应用程序之间的互操作性而设计的。 JSR168的主要价值在于它被独立软件开发商（isv）所广泛采用。在采用JSR168之前，企业应用程序开发商不得不支持所有开发商门户的不同 portlet集，支持多个门户开发商不同的portlet集在类似业务信息、内容管理、检索和分析这样的领域中非常令人头疼。使用JST168规范，现在开发商只需要支持一种portlet集。目前，JSR168在基于Java技术开发Portal产品上，得到了广泛的支持，但也仅限于Java技术。
WSRP，即Web Services for Remote Portlets的缩写，它定义了如何利用基于 SOAP 的 Web 服务在门户应用程序中生成标记片断的规范。通过定义一组公共接口，WSRP 允许门户在它们的页面中显示远程运行的 portlet，而不需要门户开发人员进行任何编程。对于最终用户，这些 porlet 就和运行在他们本地的门户上一样，但是实际上这些 portlet 来自于远程运行的 portlet 容器，并且交互是通过 SOAP 消息的交换来实现的。在面向服务的体系结构中利用 WSRP 将是一个强大的组合，从而使面向呈现的 portlet 应用程序可以被发现并重用而不用任何额外的开发和部署活动。WSRP是由OASIS组织制定，目前已得到多数厂商的支持，鉴于它基于Web服务标准，而且技术相对独立，因此随着此标准的逐渐完善，相信越来越多的Portal生产企业会支持此标准。
2 SOA设计应用
包包（人名）所在的Group从事的是为欧美航空公司量身打造客机管控平台的项目， 基于多方面考虑，整个Group采用了SOA的架构。他们没有像IBM那样设计一整套企业级服务总线，而是针对具体业务具体实现，来一个需求就暴露一个接口方法。其实，说白了，就是用JavaBean封装企业逻辑，然后通过WebSevice的方式来暴露，只是.NET没有JavaBean，而是用WF工作流来代替。
2.1SOA在项目中实现概述
作为开发者，在拿到UseCase后，只要定制一下Request和Response消息中的实体，然后在类图设计器中把契约、方法以及参数（Request）、返回值（Response）摆放并连接正确，右键点击“生成代码”菜单，就会基于SOA架构自动生成6个project。
在SOA中，遵循为每个方法定义一对Request和Response的原则（而不是一个契约的所有方法共享同一套Request和Response）。只有这样，在传来传去的Message中，才不会有太多的信息冗余。比如说，有2个方法，分别是：string GetUserName(string userId)和UserInfo GetUserInfo(string userId)，如果2个方法的Response定义在一起，那么不管调用那个方法，每次返回的Response，不是多带了一个string类型，就是多带了一个UseInfo类型，相应的消息（也就是xml文件）体积就会变大。
Java程序是不认识.NET WebServce中的List<T>的，它只认识数组，于是为了遵守SOA的跨平台兼容性，他们在Schema中只能定义数组，即使是coding，也要刻意对集合执行ToArray方法。于是，很多人都会抱怨，在调用WebService的一方，仍然是用.NET写的，于是，他们又要把接收到的数组费老大劲转换回List<T>。——这也是包包认为小型项目没必要用SOA架构的一个原因。
2.2 构建SOA在其项目中应用遇到的问题
2.2.1 SOA系统要求平台兼容
虽然大多数SOA系统要求平台兼容，但实际应用中却发现做来做去竟然全都是.NET平台，而极少甚至是没有Java平台。这时候发现数组和集合的转来转去是白做了，性能受到很大影响。这种情况其实也是有解决方案的，就是先全都做成.NET平台的集合，然后哪些方法需要暴露给J2EE使用，再包一层面向数组的WebService。
2.2.2 WebService语言差异
写WebService的人可能和你不是一个Team的，他不可能修改他的project来满足你的额外要求，或者，这个WebService是用Java写的……没辙了么？还有最后一招，就是自己再写一层WebService，并添加这个异步文件，并在其中调用原有的WebService，然后Silverlight再调用自己写的这个WebService。
2.2.3 SOA部署复杂
2.2.2中的例子，原先要部署一个Service，变成了要部署两个Service。就是说，要在ReleaseNotes里面添加这一笔配置信息。如果这个Service被部署在其他Server上，那么就要准备好几份ReleaseNotes。要知道，部属的事情不一定是开发这套code的人去做的，所以WebService的多少和出错的几率是成正比的。
SOA中部署的复杂，导致了一旦其中有一个环节出错，就摸不着头脑找不到是那一层的问题。于是要添加异常处理机制，把异常从底层到高层逐层往上冒。所以，对于一个Service方法，返回的不是成功执行后得到的string或int，而是一个object数组。第一个参数表示成功与否，如果是否，那么第二个参数就要传递捕获到的异常信息。
3 总结
如果不是大规模的项目，比如说开发人数（用户人数倒在其次）、需求变更（这个倒是用户关心的）、跨平台（比如说.NET的WebService如何给Java程序使用），应用SOA，有点杀鸡用牛刀的感觉。因为SOA中有太多的地方需要你去关注，不是说加了几个WebService把对数据库的访问放到WebMethod中就是SOA了。 SOA是一种企业级架构，当你的项目复杂到一定规模，当所需的人力到达一定规模，自然而然要使用SOA的架构。
参考文献
https://www.cnblogs.com/Jax/archive/2009/09/15/1567059.html
[2] SOA实现技术和标准.
https://blog.51cto.com/jianghui/160728
[3] 谈基于SOA的应用系统设计和开发.
http://blog.sina.com.cn/s/blog_493a84550101gswn.html