Web Services


The adoption of XML in the enterprise has seen an explosion of new trends and technologies that apply the XML standards to existing problems. The integration problem is no different. Because XML parsers are available on all platforms, XML can be used as an intermediate format to transfer messages between software components. Messages can be written, transferred, and read between many heterogeneous platforms. This solves the first problem of interoperability between platforms. The second problem to solve is the transferring of the XML data between systems, and the logical choice for this protocol is HTTP, which offers the distinct advantage of being the most common protocol to be allowed through firewalls.

XML-RPC was one of the first technologies to take advantage of XML. XML-RPC utilizes the standard HTTP POST mechanism to transfer content of type "text/xml" from client to server. It is a relatively simple model, yet is extraordinarily powerful. Listing 10-1 is a simple example of XML for a method invocation using XML-RPC. In this example, we will add two numbers.

Listing 10-1: XML-RPC representation of a method call.

start example
 <?xml version="1.0"?> <methodCall>   <methodName>calc.AddNumbers</methodName>     <params>       <param>         <value>           <int>10</int>         </value>       </param>       <param>         <value>           <int>12</int>         </value>       </param>     </params> </methodCall> 
end example

The corresponding result of the XML-RPC call is shown Listing 10-2.

Listing 10-2: XML-RPC representation of a method call result.

start example
 <?xml version="1.0"?> <methodResponse>     <params>         <param>             <value>             <int>22</int>             </value>         </param>     </params> </methodResponse> 
end example

The Simple Object Access Protocol, also known as SOAP, further builds on the pioneering work of XML-RPC and adds further definition of message envelopes, encoding, and RPC mechanisms. SOAP is implemented and supported on various platforms. The Apache development group, IBM, and Microsoft also show strong support for SOAP. SOAP is the underlying protocol of web services, and its lightweight design is proving to be a valuable asset. As an example of lightweight design, complex issues such as distributed garbage collection and the creation and destruction of distributed objects are left out of the standard. These issues are already dealt with in underlying implementations such as Enterprise JavaBeans, so there is no need to repeatedly reinvent and redefine the same architectures.

Where CORBA uses IDL for defining interfaces, web services use the Web Services Definition Language (WSDL) to define the interfaces of components and their location. It uses the HTTP protocol to send messages between components. WSDL can be used in conjunction with the Universal Description, Discovery and Integration Initiative (UDDI), which is a repository of available web services.

Using web services, compatibility among legacy systems, J2EE applications, and even Microsoft .NET applications is possible. These require a relatively small investment, since there is no run-time code that must be purchased (as with CORBA), and the required specifications are relatively simple to implement. Web services can be seen as the glue between the various technologies and legacy systems available in today's networked enterprise and business-to-business communication infrastructures.

Web Services and EJB

Web services allow components to connect to other components written in different technologies and located on different networks. So where do web services fit into J2EE? Web services are another connectivity interface to our EJB. We already have a local and a remote set of interfaces, and we simply introduce another interface that is known as a web service endpoint. This allows web-service connectivity into the J2EE environment.

The web service endpoint interface (Figure 10-4 is defined according to the JAX-RPC specification. JAX-RPC stands for Java API for XML-based RPC and is an API for developing web services using XML remote procedure calls. JAX-RPC supports the standard Java data types, JavaBeans, and collections. We will take the EuroExchange stateless session bean example from Chapter 4 and develop a web service endpoint for it. To achieve this, we define a service interface that extends the java.rmi.Remote interface. Each method signature must be defined to throw a java.rmi.RemoteException and follow the JAX-RPC rules for data types. The EuroExchange web service endpoint is defined in Listing 10-3. This interface looks very similar to the EJB remote interface, although as you will notice, it does not import or use any classes or interfaces from the javax.ejb package.

Listing 10-3: Web service interface for the EuroExchange EJB.

start example
 package ejb.exchangeSL; import java.rmi.RemoteException; import java.rmi.Remote; public interface EuroExchangeService extends Remote {   public float changeFromEuro(String currency, float amount) throws RemoteException;   public float changeToEuro(String currency, float amount) throws RemoteException;   public void setExchangeRate(String currency, float euro,float foreignCurr)     throws RemoteException; } 
end example

click to expand
Figure 10-4: Web Service Endpoints in J2EE.

The reader may question why a new, separate interface is needed for a web service endpoint. It should be noted that the JAX-RPC web services packages are separate from the EJB packages, and it is possible to implement a web service endpoint without the use of EJB. For clarity, we have separated the interfaces. Many commercially available products have the ability to automatically generate the web service endpoint from an existing EJB remote interface. The generated web service endpoint will expose only those methods that adhere to the JAX-RPC specification and data types. Another approach to avoid the defining methods in multiple interfaces is to use interface inheritance (Listing 10-4) and create your EJB remote interface from the web service endpoint.

Listing 10-4: Using interface inheritance to create web service and EJB endpoints.

start example
 package ejb.exchangeSL; import javax.ejb.EJBObject public interface EuroExchangeEJB extends EJBObject, EuroExchangeService { } 
end example

Data Types Supported by JAX-RPC

JAX-RPC supports the data types and primitives shown in Table 10-2. Single and multidimensional arrays of supported types are also allowed. Your own developed classes and JavaBeans may also be used in the web service endpoint interface. They must, however, also adhere to the JAX-RPC rules.

Table 10-2: Supported Data Types in JAX-RPC.

boolean and java.lang.Boolean

byte and java.lang.Byte

double and java.lang.Double

float and java.lang.Float

int and java.lang.Integer

long and java.lang.Long

short and java.lang.Short

java.lang.String

java.math.BigDecimal

java.math.BigInteger

java.util.Calendar

java.util.Date

java.util.ArrayList

java.util.LinkedList

java.util.Stack

java.util.Vector

java.util.HashMap

java.util.Hashtable

java.util.Properties

java.util.TreeMap

java.util. HashSet

java.util.TreeSet

All JavaBeans, and classes and fields, should also have a public default constructor and must not implement the java.rmi.Remote interface.

In order to deploy our web service endpoint with our Enterprise JavaBean, we must also modify the ejb-jar.xml deployment descriptor file to allow for the additional service endpoint element. The updated deployment descriptor is shown in Listing 10-5.

Listing 10-5: Deployment descriptor for a web service endpoint.

start example
 <?xml version="1.0" encoding="UTF-8"?> <ejb-jar version="2.1" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd">   <display-name>sl3</display-name>   <enterprise-beans>     <session>       <ejb-name>EuroExchangeBean</ejb-name>       <home>ejb.exchangeSL.EuroExchangeHome</home>       <remote>ejb.exchangeSL.EuroExchange</remote>       <ejb-class>ejb.exchangeSL.EuroExchangeBean</ejb-class>       <service-endpoint>ejb.exchangeSL.EuroExchangeService</service-endpoint>       <session-type>Stateless</session-type>       <transaction-type>Bean</transaction-type>       <security-identity>         <use-caller-identity/>       </security-identity>     </session>   </enterprise-beans> </ejb-jar> 
end example

The ejb-jar file is then run through a deployment tool. The J2EE Reference Implementation from Sun Microsystems contains a tool called wscompile, which is used for web service endpoint deployment. This tool generates the WSDL file from the service interface and deployment descriptor settings. The generated WSDL file is shown in Listing 10-6.

Listing 10-6: The WSDL file for the EuroExchange Service.

start example
 <?xml version="1.0" encoding="UTF-8"?> <definitions name="EuroExchangeService" targetNamespace="urn:Euro" xmlns:tns="urn:Euro" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">   <types/>   <message name="EuroExchangeService_changeFromEuro">     <part name="String_1" type="xsd:string"/>     <part name="float_2" type="xsd:float"/></message>   <message name="EuroExchangeService_changeFromEuroResponse">     <part name="result" type="xsd:float"/></message>   <message name="EuroExchangeService_changeToEuro">     <part name="String_1" type="xsd:string"/>     <part name="float_2" type="xsd:float"/></message>   <message name="EuroExchangeService_changeToEuroResponse">     <part name="result" type="xsd:float"/></message>   <message name="EuroExchangeService_setExchangeRate">     <part name="String_1" type="xsd:string"/>     <part name="float_2" type="xsd:float"/>     <part name="float_3" type="xsd:float"/></message>   <message name="EuroExchangeService_setExchangeRateResponse"/>   <portType name="EuroExchangeService">     <operation name="changeFromEuro" parameterOrder="String_1 float_2">       <input message="tns:EuroExchangeService_changeFromEuro"/>       <output message="tns:EuroExchangeService_changeFromEuroResponse"/>             </operation>     <operation name="changeToEuro" parameterOrder="String_1 float_2">       <input message="tns:EuroExchangeService_changeToEuro"/>       <output message="tns:EuroExchangeService_changeToEuroResponse"/>             </operation>     <operation name="setExchangeRate" parameterOrder="String_1 float_2 float_3">       <input message="tns:EuroExchangeService_setExchangeRate"/>       <output message="tns:EuroExchangeService_setExchangeRateResponse"/>              </operation></portType>   <binding name="EuroExchangeServiceBinding" type="tns:EuroExchangeService">     <operation name="changeFromEuro">       <input>         <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"              use="encoded" namespace="urn:Euro"/></input>       <output>         <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"              use="encoded" namespace="urn:Euro"/></output>       <soap:operation soapAction=""/></operation>     <operation name="changeToEuro">       <input>         <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"              use="encoded" namespace="urn:Euro"/></input>       <output>         <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"              use="encoded" namespace="urn:Euro"/></output>       <soap:operation soapAction=""/></operation>     <operation name="setExchangeRate">       <input>         <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"              use="encoded" namespace="urn:Euro"/></input>       <output>         <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"              use="encoded" namespace="urn:Euro"/></output>       <soap:operation soapAction=""/></operation>     <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="rpc"/>             </binding>   <service name="EuroExchangeService">     <port name="EuroExchangeServicePort"             binding="tns:EuroExchangeServiceBinding">             <soap:address location="REPLACE_WITH_ACTUAL_URL"/>     </port>   </service> </definitions> 
end example

The compiler-generated WSDL file should then be modified with location information. This is simple and involves modification of the soap:address location value from REPLACE_WITH_ACTUAL_URL to the actual URL of the service. The value can be set to a URL such as http://www.apress.com/EuroExchangeService. After the EJB is deployed it can then be accessed via SOAP and the web service endpoint from both Java and non-Java clients. Of course, Java clients can still access the EJB via RMI-IIOP using the existing remote interface (firewalls permitting).

Web service endpoints utilize XML and HTTP, which by nature exhibit much inferior performance to that of pure Java RMI interfaces and the IIOP protocol used in many of the J2EE containers on the market. This is because of the verbose nature of XML, which results in rather large data packets being transported. The listing of the WSDL file above should serve as a sufficient example as to how verbose an XML document can become. As such, web service endpoints should be used as endpoints or integration points into the J2EE system.

An EJB Calling a Web Service

For an EJB to invoke a web service, the JAX-RPC client API can be used. The EJB 2.1 specification adds a new element to the deployment descriptor called the service reference. It is specified using the <service-ref> tag and allows a web service to be described in the deployment descriptor and used from inside an EJB. Web services that are defined using the <service-ref> tags do not have to be implemented in EJB or even Java. They may, in fact, be developed on the Microsoft platform.

Let us now use an EJB to call a web service. The first step is to define the service references in the deployment descriptor, which we show in Listing 10-7.

Listing 10-7: EJB deployment descriptor with service reference.

start example
 <session> ... <ejb-name>WebServiceCallingBean</ejb-name> <ejb-class>ejb.WebServiceCallingBean</ejb-class> ... <service-ref>     <description> This is a reference to the EuroExchange Web Service used from Another EJB.     </description>     <service-ref-name>service/EuroExchangeService</service- ref-name> <service-interface> ejb.exchangeSL.EuroExchangeService </service-interface> </service-ref> ... </session> 
end example

The service reference tags are used to define a remote web service and are used in a similar manner to resource references. The <service-ref-name> value should follow the standard of service/<service name>, and the java interface for the web service is also specified. The calling EJB that utilizes the web service reference uses the local JNDI context to retrieve the reference in the name space java:comp/env/service. See Listing 10-8.

Listing 10-8: EJB as a client to a web service.

start example
 import javax.naming.* ... Context ctx = new InitialContext(); javax.xml.rpc.Service service = ctx.lookup("java:comp/env/service/              EuroExchangeService"); EuroExchangeService euroService = service.getPort(EuroExchangeService.class); float value = euroService.changeToEuro ("USD", 100); ... 
end example

Web services offer interoperability between heterogeneous systems using standard protocols and XML documents. Web services are integrated into EJB 2.1 and allow integration between EJB and non-EJB systems (including non-Java systems such as Microsoft .NET). To convert an existing Enterprise JavaBean into an available web service, one must create a web service endpoint either manually or using a container-provided tool. The web service endpoint must adhere to the JAX-RPC specification. A Web Services Definition Language (WSDL) file is generated that must be accessible or supplied to clients. Clients of a web service endpoint can be non-Java or Java and can be EJB components. EJB components wishing to call web services should use the <service-ref> tags and the local JNDI context to access the web service.




Enterprise JavaBeans 2.1
Enterprise JavaBeans 2.1
ISBN: 1590590880
EAN: 2147483647
Year: 2006
Pages: 103

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net