This article is a seventpoint of the J2EE Web Service Development Series. In the previous topic of this series, we have focused on the development of Web services in J2EE 1.3 platforms. From this article, Web service development under the J2EE 1.4 platform will be described.
This article first introduces the architecture of the web service in the J2EE1.4 platform, then introduces the latest specifications and the latest technologies for web services in the J2EE1.4 platform. Next, the API used by the development of Web services is introduced and the J2EE Web service development step, finally Introduced the development tool for web services.
The reference materials of this article are found.
J2EE1.4 Web Service Architecture
J2EE1.4 Theme is a web service, under the J2EE 1.4 platform:
Allow J2EE application components to be exposed to SOAP / HTTP-based web services; integration with the original Web services; key technology for web services: JAX-RPC; J2EE1.4 Web Service Framework: Web Services for J2EE.
The newly added technology of the J2EE1.4 platform upgrade is related to Web services. Under the J2EE 1.4 platform, develop, deploy, and find that web services become very convenient. Although the J2EE1.4 platform provides an upgrade for web services, it:
The web service is just a channel using the service in the J2EE platform, so it does not need to change the J2EE architecture, and the original J2EE component can be very easy to expose as a web service; the advantage of the J2EE platform is still applicable to Web services: scalability , Reliability, openness.
The J2EE1.4Web service architecture is shown in Figure 1.
Figure 1 J2EE 1.4 Web Services
In Figure 1, gray represents a newly added technology in the J2EE 1.4 platform, and white represents the original technique. In the architecture of Figure 1, the client of the web service can be an applet or a standard Java client, and of course it can be a component running in a servlet or an EJB container; the client can pass the JAX-RPC to http / ssl protocol Access the web service. The service endpoint of the web service runs in a servlet or an EJB container, which operates as a JAX-RPC and Saaj.
Web service technology in J2EE1.4
J2EE 1.4 provides a Web Service Total Framework, under which the following techniques and frameworks:
Web Services for J2EE JAX-RPC SAAJ JAXR EJB2.1 Connector Architecture1.5
These techniques or frames are described below.
Web Services for J2EE
Web Services for J2EE is a structural specification for Web services under the J2EE platform, which is why how to support Web services in J2EE 1.3 or J2EE 1.4 application servers. Specifically, Web Services for J2EE defines client models, server models, deploy models WSDL binding and security related specifications, making web service clients and implementations to transplant from a J2EE vendor to another J2EE vendor. achieve. Web Services for J2EE is built based on JAX-RPC (JSR101) to provide client programming models. The client model allows web service clients (Java or non-Java, in J2EE, or outside J2EE) to access Web services in supporting JSR109 J2EE application servers. It also allows J2EE components to call Web services by using J2EE programming models (Java or non-Java, in J2EE or outside J2EE).
Under this frame, the server can have two options:
Servlet-based service endpoint: through the JAX-RPC implementation, the servlet container provides a running environment; the service endpoint based on stateless session beans: EJB2.1 specification must be followed, and the EJB container must be operated. JAX-RPC
JAX-RPC is the core technology of Web services in the J2EE 1.4 platform, then what is JAX-RPC?
It is a remote call based on, similar to RMI; specifies the operational environment of JAX-RPC; defines the mapping method of the XML data type to Java type; defines mapping between WSDL to Java; define JAX-RPC client programming Model (STUB interface, dynamic agent, dynamic call) defines a servlet-based service endpoint model; defines the SOAP message Handler framework; provides an extended framework for complex Java database type mapping.
The framework of JAX-RPC is shown in Figure 2.
Figure 2 Architecture of JAX-RPC
The JAX-RPC client can be based on J2SE, J2EE or J2ME running environment, and the server is a servlet or an EJB container. WSDL not only describes Web services, but also plays an important role in the port point of the JAX-RPC client.
Interoperability of JAX-RPC is shown in Figure 3. The server and client communicate via SOAP, SOAP uses HTTP as the underlying transport protocol.
Figure 3 Interoperability of JAX-RPC
Saaj
Saaj is divided from JAXM 1.0, the original JAXM 1.0 is divided into JAXM1.1 and Saaj1.1. Saaj contains an API that creates and reads the SOAP1.1 specification and the SOAP message with attachments, and also includes SOAP messages that send and receive request / response models.
SAAJ can be used by JAX-RPC, but also by Web service technology such as JAXM. It is a set of universal, processed the API of the SOAP message. The relationship between JAXM, JAX-RPC and Saaj is shown in Figure 4.
Figure 4 JAXM, JAX-RPC and SAAJ relationship
JAXR
JAXR is a service registration, publishing a relevant standard API. Since the current Web service registration provider is more, if you want to use these registration services in the J2EE platform, develop a separate API for each registration service, obviously unrealistic, Jaxr has multi-layer abstraction for the registration service, making Operating today or future Web service registration centers in the J2EE platform is possible. JAXR supports three registration service types: Jaxr Pluggable Provider, Registry-Specific Jaxr Provider, Jaxr Bridge Provider (support UDDI Registry, and EBXML REGISTRY / Repository, etc.).
The JAXR specification defines two levels of support for JAXR implementation, namely:
Level0: Used to support UDDI registration; Level1: Used to support EBXML registration.
The interoperability of JAXR is shown in Figure 5.
Figure 5 Interoperability of JAXR
As can be seen from the figure, access to UDDI, EBXML, etc. can be accessed through JAXR API, J2EE components, and desktop applications.
It should be noted that JAXR is not a new registration specification, which is just a programming interface for the original registry.
EJB2.1
The EJB2.1 specification provides support for web services to define stateless session beans as a web service endpoint model. This way, in the J2EE platform, there are two web service endpoints: servlet and state-based session beans based on servlet.
With EJB as a web service endpoint, you can also use a message Handler like servlet as a service endpoint.
Under the EJB2.1 specification, the message-driven bean does not have to implement a javax.jms.MessageListener interface. Thus, in addition to developing the JMS message driver bean, you can also develop a self-defined message-driven bean, such as com.mycompany.emaillistener. Combined with the connector support, you can develop a javax.xml.Messaging. On MeyListener, the message driver bean, which is available to provide web service support. Connector Architecture1.5
In the old connector structure, only the call from the J2EE component to the enterprise resource layer (EIS) one-way, and the resource layer cannot directly call J2EE components. In the new connector specification, J2EE components can be called directly from the enterprise resource layer. In this way, we can use the connector to expose EJBs and other components to the web service endpoint, so that web services are supported.
JAXM
First, it is necessary to declare that JAXM is not part of the J2EE platform, which is just an optional development package. Send and receive SOAP-based messages via JAXM, which defines two models of sending and receiving messages:
Request-response (Request-Resposne), is a point-to-point message sending model, the message sender sends a message to the corresponding server, this way is the simple programming, the disadvantage is that the message arrives at the server . One-way, this manner needs to use the JAXM message provider, and the message sent by one end is forwarded to the receiving end by the message provider; when the receiving end responds to the message, the same first passes through the JAXM message provider, and then The message provider sends to the original sender. This approach is that the message communication is asynchronous, and the advantage is that the message can be guaranteed to be reliable to the server, and the disadvantage is that the programming is complicated.
JAXM two messaging models are shown in Figure 6.
Figure 6 jAXM two messaging models
In the J2EE 1.4 platform, the EJB2.1 message driver bean can receive JMS messages or JAXM SOAP messages.
In the following cases, you can give priority to the use of JAXM instead of JAX-RPC:
To send a document-oriented data; to send a large amount of, coarsely granular, complex stream data; need to use asynchronous data exchange models; you need to ensure that the data transmitted is received at the other party.
The JAXM interoperability model is shown in Figure 7.
Figure 7 JAXM interoperability
Java API for developing Web services
Here is the API to develop web services in a Java environment, which lists only J2EE standard development packages and optional development kits.
J2EE Web Service Framework Core API:
J2EE 1.4 (JSR 151) JAX-RPC (JSR 101) JAXR SAAJ EJB 2.1
And handle SOAP messages related APIs:
JAXM: Send a SOAP message that receives asynchronous; SAAJ: Handle the SOAP message with attachment; JAX-RPC: is a J2EEWEB service key API, which defines the SOAP message Handler API ,; JMS: Don't forget, Java Message Service API can also send SOAP message.
And WSDL-related APIs:
Java API for WSDL: See JSR110; JAX-RPC: Defines mapping between Java and WSDL.
And UDDI-related API:
JAXR: High-rise API registered by web service.
And EBXML-related APIs:
EBXML Message Service: JAXM (JSR67) supported by EBXML messages; EBXML Registration: JAXR CPP / CPA: Java API for EBXML CPP / CPA (JSR 157) and XML document management related API:
JAXP (JAVA API for XML Processing, JSR 05), used to parse the XML document, can use the insertable parser in this API, such as DOM; JAXB (Java API for XML Data-Binding, JSR31), XML document processing High-rise API, used for the binding between XML document models and Java objects; streaming API for XML (JSR 173), a PULL-PARSING API based on Iterator.
And XML security related API:
XML Digital Signature (JSR 105) XML ENCRYPTION (JSR 106) XML Trust Service (JSR 104) Secure Assertion Markup Language, (SAML, JSR 155) WS-Security (JSR 183)
Other and Web services related APIs:
XML Transactioning API for Java (JSR 156), Java API for Oasis Btp; Java Process Component API (JSR 159); Web Services for J2ME (JSR 172), providing sends to J2ME devices, receiving SOAP messages; Web Services Metadata for J2EE (JSR 181), Metadata based on Web Services.
In addition to the APIs listed above, there are other organizations developed APIs, such as Apache, IBM, BEA, ORACLE and other organizations and companies, providing many APIs for web service development, and no longer listed here.
J2EE Web Service Development Procedure
Below to discuss the development steps of Web services, just outlined here, in the later articles we will combine this development step to make specific practices.
Define web services; implement web services; create a package that can be deployed; deploy web services in the J2EE platform; release web services to bind Web services to the Registry (Service Registry); serve the client's request.
The specific work of these development procedures is described below.
Define web services
The first step is to define a web service. Web services can be defined using the WSDL (Web Service Description Language) or use the Java interface definition. At the time of definition, you can use top-down, or how to use Buttom-Up, which method is used, depending on whether there is a J2EE component that will be exposed to a web service. If there is already a J2EE component, you can use the button-up method. In this case, the WSDL description is generated from the J2EE component by some tools; in the Top-Down mode, create a WSDL, then make specific implementations. Of course, it is not absolute. In some cases, the web service designer may map newly defined WSDLs to the original J2EE component, which occurs in the middle of top-down and buttom-up. solution.
When defining a web service, it is also necessary to define the endpoint interface of the web service, and the service endpoint interface is a Java interface specified by the JAX-RPC specification. This interface must expand the javax.rmi.Remote interface. Whether using servlet as a service endpoint or a stateless session bean, the interface must be defined in accordance with the specification. This interface can be written in Java programming languages, or use some tools to generate from WSDL, such as the WSDL2JAVA tool provided by Apache Axis, can generate a web service endpoint interface from WSDL. If it is a stateless session bean, the service interface will be specified in the deployment descriptor of the bean. Please refer to this series of articles in the deployment descriptor in the bean. Routines 1 is an example of a service interface definition.
Routine 1 Defining Service Interface
Public Interface Echoservice Extends Remote
{
/ **
* Returns the information provided by the user.
* /
Public String Echo (String Name) throws RemoteException;
}
Implement web services
There are three jobs that need to be done when implementing services:
1. Select a specific service endpoint implementation, that is, using the servlet as the service endpoint or the stateless session bean as the service endpoint.
2. Implement the business logic defined in the service interface, at this stage, you can use some tools to generate the framework required for the Web service run, such as WSCompile provided by WSDL2JAVA, SUN in AXIS.
3. Create a deployment descriptor that specifies the implementation of the specific EndPoint in the deployment descriptor.
If you use servlet as a service endpoint, implement the class code should appear as shown in routine 2.
Routine 2 servlet as a service endpoint
Public Class Echoservlet Implements EchoService
{
Public String Echo (String Name)
{
// The business logic is implemented.
Return "Hello:" Name;
}
}
If you use a stateless session bean as a service endpoint, implement the class code should appear as shown in routine 3.
Routine 3 uses stateless session beans as the service endpoint
Public Class Echobean Implements Javax.ejb.SessionBean
{
Public String Echo (String Name)
{
// The business logic is implemented.
Return "Hello:" Name;
}
... // Other EJB methods.
}
After the Web service is implemented, for the EJB component, you need to specify its service endpoint interface in the EJB deployment descriptor, as shown in routine 4.
Routine 4 Writing and Component Deployment Descriptor
It can be seen that the use of stateless session beans is used as a web service endpoint, and only the HOME interface and Remote (local) interface can only be specified to specify the service endpoint interface.
Create a deployable package
The next task is to create a deployed package, the Web Services for J2EE specifies the rules of packaging, which may contain the following content in the packaged app:
Web service deployment description, specifying the running feature of the web service, description file is WebServices.xml, is the standard description of the web service in the J2EE platform, just like the EJB-JAR.XML descriptor in EJB; WSDL description, for use Describe the web service; to other J2EE components, such as that component implements this web service; the standard description of J2EE components.
The WebServices.xml section deployment descriptor is shown in routine 5.
Routine 5 WebServices.xml section deployment descriptor
"http://www.ibm.com/standards/xml/webservices/J2EE/J2EE_WEB_SERVICES_1_0.DTD">
Deploy web services in the J2EE platform
The deployment task for Web services is different in different application server environments, depending on the tool provided by the application server. Deployment descriptors that can be generated and applied to the application server vendors are generally generated by the tools provided by the application server vendor.
Release web service
After deploying the Web service, you can publish the JAXR programming, or you can use the tools provided by the Registry, IBM, Microsoft, etc. provide UDDI registration tools. Services for the client's request
The client can discover the web service through UDDI and then further call. In the call, you can use JAX-RPC, or other programming languages or call frames can also be used. When using JAX-RPC, you can use the STUB generated by JAX-RPC, or the dynamic call mechanism or dynamic agent, etc. In addition, the client can also bind the web service to the server's JNDI namespace, then find this service in the JNDI namespace, further call.
If you bind the web service to the JNDI namespace, then call sample code as shown in routine 6.
Routine 6 calls Web services
Public class mytestbean imports sessionbean {
Public void getHello (...) {
Context ctx = new initialContext ();
Echoservice ES = (Echoservice) CTX.lookup ("Java: Comp / Env / Service / EchoService);
EchoserviceProvider SQP = es.getechoserviceport ();
String hello = sqp.echohello ("hellking");
...
}
}
Web service development tool
There are now many companies that organize the Web service development tools and operational environments, which are simply introduced.
SUN
Sun offers Java Web Services Developer Pack (Java WSDP), and its latest version of JWSDP is JWSDP1.2, which contains:
JAXP, JAXB, JAXP, SAAJ, JAX-RPC, JAXR Runture, Development Instance, which support the latest Web service standards; Java WSDP Registry Server (UDDI Server), a tool for publishing and querying Web services.
JWSDP1.2 is both a development tool and a Web service running environment.
You can get the latest version of JWSDP via http://java.sun.com/webservices/download.html.
In addition, in the J2EESDK1.4beta2 released by Sun, a comprehensive support for the latest technology of Web services can be used to learn the latest technologies for web services in the J2EE platform.
You can get J2EESDK1.4beta2 by http://java.sun.com/j2ee/download.html#sdk.
Tools provided by IBM
IBM provides a large number of web service development tools and operating environments. The most commonly used WSDK, which has a lightweight WebSphere server that can easily create a web service compatible with WebSphere servers. You can download the latest version of WSDK from the IBM's official website.
Tools provided by BEA companies
BEA provides Workshop as a development tool for Web services. You can use JWS specifications very fast in Workshop. Workshop and WebLogic servers are closely integrated. Web services developed in Workshop can be easily deployed on the WebLogic server. You can download the WebLogic development and Workshop trial version from the official website of the BEA.
Tools provided by Apache organizations
Apache's latest web service development tool is AXIS, which is an alternative to the Apache SOAP project. AXIS is also a WEB service running environment, which can be inserted into the task J2EE-compatible web server, running through Axis, quickly builds and JAX-RPC-compatible web services. You can get the latest version of Axis on http://ws.apache.org/axis/.
to sum up
Through the explanation of J2EE1.4Web services, I believe that readers have a more comprehensive understanding of the Web service architecture in the J2EE1.4 platform, Web service related technology and Web service development. If you can only remember one sentence, remember: JAX-RPC is a key technology for web services in the J2EE 1.4 platform. Web Services for J2EE is a structural specification for Web services under the J2EE platform.
Next step
It has now been a preliminary understanding of the web service architecture and technology under the J2EE 1.4 platform. The next step is to develop a web service using EJB2.1 specification under the J2EE 1.4 platform.
Reference
Other articles in this series "Develop Web Services with JAXM", "Develop Web Services with JAX-RPC: EJB as a Web Services End Point", "Servlets Develop Web Services: Servlet as Web Services End Point" J2EE Home Page, Java. Sun.com/J2ee J2EE 1.4 (JSR 151), www.jcp.org / jsr / detil / 151.jsp Web Services for J2EE (JSR 109), www.jcp.org / JSR / Detail / 109.jsp Jaxm, JAX -RPC, JAXR homepage, java.sun.com / xml Java Web Services Developer Pack download, java.sun.com/webservices/downloads/webservicespack.html Java Web Services Developer Pack teaching, java.sun.com / webservices / downloads /webserviceStutorial.html Web Services Zone http://www-900.ibm.com/developerWorks/cn/webservices/index.shtml axis Home, http://ws.apache.org/axis; Web Services for J2EE, version 1.0 : Http://www-900.ibm.com/developerWorks/cn/webservices/ws-jsr109-proposed/index.shtml
