Using RPC-Style Web Services with J2EE - Summary (Page 15 of 15 )
Today, you have seen how Web Service protocols and application styles provide a future route for many application integration projects. Web Services provide a framework for the integration of internal or external applications using HTTP and XML. You have seen that Web Service protocols provide a better solution when exposing functionality for integration than existing RPC or Web mechanisms, and you have explored the Web Service functionality offered in J2EE.
You deployed a servlet-based JAX-RPC Web Service and then called this Web Service through a proxy generated from its WSDL. You deployed an EJB-based JAX-RPC Web Service and used the WSDL generated from it to create a Web Service client. You examined how state and lifecycle are handled for Web Service implementations, and you looked at issues around complex type mapping when marshaling between Java objects and XML data types.
Q&A
SOAP uses HTTP as a transport, so does this mean that it is restricted to synchronous interaction?
Any transport can be used for a SOAP message as long as someone creates a binding for it. SOAP bindings have been defined for SMTP, and such bindings can be created for any other transport mechanism, such as FTP or MQSeries, regardless of whether such mechanisms are synchronous or asynchronous.
Also, although HTTP is inherently synchronous, you can use it to pass XML documents that consist of business "messages" and that form part of a workflow. If the sender of the message is also capable of receiving such messages, it may receive a response of some form at some future point in time. This uses two synchronous interactions to create asynchronous behavior.
Can I use JAX-RPC to send an XML document rather than performing an XML-based RPC call?
Although it is possible to send an XML document as a parameter to an RPC call using JAX-RPC, document-centric interactions are intended to be serviced by the SOAP with Attachments API for Java (SAAJ) and the Java API for XML Messaging (JAXM). You will encounter SAAJ and JAXM in more detail tomorrow.
What sort of information is contained in a WSDL document?
A WSDL document contains two basic types of information. It contains the interface for the Web Service that consists of type information, message definitions (parameters and return types), operation definitions (methods that can be called), port types (groupings of methods), and bindings that define how port types are carried over different transports. A WSDL file also contains specific location information for a Web Service in the form of ports that provide a specific location for an instance of a port type and service descriptions that define groups of ports.
Why can I only expose stateless session EJBs as Web Services under JAX-RPC and not other types?
Although JAX-RPC provides an RPC-style interface to a Web Service, the whole ethos of Web Services is based around a stateless model of operation. The maintenance of state in traditional RPC terms relies on either an ongoing connection or a protocol-specific token being passed. Neither of these suits the style and granularity of Web Service interaction. All Web Service implementations under JAX-RPC for J2EE are required to be stateless, so only stateless session EJBs match this requirement.
Exercises
Today's exercise is to extend the JAX-RPC front end for the Agency case study so that a client can find all the applicants at a specific location. In the exercise directory under Day 20 on the accompanying Web site there is a version of the Agency case you have seen in this chapter. Your task is to add to the Service EJB a method that takes the name of a location and returns an array of strings representing the applicants registered at that location.
The provided files consist of the stateless session bean discussed in this chapter (Service) that allows you to list all the jobs at a particular location.
If you need a few pointers, you should:
Update the Service.java and ServiceImplementation.java files in day20/ exercise/src/agency. You can get a list of applications for a location using the findByLocation method on the ApplicantHome interface.
Build the classes using asant build-service.
Open the ear file created in the build folder and add to the Service EJB an ejb reference for the applicant home interface.
Verify and deploy your EAR to your J2EE RI application server (using deploytool or asant deploy-service).
Update the AgencyServiceClient.java file in day20/exercise/src/client to call your new method.
Build the client using asant build-client and then run it with asant run-client.
A complete solution can be found in the agency folder on the Day 20 folder on the accompanying Web site.
 This chapteris fromTeach Yourself J2EE in 21 Days, second edition, byMartin Bond et. al.(Sams, 2004, ISBN: 0-672-32558-6). Check it out at your favorite bookstore today. Buy this book now.
|
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
/ 11 
