Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
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.
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
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.
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
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.
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:
Microsoft.Web.Servicesnamespace) 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 class intercepts and processes SOAP Faults related to request messages and sends them to the Windows Event Log facility.
SOAPFaultInputFilter processes SOAP Faults related to response messages and sends them to the Windows Event Log facility. The custom filters derive
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
SOAPInputFilter classes. I'll show you code to implement custom filters later.
|Forum migration complete By Athen|
|Forum migration update By Athen|
|Not a professional article By Anonymous|
|Hurray For Practical Examples By Anonymous|
|More information? By RWHaug|