J2EE and SOA Architecture

In this article, you’ll learn how to design and develop service-oriented architecture (SOA) frameworks using the Java 2 Platform, Enterprise Edition (J2EE). By adapting an SOA framework, your organization can maximize loose coupling and reusability between systems. This article will take a high-level overview of several iterations over an SOA framework that will meet the needs of a fictional corporation. The sample frameworks developed here can be easily adapted to suit your business needs.

SOA and Web services: An introduction

An SOA is a distributed software model. The key components of an SOA include services, dynamic discovery, and messages.

• A service is a callable routine that is made available over a network. A service exposes an interface contract, which defines the behavior of the service and the messages it accepts and returns. The term service is often used interchangeably with the term provider, which specifically denotes the entity that provides the service.
• Interfaces are often published in public registries or directories where they are categorized based on different services offered, just as businesses and their phone numbers are listed in a phone book’s Yellow Pages. Clients (service consumers) can look up a particular service by dynamically querying for services based on various categorization features. This process is referred to as the dynamic discovery of services.
• Service consumers or clients consume services via messages. Because interface contracts are platform- and language-independent, messages are typically constructed using XML documents that conform to XML schema.

The figure below illustrates the various roles in an SOA.
Figure 1. The roles in an SOA

Web services as a SOA

Web services are built on top of open standards and platform-independent protocols. A Web service uses SOAP (an XML-based protocol) over HTTP for communication between service providers and consumers. Services are exposed as interfaces defined by WSDL (Web Service Definition Language), whose semantics are defined in XML. UDDI, a language-independent protocol, is used for interacting with registries and looking for services. All of these features make Web services an excellent choice for developing SOA applications.

Using the J2EE 1.4 platform for developing SOA/Web services frameworks

Version 1.4 the of J2EE platform provides complete Web services support through the new JAX-RPC 1.1 API, which supports service endpoints based on servlets and enterprise beans. JAX-RPC 1.1 provides interoperability with Web services based on the WSDL and SOAP protocols. The J2EE 1.4 platform also supports the Web Services for J2EE specification (JSR 921), which defines deployment requirements for Web services and utilizes the JAX-RPC programming model. In addition to numerous Web services APIs, the J2EE 1.4 platform also features support for the WS-I Basic Profile 1.0. The WS-I Basic Profile standards allow Web services to overcome the barriers of different programming languages, operating systems, and vendor platforms so that multiple applications can interact. This means that J2EE 1.4 offers cross-platform Web services interoperability in addition to platform independence and complete Web services support.

Under J2EE 1.4, a Web service client can access J2EE applications in two ways. The client can access a Web service created with the JAX-RPC API; behind the scenes, JAX-RPC uses a servlet to implement the Web service. A Web service client can also access a stateless session bean through the service endpoint interface of that bean. Web service clients cannot access other types of enterprise beans. The second option descried — exposing stateless EJB components as Web services — has a number of advantages:

• Leveraging existing business logic and processes: In many organizations, existing business logic has already been coded using EJB components; exposing it through Web services is the best possible option for making those services available to the outside world. An EJB endpoint is a good choice because it keeps business logic located in the same tier with the endpoint.
• Concurrency support: An EJB service endpoint implemented as a stateless session bean need not worry about multi-threaded access, since the EJB container must serialize requests to any particular instance of a stateless session bean.
• Secure access to services: Enterprise beans permit various method-level security features to be declared in the deployment descriptor. The method-level roles are mapped to an actual principal domain. Using EJB components as Web service endpoints brings this method-level security to Web service clients.
• Transaction considerations: An EJB service endpoint runs in a transaction context specified in the deployment descriptor. The container handles the transactions, so the bean developer doesn’t need to write transaction-handling code.
• Scalability: Almost all EJB containers provide support for the clustering of stateless session beans. So, as load increases, additional machines can be added to a cluster, and Web service requests can be directed to those various servers. By modeling Web services as EJB endpoints, you can make the services scalable and increase their reliability.
• Pooling and resource utilization: An EJB container provides pooling of stateless session beans. This improves resource utilization and memory management. By modeling Web services as EJB endpoints, such features can easily be extended to make Web services respond effectively multiple client requests.

With all of these advantages in mind, the following sections will show you how to expose stateless EJB components as Web services in your architecture.

Designing your SOA/Web services framework

Consider the example of a corporation where various systems — such as those for billing, finance, and invoicing — need to interact with each other. In addition, some of these applications need to be exposed to the outside world so that various business partners can interact with them. You also need to design a Web-based solution for various applications — such as the various data entry operations for entering invoices or finding the status of bills. The best choice is to design a loosely coupled system based on services. These services are backed by open standards, so any business partner can invoke them.

These considerations should point you toward a Web services/SOA framework, with your various services and business processes exposed as Web services via stateless EJB components. The figure below illustrates a SOA for internal corporate applications.
Figure . A service-oriented architecture for internal corporate applications

The various components interacting in the SOA framework are listed below. It’s a typical MVC 2 framework.

• Client: The user interacts with various applications via the Web browsers that serve as clients for your application. For example, a billing department user may enter billing details and post that information to the application. JSP pagess and XMHTML can be used for rendering the client pages.
• Application controller: The application controller is your main controller servlet. It takes care of initialization and delegates requests and responses to the request processor.
• Request processor: This is a Java class that performs preprocessing of requests by invoking the corresponding request handlers to carry out the required processing. This invocation is modeled as a command pattern.
• Request handlers: Request handlers carry out specific request activities, like interacting with services for adding or retrieving information from various enterprise information systems (EISs). Request handlers rely on business locators to find the corresponding services then accesses the desired EIS information through those services.
• Business locators: These are responsible for hiding the complexity of looking up services; they also provide caching logic. A business locator can take many forms — for instance, it could be a Web service locator, an EJB component locator, or a JMS locator.
• Session Facades: These provide a simplified view of a complex object by aggregating methods from multiple systems or services. Session facades are wrappers around the EJB Web services methods.
• EJB Web services: With the EJB 1.4 specification, Web services endpoints can be modeled as stateless session beans. As discussed above, there are a number of advantages to this technique.
• Data access interfaces: These access the EIS by using various techniques, like EJB-CMP, JDO, DAO, and various persistence technologies; the access technique used depends on interface requirements and the volume of data to be fetched, inserted, or updated. This layer is responsible for interacting with the EIS and returning data back to corresponding EJB Web service methods in the format that those methods expect.
• MQSeries/JCA/CCF: Existing mainframe-based services can be exposed as Web services, thus revealing them to the outside world. Web service clients interact with EJB Web services using the HTTP-based SOAP protocol. The EJB methods post requests to an MQSeries queue via the JMS protocol. (Using MQSeries is one way to interact with mainframe-based applications.) The MQSeries server on the mainframe side triggers the corresponding COBOL-based programs that provide the logic necessary for interacting with back-end systems like IMS DC. These programs then post the response back to the queue, which in turn is retrieved by the application logic and posted back to the EJB methods. SOAP messages can be transferred over various protocols, like HTTP, HTTPS, and JMS, but currently for uniformity this example will use HTTP and HTTPS only.

These components provide the foundations of your service-oriented architecture for internal corporate applications. Next, you can move on to expose your services to the outside world.

Exposing services to the outside world

If you’re going to expose services to external users, you need some kind of security constraints that make sure that only authorized users can access the services. One way to do this is to provide an additional Web service layer that filters out forbidden Web service requests and supplies logging and security constraints. This filter should also provide a facility for exposing to each client only the subset of services authorized for that client.

The below figure illustrates the service-oriented architecture for external corporate applications. It exposes fine-grained services to the outside world.
Figure 3. A service-oriented architecture, exposed to the outside world

Here are the basic functional units of this architecture:

• External clients: These can include Web-based clients, mobile clients, or clients coded in the .NET environment, Perl, or any other programming language; all of these clients send requests for various services. As long as you conform to the WS-I Profiles, there should be no interoperability issues.
• Corporate firewall: Based on its security policies, the sample corporation has imposed a firewall between its intranet and the Internet, restricting incoming packet information.
• Web Services Gateway: For this example, I have chosen to use the Web Services Gateway product included with WebSphere Application Server 5.0 as the gateway to expose external services. Web Services Gateway is a middleware component that provides an intermediary framework between Internet and intranet environments during Web service invocations. With the Web Services Gateway, developers and IT managers can safely externalize a Web service so that it can be invoked by clients from outside the firewall. It includes a model for the management of services (deployment, undeployment, etc.) and filters (custom code that acts on the requests and responses that flow through the gateway). It handles only incoming SOAP/HTTP requests, and requests passing through the gateway may be sent to a Java class, an EJB component, or a SOAP server (which could even be another gateway). It provides security (basic authorization) on the individual methods of a Web service, as well as for the gateway as a whole. Using the Web Services Gateway, a request from the client can be transformed into any messaging protocol required by your service. For example, your clients’ requests may come in as SOAP over HTTP, but internally you might be using SOAP over the JMS protocol; your Web Service Gateway can provide the conversion from one protocol to the other.
• EJB services: There is no change in the EJB services. The rest of the process is similar to the intranet-based services provided by the architecture illustrated in Figure2.
  

Coarse-grained services using EJB components

The processes you’ve seen so far expose fine-grained Web services to clients. As long as each business service is executed in a single business process, this set-up will work fine. But suppose a customer wants to perform a wire transfer of funds. It makes sense in such a case to provide a single, coarse-grained interface, with the customer providing all the needed information, including the amount to be transferred, the sending and receiving banks’ information, and so on. Also, in such a scenario validation needs to be performed before any execution of business logic. You should keep all these considerations in mind when designing the methods for a Web service, and also bear in mind the overhead of parsing and formulating XML requests and responses in addition to a network call.

Taking these factors into consideration, you can model Session Facades as EJB Web service endpoints. Session Facades can validate a request before delegating it to corresponding Web service methods. In this way, you provide coarse-grained services to your Web service clients.

The figure below illustrates the next iteration of your service-oriented architecture for external corporate applications. This version of the architecture exposes coarse-grained services to the outside world.
Figure 4. Service-oriented architecture with coarse-grained services

Here, the bulk of the implementation remains the same as the one outlined in Figure 3. The only difference is that you’ve exposed Session Facades as the Web service endpoints. The EJB Web services can be modeled as local rather than remote interfaces. Using session facades and method-level security, you can restrict the services to be executed. Using the Web Service Gateway can also impose security measures for Web service clients. Depending on requirements, you can go for some combination of coarse-grained and fine-grained services, exposing both to external clients by tuning your Web service gateway middleware.

This article of mine was first published by developerWorks at – Design service-oriented architecture frameworks with J2EE technology. All rights retained by IBM and the author.