使用J2EE设计面向服务的体系结构框架

使用J2EE设计面向服务的体系结构框架

撰文/Naveen Balani

面向服务的体系结构（Service-Oriented Architecture，SOA）因其固有的松散耦合与互操作性，成为许多企业应用的自然选择。在本文中您将看到，使用J2EE 1.4提供的Web服务功能可以很容易地构建能够访问现有业务流程的SOA系统。
在本文中，您将学习如何利用Java 2 Platform，Enterprise Edition (J2EE)设计和开发面向服务的体系结构（SOA）框架。通过采用SOA框架，企业可以最大程度地减少系统间的耦合，从而提高可重用性。本文从一个较高的层面概述了在SOA框架上进行的几次迭代过程，这个框架将满足一家虚拟企业的需求。这里开发的示例框架可以很容易地进行修改以适合您的商业需求。

SOA和Web服务简介
SOA是一种分布式的软件模型。SOA的主要组件包括服务、动态发现和消息。

l 服务是能够通过网络访问的可调用例程。服务公开了一个接口契约，它定义了服务的行为以及接受和返回的消息。术语服务常与术语提供者互换使用，后者专门用于表示提供服务的实体。
l 接口通常在公共注册中心或者目录中发布，并在那里按照所提供的不同服务进行分类，就像电话簿黄页中列出的企业和电话号码一样。客户（服务消费者）能够根据不同的分类特征通过动态查询服务来查找特定的服务。这个过程被称为服务的动态发现。
l 服务消费者或者客户通过消息来消费服务。因为接口契约是独立于平台和语言的，消息通常用符合XML模式的XML文档来构造。

下面的图1说明了SOA中的不同角色。
基于Web服务实现SOA
Web服务建立在开放标准和独立于平台的协议的基础之上。Web服务通过HTTP使用SOAP（一种基于XML的协议），以便在服务提供者和消费者之间进行通信。服务通过WSDL（Web Services Definition Language）定义的接口来公开，WSDL的语义用XML定义。UDDI是一种语言无关的协议，用于和注册中心进行交互以及查找服务。所有这些特性都使得Web服务成为开发SOA应用程序的优秀选择。

使用J2EE 1.4平台开发
SOA/Web服务框架
1.4版的J2EE平台通过新的JAX-RPC 1.1 API提供了完整的Web服务支持，这种API支持基于Servlet和企业Bean的服务端点。JAX-RPC 1.1基于WSDL和SOAP协议提供了与Web服务的互操作性。J2EE 1.4平台也支持Web Services for J2EE规范(JSR 921)，后者定义了Web服务的部署需求并利用了JAX-RPC编程模型。除了几种Web服务API之外，J2EE 1.4平台还声称支持WS-I Basic Profile 1.0。WS-I Basic Profile标准让Web服务克服了不同编程语言、操作系统和供应商平台之间的障碍，从而使多种应用程序之间能够交互（关于WS-I的更多信息，请参阅http://www.ibm.com/developerWorks/cn/webservices/ws-designsoa/#6。）这意味着除了平台独立性和完整的Web服务支持之外，J2EE 1.4还提供了跨平台的Web服务互操作性。
在J2EE 1.4下，Web服务客户可以通过两种方式访问J2EE应用程序。客户可以访问用JAX-RPC API创建的Web服务；在后台JAX-RPC使用Servlet来实现Web服务。Web服务客户也可以通过Bean的服务端点接口访问无状态会话Bean。Web服务客户不能访问其他类型的企业Beans。第二种选择—公开无状态EJB组件作为Web服务—有很多优势：

l 利用现有的业务逻辑和流程：在许多企业中，现有的业务逻辑可能已经使用EJB组件编写，通过Web服务公开它可能是实现从外界访问这些服务的最佳选择。EJB端点是一种很好的选择，因为它使业务逻辑和端点位于同一层上。
l 并发支持：作为无状态会话Bean实现的EJB服务端点不必担心多线程访问，因为EJB容器必须串行化对无状态会话Bean任何特定实例的请求。
l 对服务的安全访问：企业Beans允许在部署描述符中声明不同方法级别的安全特性。方法级别角色被映射到实际的主体域（Principal Domain）。使用EJB组件作为Web服务端点，把这种方法级别的安全性也带给了Web服务客户。
l 事务问题：EJB服务端点在部署描述符规定的事务上下文中运行。容器处理事务，因此Bean开发人员不需要编写事务处理代码。
l 可伸缩性：几乎所有EJB容器都提供了对无状态会话Bean群集的支持。因此当负载增加时，可以向群集中增加机器，Web服务请求可以定向到这些不同的服务器。通过把Web服务模型化为EJB端点，可以使服务具有可伸缩性，并增强了可靠性。
l 池与资源管理：EJB容器提供了无状态会话Bean池。这改进了资源利用和内存管理。通过把Web服务模型化为EJB端点，这种特性很容易扩展，使Web服务能够有效地响应多个客户请求。
记住所有这些优点，下面将展示如何在体系结构中将无状态EJB组件公开为Web服务。

设计SOA/Web服务框架
比方说有一家公司，它的各种系统（比如支付、财务和发票系统）需要彼此交互。此外，其中一些应用程序还需要对外界公开，以便不同的业务合作伙伴与它们进行交互。您还需要为各种应用程序（如输入发票的各种数据输入操作或者查看支付的状态）设计基于Web的解决方案。最佳选择就是设计一种松散耦合的基于服务的系统。这些服务应该得到开放标准的支持，这样任何业务合作伙伴都可以调用它们。
这些方面的考虑将使您转向Web服务/SOA框架，通过无状态EJB组件把各种服务和业务流程公开为Web服务。下面的图2说明了企业内部应用的SOA框架。
下面列出了SOA框架中进行交互的各种组件。这是一种典型的MVC 2框架。

l 客户（Client）：用户通过Web浏览器与不同的应用程序交互，浏览器作为应用程序的客户。比如，出纳部门的用户可能要输入帐单细节并把信息提交给应用程序。可以使用JSP页面和XHTML来呈现客户页面。
l 应用程序控制器（Application Controller）：应用程序控制器是您的主控制器Servlet。它负责初始化、委派请求和响应请求处理程序。
l 请求处理程序（Request Processor）：这是一个Java类，通过调用相应的请求执行程序完成要求的处理，对请求进行预处理。这种调用采用命令模式。
l 请求执行程序（Request Handlers）：请求执行程序完成具体请求的活动，比如与服务交互，向不同的企业信息系统（Enterprise Information Systems，EIS）增加或检索信息。请求执行程序依靠业务定位程序发现相应的服务，然后通过这些服务访问需要的EIS信息。
l 业务定位程序（Business Locators）：这些程序负责隐藏查找服务的复杂性，并提供缓存逻辑。业务定位程序可以采用多种形式，比如Web服务定位程序、EJB组件定位程序或者JMS定位程序。
l 会话Facades（Session Facades）：通过聚合来自多个系统或服务的方法，简化复杂对象的视图。会话Facades是EJB Web服务方法的包装器。
l EJB Web服务（EJB Web Services）：根据EJB 1.4规范，Web服务端点可以模型化为无状态的会话Bean。如前所述，这种技术有许多优势。
l 数据访问接口（Data Access Interfaces）：使用不同的技术（比如EJB-CMP、JDO、DAO）和不同的持久性技术访问EIS，所使用的访问技术取决于接口需求以及获取、插入或更新的数据量。这一层负责与EIS进行交互，并以相应的EJB Web服务方法所期望的格式把数据返回给这些方法。
这些组件提供了企业内部应用程序面向服务体系结构的基础。接下来讨论把服务向外界公开。
向外界公开服务
如果准备向外部用户公开服务，您需要某种安全约束来保证只有授权的用户才能访问服务。一种方法是提供另外的Web服务层，过滤掉禁用的Web服务请求，并提供登录和安全约束。这种过滤方式还应提供一种工具，向每一客户只公开授权给该用户的服务子集。
图3说明了企业外部应用的面向服务体系结构。它向外界公开了细粒度的服务。
以下是这种体系结构的基本功能单元：
l 外部客户（External Clients）：可以包括基于Web的客户、移动客户或者使用.NET环境、Perl或其他编程语言编写的客户。所有这些客户都为不同的服务发送请求。只要遵循WS-I Profiles就不会出现互操作性的问题。
l 企业防火墙（Corporate Firewall）：根据其安全策略，这家公司在Intranet和Internet之间架起了防火墙，对收到的分组信息进行限制。
l Web服务网关（Web Services Gateway）：本例中，我选择使用WebSphere Application Server 5.0中的Web Services Gateway产品作为公开外部服务的网关。Web Services Gateway是一种中间件产品，在调用Web服务时提供了Internet和Intranet之间的中间框架。使用Web Services Gateway，开发人员和IT经理可以安全地对外公开Web服务，防火墙之外的客户也能调用这些服务。它包括一个服务管理模型（部署、取消部署，等等）和过滤器（对流经网关的请求和响应起作用的自定义代码）。它只处理收到的SOAP/HTTP请求，通过网关的请求可能发送给Java类、EJB组件或者SOAP服务器（该服务器甚至还可能是另一个网关）。它可以为单个的Web服务方法提供保护（基本授权），也可以保护整个网关。使用Web Services Gateway，来自客户的请求可以被转换成服务所要求的任何消息协议。例如，客户的请求可能是HTTP上的SOAP，但在内部可以使用JMS协议上的SOAP，Web Services Gateway能够提供从一个协议到另一个协议的转换。
l EJB服务（EJB Services）：EJB服务没有任何变化。过程的其他部分和图2所示体系结构提供的基于Intranet的服务类似。

使用EJB组件实现粗粒度的服务
迄今所见到的过程都是向客户公开细粒度的Web服务。只要每个业务服务作为单个业务过程执行，这种设置就能很好地工作。但是假设客户要进行在线资金转移，这种情况下提供单一的、粗粒度的接口显然更加合理，让用户提供所有必要的信息，包括传输的金额、发出和接收的银行信息，等等。此外，这类情形中验证必须在执行任何业务逻辑之前完成。在设计Web服务方法时必须考虑到这些问题，还要记住除了网络调用之外还有解析与规划XML请求和响应的开销。
考虑到这些因素，可以把Session Facades模型化为EJB Web服务端点。Session Facades可以在把请求委派给相应的Web服务方法之前首先验证请求。这样，您就可以向Web服务客户提供粗粒度的服务。
图4说明了企业外部应用的面向服务体系结构的下一次迭代过程。这个版本的体系结构向外界公开粗粒度的服务。
这里，主要的实现仍然和图3中所示的相同。唯一的区别在于已经公开了Session Facades作为Web服务端点。EJB Web服务可以模型化为本地接口而不是远程接口。使用会话Facades和方法级安全性，可以限制要执行的服务。使用Web Services Gateway也能为Web服务客户施加安全措施。根据需要，可以实现粗粒度服务和细粒度服务的某种结合，通过调整Web服务网关中间件来向外部客户公开两种服务。（关于使用Session Facades与企业Web服务的更多信息，请参阅http://www.ibm.com/developerWorks/cn/webservices/ws-designsoa/#6。）

结束语
采用WSDL文件形式的Web服务接口可以发布到商业注册中心，从而使客户能够动态查找这些接口。如果交易伙伴已经知道这些服务，也不一定要进入商业注册中心，但是全球服务需要公共注册中心，以便客户能够查找可用的服务。（例如，各个航空公司可以把它们的机票价格服务放在注册中心，普通客户可以发现所有这类服务，并查找航空公司所提供的最低票价。）
我希望本文能够有助于您开始使用Web服务和新的J2EE 1.4规范所提供的特性构建面向服务的体系结构。