面向服务的架构标准
为什么领先的技术并不意味着厂商锁定
作者：Scott Dietzen BEA系统有限公司CTO
XML和Web服务正在作为面向服务架构（SOA）的平台来出现，它既可用于企业内部通信，也可用于企业间通信。作为第一个既支持SOA编写，也支持SOA利用的Java集成开发环境（IDE），WebLogic Workshop天生就带上了专有创新的印记。从那时起，BEA通过多种机制，从开放标准到开放源代码，已经实现了对这些创新进行投资保护的承诺，使得开发人员可以充分利用BEA的领先生产力和集成特性，而不必担心锁定在某一厂商。下面，让我们一起来看看在Workshop中基于SOA的重覆创新，以及在每种情况下是如何保护投资的。
什么是SOA?
XML和Web服务是当今的热门技术，因为它们在实现面向服务的架构（SOA）上担当了重要的角色。目前独立的、而且通常是相互孤立的应用程序，制约了业务服务的共享，SOA则正在解决这一问题。通过给单个业务操作进行定义或在表层加上“服务访问点”，IT组织能够实现以下目标：
q 使IT资源与其业务功能更密切地结合在一起。
q 通过以下方法的最佳组合和匹配，建立更加动态、更有效地利用成本的系统。
q 购买和自建
q 自制和外包
q 更迅速地发布“组合”应用程序（想想“Web流［Web flow］”和“工作流［work flow］”），提供统一的、面向任务的跨业务视图。
q 通过更加细致的增量管理需求和变化，在应用程序生命周期上获得更高的灵活性。
q 用提供“业务透明性”的基础架构替换不透明的、“黑盒子”系统更容易——这种基础架构根据流经应用程序的总体信息，提供实时的业务智能。
对象和组件已经成功地在应用内提供了重用性（应用程序的定义是：以单元形式开发和部署的代码）。但是，SOA依赖的是在应用程序之间实现重用。用SOA把不同的应用程序互连起来，这根本不是什么新东西——想想以前定义分布式的、应用间通信架构的一些努力（不用费力想什么新的首字母缩略词）：
q 同步的（面向RPC）：CICS分布式程序链接（DPL）、分布式计算环境（DCE）、分布式组件对象模型（DCOM）、公共对象请求代理体系结构（CORBA）IIOP、Java远程方法调用（RMI）、关系数据库管理系统（RDBMS）存储过程，等等。
q 异步的（面向消息的）：CICS临时数据队列（TDQ）、Tuxedo ATM、IBM MQSeries、Tibco Rendezvous、Microsoft消息队列（MSMQ）、Java消息服务（JMS），等等。
是什么使得应用的集成如此困难呢？（而且，由此推出，为什么我们作为一个行业，还必须要实现一个统一的SOA）这是因为，应用程序是由不同的开发者，在不同的地点建立的，而且是根据不同的计划部署的。任何方法，只要它依赖于多个应用程序共享一个公共的对象/数据模型（至少在某种程度上如先前所提及的），就都要面对这个事实。
XML和Web服务的角色
抽象和松散耦合，是多个独立应用程序成功共享基础架构的关键。请考虑两个成功典型：SQL和HTML。利用SQL和HTML，应用程序开发人员必须把内部的对象模型按照数据如何存储、如何搜索以及如何在屏幕上显示分别地拆解。如果我们只是考虑单个应用的需求，那么这种选择通常不是最好的选择。但是，如果跨业务应用程序之间的总体需求增加了，那么能够实现更高级别抽象的松散耦合就会证明它的价值。
XML是松散耦合应用程序间数据共享的理想方案，XML具有以下特性：
q 自解释的
q 独立于硬件、编程语言、容器等等
q 可以适应独立的变化/版本变化（对于扩展和应用程序变化，不是很脆弱）
q 是“最小公分母”（具体地说，是CPU密集的，等等，就像HTML）
XML是针对HTML的，就像Web服务栈是针对HTTP/S的。WS-*（具有最广泛行业支持的Web服务规范集合）定义了在应用程序之间移动XML的“企业服务质量”。尽管由于篇幅有限，无法在这里介绍每一个WS-*技术，但是还是能够进行简略的介绍：
q 以前在分布式计算中所有的服务质量标准已经存在于WS-*栈里，或者已经在近期的发布计划当中（以及标准化当中）。
q WS-*在一个单一的、统一的框架里，为同步操作（通常用于查询）和异步操作（通常用于业务事务处理）提供了通信基础架构。
q WS-*协议族是第一个可扩展用以满足企业内部EAI的需求，甚至企业间商务集成（B2BI）集成需求的系统。以前的技术，从未如此接近地实现过“密切合作”（指的是，可以使用企业自己的所有业务系统，合作伙伴的业务系统，甚至合作伙伴的合作伙伴的系统，等等）所要求的大量关键需求。
q 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的Web Sphere除外）之处在于，WebLogic很早就积极地投入了API的标准化工作委员会（servlets/Java Server Pages [JSP]、Java数据库连接[JDBC]、JMS、企业级Java Beans[EJB]，等等）。
BEA一直在大力保护我们为SOA在基于 Workshop创新上所做的投资。我们有多种手段确保对投资的保护：
协议：
q BEA/Microsoft/IBM WS-*协作-WS—*协议族开始主要由这三家厂商制定（在标准化之前）
q WS-*的标准化——W3C委员会和OASIS（结构化信息标准推进组织）
q WS-*的验证和分析——Web服务互操作性组织（WS-I）
编程模型：
q BEA和IBM进行的Java协作——在2003年发布，这个协作是在BEA/IBM/Microsoft Web服务协作之上构建的。它的重点在于推进服务器端Java API的标准化，特别是SOA方面；
q Java社区项目（JCP）
q 欧洲计算机制造商协会（ECMA）（例如，XScript）
q W3C（例如，XQuery）
q OASIS（例如，业务流程执行语言[BPEL]）
q Workshop产品的可移植性-如果Workshop生成了符合J2EE标准的应用程序，那么这个产品可以不加修改地运行在其他任何符合J2EE规范的容器里
q 开源软件（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的统一开发环境。同时，Workshop在不牺牲投资保护的情况下，使得开发消息驱动的代码变得非常简单。不管是同步还是异步，Web服务还是JavaBeans，HTTP还是JMS，WS-*协议族或替代品（RosettaNet、ebXML、EDI，等等），BPEL/BPELJ和Workshop都会使工作变得容易。
（8）XMLQuery：XMLQuery（或XQuery）正在迅速成为“XML的SQL”——也就是说XQuery的定位是成为操纵、转换、聚合XML数据的首要语言。XQuery是W3C选定的标准化主题。在转换XML时，XML Query比XSLT更易使用，而且差不多快了6倍。（XSLT的复杂性和执行缓慢是大多数竞争的集成厂商选择专用解决方案的原因）而且，像Workshop这样的工具还允许以拖——放方式建立转换（“XMaps”）以及合并XML文档（例如，通过查询现有企业应用程序——企业资源计划（ERP）、客户关系管理（CRM）、遗留应用程序等来得到整体的客户记录。）BEA把后者叫做“liquid data”。XQuery在WebLogic 8.1中的实现，大大领先于其他商业产品，并且已经与WebLogic Workshop、WebLogic Integration以及Liquid Data for WebLogic集成。
（7）Java Web服务（JWS）和JSR-181：Workshop 1.0引进了元数据，从而使Web服务的编写几乎和编写普通老式Java对象（POJO）一样容易：毕竟，为什么开发人员仅仅是为了编写一个可靠的和/或对话的简单的Web服务，就必须重复手工编写成百上千行的J2EE逻辑呢？Workshop JWS的基础注解语法正在JSR-181中进行标准化（BEA是这一规范的领导者）。下面是一个非常简单的Web服务例子，用POJO加上二个JSR-181注解编写：
@WebService
public class
StockQuoteService {
@WebMethod
public float
getLastTradePrice（
String tickerSymbol）{
// ...
}
};
使用进一步的注解、模式和WSDL，可以把它自定义为：
@WebService（
name="ExampleStockQuoteService"，
targetNamespace=
"http：//www.openuri.org/
ExampleStockQuoteService/
MyExamples"）
public class StockQuoteService {
@WebMethod（operationName=
"GetLastTradePrice"）
@DocumentWrapper（
requestElement（name =
"TradePricesRequest"）
responseElement（name =
"TradePriceResponse"））
public float getLastTradePrice（
String tickerSymbol） {
}
};
当然，Workshop的JWS会继续定义注解以“开启”Web服务架构更加丰富的服务质量特性：
@WebService（targetNamespace =
"http：//workshop.bea.com/
CreditReport"）
@Conversation（maxAge="1 hour"，
maxIdleTime="30 minutes"）
public class CreditReportService {
@WebMethod
@ConversationPhase（START）
@Reliable
public void requestReport（
String ssn） {
}
@WebMethod
@ConversationPhase（CONTINUE）
public ReportResult
getCurrentStatus（） {
}
@WebMethod
@ConversationPhase（FINISH）
public void cancelReport（） {
}
};
虽然这些更加丰富的注解将不会是JSR-181首个版本的组成部分（部分原因是许多WebLogic之外的容器还不能提供可靠的、会话式的Web服务），BEA仍然在迁移JWS文件，使其采用基于JSR-175的元数据。同时保证使用一个开放源代码的瘦运行时映射。完全的JWS文件可以部署到任何J2EE容器里。在JSR-181的后续版本里，我们希望加入JWS余下的功能。
（6） EJBGen和EJB“3.0”：EJBGen显著地提高了EJB编程的生产率。EJBGen使用JavaDoc注解，因此能够极其容易地把POJO变成EJB。EJBGen现在是WebLogic Workshop的一部分，所以它的语法很容易学习。长远来看，我们正在把EJBGen的语法转变为基于JSR-175的元数据（Workshop当然将会提供到新语法的自动移植）：
@Session public class
PurchaseOrderService {
public String
submitPurchaseOrder（PO po） {}
}
另外，BEA正在和更大的Java社区协作，希望把这类注解进行标准化，将其加入EJB标准的下一个主要修订。更重要的是，任何现存的EJB项目都可以装入Workshop，用EJBGen编辑，然后EJBGen输出的EJB项目是可以在任何符合J2EE规范的容器中运行的标准EJB项目。
（5）XMLBeans：基于XML的应用集成的一个主要诱人之处就是“松散耦合”——松散耦合的应用程序不受XML/Web服务接口变化的影响，反之亦然。但是在实践中，现有的XML编程模型相当枯燥、容易出错，远远达不到松散耦合的目标。XMLBeans是一个“XML——模式编译器”（它从XML 模式生成Java的类封装器），它能解决所有这些问题，还能提供对XML高效、无损失的操纵。长远来看，XMLBeans一直在跟踪正在出现的Java-XML绑定标准。XMLBeans已经作为一个Apache开放源代码项目可以在WebLogic以外的应用服务器上使用。
（4）XScript：如果使用自身就支持XML的内嵌脚本，许多XML的操作能够更简单地内部执行。Workshop 1.0引入了XScript（有时被描述为“有XML扩展的JavaScript”），就是为了实现这个目的。BEA在ECMA中建立并领导了ECMAScript for XML（E4X）小组，把这项技术贡献给国际Java/ECMAScript语言标准。在2004年3月，E4X获得了ECMA TC39（编程语言委员会）的一致通过，这使得ECMAScript成为第一个本身包含对XML支持的主流编程语言。ECMA General Assembly有望在2004年6月最终通过一个国际性的E4X标准。
（3）Page Flow for Java（JPF）和Struts：Apache Struts是基于Java的Web用户界面的“模型——视图——控制器”框架的事实标准。它的麻烦在于，编写Struts应用程序是一个代码密集型和过于复杂的工作。Workshop的Page Flow for Java（JPF）以图形化的方式管理数据和业务逻辑流，从而支持用拖放方式进行复杂的Struts应用程序编程。JPF的运行时（run time）是标准的Struts扩展，BEA已经用可移植工具包的形式将其提供给Tomcat和其他J2EE/Servlet 1.3容器使用。而且，在一下个主要发行版里，Workshop还将支持Java Server Faces（JSF，JSR-127），这将使基于Struts的组件和基于JSF的组件能够更容易地混合与匹配。
（2）Portlets、WSRP和内容管理：对于门户的重复开发，没有比用WebLogic Portal 8.1的拖、放和查看功能更容易的了。但是，这种开发上的简易，不应当以被厂商锁定为代价。门户最基本的构件正在进行标准化，包括Java Portlet规范（JSR-168）、用于远程门户的Web服务（WSRP，由OASIS标准化）以及内容管理解决方案的标准化接口（JSR-170）。Workshop支持在BEA门户里使用外部应用程序，因为Workshop能够自动地把现有Web用户接口用portlet封装起来，也可以自动利用支持WSRP的应用程序。另外，Workshop提供了建立标准Java应用程序以及建立WSRP生成器的能力，因此可以很容易地集成进非BEA的门户里。
（1）控件：控件是用于拖放式编排的服务器端组件模型-图形编程的“Web流”（JPF）和“工作流”/业务流程（JPD和BPELJ）。控件是可重用的组件，利用丰富的IDE集成（自定义向导、属性和图形），可以极大地简化对基于J2EE资源的访问。控件还为智能地处理容器服务（例如自动资源管理、事务、安全性、异步以及组件嵌套）提供了运行时支持。Workshop控件框架是可扩展的-目前有超过100家的独立软件供应商（ISV）正在提供自己的控件，支持使用Workshop工具和统一的界面，对他们的增值服务进行自定义和编排。其中最重要的是，客户或ISV建立了一个控件，这个控件就可以在业务流程内部重用，业务流程从Web应用程序或门户，一直到建立Web服务，甚至是WebLogic应用内的任何方面。
长远来看，BEA正在重新设计控件的运行时（run time），提供可移植性，使控件可以在其他符合J2EE标准的容器里运行。至少会产生一个开放源代码的瘦控件运行时，使Workshop控件可以移植到其他符合J2EE标准的容器里。不过，我们的目标是和Java社区中的其他人合作，使得控件成为一个得到完全认可的Java标准。我们拭目以待。
总结
当然，是创新而不是投资保护为WebLogic Workshop在第一名的位置上创造了这些振奋人心的成就。Workshop是第一个使J2EE编程变得像PowerBuilder或Visual Basic编程一样容易的应用框架，是最简单、最丰富的SOA和Web服务编写与编排的开发环境，是应用集成的第一个集成工具和运行时。在Workshop 8.1之前，寻找发布端到端集成解决方案的开发人员，通常不得不为下面的每项工作去处理不同的工具和运行时：
q 业务流程设计/建模
q 业务流程执行/管理
q 转换
q 适配器的选择/自定义
q J2EE/Web服务开发/部署
q 消息传递和消息代理
q 用户界面（UI）设计
q 门户用户界面（UI）聚合
q B2B
q 协作
（想想这有多讽刺——在WebLogic Workshop 8.1之前，开发人员要想完成集成工作，通常必须花相当多的时间把他们的集成技术“集成”起来。）
这十大总结，显示了BEA如何通过标准、开放源代码、可移植工具包，以及任何一种能够最佳满足客户投资保护需求的机制，来履行他们对客户提供投资保护的承诺的。一如既往，我们的客户可以使用BEA最先进的创新，同时确信他们的投资会得到长远的保护。BEA认识到，厂商锁定的日子已经结束了，至少在Java社区里是这样。客户需要投资保护，BEA就为客户提供投资保护。
最后，让我给大家留些最后的思考：不要忘记“面向服务架构”中的“架构”。实现SOA真正挑战的不是厂商的技术，真正的挑战是定义“正确的”可重用业务服务（通常要通过封装传统应用程序），然后为您的业务最优地编排这些服务：
q 业务服务应当是同步的（RPC风格的）还是异步的（消息传递风格的），还是二者都要？
q 业务服务应当组织到工作的事务单元里，还是组织成一组消息，并在执行失败的时候有一套应对措施？
q 怎样才能实现应用模式之间的最大限度重用？（对于表示常见数据类型——如客户、订单——的模式，如何才能限制它们的泛滥？因为模式的泛滥会增加互操作性的复杂程度。）
这些有关应用架构方面的思考是独立于底层技术选择的（而且通常比底层技术的选择更重要！）。
致谢：我在写作这篇文章时得到了很多帮助。特别感谢Yaron Goland、John Beatty、Gordon Simpson和Matt Mihic。
发表于 @ 2004年08月19日 16:18:00|评论(loading...)|编辑