Use J2EE design-oriented architecture framework
Writing / Naveen Balani
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 article outlines several iterative processes on the SOA framework from a higher level, which will meet the needs of a virtual company. The sample frames developed here can be easily modified to suit your business needs.
Introduction to SOA and Web Services SOA is a distributed software model. The main components of SOA include service, dynamic discovery, and messages.
l 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 with the term provider, and the latter is specifically used to represent an entity that provides a service. l The interface is usually published in a public registration center or directory and classifys in accordance with the different services provided, just like the business 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. l 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. Web-based implementation SOAWeb services are based on open standards and independent protocols. 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 Services Definition Language), and the semantic use of WSDL uses 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.
Developing the J2EE 1.4 Platform 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 the web service to overcome the obstacles between different programming languages, operating systems, and vendor platforms, thereby enabling multiple applications to interact (for more information on WS-I, see http: //www.ibm.com/developerWorks/cn/webservices/ws-designsoa/#6.) This means that in addition to platform independence and complete web service support, J2EE 1.4 also provides cross-platform web services interoperability. Sex. Under J2EE 1.4, web service customers can access J2EE applications in two ways. Customers can access Web services created with JAX-RPC API; use servlets in the background JAX-RPC 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 component as a web service - there are many advantages: L using existing business logic and processes: In many companies, existing business logic may have written in EJB components, open through the web service It may be the best choice to access these services from the outside world. The EJB endpoint is a good choice because it allows business logic and endpoints on the same layer. l Concurrency: EJB service endpoints implemented as a stateless session bean do not have to worry about multithreading access because the EJB container must serialize a request for any specific instance of stateless session beans. l Security Access to the service: Enterprise Beans allows different method levels of 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. l Transaction Questions: 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. l Scalability: Almost all EJB containers provide support for stateless session bean 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. l 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 following will show how to disclose the stateless EJB components in the architecture as a web service.
Designing the SOA / Web service framework has a company that there is a company, such as payment, finance and invoice system) needs 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. Various components for interacting in the SOA framework are listed below. This is a typical MVC 2 frame.
l Customer: The user interacts with different applications through a web browser, the browser as the application of the application. 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. l Application Controller: The application controller is your main controller servlet. It is responsible for initialization, delegating requests and responding request processing programs. l Request Processor: This is a Java class that preproces the request by calling the corresponding request execution program to complete the request. This call uses command mode. l Request Handlers: Request executive executing the program to complete the specific request, such as adding or retrieving information to different enterprise information systems (Enterprise Information Systems, ES). The request executation rely on the service location program to discover the appropriate service, and then access the required EIS information through these services. l 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. l 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. l EJB Web Services: According to the EJB 1.4 specification, the web service endpoint can model a stateful session bean. As mentioned earlier, this technology has many advantages. l Data Access Interface: Use different technologies (such as EJB-CMP, JDO, DAO) and different persistence technologies to access the EIS, the access technology used depends on interface requirements and data acquisition, insert or update. the amount. This layer is responsible for interacting with EIS and returns data to these methods with the corresponding EJB web service method. These components provide the basis for the internal application of the company's internal application. Next, discuss the service to the outside world. Open a service to the outside, if you are ready to open service to the outside 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. The following is the basic functional unit of this architecture: External clients: can include web-based clients, 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. l Corporate Firewall: According to its security policy, this company has a firewall between intranet and the Internet, and limits the received packet information.
l 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. 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 Services Gateway can provide conversion from one protocol to another. l EJB Services: There is no change in EJB services. Other parts of the process are similar to the Intranet-based service provided by the architecture shown in Figure 2. The process of achieving coarse particle size using the EJB component has been used to open a fine-grained Web service to the client. 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 illustrates the next iterative process for the external application of the enterprise. This version of the architecture is open to the outside world. 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 Services 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 http://www.ibm.com/developerWorks/cn/webservices/ws-designsoa/#6.)
