Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Java Web services for various client types

Use attachments from Java, .Net, and browser clients for FOP Web services

By Avinash Gokli, JavaWorld.com, 09/12/03

Successful deployment of Java-based Web services requires detailed knowledge and understanding of fundamental concepts behind Web services, different Simple Object Access Protocol (SOAP) implementations, XML-related technologies, SOAP Fault monitoring, and finally, clients using the Web service.

In this article, I discuss Java-based Web services' design and code for different client types. I cover Axis and .Net implementations and briefly discuss the architecture of both implementations. You should already be familiar with Apache Struts.

Note: You can download this article's source code from Resources.

FOP Web services

Apache's Formatting Objects Processor (FOP) is a print formatter powered by Extensible Stylesheet Language formatting objects (XSL-FO) and an output independent formatter. FOP is a Java application that reads a formatting object tree and renders the resulting pages to a specified output. XSL FOP supports PDF, PCL, PS, SVG, XML, Print, AWT, MIF, and TXT output formats. Browser-, Java-, or .Net-based clients send attachments (as static XSL-FO documents or XML and XSL documents) to an FOP Web service, which renders inputs and responds to the user in the desired output format (e.g., PDF). These attachments are part of a SOAP message. The SOAP standard and most of its Java implementations support MIME (Multipurpose Internet Mail Extensions) attachments. Microsoft's .Net platform supports DIME (Direct Internet Message Encapsulation) attachments only. Apache's Axis SOAP implementation supports MIME as well as DIME attachments. The FOP Web service described in this article covers interoperability issues between Apache Axis for Java and Web Services Enhancements (WSE) 1.0 for Microsoft .Net. First, here's an FOP Web services overview.

FOP Web services are based on the Java platform and use Apache Axis as the SOAP engine. You can install Axis on Java-based Web servers, such as Apache Tomcat, IBM WebSphere, etc. The .Net client uses Microsoft's WSE implementation, and custom filters handle exceptions and SOAP Fault elements. The FOP Web services implementation uses Axis's custom handlers to process attachments prior to invoking XSL-FOP logic and processes responses that might contain SOAP Faults. The custom filters and handlers let you scale the Web services and reuse SOAP Faults and attachment-processing logic. Axis lets you wrap Java exceptions with SOAP Faults. I discuss Axis custom handlers and WSE custom filters later in the article.

Browser-, Java-, and .Net-based clients can invoke FOP Web services. Figure 1 displays an FOP Web service and its .Net (C#, Visual Basic, etc.) client environment. Figure 2 shows an FOP Web service with browser- and Java-based clients. These figures illustrate key differences in how clients invoke FOP Web services. The .Net client directly invokes FOP Web services. The browser-based client invokes FOP Web services using JavaServer Pages (JSP), Struts, Façade, and FOPClient. The Java client invokes FOP Web services using Façade and FOPClient.

The .Net client (e.g., user) invokes a Windows program, FOPClient.exe, which in turn reads attachments from a local directory. The browser-based client also reads attachments from a local directory and then invokes a URL for the FOP Web service. The attachments are inputs to the FOP Web services' FOPService class and are rendered to the XSL-FO processor to perform transformation to the desired output format. The FOPService class then sends a response message to the client. The response message can be a SOAP Fault or attachment (e.g., PDF) that you can store in a local directory.

Figure 1. .Net client FOP Web service. Click on thumbnail to view full-size image.

Figure 2. Browser (with Struts integration) and Java client FOP Web service. Click on thumbnail to view full-size image.

Apache Axis architecture overview

In this section, I briefly discuss how the Axis engine works. Axis's primary responsibility is to invoke a series of handlers and process SOAP messages. Axis uses Message objects to wrap SOAP request, response, and fault messages. These Message objects are placed into MessageContext objects, and become available to all Axis implementation components. So the MessageContext object is a container for request, response, and fault messages and also offers other information, such as target service name, transport protocol for messages, and request message type (e.g., RPC (remote procedural call)/document). The MessageContext object's structure includes a request message and/or response message. Each message has a SOAPPart object and an optional Attachments object (they are Axis APIs). An FOP Web service includes the Attachments object.

The handlers are invoked in order, which is primarily determined by deployment configuration (server-config.wsdd). I will discuss Axis deployment configuration later. A MessageContext object passes through a configured set of handlers; each handler does whatever the MessageContext object requires. An FOP Web service includes a Handler(AttachmentHandler) that processes attachments included in the incoming request message and a Handler(SOAPFaultHandler) that processes SOAP Faults included in the response message. Figure 3 illustrates the Axis architecture.

Figure 3. Axis architecture and SOAP message processing. Click on thumbnail to view full-size image.

Microsoft .Net WSE architecture overview

FOP Web services implementation supports .Net clients by using Microsoft's WSE. WSE represents a subset of Microsoft's GXA (Global XML Architecture) and extends to standard SOAP functionalities. WSE includes:

• WS-Security: Implements security requirements for Web services.
• WS-Routing: SOAP-based protocol that routes SOAP packets from one point to another over different types of transport protocols, such as HTTP, TCP, asynchronous, etc.
• WS-Referral: The WS-Referral protocol provides instructions about how you should route SOAP messages.
• WS-Attachment: Lets you attach files, such as images, XML, etc., to a SOAP message without serializing its contents into XML. Examples include sending files such as images, XML, etc. At present, .Net implementation supports DIME attachments only, which creates interoperability issues between Java and .Net platforms. WSE uses DIME for sending and receiving SOAP messages with additional attachments, like binary files and XML fragments. DIME encapsulates a SOAP message and its related attachments in a MIME-like way. As with SOAP, you send DIME messages using standard transport protocols such as HTTP, TCP, and UDP. In FOP Web services, you use DIME attachments to send XML and XSL or FO files to the FOPService class.
• WSE and filters (standard and custom): WSE provides standard sets of classes (under the Microsoft.Web.Services namespace) to implement the above functionalities. WSE includes a standard set of filters and allows custom filters to provide additional functionalities, such as managing SOAP Faults or encrypting and decrypting SOAP request and response messages. Standard and custom filters intercept SOAP request and response messages. WSE's built-in outgoing and incoming standard filter sets provide functionality for diagnostic, security, timestamp, referral, and routing features.

Figure 4 illustrates two custom filters, SOAPFaultOutputFilter and SOAPFaultInputFilter. The SOAPFaultOutputFilter class intercepts and processes SOAP Faults related to request messages and sends them to the Windows Event Log facility. Similarly, SOAPFaultInputFilter processes SOAP Faults related to response messages and sends them to the Windows Event Log facility. The custom filters derive from the SOAPOutputFilter (for request messages) and the SOAPInputFilter (for response messages) classes. You must add these filters to the PipeLine (Microsoft.Web.Services.PipeLine) class and must override ProcessMessage() methods of the SOAPOutputFilter and SOAPInputFilter classes. I'll show you code to implement custom filters later.

 

Improve efficiency with Visual Studio(r) 2010 Beta 2. - Microsoft

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.