Achieving Java/J2EE Interoperability
It is safe to assume that any enterprise in the world consists of multiple software platforms, and the stakeholders of the enterprise have made significant investments in existing solutions based on COM, COM+, and other non-Microsoft technologies. The WCF team has provided a comprehensive integration model to work alongside, around, and within existing COM+ solutions. In Chapter 10, we focused on how WCF can work with existing COM+ applications from both a client and a service. This chapter focuses on Java/J2EE (and other technology) interoperability capabilities and issues.
The tack for cross-platform interoperability is to work primarily with the standards as published by industry-supported and industry-controlled committees. However, each vendor has the tendency to implement its "interpretation" of the standard. To achieve a neutral perspective, the WCF team generated many compatibility tests for a subset of the different vendor implementations. In addition to internal testing, Microsoft created the WCF Interoperability Plug-Fest[] program to work with stack vendors to achieve greater compliance and compatibility.
[] You can find documents and background for the WCF Interoperability Plug-Fest program at http://www.mssoapinterop.org/ilab/.
One of the more notable participants in the Plug-Fest program and offering general WCF interoperability has been Sun. The Sun web services team worked alongside the WCF team on several occasions and has publicly released an open source framework focused primarily on interoperability with WCF. Started as Project Tango,[] it has evolved into Web Services Interoperability Technology[](WSIT), which is available today in open source form. The main capabilities and standards provided in WSIT are as follows:
[] You can find Harold Carr's blog entry about Project Tango at http://weblogs.java.net/blog/haroldcarr/archive/2006/02/an_overview_of_1.html.
[] You can find the WSIT home page at http://java.sun.com/webservices/interop/index.jsp.
Bootstrapping communication (WS-MetaDataExchange)
Securing communication (WS-SecurityPolicy, WS-Security, and WS-Trust)
Optimizing communication (MTOM and WS-SecureConversation)
Enabling reliability (WS-ReliableMessaging)
Enabling atomic transactions (WS-Coordination and WS-AtomicTransactions)
Another major participant in the WCF/.NET interoperability process is the Axis project from the Apache Software Foundation.[] It's a major participant in that the WCF team has worked with Axis on its own, ensuring WCF compliance with the WS-* standards by leveraging Axis. Additionally, the Axis team reports that it too has done interoperability testing for the Axis2 1.0 release from May 2006.
[] You can find the Apache Axis2 home page at http://ws.apache.org/axis2/.
Non-Microsoft SOA Platforms
We briefly discussed Sun as a commercial product vendor that has resources focused on .NET and WCF interoperability. Sun is not alone in that commitment. We cannot cover in this short chapter what every vendor or open source team has produced in support of WS-* and WCF/.NET interoperability. However, we'll focus on a few key vendors that have openly supported and worked with .NET interoperability issues. Table 13-1 lists the leading vendors and their support of the WS-* standards within their products.[]
[] Apache is listed as a vendor even though it is an open source foundation supported by community members.
| vendor/Product | MTOM? | WS-Security? | WS-ReliableMessaging? |
|---|---|---|---|
| Microsoft | Yes | Yes | Yes |
| IBM | No | Yes | Yes |
| Sun | Yes | Yes | Yes |
| Apache | Yes | Yes | Yes |
| Tibco | No | Yes | No |
| gSOAP | Yes | Yes | No |
One of the earliest interoperability efforts was to implement the WS-I Basic Profile. What is the WS-I Basic Profile? You'll dive into that topic now.
Interoperability with WS-I Basic Profile
In the beginning stages of the industry's implementation of the standards, people recognized that many of the stacks had been built upon an inconsistent foundation of technologies. Some vendors had chosen different versions of WSDL or SOAP as examples. Even how SOAP faults were returned by each implementation had been done differently in each implementation. So, getting interoperability amongst different implementations was a substantial challenge. In many instances, it was impossible without a significant amount of custom coding. Given the amount of coding required, it precluded the need for a vendor implementation and threw the whole "build vs. buy" question heavily in favor of in-house development when interoperability was required.
The early vendor SOA frameworks did not conform to common open standards (in other words, they were vendor specific). This was mostly because of both customer and market demands. However, this was a major obstacle to achieve "true" interoperability between multiple vendors.
The major industry participants combined resources forming the Web Services Interoperability (WS-I) Organization to facilitate and move web service standards forward in a non-proprietary and open manner. WS-I consists of a mix of products, services, and most important, user corporations—the primary focus of why we as solution architects exist. Currently, approximately 90 organizations are participating, with nearly 30 percent comprised of user corporations.[] We'll discuss the core components of the Basic Profile in the next section.
[] This is based upon WS-I.org information as of June 12, 2006.
Core Components
In April 2004, WS-I released Basic Profile 1.0.[] This set of specifications laid the groundwork for vendors and customers to begin from a sound base. The specification represents the first generation of interoperable web service specifications. The importance of the Basic Profile cannot be minimized because with the initial release, many product companies and open source groups recognized that the market will no longer allow stand-alone proprietary interoperability stacks.
[] You can find the WS-I Basic Profile 1.0 home page at http://www.ws-i.org/Profiles/BasicProfile-1.0.html.
The Basic Profile 1.0 specification is built upon a consistent set of foundation specifications that together form the core of it:[]
[] You can find IBM Developer Works at http://www-128.ibm.com/developerworks/webservices/library/ws-basicprof.html.
SOAP 1.1
WSDL 1.1
UDDI 2.0
XML 1.0 (Second Edition)
XML Schema Part 1: Structures
XML Schema Part 2: Datatypes
RFC 2246: The Transport Layer Security Protocol Version 1.0
RFC 2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
RFC 2616: HyperText Transfer Protocol 1.1
RFC 2818: HTTP over TLS
RFC 2965: HTTP State Management Mechanism
The Secure Sockets Layer Protocol Version 3.0
Given the agreement amongst the participants, interoperability at the basic level was now a greater possibility. In April 2006, the WS-I committee updated the Basic Profile to version 1.1 with some updates and some corrections to published errata. We want to emphasize that interoperability is not a guarantee that vendors will adhere to specifications. Given the complex nature of the WS-* specifications, small variations in how each framework interprets the specification generally lead to incompatibilities. This is why Microsoft has worked with other vendors to validate WCF with the major competitors that also happen to be members of the WS-I organization. We'll now discuss the Basic Profile implementation by Microsoft starting with ASP.NET.
ASP.NET Support of Basic Profile
Since ASP.NET 1.0/1.1 was a shipping product prior to the official specification release (it was still a "draft" in 2002), it didn't offer official support for Basic Profile 1.0; however, it was possible by following simple guidelines[] to implement it. With ASP.NET 2.0, you enable support for Basic Profile 1.1 by applying the WebServiceBinding attribute to your service class, as shown in Listing 13-1.
[] You can find WS-I Basic Profile 1.1 at http://www.ws-i.org/Profiles/BasicProfile-1.1.html.
Example. Enabling Basic Profile in ASP.NET 2.0
[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class WebService : System.Web.Services.WebService {...} |
Microsoft Web Service Extensions
During the evolution of web services, Microsoft provided an add-on framework to the core .NET runtime (both 1.1 and 2.0) in support of the evolving web service standards. With .NET 1.1 Microsoft released version 1.0 and 2.0 of Web Services Enhancements (WSE). With the release of .NET 2.0, Microsoft updated WSE to version 3.0.
WSE 2.0 offered no direct validation of producing services that were guaranteed to be Basic Profile compliant. Because ASP.NET 3.0 added the WebServiceBinding attribute to provide validation of conformance to Basic Profile 1.1, WSE 3.0 inherited that capability.
Additionally, the Microsoft Patterns and Practices team published a reference application[] demonstrating how to build services that conform to WS-I Basic Profile along with an implementation guidance document.[]
[] http://msdn.microsoft.com/library/en-us/dnsvcinter/html/WSI-BP_MSDN_LandingPage.asp
[] You can find the Microsoft WS-I Basic Security Profile sample application at http://www.gotdotnet.com/codegallery/codegallery.aspx?id=0fecd2c7-b2b1-4d85-bd66-9d07a6ecbd86.
Windows Communication Foundation Basic Profile Support
WCF enables WS-I Basic Profile 1.1 through the BasicHttpBinding class. So, with WCF, writing base-level interoperable services that confirm to WS-I Basic Profile is as easy as leveraging the BasicHttpBinding class through code, as shown in Listing 13-2.
Example. Applying Basic Profile in Code
Uri baseAddress = new Uri( "http://localhost:8080/MyService" );
//Instantiate new ServiceHost
myServiceHost = new ServiceHost( typeof( MyService ), baseAddress );
//the following for programmatic addition of Basic Profile 1.1
BasicHttpBinding binding = new BasicHttpBinding();
myServiceHost.AddServiceEndpoint(
typeof( IMyInterface,
binding,
baseAddress); |
In Listing 13-2, we just add the BasicHttpBinding instance to the ServiceHost instance's endpoints. Again, the power of WCF is that you can also enable the same capability for Basic Profile 1.1 support declaratively through configuration, as shown in Listing 13-3.
Example. Applying Basic Profile Through Configuration
<bindings>
<basicHttpBinding>
<binding name="WebServiceSoap"
...
</binding>
</bindings> |
Using the declarative, configuration-driven model allows the distinct abstraction of both the service and the client of the service (given both sides are WCF) from the transport and the messy details of the available bindings. Abstraction is critical to the WCF programming model and is what sets the tools and framework apart from the competing stacks such as Axis2. Although other stacks provide tools and a configuration-driven approach, the WCF/Visual Studio combination enables rapid development with generally a first working model without requiring you to learn additional object models or implementation patterns.
As the WS-* specifications advance requirements for greater control over security, reliable messaging, and atomic transactions, WCF allows, when using the declarative model, direct support without recoding the service or client implementation. So, with the declarative method, you can update the application configuration file as shown in Listing 13-4.
Example. Applying WSHttpBinding in Configuration
<bindings> <wsHttpBinding> <binding name="... " ... </binding> </wsHttpBinding> </bindings> |
Through the wsHttpBinding configuration element you can now support additional levels of reliability and security that are demanded for both internal and external services for enterprise solutions.
Implementing Basic Profile ensures you of seamless integration with other services from non-Microsoft platforms. However, one of the most common issues of transferring information is sending attachments to another non-Microsoft platform. This is a necessity today with substantial binary files, graphics files, and product files (such as Acrobat PDF files) being exchanged between multiple platforms. Therefore, how do you send these binary data over WCF services? What mechanisms are available in WCF to achieve this?
Sending Binary Data Over Web Services
Generally, when you look at most types of services, they utilize short, succinct messages that contain primarily text. The one-way and two-way message exchange patterns that are the most common simply pass a few parameters. The parameters are generally primitives and possibly get another primitive or more complex type back. WCF, along with most web service frameworks, has been optimized for these patterns.
However, since the inception of messaging technologies (such as MQSeries/WebSphere MQ and other message-oriented middleware), solutions have required some type of large object transfer between tiers or potentially binary data. Many times in the past while the bulk of the solution focused on the short message exchange patterns, the large objects were sent out of band, potentially using FTP with PGP or other convoluted solutions. Existing systems leverage data formats that are usable cross platform in their existing forms. Image data (GIF, JPEG, and TIF) is an example of this type of data. Also, the prevalence of PDF files is another example of a data format that transgresses platforms easily.
One method that can be leveraged is embedding the binary data as a Base64-encoded stream. This is a simple method, which is directly supported by the xs:base64Binary XML schema type. However, it has some significant drawbacks. The first is the additional overhead with the encoding/decoding of the binary data, which adds processing cost. The other potentially more significant issue is that the Base64 algorithm can increase the payload size by approximately 33 percent.[]
[] You can find scenarios, patterns, and implementation guidance for WSE 3.0 at http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnpag2/html/wssp.asp.
Although effective, the overall issues related to size can impact the performance of services. Given the response is generally buffered prior to transmission, large objects will consume memory resources in addition to the CPU overhead of encoding. Also, given the direct embedding of the binary resource inside the XML document, this impacts the performance of XML parsers that are now required to buffer or read past the embedded data in order to obtain other elements and values.
An alternative to embedding binary data inside the XML document was published in December 2000.[] This specification was built upon the Multipurpose Internet Mail Extensions (MIME) specifications. A similar specification, WS-Attachments, follows the same pattern, leveraging MIME at its core. Both, as you'll soon see, have been superseded and have minimal industry support.
[] You can find MIME, Section 6.8, Base64 Content-Transfer-Encoding, at http://www.ietf.org/rfc/rfc2045.txt.
MIME provides a way to transfer the binary data alongside the core SOAP response inside a MIME message. Listing 13-5 shows a stub of a MIME message.
Example. SwA Message Sample
MIME-Version: 1.0
Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml;
start="<[email protected]>"
Content-Description: This is the optional message description.
--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <[email protected]>
<?xml version='1.0' ?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
..
<theSignedForm href="cid:[email protected]"/>
..</SOAP-ENV:Body> </SOAP-ENV:Envelope> --MIME_boundary Content-Type: image/tiff Content-Transfer-Encoding: binary Content-ID: <[email protected]> ...binary TIFF image... --MIME_boundary-- |
As shown in Listing 13-5, the section in bold is the body of the SOAP response. That response body contains an element called theSignedForm with a relative reference of cid:.... The cid represents the Content-ID that is present within the MIME message. What SwA does provide is a way to optimize access to the XML body without forcing parsers and readers to consume the binary data until absolutely necessary.
SwA has several issues. One primary issue is that the URI reference outside the SOAP body bypasses any message-level security. To alleviate this, it's necessary to provide transport-level encryption or security such as SSL or S/MIME. However, these URI references could be outside the MIME message itself and not be required to be relative to the current message.
Direct Internet Message Encapsulation (DIME)
When Microsoft shipped WSE 1.0 for .NET 1.1, it provided a method for passing attachments in a SOAP message but outside the SOAP envelope. As a result of its presence as an attachment, it falls outside the capabilities of SOAP security and consequently requires transmission or transport-level security such as SSL. While only Microsoft submitted it to the Internet Engineering Task Force, both IBM and Microsoft authored it. Because of a variety of reasons, it didn't gain industry backing.
Direct Internet Message Encapsulation (DIME) leveraged fixed field size, and bytes are ordered according to network byte order, or big-endian. This works well for Windows and most Unix variants but requires additional overhead on platforms that don't conform to the same sequencing methods. DIME also supported chunking of a message, which is splitting a message over multiple DIME records.
The WSE 2.0 programming model requires developers to manipulate the SOAP response by adding attachments programmatically. Listing 13-6 is a snippet of WSE 2.0 code that adds the file attachment, along with its content type (image/jpeg) directly to the SOAP response.
Example. Using DIME in WSE 2.0
[WebMethod]
public void GetFile(string fileName)
{
SoapContext respContext = ResponseSoapContext.Current;
DimeAttachment dimeAttach = new DimeAttachment("image/jpeg",
TypeFormat.MediaType, fileName);
respContext.Attachments.Add(dimeAttach);
} |
As you can see in Listing 13-6, the implementation details are not abstracted from the service implementation. The service developer is now forced to understand the implications and requirements of transferring binary or large objects through the service tier. A more natural method signature would be just to return the binary data as a stream or an array of bytes.
Microsoft realized the transitional status of DIME, and when WSE 3.0 (for .NET 2.0) was released, Microsoft terminated the support of DIME. The technology that replaced it is called Message Transmission Optimization Mechanism (MTOM). Listing 13-7 is a similar interface but implemented with MTOM-expected support as part of WSE 3.0.
Example. Using MTOM in WSE 3.0
[WebMethod]
public byte[] GetFile(string fileName)
{
byte[] response;
String filePath = AppDomain.CurrentDomain.BaseDirectory +
@"App_Data" + fileName;
response = File.ReadAllBytes(filePath);
return response;
} |
As you'll soon see, the transition from the WSE 3.0 implementation of MTOM to the WCF implementation of MTOM is nearly seamless given the more natural way of implementing service interfaces without implementation-dependant details. Also, the WSE 3.0 MTOM is wire-level compatible with WCF's initial release.
Message Transmission Optimization Mechanism (MTOM)
With the limitations of the attachment-oriented approaches, industry participants developed a new specification that alleviated many of the issues of past specifications while ensuring compatibility with the emerging WS-* standards. Along with MTOM, XML-binary Optimization Packaging (XOP) is managed by the WCF encoding class MtomMessageEncodingBindingElement. This is controlled by setting the messageEncoding attribute on the binding with alternatives of Text or Binary. Listing 13-8 is an example of an application configuration that establishes through the declarative model that MTOM encoding should be used.
Example. Using MTOM Through Configuration
<system.serviceModel>
<services>
<service name="MtomSvc.MtomSample">
<endpoint binding="wsHttpBinding"
contract="MtomSvc.IMtomSample"
bindingConfiguration="MyBinding"/>
</service>
</services><bindings>
<wsHttpBinding>
<binding name="MyBinding" messageEncoding="Mtom" />
</wsHttpBinding>
</bindings>
</system.serviceModel> |
In the configuration file shown in Listing 13-8, we've applied the Mtom value to the messageEncoding attribute for the default settings of wsHttpBinding. This now tells the WCF framework that it should apply MTOM (with XOP) on the messages during normal channel processing inside the WSHttpBinding instance. The optimization of the content is then based upon how the XOP implementation is applied within WSHttpBinding by using the internal class System.ServiceModel.Channels.MtomMessageEncoder. What traverses the wire, across the chosen transport, is a series of MIME message consisting of a SOAP request and for the final response from the server a binary stream (marked as Content-Type: application/octet-stream).
In the Chapter 13 sample code, MtomTest provides a WCF client and server using configuration, and WSHttpBinding does its message exchange, leveraging the MTOM capabilities of WCF. The sample code contains a single service method that returns an array of bytes, as shown in Listing 13-9.
Example. WCF GetFile Service Contract
namespace MtomSvc
{
[ServiceContract()]
public interface IMtomSample
{
[OperationContract(
ProtectionLevel=System.Net.Security.ProtectionLevel.None)]
byte[] GetFile( string fileName );
}
public class MtomSample : IMtomSample
{
public byte[] GetFile( string fileName )
{
byte[] result = File.ReadAllBytes(
Path.Combine(
AppDomain.CurrentDomain.BaseDirectory, fileName) );
return result;
}
} |
We've taken the same method signature as illustrated in the WSE 3 example (Listing 13-7) that leveraged MTOM, and we defined an interface and provided an implementation in a concrete class. We've also applied an OperationContract property of ProtectionLevel.None to the operation so the only protection is authentication (the alternatives being Sign and EncryptAndSign).
|
The service class just reads the filename passed on the request into an array of bytes and then returns that to the caller. The MtomTest client application displays the results in a text box or, for the image request, converts it into an image and updates the Image control.
You'll now look at what occurs during the request and reply from the client. Figure 13-1 illustrates the calling sequence from client to server over the life of the request. This will illustrate the initial key exchange (and subsequent token generation) between the client and services. This also illustrates how the token is utilized to invoke a GetFile() command at the service.
MTOM message exchange
The MtomTest sample directory contains several Ethereal[] capture logs along with a series of text files taken from the MIME parts of the requests. Those text files are labeled 1.txt through 6.txt—they match Figure 13-1, with each odd-numbered file representing the request coming from the client and each even-numbered file representing the response from the server.
[] You can find the W3C's Soap with Attachments at http://www.w3.org/TR/SOAP-attachments.
The first two request-reply pairs represent the key exchange as part of the WS-Security implementation within WCF. This is primarily for establishing a token exchange that will be used later for message signing. The third and fourth requests illustrate the token being used to inquire about endpoints. This objective of this call is to illustrate how the token is utilized by the client to communicate with the server. The following code snippet illustrates the binary token that is used to pass on credentials to the service:
<s:Body> <t:RequestSecurityTokenResponse Context="uuid-af1f0d7a-6fd7-4c06-9ce0- 7a5acb18669f-2" xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401- wss-wssecurity-utility-1.0.xsd"> <t:BinaryExchange ValueType="http://schemas.microsoft.com/net/2004/07/ secext/WS-SPNego">TlRMTVNTUAADAAAAGAAYAHgAAAAYABgAkAAAA BAAEABIAAAAEAAQAF gAAAAQABAAaAAAABAAEACoAAAANYKY4gUBKAoAAAAPQwBMAFcAQw BGAFgAUAAxAGMAaQBjAG8AcgBpAGEAcwBDAEwAVwBDAEYAWABQAD EA5OLHzcQEcZYAAAAAAAAAAAAAAAAAAAAAsz6BrLvbKI9JA2UWtQEQolh SFoU9HXfU0vvvDPQuWoNlKxIgckKTwQ== </t:BinaryExchange> </t:RequestSecurityTokenResponse> </s:Body>
The fifth request is the actual SOAP request using an action of http://tempuri.org/IMtomSample/GetFile. The body of the SOAP request contains an unencrypted request value inside the SOAP body:
<fileName>LogoText.JPG</fileName>
If you look at the file 6.txt, you'll see a MIME message consisting of two parts. The first part is the SOAP envelope representing the GetFileResponse message, as shown in Listing 13-10. Inside that element is an xop:Include element that points to the second part of the MIME message.
Example. GetFileResult with XOP Reference
<GetFileResult>
<xop:Include
href="cid:http%3A%2F%2Ftempuri.org%2F1%2F632858870617208016"
xmlns:xop="http://www.w3.org/2004/08/xop/include"/>
</GetFileResult> |
The second part of the MIME message is the raw binary stream as read initially from the file system into the byte[]. If you look in the file 6.txt, you can see the MIME content header for the binary stream, as shown in Listing 13-11.
Example. Binary Content Part of MIME Message
--uuid:c336b34f-7c2b-4ca6-9534-141723adcf4c+id=9 Content-ID: <http://tempuri.org/1/632858870617208016> Content-Transfer-Encoding: binary Content-Type: application/octet-stream |
The Content-ID in this part of the MIME message is not HTML encoded, while in the SOAP response part (Listing 13-10) it is. The other aspect is that the encoding type is binary and marked as an octet-stream. What follows the customary set of two CR/LF (0x0D, 0x0A) is the raw binary data directly from the byte[]. The content length matches the original file size (you can examine this with the Ethereal logs) without any compression or modification.
The exchange used in Listing 13-10 doesn't apply any message level to either the request or the reply. If you update the OperationContract attribute's ProtectionLevel property to EncryptAndSign, you get message-level encryption on both the SOAP envelope and the binary data that is contained in the second part of the MIME message. The capture results with EncryptAndSign for the final response are contained in the file 6-WithEncryptAndSign.txt.
MTOM Industry Acceptance
The W3C published the MTOM specification in January 2005.[] Since that time, several other key vendors have signed on to ship products that contain support for MTOM. Microsoft had been one of the first to support it with Visual Studio 2005 and WSE 3.0. Microsoft continues that support up through WCF.
[] You can find the Ethereal network protocol analyzer at http://www.ethereal.com/.
At the time of this writing, many of the non-Microsoft frameworks have either indicated an intention to support MTOM in future versions of their application server software or have shipped early adopter (EA) code.
If you look at the Java technology stack, some competing technologies provide the foundation for web services. As a result, how you enable MTOM support in the Java environment varies by what choice you make with regard to the primary application server and development tools.
Sun's Tango project, along with its NetBeans tools and frameworks, provides a similar model to Microsoft. Both provide a metadata-driven approach and tools to abstract andsimplify developing web services based upon the emerging standards.
Apache's Axis2 Support of MTOM
You'll now look at how Axis2 1.0 provides support for MTOM. Axis2 1.0 was released as an early adopter version in May 2006.[] The Axis2 project was a major rewrite from the initial Axis web services project. Axis2 leverages a pipeline handler model for message handling (similar to Axis) with an extensibility model that allows both the community and enterprises to extend Axis2.
[] You can find MTOM and XOP at http://www.w3.org/TR/soap12-mtom/ and at http://www.w3.org/TR/xop10/.
The Axis2 project has more of a code generation model with the use of tools to facilitate developing web services. Additionally, Axis2 uses the Axis Object Model Element (AXIOM OMElement) that becomes the primary message that is passed through the participants in adistributed architecture. The Axis2 project also has an Eclipse[] plug-in wizard for helping generate code either from WSDL or from Java classes (WSDL2Java or Java2WSDL).[]
[] You can find the Axis2 project at http://ws.apache.org/axis2/.
[] You can find the Eclipse IDE at http://www.eclipse.org.
So, using the MtomTest sample, you can first generate the WSDL using the SvcUtil.exe utility as provided with WCF using the following command line (after starting the WCFHost project):
svcutil /t:metadata http://localhost:8080/ FileService
This creates three output files representing the base WSDL with the two imports. Using this WSDL, you can now create the Java classes for consuming the MtomTest web service, as shown in Figure 13-2.
Accessing Axis2 Code Generator from Eclipse
The wizard lists the Axis2 Code Generator that's accessed from the New menu option. We won't cover in too much detail the capabilities of Code Generator. The next step is to choose either to generate a Java class from a WSDL or to generate a Java class to a WSDL. We will choose to generate a WSDL to a Java class (the Generate Java Source Code from a WSDL File option), as shown in Figure 13-3.
Generating Java code from WSDL
Click Next, and you will then be prompted to choose the input WSDL file. This will be the file you created using the SvcUtil.exe utility. Then click Next again, and you will see the choices for code generation, as shown in Figure 13-4.
Axis2 code generation options
Enter the service name in the Service Name box shown in Figure 13-5. For this example, we'll just generate the client-side proxy along with a test case class that will demonstrate the calling paradigm provided by the Axis2 framework. We've just enabled synchronous calling and enabled the generation of a test case. The next page of the wizard asks for the output directory. Although the Finish button is enabled, you must specify a directory, or the wizard will complete without an error but won't produce any results. We've included the generated code as part of the chapter sample code; it's in the MtomTestJava directory, and the WSDL used is in the MtomTestWsdl directory. Please note the WSDL2Java-generated class is called FileServiceTest.
Listing 13-12 shows the test case-generated code directly from the WSDL2Java wizard.
Example. Axis2 WSDL2Java-Generated Code
public class FileServiceTest extends junit.framework.TestCase {
public void testGetFile() throws java.lang.Exception {
org.tempuri. FileServiceStubstub = new org.tempuri.FileServiceStub ();
org.apache.axiom.om.OMElement param4 =
(org.apache.axiom.om.OMElement)
getTestObject(org.apache.axiom.om.OMElement.class);
// todo Fill in the param4 here
assertNotNull(stub.GetFile(param4));
}
//Create an OMElement and provide it as the test object
public org.apache.axiom.om.OMElement getTestObject(java.lang.Object dummy) {
org.apache.axiom.om.OMFactory factory =
org.apache.axiom.om.OMAbstractFactory.getOMFactory();
org.apache.axiom.om.OMNamespace defNamespace =
factory.createOMNamespace("", null);
return org.apache.axiom.om.OMAbstractFactory.getOMFactory()
.createOMElement("test", defNamespace);
}
} |
As you can see in the code, the main interaction from the developer perspective is navigating the OMElement, which is a hierarchical object model representing an XML InfoSet.[]
[] You can find the Axis2 Eclipse plug-in at http://ws.apache.org/axis2/tools/1_0/eclipse/wsdl2java-plugin.html.
Compare the coding approach presented by Axis2 and AXIOM to the experience presented by WCF. The .NET Framework from its initial inception has provided methods to develop against a strongly typed object model representation of XML data as well as through hierarchical navigation using XML technologies. Microsoft has provided tools to make the serialization and representation of XML data more seamless using a user-friendly integrated development environment (in other words, Visual Studio 2005). The key result is that you can do more with less coding, leaving the intricacies of working with XML to the framework.
Sun Microsystems' Support of MTOM
Sun, the creator of Java, has worked with Microsoft on WCF interoperability testing, as mentioned previously. The WSIT project, as of this writing, is in early adaptor form and source code only.[] However, given the marketing from Sun's team and the demonstration at the JavaOne 2006 conference, it is clear Sun is committed to a viable and working framework.
[] You can find an AXIOM tutorial at http://ws.apache.org/axis2/1_0/OMTutorial.html#OM.
WSIT relies on two foundational Java technologies: JAX-WS[] and JAXB.[] The combination of these technologies provides a similar development experience to the WCF model. Both rely on attributes and metadata for web service definition, and along with JAXB, they provide a strongly typed development experience that increases developer productivity.
[] You can find GlassFish Project Tango/WSIT information at https://wsit.dev.java.net/.
Sun's NetBeans project, which is an open source stepchild of the Java community, provides a development environment that additionally alleviates the requirements that developers understand hand-coding to a new API or understand navigating an object graph. The NetBeans WSIT module,[] as shown in Figure 13-5, hides the intricacies of the framework requirements.
NetBeans WSIT module
Before moving on, we'll make a few important observations regarding the state of the Java community and the vendor support of a consistent approach to working with web services and the emerging standards: JBoss, acquired by Red Hat in 2006, has stated that it will no longer work with the Axis project and will proceed with the development of its own SOAP stack.[] At the time of this writing, JBoss supports only 30 percent of the MTOM specification.[] Additionally, neither IBM nor BEA has published or shipped a product that supports MTOM, although both companies were part of the W3C specification committee. Marketing and news releases indicate they are expected to ship products by 2007.
[] http://wiki.jboss.org/wiki/Wiki.jsp?page=WebServiceStacks
These are the options available to transfer binary data between Microsoft and non-Microsoft SOA offerings. We'll now discuss how WS-ReliableMessaging is used in non-Microsoft SOA offerings.