S.V.

Krishna Reddy, ADP

Chapter 10. Web Services Interoperability Technologies

SCDJWS

Chapter 10. Web Services Interoperability Technologies

Describe WSIT, the features of each WSIT technology and the standards that WSIT Implements for each technology and how it works.

Sun is working closely with Microsoft to ensure interoperability of web services enterprise technologies such as message optimization, reliable messaging, and security. The initial release of WSIT is a product of this joint effort. WSIT is an implementation of a number of open web services specifications to support enterprise features. In addition to message optimization, reliable messaging, and security, WSIT includes a bootstrapping and configuration technology. Figure below shows the underlying services that were implemented for each technology.

Starting with the core XML support currently built into the Java platform, WSIT uses or extends existing features and adds new support for interoperable web services. See the following sections for an overview of each feature: Bootstrapping and Configuration Bootstrapping and configuration consists of using a URL to access a web service, retrieving its WSDL file, and using the WSDL file to create a web service client that can access and consume a web service. The process consists of the following steps, which are shown below:

Page 1 of 17

S.V.Krishna Reddy, ADP

Chapter 10. Web Services Interoperability Technologies

SCDJWS

Client acquires the URL for a web service that it wants to access and consume. How you acquire the URL is outside the scope of this tutorial. For example, you might look up the URL in a Web Services registry. The client uses the URL and the wsimport tool to send a MetadataExchangeRequest to access the web service and retrieve the WSDL file. The WSDL file contains a description of the web service endpoint, including WS-Policy assertions that describe the security and/or reliability capabilities and requirements of the service. The description describes the requirements that must be satisfied to access and consume the web service. The client uses the WSDL file to create the web service client. The web service client accesses and consumes the web service. Message Optimization Technology A primary function of web services applications is to share data among applications over the Internet. The data shared can vary in format and include large binary payloads, such as documents, images, music files, and so on. When large binary objects are encoded into XML format for inclusion in SOAP messages, even larger files are produced. When a web service processes and transmits these large files over the network, the performance of the web service application and the network are negatively affected. In the worst case scenario the effects are as follows: The performance of the web service application degrades to a point that it is no longer useful. The network gets bogged down with more traffic than the allotted bandwidth can handle.

Page 2 of 17

S.V.Krishna Reddy, ADP

Chapter 10. Web Services Interoperability Technologies

SCDJWS

One way to deal with this problem is to encode the binary objects so as to optimize both the SOAP application processing time and the bandwidth required to transmit the SOAP message over the network. In short, XML needs to be optimized for web services. This is the exactly what the Message Optimization technology does. It ensures that web services messages are transmitted over the Internet in the most efficient manner. Sun recommends that you use message optimization if your web service client or web service endpoint will be required to process binary encoded XML documents larger than 1KB. Reliable Messaging Technology Reliable Messaging is a Quality of Service (QoS) technology for building more reliable web services. Reliability is measured by a system's ability to deliver messages from point A to point B without error. The primary purpose of Reliable Messaging is to ensure the delivery of application messages to web service endpoints. The reliable messaging technology ensures that messages in a given message sequence are delivered at least once and not more than once and optionally in the correct order. When messages in a given sequence are lost in transit or delivered out of order, this technology enables systems to recover from such failures. If a message is lost in transit, the sending system retransmits the message until its receipt is acknowledged by the receiving system. If messages are received out of order, the receiving system may re-order the messages into the correct order. The Reliable Messaging technology can also be used to implement session management. A unique message sequence is created for each client-side proxy and the lifetime of the sequence identifier coincides with the lifetime of the proxy. Therefore, each message sequence can be viewed as a session and can be used to implement session management. You should consider using reliable messaging if the web service is experiencing the following types of problems: Communication failures are occurring that result in the network being unavailable or connections being. dropped Application messages are being lost in transit. Application messages are arriving at their destination out of order and ordered delivery is a requirement. To help decide whether or not to use reliable messaging, weigh the following advantages and disadvantages: Enabling reliable messaging ensures that messages are delivered exactly once from the source to the destination and, if the ordered-delivery option is enabled, ensures that messages are delivered in order. Enabling reliable messaging causes a degradation of web service performance, especially if the ordered delivery option is enabled.

Page 3 of 17

S.V.Krishna Reddy, ADP

Chapter 10. Web Services Interoperability Technologies

SCDJWS

Non-reliable messaging clients cannot interoperate with web services that have reliable messaging enabled. Security Technology Until now, web services have relied on transport-based security such as SSL to provide point-to-point security. WSIT implements WS-Security so as to provide interoperable message content integrity and confidentiality, even when messages pass through intermediary nodes before reaching their destination endpoint. WS-Security as provided by WSIT is in addition to existing transport-level security, which may still be used. WSIT also enhances security by implementing WS-Secure Conversation, which enables a consumer and provider to establish a shared security context when a multiple-message-exchange sequence is first initiated. Subsequent messages use derived session keys that increase the overall security while reducing the security processing overhead for each message. Further, WSIT implements two additional features to improve security in web services: Web Services Security Policy -- Enables web services to use security assertions to clearly represent security preferences and requirements for web service endpoints. Web Services Trust -- Enables web service applications to use SOAP messages to request security tokens that can then be used to establish trusted communications between a client and a web service. WSIT implements these features in such a way as to ensure that web service binding security requirements, as defined in the WSDL file, can interoperate with and be consumed by WSIT and WCF endpoints.
Describe how to create a WSIT client from a Web Service Description Language (WSDL) file.

Unlike developing a web service provider, creating a web service client application always starts with an existing WSDL file. This process is similar to the process you use to build a service from an existing WSDL file. The WSDL file that the client consumes already contains the WS-* policy assertions (and, in some cases, any value-added WSIT policy assertions that augment Sun's implementation, but can safely be ignored by other implementations). Most of the policy assertions are defined in the WS-* specifications. Sun's implementation processes these standard policy assertions. The policy assertions describe any requirements from the server as well as any optional features the client may use. The WSIT build tools and run-time environment detect the WSDL's policy assertions and configure themselves appropriately, if possible. If an unsupported assertion is found, an error message describing the problem will be displayed. Typically, you retrieve the WSDL directly from a web service provider using the wsimport tool. The wsimport tool then generates the corresponding Java source code for the interface described by the WSDL. The Java compiler, javac, is then called to compile the source into class files. The programming code uses the generated classes to access the web service.

Page 4 of 17

S.V.Krishna Reddy, ADP

Chapter 10. Web Services Interoperability Technologies

SCDJWS

Describe how to configure web service providers and clients to use message optimization.

MTOM (Message Transmission and Optimization Mechanism) together with XOP (XML Binary Optimized Packaging) defines how an XML binary data such as xs:base64Binary or xs:hexBinary can be optimally transmitted over the wire. XML type, such as xs:base64Binary is sent in lined inside the SOAP envelope. This gets quite inefficient when the data size is more, for example a SOAP endpoint that exchanges images/songs etc. MTOM specifies how XOP packaging can be used to send the binary data optimally. MTOM feature is disabled in JAX-WS by default. It can be enabled on the client and server. Once enabled all the XML binary data, XML elements of type xs:base64Binary and xs:hexBinary is optimally transmitted. An schema element of type xs:bas64Binary or xs:hexBinary can be annotated by using attribute reference using xmime:expectedContentType. JAXB 2.0 specification defines xmime:expectedContentType to Java type mapping:
image/gif image/jpg text/plain text/xml application/xml multipart/* all other types java.awt.Image java.awt.Image java.lang.String javax.xml.transform.Source javax.xml.transform.Source javax.activation.DataHandler javax.activation.DataHandler

<element name="image" type="base64Binary" />

is mapped to:

byte[]

<element name="image" type="base64Binary" xmime:expectedContentTypes="image/jpeg" xmlns:xmime="http://www.w3.org/2005/05/xmlmime"/>

is mapped to:

java.awt.Image

How to enable MTOM in JAX-WS 2.0

Enabling MTOM on Server o Enable using @javax.xml.ws.soap.MTOM annotation on the endpoint (SEI) implementation
class:

o o

@javax.xml.ws.soap.MTOM @WebService (endpointInterface = "mtom.server.Hello")

Page 5 of 17

S.V.Krishna Reddy, ADP

Chapter 10. Web Services Interoperability Technologies

SCDJWS

o o o

public class HelloImpl implements Hello { .... }

o MTOM can be also be enabled on an endpoint by specifying enable-mtom attribute to true on an endpoint element in sun-jaxws.xml deployment descriptor: o o o o o o o o <?xml version="1.0" encoding="UTF-8"?> <endpoints xmlns='http://java.sun.com/xml/ns/jax-ws/ri/runtime' version='2.0'> <endpoint name="Mtom" implementation="mtom.server.HelloImpl" url-pattern="/hello" enable-mtom="true"/> </endpoints>

o Enable using @BindingType on the endpoint (SEI) implementation class: @BindingType(value=javax.xml.ws.SOAPBinding.SOAP11HTTP_MTOM_BINDING)

will enable MTOM on the deployed endpoint for SOAP 1.1 binding.

@BindingType(value=javax.xml.ws.SOAPBinding.SOAP12HTTP_MTOM_BINDING)
will enable MTOM on the deployed endpoint for SOAP 1.2 binding.

Enabling MTOM on Client o To enable MTOM on client-side, pass javax.xml.ws.soap.MTOMFeature as WebServiceFeature parameter while crating the Proxy or Dispatch. Here is the code snippet from the client MtomApp.java of the MTOM sample: Hello port = new HelloService().getHelloPort(new MTOMFeature()); - gives
a proxy with MTOM enabled.

javax.xml.ws.Service.createDispatch( .... ,new MTOMFeature()); - gives a Dispatch instance with MTOM enabled. o JAX-WS 2.0 specification has defined API to enable and to check if the MTOM is enabled. javax.xml.ws.soap.SOAPBinding.setMTOMEnabled(boolean enable) - enable or
disable MTOM.

javax.xml.ws.soap.SOAPBinding.isMTOMEnabled() - returns true if MTOM is

enabled otherwise false.

Hello port = new HelloService.getHelloPort(); //get the binding and enable mtom SOAPBinding binding = (SOAPBinding)((BindingProvider)port).getBinding(); boolean mtomEnabled = binding.isMTOMEnabled();

Page 6 of 17

S.V.Krishna Reddy, ADP

Chapter 10. Web Services Interoperability Technologies

SCDJWS

binding.setMTOMEnabled(true);

As defined by JAXB 2.0 specification xs:base64Binary and xs:hexBinary mapping to java is byte[]. JAXWS implementation has set a threshold of 1KB of byte[] size. This threshold can be modified using implementation specific property com.sun.xml.ws.developer.JAXWSProperties.MTOM_THRESHOLD_VALUE in the RequestContext on the client side and in the MessageContext on the server side. If the byte[] that is being sent is less than this threshold (default is 1KB) then the binary data is base64 encoded by JAXB and in lined inside the SOAP Body otherwise the binary data is sent as attachment mime part in Multipart/Related package and XML infoset for the binary data is XOP encoded by JAXB - <xop:Include href=...> is used to reference the attachment. The XOP encoding and packaging is done as per described by the XOP packaging rules. The href is the the Content-ID of the attachment and is encoded as per CID URI scheme defined in RFC 2111. xmime:contentType attribute may appear on the element that includes binary data to indicate preferred media type as annotated on the corresponding schema.
What is MTOM Perhaps the best way to understand the pros and cons of MTOM is to see an actual on-the-wire message. See an example below:

Content-Type: Multipart/Related; start-info="text/xml"; type="application/xop+xml"; boundary="----=_Part_0_1744155.1118953559416" Content-Length: 3453 SOAPAction: "" ------=_Part_1_4558657.1118953559446 Content-Type: application/xop+xml; type="text/xml"; charset=utf-8 <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Body> <Detail xmlns="http://example.org/mtom/data"> <image> <xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:[email protected]" /> </image> </Detail> </S:Body> </S:Envelope>

------=_Part_1_4558657.1118953559446 Content-Type: image/jpeg Content-ID: <[email protected]>

... binary data ...

Page 7 of 17

S.V.Krishna Reddy, ADP The noteworthy points are:

Chapter 10. Web Services Interoperability Technologies

SCDJWS

1. The binary attachment is packaged in a MIME multi-part message (the same mechanism used in email to handle attachments). 2. An xop:Include element is used to mark where the binary data is. 3. The actual binary data is kept in a different MIME part. MTOM is efficient, in the sense that it doesn't have the 33% size increase penalty that xs:base64Binary has. It is interoperable, in the sense that it is a W3C standard. However, MIME multipart incurs a small cost proportional to the number of attachments, so it is not suitable for a large number of tiny attachments. Schema:

<element name="Detail" type="types:DetailType"/> <complexType name="DetailType"> <sequence> <element name="image" type="base64Binary" /> </sequence> </complexType>

JAX-WS and MTOM example JAX-WS MTOM WSDL:

<definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://attachment.tip/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://attachment.tip/"> <types/> <message name="sendImage"> <part name="image" type="xsd:base64Binary"/> </message> <message name="sendImageResponse"/> <message name="sendOctet"> <part name="octet" type="xsd:base64Binary"/> </message> <message name="sendOctetResponse"/> <portType name="AttachmentTip"> <operation name="sendImage"> <input message="tns:sendImage"/> <output message="tns:sendImageResponse"/> </operation> <operation name="sendOctet"> <input message="tns:sendOctet"/> <output message="tns:sendOctetResponse"/> </operation> </portType> <binding name="AttachmentBinding" type="tns:AttachmentTip"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="sendImage">

Page 8 of 17

S.V.Krishna Reddy, ADP

Chapter 10. Web Services Interoperability Technologies

SCDJWS

<soap:operation soapAction=""/> <input> <soap:body namespace="http://attachment.tip/" use="literal"/> </input> <output> <soap:body namespace="http://attachment.tip/" use="literal"/> </output> </operation> <operation name="sendOctet"> <soap:operation soapAction=""/> <input> <soap:body namespace="http://attachment.tip/" use="literal"/> </input> <output> <soap:body namespace="http://attachment.tip/" use="literal"/> </output> </operation> </binding> <service name="AttachmentService"> <port binding="tns:AttachmentBinding" name="AttachmentTip"> <soap:address location="http://localhost:9080/MTOMService/services/AttachmentTip"/> </port> </service> </definitions>

The MTOM binding contains no MIME information. In fact, there's no way to tell, from the WSDL, that you're dealing with attachments; the WSDL's binding looks like a normal binding. JAX-WS MTOM Java interface:

package tip.attachment; import import import import javax.jws.WebMethod; javax.jws.WebParam; javax.jws.WebService; javax.jws.soap.SOAPBinding;

@WebService(name = "AttachmentTip", targetNamespace = "http://attachment.tip/") @SOAPBinding(style = SOAPBinding.Style.RPC) public interface AttachmentTip { @WebMethod public void sendImage( @WebParam(name = "image", partName = "image") byte[] image ); @WebMethod public void sendOctet( @WebParam(name = "octet", partName = "octet") byte[] octet ); }

Page 9 of 17

S.V.Krishna Reddy, ADP

Chapter 10. Web Services Interoperability Technologies

SCDJWS

Because the WSDL is a normal-looking WSDL with no hint of attachments, you end up with a Java interface that reflects that as well. Given parts of type base64Binary (or hexBinary), JAX-WS maps those to parameters of type byte[]. With MTOM, the MIME-ness of the types has all been extracted from the WSDL with the burden placed on the client or server run time to format the content appropriately. The interface portion of both WSDLs shows that the data type in the operations is base64Binary, which maps to byte[]. In the JAX-RPC Sw/A WSDL, however, you know from the binding that the part types are a MIME image and a MIME octet stream. In the JAX-WS MTOM WSDL, this information is lost. This may seem like a bad thing, but the positive spin is that this completely cleans up the interface. No matter what the binding, the interface is always the same. In fact, the implementors of the client and the server codebases shouldn't be bothered with the notion of whether the parameter is an attachment. That's merely a detail of the SOAP message, and the writers of the WSDL-to-Java mappings have tried their best to abstract the programmer away from the details of the SOAP message. However, if you really want to know what the MIME type is - if you want to get back to the information you lost - JAX-WS provides support for an attribute that you can inject into an XML element: expectedContentTypes.
JAX-WS MIME attribute:

<definitions ...> <types> <xsd:schema xmlns:tns="http://attachment.tip/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://attachment.tip/"> <xsd:element name="sendImage" type="tns:sendImage"/> <xsd:complexType name="sendImage"> <xsd:sequence> <xsd:element xmlns:ns1="http://www.w3.org/2005/05/xmlmime" ns1:expectedContentTypes="image/*" name="image" type="xsd:base64Binary"/> </xsd:sequence> </xsd:complexType> <xsd:element name="sendImageResponse" type="tns:sendImageResponse"/> <xsd:complexType name="sendImageResponse"> <xsd:sequence/> </xsd:complexType> <xsd:element name="sendOctet" type="tns:sendOctet"/> <xsd:complexType name="sendOctet"> <xsd:sequence> <xsd:element xmlns:ns1="http://www.w3.org/2005/05/xmlmime" ns1:expectedContentTypes="application/octet-stream" name="octet" type="xsd:base64Binary"/> </xsd:sequence> </xsd:complexType> <xsd:element name="sendOctetResponse" type="tns:sendOctetResponse"/>

Page 10 of 17

S.V.Krishna Reddy, ADP

Chapter 10. Web Services Interoperability Technologies

SCDJWS

<xsd:complexType name="sendOctetResponse"> <xsd:sequence/> </xsd:complexType> </xsd:schema> </types> ... </definitions>

JAX-WS Java interface mapped from the MIME attribute:

package tip.attachment; import import import import import import import java.awt.Image; javax.activation.DataHandler; javax.jws.WebMethod; javax.jws.WebParam; javax.jws.WebService; javax.xml.ws.RequestWrapper; javax.xml.ws.ResponseWrapper;

@WebService(name = "AttachmentTip", targetNamespace = "http://attachment.tip/") public interface AttachmentTip { @WebMethod @RequestWrapper(localName = "sendImage", targetNamespace = "http://attachment.tip/", className = "tip.attachment.SendImage") @ResponseWrapper(localName = "sendImageResponse", targetNamespace = "http://attachment.tip/", className = "tip.attachment.SendImageResponse") public void sendImage( @WebParam(name = "image", targetNamespace = "") Image image ); @WebMethod @RequestWrapper(localName = "sendOctet", targetNamespace = "http://attachment.tip/", className = "tip.attachment.SendOctet") @ResponseWrapper(localName = "sendOctetResponse", targetNamespace = "http://attachment.tip/", className = "tip.attachment.SendOctetResponse") public void sendOctet( @WebParam(name = "octet", targetNamespace = "") DataHandler octet ); }

One of the of additional benefits of MTOM is the fact that you can turn it on or off. In the case of Sw/A, if one side or the other doesn't support sending Sw/A attachments, then the contract defined by the WSDL cannot be honored. On the other hand, a client could choose to send data as an MTOM attachment or inline in the SOAP message. No matter what the client chooses, it can still interact with the Web service. MTOM is just an optimization of sending content, not a mandate like Sw/A.
Page 11 of 17

S.V.Krishna Reddy, ADP

Chapter 10. Web Services Interoperability Technologies

SCDJWS

JAX-WS still supports the Sw/A model. By default, JAX-WS maps a Sw/A attachment to a byte[] on the Java interface. To get the mapping you are used to in JAX-RPC, you can use the enableMIMEContent WSDL binding definition. Listing below shows the JAX-WS version of the Java interface
Create a Microsoft Windows Communication Foundation (WCF) client that accesses a Java web service.
The process of creating a WCF C# client to a Web Service is similar to that for a Java programming language client. To create a WCF client you will: 1. Use the svcutil.exe tool to generate the C# proxy class and contracts for accessing the web service. 2. Create a client program that uses the generated files to make calls to the Web Service. You must have the following software installed to create the WCF client:

Microsoft Windows Software Development Kit (SDK) for July Community Technology Preview Microsoft .NET Framework 3.0 RTM The .cs client enabled from Java
You must also deploy the Java web service. The Client Class The client class uses a generated proxy class, AddNumbersImpl, to access the web service. The port instance variable stores a reference to the proxy class:

... port = new AddNumbersImplClient("AddNumbersImplPort"); ...

Then the web service operation addNumbers is called on port:

... int result = port.addNumbers (number1, number2); ...

The following is the full Client.cs class:

using System; class Client { static void Main(String[] args) { AddNumbersImplClient port = null; try { port = new AddNumbersImplClient("AddNumbersImplPort"); int number1 = 10; int number2 = 20; Console.Write("Adding {0} and {1}. ", number1, number2); int result = port.addNumbers (number1, number2);
Page 12 of 17

S.V.Krishna Reddy, ADP

Chapter 10. Web Services Interoperability Technologies

SCDJWS

Console.WriteLine("Result is {0}.\n\n",result); number1 = -10; Console.Write("Adding {0} and {1}. ", number1, number2); result = port.addNumbers (number1, number2); Console.WriteLine("Result is {0}.\n\n",result); port.Close(); } catch (System.ServiceModel.FaultException e) { Console.WriteLine("Exception: " + e.Message); if (port != null) port.Close(); } } }

When creating a Java programming language client, you use the wsimport tool to generate the proxy and helper classes used by the client class to access the web service. When creating a WCF client, the svcutil.exe tool provides the same functionality as the wsimport tool. svcutil.exe generates the C# proxy class and contracts for accessing the service from a C# client program:

svcutil /config:Client.exe.config http://localhost:8080/wsit-enabledfromjava/addnumbers?wsdl

The command compiles the proxy class, configuration file, and Client.cs client class into the Client.exe executable file:

C:\WINNT\Microsoft.NET\Framework\v2.0.50727\csc.exe /r:"C:\WINNT\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\System.ServiceModel.dll" /r:"C:\WINNT\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\System.Runtime.Serialization.dll" Client.cs AddNumbersImplService.cs

You can change the location of the csc.exe C# compiler and the System.ServiceModel and System.Runtime.Serialization support DLLs if you installed the .NET 2.0 and 3.0 frameworks to nondefault locations.

Page 13 of 17

S.V.Krishna Reddy, ADP

Chapter 10. Web Services Interoperability Technologies

SCDJWS

Describes the best practices for production and consumption of data for interoperability between WCF web services and Java web service clients or between Java web services and WCF web service clients.
Primitives and Wrappers Java primitive and wrapper classes map to slightly different XML schema representations. Therefore, .NET bindings will vary accordingly. A Java primitive type and its corresponding wrapper class are shown below. Java code fragment:

public class StockItem{ public Double wholeSalePrice; public double retailPrice; }

Schema fragment:

<xs:complexType name="stockItem"> <xs:sequence> <xs:element name="wholeSalePrice" type="xs:double" minOccurs="0"/> <xs:element name="retailPrice" type="xs:double"/> </xs:sequence> </xs:complexType>

.NET C# auto generated code from schema:

public partial class stockItem { private double wholeSalePrice; private bool wholeSalePriceFieldSpecified; private double retailPrice; public double wholeSalePrice { get{ return this.wholeSalePrice;} set{this.wholeSalePrice=value} } public bool wholeSalePriceSpecified { get{ return this.wholeSalePriceFieldSpecified;} set{this.wholeSalePriceFieldSpecified=value} } public double retailPrice { get{ return this.retailPrice;} set{this.retailPrice=value} } }

Page 14 of 17

S.V.Krishna Reddy, ADP BigDecimal Type

Chapter 10. Web Services Interoperability Technologies

SCDJWS

Limit decimal values to the range and precision of .NET's System.decimal.

java.math.BigDecimal maps to xs:decimal.

.NET maps xs:decimal to System.decimal. These two data types support different range and precision. java.math.BigDecimal supports arbitrary precision. System.decimal does not. For interoperability use only values within the range and precision of System.decimal. (See System.decimal.Minvalue and System.decimal.Maxvalue.) Any values outside of this range require a customized .NET client. Java code fragment:

public class RetBigDecimal { private BigDecimal arg0; public BigDecimal getArg0() { return this.arg0; } public void setArg0(BigDecimal arg0) { this.arg0 = arg0; } }
Schema fragment:

<xs:complexType name="retBigDecimal"> <xs:sequence> <xs:element name="arg0" type="xs:decimal" minOccurs="0"/> </xs:sequence> </xs:complexType>

.NET auto generated code from schema

public partial class retBigDecimal{ private decimal arg0Field; private bool arg0FieldSpecified; public decimal arg0 { get { return this.arg0Field;} set { this.arg0Field = value;} } public bool arg0Specified { get { return this.arg0FieldSpecified;} set { this.arg0FieldSpecified = value;} } }

XMLGregorianCalendar Type Use java.xml.datatype.XMLGregorianCalendar instead of java.util.Date and java.util.Calendar.

Page 15 of 17

S.V.Krishna Reddy, ADP

Chapter 10. Web Services Interoperability Technologies

SCDJWS

XMLGregorianCalendar supports the following XML schema calendar types: xs:date, xs:time, xs:dateTime, xs:gYearMonth, xs:gMonthDay, xs:gYear, xs:gMonth, and xs:gDay. It is statically mapped to xs:anySimpleType, the common schema type from which all the XML schema calendar types are
dervived. .NET maps xs:anySimpleType to System.string.

java.util.Date and java.util.Calendar map to xs:dateTime, but don't provide as complete XML support as XMLGregorianCalendar does.
Use the annotation @XmlSchemaType for a strongly typed binding of XMLGregorianCalendar to one of the XML schema calendar types. Java code fragment:

public class PurchaseOrder { public javax.xml.datatype.XMLGregorianCalendar orderDate; }

Schema fragment:

<xs:complexType name="purchaseOrder"> <xs:sequence> <xs:element name="orderDate" type="xs:anySimpleType" minOccurs="0"/> </xs:sequence> </xs:complexType>

.NET auto generated code from schema:

public partial class purchaseOrder { private string orderDateField; public string orderDate { get { return this.orderDateField; } set { this.orderDateField = value; } } }

Enum Type A Java enum type maps to an XML schema type constrained by enumeration facets. This, in turn, binds to the .NET type enum type. Java enum -> xs:simpleType (with enumeration facets) -> .NET enum. Java code fragment:

public enum USState {MA, NH}

Schema fragment:

<xs:simpleType name="usState"> <xs:restriction base="xs:string">

Page 16 of 17

S.V.Krishna Reddy, ADP

Chapter 10. Web Services Interoperability Technologies

SCDJWS

<xs:enumeration value="NH" /> <xs:enumeration value="MA" /> </xs:restriction> </xs:simpleType>

.NET auto generated code from schema:

public enum usState { NH, MA }

Page 17 of 17