9.5 Document-Oriented Web Services

The preceding sections have shown how to develop a Web service using a stateless session bean and how to access a Web service given its WSDL description. The J2EE platform also supports a document-oriented programming model for EJB-based Web services. This document-oriented programming model is made possible because JAX-RPC supports passing parameters to Web service operations not only in the document mode defined by SOAP and WSDL, but also as attachments in messages. (For a more detailed treatment of these concepts, refer to the JAX-RPC section of the Java Web Services Tutorial, at http:/java.sun.com/webservices.)

Today, enterprises prefer to interact by using paper or electronic documents. This document-oriented interaction style contrasts with the object-oriented RPC interaction style of the previous examples in this book. However, both interaction styles are useful in different scenarios. The document-oriented style is often best when it is necessary to build Web services that reflect traditional document-based business processes.

The document-oriented style of interaction is useful in the following circumstances:

  • A loosely coupled interaction is desired. Loose coupling implies that the two communicating parties may be separated by geographical or temporal distances that make it difficult to interact in a tight request/response pattern. With loose coupling, the communicating parties need to agree only on the document formats to be exchanged.

  • The interaction may be asynchronous and involve complex interaction patterns. The sender might not expect an immediate reply from the receiver. The sender thus continues with other processing after sending the request. The receiver receives the request and might process it at a later time or perhaps might need human intervention to process the request. The receiver might send multiple messages back to the sender while the receiver is processing the request. For example, the receiver might send an initial acknowledgment followed by status messages as the request moves through various stages of processing.

  • Large-grained operations are performed. Each request involves a significant amount of work that might take days to complete.

  • The receiver processes the document as is. The receiver does not convert the entire document into a programming language native data structure, such as Java objects. Instead, the receiver extracts only the document elements of interest and passes the document to another component in the business workflow to complete other steps in the processing.

  • The content exchanged is considered "rich. " The documents exchanged have complex structures, including multiple types of elements, constraints on their values, and optional elements. Often the documents are self-describing, allowing the receiver to make sense of the content.

Document-oriented processing generally operates on XML documents. For such document-oriented styles of processing, the JAX-RPC and JAX-P standards provide techniques and APIs that allow application developers to create, send, receive, and consume XML documents.

The JAX-P specification, as well as the JAX-B specification and the allied W3C standards SAX, DOM, and TrAX, define APIs to create and process XML documents. An enterprise bean may use these APIs to directly create an XML document and populate it with its various elements before sending it to a Web service. An enterprise bean implementing a Web service may also use these same APIs to process a received XML document, using the APIs to extract the values associated with the received document's elements into Java objects and data types.

The following options exist for sending and receiving XML documents between partners in a Web service interaction:

  • Send the XML document as a text string over an HTTP request. This may be done by using the J2SE URL APIs to open an HTTP URL connection to the Web service and then to post the XML document. The Web service side uses a servlet to receive the incoming text and to convert it to an XML document. The Web service then forwards the XML document to an enterprise bean for processing. Most Web and application server products today support this option, although it is low level and potentially more complex to program. However, this option may not be fully interoperable, because it does not use the Web services standards WSDL and SOAP.

  • Use the SOAP with Attachments protocol and the WSDL MIME data type bindings. The WSDL and SOAP standards define how to send and receive documents including XML documents, text documents, binary images, and so forth in SOAP messages, using the MIME data type encodings. JAX-RPC defines corresponding Java APIs for document-oriented interactions based on these standards. An XML document is represented in the method signatures of the Web services endpoint interface, using the JAX-P type javax.xml.transform.Source. This makes it possible for a client to construct an XML document and provide it as a SAX, DOM, or stream source object to the method call on the Web services interface. Also, an enterprise bean can extract the XML document from the Source object that is passed in as a parameter to the business method call.

As you can see, the EJB architecture and allied J2EE APIs provide the necessary features to enable the development of Web services that use document-oriented styles of processing.



Applying Enterprise Javabeans
Applying Enterprise JavaBeans(TM): Component-Based Development for the J2EE(TM) Platform
ISBN: 0201702673
EAN: 2147483647
Year: 2003
Pages: 110

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