在Eclipse->Help->Install new software
http://dist.springsource.com/release/TOOLS/update/3.9.4.RELEASE/e4.7/
SOA设计与应用
包包（人名）所在的Group从事的是为欧美航空公司量身打造客机管控平台的项目， 基于多方面考虑，整个Group采用了SOA的架构。他们没有像IBM那样设计一整套企业级服务总线，而是针对具体业务具体实现，来一个需求就暴露一个接口方法。其实，说白了，就是用JavaBean封装企业逻辑，然后通过WebSevice的方式来暴露，只是.NET没有JavaBean，而是用WF工作流来代替。
作为开发者，在拿到UseCase后，只要定制一下Request和Response消息中的实体，然后在类图设计器中把契约、方法以及参数（Request）、返回值（Response）摆放并连接正确，右键点击“生成代码”菜单，就会基于SOA架构自动生成6个project。
SOA主要技术和标准，根据技术标准在SOA中的角色功能，将其分为三大类：服务层次上的信息交互规范、基础通信标准规范、元数据标准规范。根据各种标准规范在SOA 体系中的角色功能，可以将 SOA 协议栈分为 7 层，如图1所示。从底向上，包括传输层、消息层、描述层、管理层、服务组合层、表示层及服务发现注册层，其中除了ebXML和电子商务相关的技术标准（如资源注册的ebRS、消息表示ebMS、外部服务资源编排的WS-CDL等）外，大多数在国内已经得到了相当的应用，如东方通科技的应用集成产品TongIntegrator和应用服务器TongWeb，都支持部分Web服务的相关技术标准，如传输层的SOAP、RMI、SMTP，消息层的SOAP、JMS以及描述层的WSDL协议等。
1）W3C 组织提出的标准的Web服务描述语言WSDL，它从句法层面对Web服务的功能进行描述，包括4个不同的粒度：数据类型（Data type）、消息（Message）、方法（Operation）和访问端口（PortType）。这只是提供了Web服务的接口描述，对服务的行为约束和属性描述缺乏进一步的支持。
2）OWL-S是语义Web服务标记语言的标准，它比WSDL更能向用户提供可理解的服务资源的描述形式，提高服务选取与推荐的准确性。语义Web服务的主要方法是利用Ontology来描述Web服务，然后通过这些带有语义信息的描述实现Web服务来实现服务的自动发现，调用和组合。语义Web和Web 服务是语义Web服务的两大支撑技术。OWL-S是连接两大技术的桥梁，目前对语义Web服务标记语言研究最重要的组织就是DARPA组织，其研究组 OWL Services Coalition提出了语义Web服务标记语言OWL-S（原DAML-S）。
3）XML Web服务和ebXML都使用SOAP 作为消息传输技术，但是XML Web服务服务定义了松散耦合的协议堆栈，该堆栈由可靠传输 (WS-Reliability) 和 安全 (WS-Security) 的各个规范组成，而ebXML将所有这些功能都融入到自己的消息传递标准和ebMS中，从而使用混合技术。
XML Web服务分别使用WSDL和UDDI标准，UDDI注册机制是基于目录的体系结构，其注册内容包括技术模型和业务模型，本身可扩展但目前其注册的内容和描述还不够丰富和完整。
而 ebXML将服务描述和发现机制对应两个标准，一是注册信息模型ebRIM，二是注册服务规范ebRS。ebXML注册机制要比UDDI丰富和完善的多，它的注册机制用途广泛，可以表示范围广泛的数据对象，包括 xml 模式、业务流程描述、ebXML Core Component、UML模型、一般贸易合作伙伴信息及软件组件。
4）SCA（Service Component Architecture），即服务组件架构，提供了一种编程模型，可以支持基于SOA的应用程序实现。SCA是一种模型，可以支持实现服务组件的各种技术，连接服务组件的各种存取方法。对于组件，不仅包括不同的编程语言，也包括这些语言使用的框架和环境。对于存取方法SCA合成操作支持各种通讯、服务存取技术，如：WS、MQ、RPC。SCA规范包括了Assemble Model和Client Model两部分。前者约定了如何将异种组件（Java类，BPEL，Web Service）组装并发布成SOA服务，是SCA最大的特点和最核心的概念；后者则约定了如何在异种语言环境中调用SOA服务。通过这两部分的规范，就可以完全解决了服务从服务端到客户端的跨语言、跨环境的问题。
5）JBI 是Java商业集成（Java Business Integration）的简称。这个标准定义了一个标准的体系结构允许第三方的组件插入到标准的基础设施上，并且即使这些组件是有不同提供商提供的，它们也可以以一种可预见的和可靠的方式互操作。从高层次上看，JBI 定义了可以从可插入组件构建集成系统的体系结构，这一结构中组件的交互使用一种经过中介的消息交换机制，而这一消息交换模式是基于WSDL 2.0或WSDL 1.1的。
6）WS4BPEL，即Web服务业务流程执行语言，它是一种可执行语言，能够与各种促使业务流程自动化的软件系统相兼容。
7）WS-CDL，即Web Services Choreography Definition Language，Web服务编排定义语言，它定义为在多个交易伙伴之间建立形式化关系，它不要求所有被集成的端点（endpoints）都有Web服务基础设施。
8）JSR168 是java 规范要求，它为创建portlet建立标准的api，它是为实现porltet、基于java的门户服务器和其他web应用程序之间的互操作性而设计的。 JSR168的主要价值在于它被独立软件开发商（isv）所广泛采用。在采用JSR168之前，企业应用程序开发商不得不支持所有开发商门户的不同 portlet集，支持多个门户开发商不同的portlet集在类似业务信息、内容管理、检索和分析这样的领域中非常令人头疼。使用JST168规范，现在开发商只需要支持一种portlet集。
9）WSRP，即Web Services for Remote Portlets的缩写，它定义了如何利用基于 SOAP 的 Web 服务在门户应用程序中生成标记片断的规范。通过定义一组公共接口，WSRP 允许门户在它们的页面中显示远程运行的 portlet，而不需要门户开发人员进行任何编程。对于最终用户，这些 porlet 就和运行在他们本地的门户上一样，但是实际上这些 portlet 来自于远程运行的 portlet 容器，并且交互是通过SOAP 消息的交换来实现的。
包包对比SOA中技术和标准，发现应用于其项目中的一些问题。
1）虽然大多数SOA系统要求平台兼容，但实际应用中却发现做来做去竟然全都是.NET平台，而极少甚至是没有Java平台。这时候发现数组和集合的转来转去是白做了，性能受到很大影响。这种情况其实也是有解决方案的，就是先全都做成.NET平台的集合，然后哪些方法需要暴露给J2EE使用，再包一层面向数组的WebService。
2）写WebService的人可能和你不是一个Team的，他不可能修改他的project来满足你的额外要求，或者，这个WebService是用Java写的……没辙了么？还有最后一招，就是自己再写一层WebService，并添加这个异步文件，并在其中调用原有的WebService，然后Silverlight再调用自己写的这个WebService。
3）2中的例子，原先要部署一个Service，变成了要部署两个Service。就是说，要在ReleaseNotes里面添加这一笔配置信息。如果这个Service被部署在其他Server上，那么就要准备好几份ReleaseNotes。要知道，部属的事情不一定是开发这套code的人去做的，所以WebService的多少和出错的几率是成正比的。
4）SOA中部署的复杂，导致了一旦其中有一个环节出错，就摸不着头脑找不到是那一层的问题。于是要添加异常处理机制，把异常从底层到高层逐层往上冒。所以，对于一个Service方法，返回的不是成功执行后得到的string或int，而是一个object数组。第一个参数表示成功与否，如果是否，那么第二个参数就要传递捕获到的异常信息。