The new Java API makes the Web service world easier access
Level: Advanced
Naveen Balani
(Naveenbalani @ Rediffmail) Technical Analyst February 2004
Service-Oriented Architecture (SOA) has become a natural choice for many enterprise applications due to its inherent loose coupling and interoperability. As you will see this article, the Web service feature provided using J2EE 1.4 can easily build an SOA system that accesss existing business processes.
In this article, you will learn how to use Java 2 Platform, Enterprise Edition (J2EE) and develop the service-oriented architecture (SOA) framework. By using the SOA framework, companies can minimize the coupling between systems, thereby increasing reusability. This paper outlines several iterative processes on the SOA framework from a higher level, which will meet the needs of a fictional company. The sample frames developed here can be easily modified to suit your business needs.
SOA and Web services: Introduction
SOA is a distributed software model. The main components of SOA include service, dynamic discovery, and messages.
Service is an adjustment routine that can be accessed through the network. The service discloses an interface contract that defines the behavior of the service and the message accepting and returning. The term service is often used interchangeably with the term provider, and the latter is specifically used to represent an entity that provides services. The interface is usually published in a public registration center or a directory and classified there according to the different services provided, just like the enterprises and phone numbers listed in the phone book yellow page. Customer (service consumers) can find specific services by dynamic query services based on different classification features. This process is called the dynamic discovery of the service. Serving consumers or customers consume services through news. Because the interface contract is independent of the platform and language, the message is usually constructed with an XML document that meets the XML mode.
Figure 1 below illustrates different roles in SOA.
Figure 1. Roles in SOA
Web services are based on open standards and independent platform-based protocols as SOAWEB services. The Web service uses SOAP (a XML-based protocol) via HTTP to communicate between service providers and consumers. The service is disclosed by the interface defined by WSDL (Web Service Definition Language), and WSDL's semantics use XML definitions. UDDI is a language-independent protocol, interacting with the registry and looking for services. All of these features make Web services become an excellent choice for developing SOA applications.
Develop SOA / Web Services Framework with J2EE 1.4 platform
The 1.4 version of J2EE platform provides complete web service support through the new JAX-RPC 1.1 API, which supports service endpoints based on servlet and enterprise beans. JAX-RPC 1.1 provides interoperability with Web services based on WSDL and SOAP protocols. The J2EE 1.4 platform also supports the Web Services for J2EE specification (JSR 921), which defines the deployment requirements for web services and utilized JAX-RPC programming models. In addition to several Web service APIs, the J2EE 1.4 platform also claims to support WS-I Basic Profile 1.0. The WS-I Basic Profile standard allows Web services overcomes obstacles between different programming languages, operating systems, and vendor platforms, thereby enabling multiple applications to interact (for more information on WS-I, see Resources) Part.) This means that in addition to platform independence and complete Web service support, J2EE 1.4 also provides interoperability of cross-platform web services.
Under J2EE 1.4, web service customers can access J2EE applications in two ways. Customers can access the web services created with JAX-RPC API; JAX-RPC after the scene uses servlet to implement web services. Web service customers can also access stateless session beans through the BEAN's service endpoint interface. Web service customers cannot access other types of enterprise beans. The second choice - Public stateless EJB components as web services - there are many advantages: Using existing business logic and processes: In many companies, existing business logic may have written in EJB components, open via Web service It may be the best choice for accessing these services from the outside world. The EJB endpoint is a good choice because it allows business logic and endpoints on the same layer. Concurrency support: EJB service endpoint implemented as a stateless session bean does not have to worry about multi-threaded access because the EJB container must serialize a request for any specific instance of stateless session beans. Security Access to the service: Enterprise Beans allows different method level security features to be declared in deployment descriptors. Method level roles are mapped to the actual main domain (Principal Domain). Use the EJB component as a web service endpoint, bring this method level of security to the web service customer. Transaction Problem: The EJB service endpoint is running in the transaction context specified by the deployment descriptor. Container handles transactions, so Bean developers do not need to write transaction processing code. Scalable: Almost all EJB containers provide support for stateless session beans clusters. Therefore, when the load increases, it can be added to the cluster, and the web service request can be directed to these different servers. By modeling the Web service to an EJB endpoint, the service can be scalable and the reliability is enhanced. Pool and Resource Management: The EJB container provides a stateless session bean pool. This improves resource utilization and memory management. By modeling the web service to EJB endpoints, this feature is easy to expand, so that the web service can effectively respond to multiple customer requests.
Remember all of these advantages, the next section will show how to disclose the stateless EJB components in the architecture as a web service.
Design SOA / Web Service Framework
For example, there is a company, and its various systems (such as payments, finance and invoice systems) need to interact with each other. In addition, some applications need to be open to the outside world, so that different business partners interact with them. You also need to design a web-based solution for a variety of applications (such as various data input operations that enter invoices or status). The best choice is to design a loosely-coupled-based system. These services should be supported by open standards, so any business partners can call them.
These aspects will make you turn to the Web Services / SOA framework, which opens various services and business processes to Web services through the stateless EJB component. Figure 2 below illustrates the SOA framework for the internal application of the company.
Figure 2. Service-oriented service architecture in internal application
Various components for interacting in the SOA framework are listed below. This is a typical MVC 2 frame.
Customer (Client): The user interacts with different applications through a web browser, the browser as the app's customer. For example, users of the westerner may have to enter bill details and submit the information to the application. You can use JSP pages and XHTML to present the customer page. Application Controller: The application controller is your main controller servlet. It is responsible for initialization, delegating requests and responding request processing programs. Request Processor: This is a Java class that is preprocessed by calling the corresponding request execution program to perform requests. This call uses command mode. Request Handlers: Request executive executing the program to complete specific requests, such as adding or retrieving information to different enterprise information systems, ENTERPRISE Information Systems, ESTEMS, ESE. The request executation rely on the service location program to discover the appropriate service, and then access the required EIS information through these services. Business Locator: These programs are responsible for hiding the complexity of the lookup service and providing cache logic. The business positioning program can use a variety of forms, such as a web service location program, an EJB component location program, or a JMS positioning program. Session Facades (session facades): Simplify complex objects by aggregating methods from multiple systems or services. Session Facades is the wrapper of the EJB web service method. EJB Web Services: According to the EJB 1.4 specification, the web service endpoint can model the stateless session bean. As mentioned earlier, this technology has many advantages. Data Access Interfaces: Use different technologies (such as EJB-CMP, JDO, DAO) and different persistence technologies to access EIS, access technology used depends on interface requirements and data volume for acquisition, insert, or update . This layer is responsible for interacting with EIS and returns data to these methods with the corresponding EJB web service method. MQSeries / JCA / CCF: The existing host-based service can be publicly a web service to show them to the outside world. Web Services Use HTTP-based SOAP protocol interact with EJB Web services. The EJB method sends a request to the MQSeries queue through the JMS protocol. (Using MQSeries is a way to interact with host-based applications.) The MQSeries server of the host is triggered with the corresponding COBOL-based program, and the latter provides the necessary logic for interacting with the background system (such as IMS DC). These programs then returns the response to the queue, and the application logic retrieves these responses and returns to the EJB method. SOAP messages can be transmitted through different protocols, such as HTTP, HTTPS, and JMS, but in order to unify, this example only uses HTTP and HTTPS. These components provide the basis for the internal application of the company's internal application. Next, discuss the service to the outside world.
Open service to the outside world
If you are ready to open service to an external user, you need some security constraint to ensure that only authorized users can access the service. One way is to provide additional web service layers, filter out the disabled Web service request and provide login and security constraints. This filtering should also provide a tool to disclose to each customer to the service subset of the user. Figure 3 illustrates a service-oriented architecture for enterprise external applications. It discloses fine-grained services to the outside world.
Figure 3. Service-oriented service architecture disclosed in the outside world
The following is the basic functional unit of this architecture:
External Clients: You can include web-based customers, mobile customers, or customers written in .NET environment, Perl, or other programming languages. All of these customers send requests for different service. Just follow the WS-I Profiles without interoperability. Corporate Firewall: According to its security policy, this company has a firewall between Intranet and Internet, limits the received packet information. Web Services Gateway: In this example, I chose the Web Services Gateway product in WebSphere Application Server 5.0 as a gateway that publicly externally served. (For more information on the product, see References.) Web Services Gateway is an intermediate product that provides an intermediate frame between Internet and intranet when calling a Web service. Using Web Services Gateway, developers and IT managers can safely open Web services, customers outside the firewall can also call them. It includes a service management model (deployment, cancel deployment, etc.) and a filter (custom code to the request and response of the gateway). It only processes the received SOAP / HTTP request, which may be sent to the Java class, EJB component or SOAP server (the server may even be another gateway) through the request of the gateway. It can provide protection (basic authorization) for a single web service method, or protect the entire gateway. Using Web Services Gateway, requests from customers can be converted into any message protocol required by the service. For example, the customer's request may be SOAP on HTTP, but the SOAP on the JMS protocol can be used inside, Web Service Gateway can provide conversion from one protocol to another. EJB Services: EJB services have no changes. Other parts of the process are similar to the Intranet-based service provided by the architecture shown in Figure 2.
Use EJB components to achieve coarse particle size service
The processes seen so far are all open-grained Web services to customers. This setting can work well as long as each business service is executed as a single business process. However, it is assumed that the customer wants online capital transfer. In this case, the coarse granular interface is clearly more reasonable, allowing users to provide all necessary information, including transmission, and receiving bank information, and so on. In addition, verification in such cases must be done before performing any business logic. These issues must be considered when designing a web service method, but also remember that there is an overhead of resolving and planning XML requests and responses except network calls.
Considering these factors, you can model the Session Facades to EJB Web Services endpoints. Session Facades can first verify the request before applying the request to the corresponding web service method. This way, you can provide a coarse granular service to web service customers. Figure 4 below illustrates the next iteration process for the external application of the enterprise. This version of the architecture is open to the outside world.
Figure 4. Service-oriented service architecture
Here, the main implementation is still the same as shown in FIG. The only difference is that Session Facades have been published as a web service endpoint. The EJB web service can model the local interface instead of the remote interface. Use session facades and method level security to limit the service you want to do. Use Web Service Gateway to apply security for web service customers. A certain combination of coarse particle size services and fine-grained services can be achieved as needed, and two services are disclosed to external customers by adjusting the WEB service gateway middleware. (For more information on using Session Facades and corporate web services, see Resources.)
Conclude
Web service interfaces in the form of WSDL files can be released to the business registry, allowing customers to dynamically find these interfaces. If the trading partner already knows these services, it is not necessary to enter the commercial registration center, but the global service requires a public registration center so that customers can find available services. For example, each airline can put their ticket price services in the registration center, and ordinary customers can discover all such services and find the minimum fare provided by airlines.
I hope this article will help you start using the features provided by Web services and new J2EE 1.4 specification build-oriented architectures. You can modify and adjust the SOA Web service framework described in this article to adapt to your business needs.
Reference
To learn from WS-I Profiles. Take a look at David Leigh's "Implementing Business Processes Using WebSphere Studio Application Developer Integration Edition, Part 2: Extend Your Business Process" (Sep 2003), this paper takes place from the Scene of IBM e-commerce. Read Grant Hutchinson's "DB2 Web Service: Blueprint" (August 2002), this article comes from the DB2 developer garden. Take a look at Chandra Venkatapathy and Simon Holdsworth's "Web Services Gateway Getting Started" (DeveloperWorks, May 2002). Learn how to "provide facade interface for enterprise Web services" through Masahiro Ohkawa's article (DeveloperWorks, January 2004). Read other developerWorks articles written by Naveen Balani:
"Write the JMS Application" (February 2003) "Delivery Web Service to Mobile Application" (Jan 2003) "Build a Web Service MVC Architecture" (April 2002)
About author
