Design So A With J2EE
Design So A With J2EE
Design So A With J2EE
Search for:
within
All of dW
Search help
IBM home
developerWorks
My account
Naveen Balani (naveenbalani@rediffmail) Technical Analyst 23 January 2004 The loose coupling and interoperability inherent in a service-oriented architecture (SOA) make it a natural choice for the many enterprise applications. In this article, you'll see how the Web services features available in J2EE 1.4 make it easy to build SOA systems that provide access to the business processes that you already have.
Coarse-grained services using EJB components Conclusion Resources About the author Rate this article
Related content:
Provide a Facade interface for enterprise Web services An introduction to Web services gateway
Subscriptions:
dW newsletters
In this article, you'll learn how to design and develop service-oriented architecture (SOA) dW Subscription (CDs and downloads) 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.
Figure 1 below illustrates the various roles in an SOA. Figure 1. The roles in an SOA
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. (See the Resources section for more on WS-I.) 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.
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 COBOLbased 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.
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. (See Resources for more on this product.) 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 Figure 2.
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. (For more information on using Session Facades with enterprise Web services, see Resources.)
Conclusion
Web services interfaces, in the form of WSDL files, can be published to a business registry; these interfaces can then be dynamically looked up by your clients. If the services are known to trading partners, a business registry is generally not required, but global services need a public registry so any client can look up available services. For instance, various airline systems might host their air fares services in a registry, and a generic client could discover all such services and find the cheapest air fares provided by the airlines. I hope this article has given you a start on building a service-oriented architecture with Web services and the features provided by the new J2EE 1.4 specification. You can adapt and fine-tune this SOA Web services framework to suit your business needs.
Resources
q
Learn more about the WS-I profiles. Check out "Implementing business processes using WebSphere Studio Application Developer Integration Edition, Part 2: Extend your business process," David Leigh (September 2003) from the IBM e-business on demand series of scenarios. Find out about "DB2 Web services: The big picture," Grant Hutchinson (August 2002) in this article from the DB2 Developer Domain. Get "An introduction to Web services gateway," in this article by Chandra Venkatapathy and Simon Holdsworth (developerWorks, May 2002). Learn how to "Provide a Facade interface for enterprise Web services," in this article by Masahiro Ohkawa (developerWorks, January 2004). Read these additional developerWorks articles by Naveen Balani:
r r r
"Programming JMS applications using AXIS" (February 2003) "Deliver Web services to mobile apps" (January 2003) "Web services architecture using MVC style" (April 2002)
Comments?
Submit feedback
developerWorks
About IBM
Privacy
Terms of use
Contact