关于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的整个规范。