用Web Services整合NET和J2EE.docx
《用Web Services整合NET和J2EE.docx》由会员分享，可在线阅读，更多相关《用Web Services整合NET和J2EE.docx（10页珍藏版）》请在冰豆网上搜索。
用WebServices整合NET和J2EE
用WebServices整合.NET和J2EE
用WebServices整合.NET和J2EE
来源:
互联网 时间:
2006-04-11
互用性（Interoperability）问题说起来容易但通常实现起来却比较困难。
尽管Web
service曾承诺要提供最佳的解决方案来衔接基于.NET和J2EE的应用程序，但其过程却并不简单。
我们发现在使用SOAPBuilders和
WebServicesInteroperabilityDemo（WSID）时还需要考虑许多问题。
近期发布的WebServices
InteroperabilityOrganization（WS-I）对此也提供了很多有价值的深层见解。
本
文包括了从这个demo的开发过程、参与SOAPBuilders互用性测试，以及WS-I于近期发布的有关互用性的规范中获得的经验总结（想了解更多关
于WS-I的资料，可以查阅工具条中的“谈谈WS-I”）。
以下，我们就开始研究在哪些范围可以通过使用Web
services来实现互用性以减少你目前以及未来在.NET和J2EE上的投资。
我们提供的结论将有助于你决定是否应该同时对这两种平台进行投资，以及
基于Webservice互用性的局限性是否会使你只选择其中的一个平台。
互用性问题出现于计算机行业发展的早期阶段。
当时软件的开发
是为了适应某一特定的硬件应运而生的，近期则是为了适应采用特定硬件配置的特定操作系统。
然而，操作系统是会经常更换的，而且经常会采用新的硬件或对硬件
进行升级。
因此，尽管计算机应用程序使用了基于操作系统的编译或解释语言，但仍然受到操作系统改变的冲击。
这的确是事实，尽管有一些高级语言（有时被称为
第三或第四代语言，比如VisualBasic、C#和Java）的幕后想法是使程序员在一种更高级别的抽象层中来开发程序。
在计算机
应用的早期阶段，人们没有太多地考虑接口连接或整合程序的问题。
这种状况一直持续到计算机体现出了重要的商业用途--
使部分或所有商业操作实现自动化，一些有关投资保护（investment
protection）、整合以及互用性等实际问题才随之产生。
商业要求无论投资何种软件，他们都可以持续使用这些程序，而不管硬件、操作系统和开发技术
是否发生变化。
这就使得软件在完全不同的硬件和操作系统之间的兼容性成为企业最大的、花费最高的问题，因为它直接影响到生产力
（productivity）、停工期（downtime）、机会的把握和其他一些失效方面的问题。
.NET和J2EE的互用性问题之
所以非常重要，是因为大多数企业都在使用其中之一或同时使用这两种平台来开发程序。
.NET和J2EE分别代表了解决本质上相同的问题的不同方法：
开发、
部署和管理定制商业程序。
定制商业程序的重要性在于商务本身有着不同的运作，如果不能使其具有独特之处则会影响管理存货（inventory）、处理定单
或提供财政服务（financialservices
）这些问题。
实际上，企业之间的相互竞争经常是很激烈的；比如，Wal-Mart曾吹捧自己著名的进销存系统（inventory
managementsystem），说它可以近实时地巩固来自于其所有店铺的购买力，而且能够使用这些信息从供应商处得到较低进价。
了解.NET和J2EE的区别
在一个完美世界里，用于自定义应用程序的主要开发平台之间是完全兼容的，为某一平台编写的程序能够完全适用于其他平台。
然而，我们离完美的世界还差得很远。
目前的软件行业还相当不成熟，甚至可以说还没有完全标准化。
和
电子行业及其他行业不同，计算机行业一直在为建立一套标准而努力。
就在不久以前，DVD
Forum成功地发布了一套用于DVD-ROM软件和硬件的标准。
所有DVD播放器均可播放任何DVD碟，所有DVD硬件制造商以及DVD碟制造商都将依
照相同的编码标准。
而在软件行业中，各主要开发商均实行各自不兼容的软件系统。
他们鼓吹各自的产品对开发人员如何有用，以此期望开发人员使用他们的产品来
开发项目，因为一旦程序开发进入生产（production）阶段，一般就不会更换使用其他产品了。
软件开发商们不是要建立一种所有人共同参与的市场，而
是为了在这个复杂的开发市场中占有一席之地。
Microsoft.NET的最初想法是希望进行接近操作系统平台的定制开发，当然，这是指
使用Windows（目前是XP、ME和2000）。
Visual
Basic和C#是.NET平台上最重要的开发语言，并且它们不能在其他平台上运作。
而基于Java的J#和.NET平台也是互不兼容的。
Microsoft声称有许多开发商在开发与.NETcommonlanguageruntime
（CLR）相合作的语言，但直到今天，我们看到CLR还只是一个Windows“版”的技术。
这就说明存在一个重要的互用性问题，因为每种编程语言（根据
定义来划分）都有其各自特定的数据类型和数据结构。
图1.比较.NET和J2EE
仅凭一个简单的HTTP连接
是无法实现互用性的，因为程序是在操作系统之上的编程语言抽象层中进行开发的（见图1）。
.NET和J2EE平台上的开发编程语言有着本质上的区别
（.NET比较私有化而J2EE则更开放）。
另一个重要的区别是对.NET来说，开发环境和操作系统是由同一开发商所提供的。
.NET和J2EE针对分布
式应用程序有着不同的、不相兼容的二进制通讯协议（binarycommunicationprotocols）：
它们分别是.NET
remoting和RemoteMethodInvocation/InternetInter-OrbProtocol（IIOP）。
当然和VB、C#、甚至J#相比，Java有着不同的数据类型和数据结构。
通常解决互用性的首要问题就是处理数据类型和结构的不兼容型，这也是在测试Webservices互用性过程中的一个重要挑战。
尽
管Java运行于Windows平台，但J2EE应用程序却能够在任何平台上进行开发，并以通常被称为“松散耦合”（loosely
coupled）的方式和任何操作系统相连。
换言之，J2EE尽量避免了使用操作系统特有的（operating-system-specific）特性
和功能，比如直接内存管理（directmemory
management）；或是平台特有的（platform-specific）通信机制，比如MicrosoftRemoteProcedure
Call（RPC）。
.NET开发环境能够充分利用操作系统的“紧密耦合”（tightly
coupled）或“本地”（native）实现的优势，并能随意使用Microsoft特定的功能和操作系统服务。
总体来说.NET更容易使用，它比
J2EE更好地结合了Windows本身的特性；但J2EE程序的优势在于可以运行于其他操作系统之中（见资源）。
在编程语言行为
（programminglanguage
behavior）、本地分布式计算协议、数据类型和结构，以及从操作系统服务中分离（isolation）等方面的不同都会对互用性产生影响。
除非所有
人都使用相同的编程语言、操作系统和应用程序，否则你还是需要了解各种复杂的互用性问题，以及哪种方案更值得去研究。
权衡WebServices解决方案
用
来解决互用性问题的Webservices规范已经出台了，其中包括解决.NET和J2EE的互用性方案以及SimpleObject
AccessProtocol（SOAP）、WebServicesDescriptionLanguage
（WSDL）、UniversalDescription、Discovery和Integration
（UDDI）等协议。
了解它们真正能解决什么问题以及如何通过使用它们来解决问题是相当重要的（见图2）。
图2.回顾基本的WebServices架构
SOAP
规范定义了从HTTP到TCP/IP数据传送的消息格式，WSDL规范定义了如何描述一个Web
service，而UDDI则定义了如何注册（register）和发现（discover）Web
service描述。
SOAP和WSDL是位于WorldWideWebConsortium
（W3C）底层的标准。
W3C还负责定制HTML和XML领域的各种规范。
另外，W3C还为WebServices
ArchitectureWorkingGroup提供赞助，该组织负责开发一个用于包含基本规范的Web
service参考架构（reference
architecture）。
如图2中可以看到架构规范的工作草案图表中所显示的SOAP、WSDL和UDDI的关系。
Web
service规范和实现它们的底层平台是完全独立开的，这和HTTP与HTML之间的情况相似，同时它们能在.NET和J2EE平台上运行的很好。
想了
解更多关于.NET和J2EE对Webservice规范的支持差异的比较，请查阅Eric的文章“DecideBetweenJ2EEand
.NETWebServices”。
WebServicesArchitectureWorking
Group还制定了一些扩展规范（extended
specification），比如在安全性、协调（orchestration）和事务处理方面的规范。
用来实现这些规范的产品并不是很多，因此在这里
我就不详细地介绍了，除非说到一些更为复杂的互用性问题，因为你必须了解Web
service交互的每个部分是否支持其他规范，以及它们支持哪些规范。
但从到目前为止的经验来看，即使是最基本的Web
service规范也试图向互用性挑战，这是因为Web
service技术存在于一个高级的抽象层中，它包括两种主要的交互方式（interactionstyle），每种都有其各自考虑的范围。
访问机制
一
般来说，开发人员会使用两种机制来访问一个远程程序（就是从位于一个不同地址空间（address
space）的程序中调用另一个应用程序）：
RPC，它主要包括定义和使用外部程序调用接口；以及文件或队列（queue）操作，其中程序通过对文件或队
列的读写来实现数据共享。
SOAP是被指定且考虑了这两种途径而编写的（协议）。
在Web
service领域里，它们被称为面向RPC（RPC-oriented）
和面向文档（document-oriented）的交互方式。
面向RPC方法在同步通信功能中比较常见，比如用在CORBA、COM，以及用在.NET
和J2EE的二进制通信协议里。
使用RPC的一个好处是请求者（requestor）能看到接口定义（interfacedefinition
）中有关service的定义；就是说，程序或方法名以及调用参数可以用来提供有关service行为的信息。
使用基于工具包的
RPC方法的另一个好处是用于实现RPC方式的编程接口会自动实现真实的数据类型与XML结构之间的转换。
这样会使程序员从数据转换中解脱出来。
使用面向
文档（或称为消息传输）方式的优势在于请求者和提供者只需在数据（或schema）定义上取得一致就可以了，而对程序或方法调用的具体细节不作要求。
然
而，面向文档方式仅限于使用XML文档发送和接收数据。
由于现在基于XML文档的使用越来越广泛，所以这也不是什么问题，尽管早期的使用者更愿意将非
XML信息转换到合适的XML结构中，以此提高文件交互方式。
最终，使用基于RPC还是基于文档方式将由各自service的调用方法（你是否需要在一个
普通文档上用详细的参数或相对较少的调用操作来完成大量特定的方法调用呢？
）和被传输的数据类型（你需要转换的数据是简单的还是复杂的数据类型？
）来决
定。
大量的互用性工作是由SOAPBuilders通过面向RPC的交互方式在WSID中完成的--
主要是通过“调试”或在多个SOAP产品实现中找到所支持数据类型和架构的共同点（common
denominator）。
其结果定义了一组可以用来实现互用性的数据类型和结构。
因此该列表成为你检查正在使用的.NET和J2EEWeb
service产品的首要事情。
在本文的后面部分我会教你怎么做。
较低层次的互用性工作是用面向文档的交互方式来完成的。
然而，WS-I
曾声称很难用面向RPC方式来实现广泛的互用性，并且呼吁企业使用面向文档方式来获得更好的结果。
面向文档方式实现了“文件共享”模式。
传输SOAP消息
就如同通过一个消息代理（messagebroker）--如MicrosoftMessageQueue（MSMQ）或MQ
Series的JavaMessagingServices（JMS）来传送异步消息（asynchronous
message），其差别仅仅在于传输是在TCP/IP上使用HTTP，同时消息格式是由WSDL定义的。
实际上，面向文档方式尽量避免在Web
service层中解决数据类型和结构问题，但开发此类程序还需要做更多工作。
我们将在本文的后面部分谈到这个问题。
使用面向连接（Connection-Oriented）的协议
面
向RPC和面向文档交互之间的关系相当于同步和异步通信协议之间的关系。
同步通信通过阻塞（block）调用程序直到被调用的程序返回一个响应来模拟一个
子程序。
如果被调用的程序没有完成则调用程序会收到错误消息，不管被调用的程序是在远程网络上还是在本地机器中运行。
但实现这种模式的一个必要条件是调用
程序和被调用程序之间必须保持一种连接或会话（conversation）。
这种持续连接会消耗大量的网络资源，这也是HTTP不支持它的原因。
这
就意味着你在使用.NET和J2EE对象模式时会有很多限制条件。
比如，你无法在HTTP上使用依赖于同一对话的多个交互操作的SOAP，而且你无法执行
对象生命周期管理（objectlifecyclemanagement
）功能，比如建构（create）、析构（destroy）和碎片整理（garbagecollection）。
但通过异步调用，你可
以通过一个程序写入文件，随后用另一个程序来从文件中读出数据。
你只需要在读写文件的过程中有一个网络连接。
这些程序可以在同一机器或不同机器的相同或不
同地址空间中运行，只要由“调用”（或生成）程序写入的数据能够被“被调用”（或使用）程序所接受就可以了。
然而，在异步调用的情况下，调用程序在没收到
返回数据时无法了解到底发生了什么；而定制标准的错误处理和结果分析（resolution）又成为另外的互用性问题。
当你无法决定
Webservice是不是正确的选择时可以用它来衡量，了解你是否需要使用同步协议是非常重要的。
从定义来说，基于HTTP的Web
service
是一种单向（one-way）异步消息，因此，它是解决基于文件或基于队列的互用性问题的最好方法。
比如，如果互用性需要包含用数据更新来同步用户响应，
那么Webservice可能就不是个好办法了。
然而尽管它有明显的缺陷，却还是能够实现互用性的。
图3.建立联系
深入了解WSID
WSID
是由TonyHong（XM的创始人和主席）、SIGS/101会议和Web
services技术的主要公司，包括Microsoft、IBM、IONA、eXcelon（现在是一个Progress
Software）、MindElectric、AmberPoint和WebMethods共同发起的，用来研究多开发商共同实现Web
service兼容性的问题。
其目标是通过使用一个简单却不平凡的、切实的商业背景（business
scenario）来实现一个多开发商共同开发的、跨平台的Web
service互用性范例。
目前大多数demo实现是基于J2EE的产品，但由于Microsoft也是这个demo的发起者之一，所以.NET也被包括
在内。
WSID已经在2002年8月在Boston的WebServicesOne大会上公布了，尽管其在线版（online
version）的计划还在酝酿之中（见资源）。
该范例使用了一个简单的购买网络（purchasing
network）。
供应商为用户提供目录，而用户则给供应商提交一份购买清单。
供应商会首先检查用户当前的信用情况，然后向代理商店发出送货单（见图
3）。
出于几个原因，XMethod通过提供静态的XML文件和Webservice接口实现其在demo网络的重要作用：
一个带Webservice和浏览器接口的、包含所有参与者及其相关终端的列表。
从Customer到bank的映射关系。
保持WSDL文件和列出终端用户的UDDI记录。
包含所有已定义接口的标准WSDL文件的在线集合。
一个日志服务（loggingservice）。
这
些接口都被包含在一个单独的文档中，你可以从XMethodsWeb
site中找到它们（见资源）。
这个很棒的Demo中包括用于内部组件通信（inter-component
communication）必须的RPC-encoded结合和document-literal结合实例。
以及跨越所有平台的大量的参与调节这些方式
和编码结合。
Demo内部操作成功与否主要取决于操作精度和WSDLWeb
service操作定义的相对简单。
而且，所有demo的行为都通过一个loggingWeb
service来完成，这个service最初是由Xmethods网站提供的。
当一部分人开始对WSID进行组装的时候，另一个由大约
15个Web
services供应商组成的非正式组织将共同执行一套普通测试版，通过使用SOAPBuilders来提高互用性水平。
所有开发商均发布测试版终端以证
明其实现互用性的水平。
其他供应商则可以测试其自身实现，使用已发布的测试终端，然后和其他供应商一起完成对互用性水平的测定（见资源）。
SOAPBuilder
是通过和其他成员一起讨论来完成评估的，期间完成定制和校正的工作并得到一个新的测试版。
每次讨论的目的是通过一些重要的方法来提高互用性水平，比如在测
试版中包括更多数据类型和结构，或者在WSDL规范中包含更多内容。
该组织集中使用通过测试大量开发商对SOAP规范中RPC编码的阐述，用面向RPC的
交互方式来解决互用性问题。
截至发稿日期，SOAPBuilder已经完成了五次讨论并得到大量的讨论结果，结论证明用简单数据类型（如整数型和文本型）
比复杂数据类型（如数组和结构型）更容易实现互用性。
使用的数据类型越复杂，通过所有测试的开发商数量就越少。
大多数开发商使用的是J2EE平台，因此很
容易找到J2EE供应商并找到每个供应商能够在互用性测试中支持哪种数据类型及多少数据类型。
你可以查看SOAPBuilder的结果以了解哪种数据类型
和结构在面向RPC方式中是可用的。
由于该组织是非正式的，因此SOAPBuilders的章程还在商议之中。
一些人认为既然WS-I
已经发布了其最初的建议书（见资源），因此目前并不需要SOAPBuilders。
然而，许多开发商还是坚持支持基于RPC方式的Web
services产品，而且使用RPC会简化面向RPC中间件的互用性实现，比如.NET、J2EE和CORBA。
在许多情况下SOAPBuilder和
WS-I是交替使用的，因为它们的目标都是建立一个实现互用性的通用Webservice规范。
依照WebService发展蓝图
当Web
service的应用变得成熟并成为主流产品的时候，就需要在现有的Web
service标准中增加一些其他功能，为了实现这些需求，WS-I计划发布一个结构蓝图（architecturalroad
map），用于识别功能区和需要在将来的Webservice规范中关注的功能。
由于很多标准组织不断建立和采用新的规范来增强现有的Web
service功能，WS-I将继续推出一个确保测试资料支持现有要求和内部独立性的论坛。
我们要强调的是WS-I提出的两个用于工具
和基本应用程序的主要开发平台：
C#（.NET）和Java
（J2EE）。
这就是说WS-I将来的工作很可能直接同.NET和J2EE的互用性相关，这将具有很重要的意义，因为WS-I建议中的工具和策略将肯定
（至少）能够正确运行于这两个大的开发平台之上。
SOAPBuilder花费了大约1年的时间用来测试面向RPC方式的互用性（调试
每种RPC的编码实现）。
然而WS-I的BasicProfileWorkingGroup（BPWG）
声称使用RPC编码很难实现互用性，尤其在处理RPC编码认可的普通数据类型和数据结构时。
它将被从最近提出的互用性资料中（详细资料见Go
Onlinebox）剔除出来。
这意味着WS-I建议仅适用于通过面向文档类型来实现互用性问题。
但这将问题退回到应用程序上，而使Web
services从本质上只能是在Internet上来回传送文件。
这还是不能解决互用性问题。
.NET和J2EE平台的基本性能的发展
归功于对内部企业局域网（corporateLANs
）或其他受控的公司内部网络中对自定义应用程序开发支持的需求。
程序开发最初的主要范围被假定在一个公司里。
围绕.NET和J2EE建立的产品和
service是直接销往各个公司的，它们提供用于商业业务处理的商用应用程序工程开发的支持。
以特定的语言和平台来支持业务数据处理会将用户局限于一种语言、产品或中间件构造中，它们决定了软件开发商能获得多少收益，有关这种收益的竞争就是出现各种各样平台的原因。
Webservice标准承诺通过提供一个通用的XML消息抽象层来解决.NET和J2EE之间的差异。
然而，该规范本身的局限性以及在其实现中的局限性都将限制互用性实现的级别。
软
件工业还在持续着收益之争，因为大量建立的软件公司的商业模式是基于此的。
它们在目前的客户群（installed
base）不受威胁的情况下不可能做出改变，或者放弃它们所依赖的现有客户。
这就是说，当你在业务中使用Web
service时，它们可能会在其中增加一个解决重要问题的抽象层。
然而，在你处理.NET和J2EE之间的互用性时，了解其可能性和局限性是非常重要
的，这同样适用于成功实现论证（比如WSID提供的图表）和WS-I提供的大量建议。
关于作者:
Richard
Bonneau是IONATechnologies的一名著名工程师。
他以前曾担任WebServicesIntegration
PlatformProducts的技术主管，现在则成为TechnologyResearch的一名主管。
Rich还在Digital
EquipmentCorp./Compaq
Computer公司从事过不同系统的整合和软件技术的研究，他代表IONA出席了本文中提到的WSID和WS-I大会。
你可以通过
rich.Bonneau@和他联系。
EricNewcomer是IONA
Technologies的CTO，该公司为Web
service的整合提供独立的电子商务平台。
Eric主要负责定制IONA的技术蓝图和IONA的OrbixE2AE-business
Platforms的发展方向，因为它们和标准采用、架构和产品设计相关。
他是WorldWideWebConsortium中的XML
Protocols和WebServicesArchite
升级会员 