JCA跟Web服务的讨论

前不久我去了趟东海岸，在那里我拜会了很多开发者、客户以及合作伙伴，跟各种各样的人交谈过，并听到了很多圈内的趣事。

最近，我主要忙于一项大的Web服务。因此花了大量的时间来学习、找人谈话并写了一些关于这项技术的东西。在与该领域内不同的客户群交流时，我吃惊地发现一个问题一而再再而三地反复出现。

人们总是问我J2EE连接器体系结构(J2EE Connector Architecture，JCA)和Web服务的区别是什么。他们很想知道选择其中一个而不是另外一个的标准是什么。最初，我感到很诧异，因为答案看上去那么显而易见。但是，稍加思索，我就明白了人们为什么会混淆。供应商们将Web服务定位为标准的集成服务，他们的市场销售做的如此之好，以至于公司和个人用户已经开始感到忧虑，因为JCA也在做同样的宣传。人们很自然地得出结论，这两种技术在互相竞争，是互相排斥的。真的吗？有一点，但不全是。

了解定位

Web服务和JCA都是解决集成问题方面的标准，但它们却并不互相竞争。开发者和用户们需要知道这两者是不同的，并且需要知道这两种技术的差别所在，这一点很重要。

Web被定位于用来标准化集成的技术，而JCA规范则用来标准化企业应用集成（EAI）。其中EAI是广义上集成问题的一个子集。因此，问"如果我有一个EAI问题，该使用Web服务、JCA，还是两者兼而有之？"这样的一个问题，完全是合乎情理的。

最大的区别在于侵入

侵入（Intrusion）是指为了支持集成技术而需要对遗留系统做的改动。

l JCA：该技术需要很少或者不需要对遗留系统的侵入。JCA适配器可以利用本地API、套接字、数据访问以及其他不需要更改现有代码基础的技术来访问遗留系统。于是公司就可以利用在已部署系统中的投入，而不必再投入额外的资源来更新系统以支持集成。
l Web服务：为了让遗留系统能本地支持将Web服务用作EAI方案，必须需要很高程度的侵入。遗留系统必须被更新并且修改，以包含一个Web服务栈。这个栈将处理所有的SOAP消息分析和遗留系统调用，这是一项很庞大的任务。大多数企业都不会贸然修改现有的COBOL或者旧的大型机应用以引进一种还不成熟的Web服务栈。

因此，如果一个公司想为EAI使用Web服务，最有可能的做法是购买一个Web服务网关，该网关将截取Web服务消息，对遗留系统进行本地调用，得到响应，然后将其转换成一个响应Web服务消息。JCA很容易就能被用作进行本地遗留系统调用的技术，但很多公司可能反对使用这么多的消息层来启用EAI。

顺便说一下，我个人认为EAI问题最终会成为Microsoft的.NET策略中的一个障碍。由于大多数遗留系统都不是运行在Microsoft Windows上，所以.NET不可能直接进行遗留系统集成。Microsoft已经公开宣称Web服务为他们未来的EAI战略。这意味着Microsoft在依赖公司将Web服务栈内置于遗留系统中以获得对它们的访问。我想说的是企业肯定不会接受这种做法，来做这么一笔投资。因为那些使用.NET的企业将被迫购买EAI服务器（WebLogic Server是不错的选择）来截取Web服务请求并使用像JCA这样的EAI类技术来进行集成。

上下文传播

需要考虑的一个严重的基础结构问题是从使用遗留系统的客户到遗留系统本身的事务和安全上下文传播（Context Propagation）。

l JCA：JCA支持从JCA服务器到遗留系统的安全和事务传播。这是JCA设计中最主要的基础结构概念之一，也是被很多集成环境采用的一个强有力的原因。这意味着如果一个标识用户的XA事务上下文或者安全上下文是在应用服务器中创建的，那么当应用服务器调用遗留系统上的服务时，遗留系统就会感染上事务和安全上下文。就XA事务来说，这意味着如果遗留系统是XA-compliant的资源管理器，它就能参与XA事务。这样设计师们就能设计出EAI系统，这种系统能保证具有遗留系统以及使用该系统的客户的ACID事务。至于安全来说，这意味着用于个人的单点登陆（single sign-on）可用于客户和遗留系统之间。在设计和遗留系统的交互时，这些是需要考虑的关键特性。
l Web服务：Web服务消息可以传播一个事务或者安全上下文来作为一个SOAP头部扩展，这是可能的，但现在标准的做法已经不这么做了。另外，即使存在这样一个标准，也不会用来传播XA事务和内部的安全用户标识符。Web服务可以将客户从服务器上分离出来，就和MOM系统将生产商和消费者分离一样。是的，跨过Web服务消息传播XA事务上下文是有可能的，但Web服务的本性意味着谁也不能预测响应消息究竟何时发送或抵达目的地。XA事务是一个寿命很短的事务，通常每30秒自动进行一次transaction rollback。Web服务的这种不可预测和不连贯的本性使它成为XA事务上下文不太现实的传输手段。系统级的安全标识符同样有这个问题。这意味着利用Web服务来访问远程系统的客户不能使用XA事务来实现同样的目的。

但是也不要对Web服务失望。Web服务为业务逻辑（business logic）层提供了一个商业级的接口，而不是一个细粒度（fine-grained）的方法。如果这样的话，Web服务就需要事务，安全以及很多其他的基础结构技术，但是它们必须应用于Web服务所运行的环境中（不可预测的响应，不可预测的载荷，应用的来去，XML格式的变化等）。例如，OASIS工作于商业事务协议（BTP），为该环境中的系统提供了寿命很长的事务。另外，它还创建了很多安全Web服务规范。Web服务最终会改变开发者对商业服务的看法以及他们用来创建商业服务的体系结构，但是这些新的方案是否适用于EAI，这得你自己判断。

代码绑定

代码绑定是EAI简单但重要的一面。我们可以将Web服务和JCA做一个比较。

l JCA：JCA是基于Java的技术，这并不意味着遗留系统必须是用Java编写的，但是使用JCA的遗留应用必须用Java编写。这给设计师们某些暗示。首先，任何使用JCA的应用和它对JCA的使用绑定在一起。这意味着如果应用对遗留系统的使用需要作出变化，那么开发者必须动手重新编写JCA访问代码以作出改动。这对于一些公司来说可能是问题也可能不是。其次，应用可以利用对访问遗留系统的客户所作的强制声明（strong typing）和编译时间检查。由于用来访问遗留系统的数据类型和方法是以Java类型出现的，使用JCA的Java应用可以对遗留系统的语义用法进行编译时间检查（它并不确认该系统的正确用法，只是说明使用该系统的语法是正确的）。
l Web服务：Web服务EAI方案允许用任何语言编写的客户端都能访问遗留系统，这些客户端可能是用Java，C#，Fortran，或者COBOL编写的。同样，由于Web服务使用XML消息来和其他系统通信，与Web服务动态连接并获取WSDL文档来理解消息结构的客户端不能从编译时间检查中获得任何好处。但是，Web服务的格式可能是实时的，应用也可以动态地和它一起变化，也就是说Web服务的改变并不一定意味着使用Web服务的客户端需要重新编写。

数据绑定

数据绑定用来将遗留系统数据的格式变成客户端应用可用的一种格式。
l JCA：JCA需要对一个Java数据类型（Java类）的数据绑定。这对于在本地类型和Java类型之间有一个清晰映像的简单数据类型来说。但如果遗留系统有复杂的相关或者二进制数据必须被处理，那么很快就会有麻烦。JCA 1.0没有一个表示遗留系统中数据格式的标准作法，并且动态客户端也不能连接到JCA适配器上以"发现"遗留系统的数据格式是什么。JCA 2.0包含了一个元数据功能（metadata facility），它能允许JCA客户端查询JCA适配器，以便动态地发现遗留系统中的数据形状和类型。
l Web服务：Web服务给遗留系统带来了一个有趣的问题，因为遗留系统中的数据必须首先被转换成XML来传输，然后再转换成使用Web服务的客户端的编程语言格式。如果EAI系统使用客户端->Web服务->服务器中间件->本地集成适配器->遗留系统这种途径，那么遗留系统中的数据将沿着一种丑陋的格式传输，即本地格式->本地集成适配器转换的语言格式->XML转换->使用Web服务的客户端的语言格式。除非数据绑定技术取得突破性进展，否则原始数据的很多含义在这些转换过程中很有可能丢失（更不用说系统变慢这样显著的性能了）。

另一方面，很多公司用XML格式来表示遗留数据自有他们的道理。XML在商业上很有意义，有很多种方法来跨越不同的应用和系统使用这些商业意义。但是，如果遗留系统在本地将它的数据用XML展现出来，那么Web服务可能会提供一个无缝方案，该方案使得对JCA的使用也变得很麻烦。在过去的三年里人们创建了很多使用XML作为数据格式的系统，这些系统现在都已成为遗留系统，所以这种方案可能是可行的。

结论

我希望通过本文大家能比较了解JCA和Web服务的体系结构在用于EAI时的主要区别。我们对于这两者定位的争论以及进一步的比较很感兴趣，如果您有什么新的想法，请告诉我们。可以发送电子邮件，让我们共同讨论。

原文URL： http://dev2dev.bea.com/articles/552.jsp