面向服务的架构标准领先技术不意味厂商锁定XML和Web服务正在作为面向服务的架构(SOA)的平台来出现，它既可用于企业内部通信，也可用于企业间通信。

作为第一个既支持SOA编写，也支持SOA 利用的Java集成开发环境(IDE)，WebLogic Workshop天生就带上了专有创新的印记。

从那时起，BEA通过多种机制，从开放标准到开放源代码，已经实现了对这些创新进行投资保护的承诺，使得开发人员可以充分利用BEA的尖端生产率和集成特性，而不必担心锁定在某一厂商。

下面，让我们一起来看看在Workshop中基于SOA的关键创新，以及在每种情况下是如何保护投资的。

什么是SOA?XML和Web服务是当今的热门技术，因为它们在实现面向服务的架构(SOA)上担当了重要的角色。

目前独立的、而且通常是相互孤立的应用程序，制约了业务服务的共享，SOA则正在解决这一问题。

通过给单个业务操作进行定义或在表层加上“服务访问点”，IT组织能够：•使IT资源与其业务功能更密切地结合在一起•通过以下方法的最佳组合和匹配，建立更加动态、更有效地利用成本的系统•购买和自建•自制和外包•更迅速地发布“组合”应用程序(想想“Web流(Web flows)”和“工作流(work flows)”)，提供统一的、面向任务的跨业务视图•通过更加细致的增量管理需求和变化，在应用程序生命周期上获得更高的灵活性•用提供“业务透明性”的基础架构替换不透明的、“黑盒子”系统更容易—这种基础架构根据流经应用程序的总体信息，提供实时的业务智能。

对象和组件已经成功地在应用内提供了重用性(应用程序的定义是：以单元形式开发和部署的代码)。

但是，SOA依赖的是在应用程序之间实现重用。

用SOA把不同的应用程序互连起来，这根本不是什么新东西—想想以前定义分布式的、应用间通信架构的一些努力(不用费力想什么新的首字母缩略词)：•同步的(面向RPC)：CICS分布式程序链接(DPL)、分布式计算环境(DCE)、分布式组件对象模型(DCOM)、公共对象请求代理体系结构(CORBA)IIOP、Java 远程方法调用(RMI)、关系数据库管理系统(RDBMS)存储过程，等等。

•异步的(面向消息的)：CICS临时数据队列(TDQ)、Tuxedo ATM、IBM MQSeries、Tibco Rendezvous、Microsoft消息队列(MSMQ)、Java消息服务(JMS)，等等。

是什么使得应用的集成如何困难呢(而且，由此推出，为什么我们作为一个行业，还必须要实现一个统一的SOA)?这是因为，应用程序是由不同的人们，在不同的地点建立的，而且根据不同的计划部署的。

任何方法，只要它依赖于多个应用程序共享一个公共的对象/数据模型(至少在某种程度上如先前所提及的)，就都要面对这个事实。

XML和Web服务的角色抽象和松散耦合，是多个独立应用程序成功共享基础架构的关键。

请考虑二个成功典型：SQL和HTML。

利用SQL和HTML，应用程序开发人员必须把内部的对象模型按照数据如何存储、如何搜索以及如何在屏幕上显示分别地拆解。

如果我们只是考虑单个应用的需求，那么这种选择通常不是优化的选择。

但是，如果跨业务应用程序之间的总体需求增加了，那么能够实现更高级别抽象的松散耦合就会证明它的价值。

XML是松散耦合应用程序间数据共享的理想方案，XML具有以下特性：•自解释的•独立于硬件、编程语言、容器等等•可以适应独立的变化/版本变化(对于扩展和应用程序变化，不是很脆弱)•是“最小公分母”(啰嗦点说，是CPU密集的，等等，就像HTML)XML是针对HTML的，就像Web服务栈是针对HTTP/S的。

WS-*(具有最广泛行业支持的Web服务规范集合)定义了在应用程序之间移动XML的“企业服务质量”。

尽管由于篇幅有限，无法在这里介绍每一个WS-*技术，但是还是能够介绍：•以前在分布式计算中所有的服务质量标准，或者已经存在于WS-*栈里，或者已经在近期的发布计划当中(以及标准化当中)。

•WS-*在一个单一的、统一的框架里，为同步操作(通常用于查询)和异步操作(通常用于业务事务处理)提供了通信基础架构。

•WS-*协议族是第一个可扩展以满足企业内部企业应用集成(EAI)需求，甚至企业间B2B集成需求的系统。

以前的技术，从未如此接近地实现过“密切合作”(指的是，可以使用企业自己的所有业务系统，合作伙伴的业务系统，甚至合作伙伴的合作伙伴的系统，等等)所要求的大量关键需求。

•WS-*协议族允许IT组织利用可移植的和可互操作的行业标准来降低成本，并避免锁定在某一厂商。

WebLogic Workshop在2002年WebLogic首次发布时，WebLogic Workshop 成为通过XML和Web服务关注编写SOA的第一个Java IDE。

随着BEA WebLogic 8.1在2003年的发布，我们已经把WebLogic Workshop从1.0版的Web服务工具转变成了一个独一无二的包罗万象的开发环境，可以编写、利用以及编排基于SOA 的应用程序。

使用Workshop，就可以建立任何一种面向SOA的代码，其中包括纯粹的Web应用程序、J2EE程序、门户、业务流程自动化、XML聚合/转换、消息代理等等。

在发布第一个用于SOA的IDE(在Workshop 8.1之前，集成的技术发展水平就是一堆互不集成的工作大杂烩)的时候，BEA确实引入了多个专有的创新。

毕竟，专有和创新有着与生俱来的联系。

有着大量先例说明，标准的内容由于采用、认可专有创新，而不是自行创新，从而变得更好：TCP/IP、SQL、Web、Java、以及XML/Web服务，都是沿着这条路发展的。

回想 WebLogic的第一版(回到1996年，对于它是否为业界第一台Web应用服务器仍有争议)，其中包括了大量用于Web页面呈现、数据库访问、事件处理、服务器端组件等方面的专用创新。

WebLogic优于其他专用技术的同行(著名的例外是 IBM 的 WebSphere)之处在于，WebLogic很早就积极地投入了API的标准化工作委员会(servlets/JavaServer Pages [JSP]、Java数据库连接[JDBC]、JMS、企业级JavaBeans[EJB]，等等)。

对于我们为SOA在基于 Workshop创新所做的投资，BEA一直在大力保护。

我们有多种手段确保对投资的保护：协议：•BEA/Microsoft/IBM WS-*协作—WS-*协议族开始主要由这三家厂商制定(在标准化之前)•WS-*的标准化—W3C委员会和OASIS(结构化信息标准推进组织)•WS-*的验证和分析—Web服务互操作性组织(WS-I).编程模型：•BEA和IBM进行的Java协作—在2003年发布，这个协作是在BEA/IBM/Microsoft Web服务协作之上构建的。

它的重点在于推进服务器端Java API的标准化，特别是SOA方面。

•Java社区项目(JCP)•欧洲计算机制造商协会(ECMA)(例如，XScript)•W3C(例如，XQuery)•OASIS(例如，业务流程执行语言[BPEL])•Workshop产品的可移植性—如果Workshop生成了符合J2EE标准的应用程序，那么这个产品可以不加修改地运行在其他任何符合J2EE规范的容器里•开源软件(OSS)—映射到J2EE的开放源代码运行时基础架构，因此支持到WebLogic之外的容器的移植性。

Workshop投资保护的十大措施实际上，对于在WebLogic Workshop 8.1 IDE中的每项创新，BEA都会为客户或合作伙伴提供或发布一项长期的投资保护方法。

下面，我们一起来看看Workshop的10大创新，以及如何保护在用Workshop开发的应用程序中的投资。

(10)元数据和JSR-175：Workshop大量采用JavaDoc注解来获取应用程序的元数据—元数据是指发给容器的声明指令，指令里封装了那些经常使用但是通常很复杂，开发人员不愿意重复编写代码的那部分活动。

像 Workshop 这样的智能工具为编写和更新这类元数据提供了结构化的支持(例如属性表)。

通过把这些元数据以内嵌方式包含在应用程序的代码里，开发人员编程时需要的代码更少。

(XML部署描述符仍然由相应的工具生成)。

至少，部分是因为这个方法的流行，Sun和Java社区的其他成员已经决定直接在Java语言内部采用大量的元数据(JSR-175，它包含在J2SE 1.5版里)。

现有的Workshop产品会用 WebLogic即将发布的版本自动升级为JSR-175语法。

(9)BPEL、BPELJ 和JPD：BPEL规范最初是由BEA、IBM 和 Microsoft制定的—这是一套最好的知识产权组合，包括来自Microsoft的XLANG、IBM的WSFL以及BEA的Process Definition for Java (用于Java的流程定义，JPD)。

从那以后，BPEL已经转变交给OASIS进行标准化。

BPEL是基于XML的编程语言，本身也是用XML编写的，所以它是与平台无关的(它可以运行在Java、.NET等平台上)。

BPEL既可用来定义(编写)Web 服务，也可以编排(编写使用Web服务的工作流)Web服务。

所有在BPEL中的数据操纵工作都是用XML和Web服务完成的。

例如，条件用XPath编写。

消息的发送和接收用WSDL端口类型，等等。

在另一方面，BPELJ(用于Java的BPEL)定义了如何把BPEL和Java混合起来(混合的方式与JSP把HTML和Java混合的方式不同)。

使用BPELJ，条件和数据操纵可以通过Java代码注解的代码段完成。

这样就允许传统的企业计算，例如通过JDBC的数据库访问，能够与基于BPELJ的业务流程无缝地集成在一起。

BPELJ允许Java/J2EE组件，例如JavaBeans，可以用与Web服务编排一样的方式进行编排。

BPELJ的技术白皮书由BEA和IBM在2004年3月联合发布，而且已经通过JSR-207变成Java标准化的主题(BEA是这一规范的领导)。

BEA目前正设法在WebLogic的下一个主要发行版中实现BPELJ，此外还将提供把在Workshop 8.1中定义的工作流(BPELJ的前身—Java的流程定义)自动移植到BPELJ中。

在WebLogic Integration 8.1里，我们独家整合了卓越的业务流程图形化编辑工具，它具备了“get out of jail free card”的能力，可以使标准的Java/J2EE做更困难的编程工作—做这些工作时，完全不用离开Workshop 的统一开发环境。