Java EE 5平台为SOA提供的更多功能

　　关于Java EE 5平台，从来不缺乏批评的声音，这些评论员们认为，对于从事Web服务和SOA项目的开发人员而言，Java EE 5平台过于复杂、难以掌握;但是，它也有自己的拥护者，其中之一便是Kevin Schmidt——Sun微系统公司SOA部门主管。

　　Java EE 5 为Web服务和SOA 的开发人员提供了哪些功能呢?

　　Kevin Schmidt说:Java EE 5平台所添加的功能能够协调和使用服务，因此，构建服务以支持SOA就变得更加简单。关于这一优势，不仅反映在Java EE 5本身，而且，在我们所使用到的围绕Java EE 5的其他事物中也都能观察到。

　　那么，围绕Java EE 5的事物具体指什么呢?

　　Schmidt说：其中一部分是指复合应用程序平台(Composite Application Platform)，这是Sun公司收购SeeBeyond公司，进行产品整合之后的新套件。它提供了构建将BPEL、XSLT以及其他运行于J2EE环境下的技术融为一体的Java EE 5应用程序的功能。Java EE 5提高了Web服务堆栈的性能、通过标记提高了程序设计模型的性能，因此，对于开发人员而言，这使得构建服务以及构建符合EJB 3.0的额外功能变得更加简单。

　　我们正在开发的另外一些功能，是作为Glassfish开源应用程序服务器的一部分嵌入到一个JBI(Java业务整合)运行时中的，这样一来，开发人员就能够使用其它技术——例如，业务处理引擎、业务规范引擎、用于传输的其他语言——来利用Java EE的优势，这是因为，构建能够与各种系统进行交互、以继承Java代码和组件的服务时，Java EE的功能非常强大。同时，通过并行地使用其他技术、不断的开发工具和连续的运行时，Java EE的功能也能够得以提高。Java EE允许开发人员为SOA构建各种不同的服务。然后，开发人员就能够把这些服务应用到SOA应用程序中去。

　　支持Java EE 5的开发商们都纷纷指向EJB 3.0，把它作为Java EE 5中用于SOA的一个优势，那么，对于开发人员而言，EJB 3.0意味着什么呢?

　　Schmidt说：使用EJB3.0，开发人员就能够很轻松地构建即将成为SOA一部分的服务组件，这是一个非常重要的进步。与以前的EJB规范相比，EJB 3.0的确减少了很多困难、降低了复杂性。对于那些作为Web服务暴露的EJB组件，我们所构建的一些与EJB 3.0协同运行的工具，包括NetBeans 5.5，都使得它们的构建变得更加容易。EJB 3.0也能够帮助你构建底层的组件，然后，这些组件再被构建到支持SOA的服务中。或者你能够直接构建那些服务，并把EJB组件作为Web服务暴露。

　　链接Web服务是怎么样的呢?

　　Schmidt说：对于链接Web服务而言，在Java EE中包含了用于部署和暴露Web服务的功能，也包含了利用NetBeans所提供的工具来调用Web服务的功能。通过使用NetBeans，发现一个Web服务描述语言(WSDL)、导入该WSDL到你的应用程序中、再调用它，这一系列过程变得十分简单。开发人员对这一系列过程的经验也很丰富。他们根本不需要了解——文件是采用什么技术如何生成的——这样的底层细节。NetBeans为开发人员隐藏了所有的底层细节，也隐藏了JBI运行时和处理服务引擎(处理服务引擎是JBI的一部分，用于协调在Java EE内构建的服务与外部服务)。当然，你也能够使用业务处理执行语言，来协调这些服务。使用这种方式的话，你就能够构建规模更大的应用程序。而且，比起使用Java代码本身，这种方式要敏捷的多。

　　有没有业务案例来说明SOA应用程序是如何结合在一起，并且按照上述方式协作的呢?

　　Schmidt说：有可能有一个公共服务或者你可能有一个业务伙伴，他暴露Web服务来为你提供一些功能。你可能有一个业务伙伴提供信用检查。你也可能有一笔银行正在处理的贷款。对于你的公司而言，业务逻辑作为业务处理的一部分，它是唯一的。该业务逻辑已经用Java语言来写，或者你打算用Java语言来写。那么，你能够使用Java来创建其他服务，然后通过Java来调用该服务到信用检查服务这一外部服务中。或者，更为普遍的是，另外一些人为贷款审批应用程序创建了一个业务处理程序，在该应用程序中，他们将协调自己公司内部的服务与其它公司的服务，如调用信用检查。

　　链接到微软平台又是怎样的呢?

　　Schmidt说：当然存在着这样一个领域，在JAX-WS(XML Web服务的Java API)以及Web服务技术方面——用于满足使用微软技术创建的组件之间的交互性，我们已经做了大量的工作。在我们刚才谈论的例子中，业务伙伴也有可能是使用.NET来写他们的信用检查服务。那么，通过JAX-WS提供的功能，我们就能够调用.NET应用程序，并且进行无缝协作。而且，不仅仅只有外部业务伙伴会使用到微软的技术。我们当然知道，根据目前的情况，各大公司都会使用多种技术来构建他们的应用程序。因此，他们可能使用.NET来构建一部分应用程序，但是，他们希望通过协作来创建规模更大的应用程序。这就很有可能是从Java或者更高级的语言如BPEL中，发出这些调用。

　　JBoss公司提倡一种他们称之为“Java EE是照菜单点(Java EE a la carte)”的方法，这意味着开发人员能够根据他们对特定应用程序的需要，仅仅使用Java EE 5的一部分，忽略剩余其他部分。那么，这是使用Java EE 5平台的可行方法么?

　　Schmidt说：我们相信，这当然是一种可行的方法。我们也在积极探寻各种方法，希望能够通过提供Java EE 5组件来满足业务需求，采用这种方式，你就可以仅仅使用你所需要的部分。一个典型的例子就是JBI。从根本上说，你能够获得各种不同的服务引擎和绑定组件，但是，你仅仅能够挑选其中一种你所需要的来使用。类似地，我们正在寻找，如何基于开发人员对其应用程序的特殊需求来提供Java EE 5的组件。

　　一些分析员评论说Java EE 5对于SOA开发而言过于复杂，那么，把该平台划分为各个组件，这能够回应那些评论所提出的问题么?

　　Schmidt说：这当然是一个非常有价值的方式。Java EE 5确实是满足人们认为更加轻量级的解决方案。通常当你谈论轻量级或是重量级时，这都取决于个人看问题的角度。你可能仅仅使用Java EE的一部分构来建一个应用程序，虽然是运行在完整的Java EE容器中，但是，这仍然是轻量级的，因为你不需要对Java EE所提供的每一个部分进行配置。当然，当你构建一个Java EE应用程序时，你是不需要使用标准的每个部分的。因此，大多数关于Java EE 5的评论都是基于个人的角度——重量级与轻量级的区别是什么。

　　因此，开发人员可以不考虑其他组件是否有用，因为他们并不需要使用完整的Java EE 5包，是么?

　　Schmidt说：目前，依据我们的Glassfish项目中已经完成的部分，虽然，我们还没有能力提供所有的组件，但是，这正是我们积极努力的目标。当然，当你构建应用程序时，你完全可以不使用EJB组件。为了满足你的目的，你可以仅仅使用Java EE的一部分来完成应用程序的构建。所以，当你构建应用程序时，你根本不需要使用Java EE 5的整个规范。