Developing interoperable Web Services-consolidating Java and Microsoft. NET

Services|web developing interoperable Web services-integrating Java and Microsoft. NET

Interoperability is one of the main promises of WEB services. WEB services are designed to be independent of the underlying operating system and programming language. In this article we introduce basic Web services interoperability issues. We'll focus on the two most popular Platforms-java and Microsoft. NET.

Introduction

WEB Services interoperability can divided into two base categories:soap interoperability and WSDL interoperability.

In our previous articles we learned this SOAP is a very high-level protocol the mandates of XML documents E Xchanged over some transport protocol. That ' s quite a vague definition. The vagueness of this definition makes SOAP extremely extensible and versatile but it also makes interoperability a bit C Hallenging. At a basic level, we start my quest to achieve interoperability in the transport protocol level. Both parties involved in a message exchange must agree to use the same transport, protocol as HTTP, SMTP, or JMS. But transport protocol compatibility doesn ' t necessarily ensure. There are other issues that affect interoperability. One example is data type encoding. An encoding style defines how programmatic the data types are in XML. The SOAP specification does not mandate any particular encoding style, and developers are free to use any encoding style T Hey want. In theory there are virtually unlimited choices of encoding styles that are Mutually incompatible. Fortunately there is a standard convention. Section 5 of the SOAP specification defines a encoding style, and it has became the de facto standard for SOAP encoding. This encoding provides to the automated SOAP interoperability tests that are periodically out by the MA Jor SOAP Solutions vendors. You can have a test results online at http://soap.systinet.net/interop/soap/index.html

More and more we ' re finding-WSDL lies at the heart of WEB services interoperability. The WSDL is the description language for WEB services. Usually a WSDL document is automatically generated by WEB services framework tools (e.g., WASP Wsdlcompiler) from the code Written in a particular programming language. Developers can use the WSDL document to generate client-side stubs or proxies, which provide access to Web convenient Ices. Thus the key to enabling seamless Web services interoperability are the ability of one Web services framework to consume th E WSDL documents generated by the other frameworks. The WSDL interoperability effort is just taking off. You can-further details at http://soap.systinet.net/interop/wsdl/index.html.

Although there are still some interoperability-issues, the resolved vendors are progressing-very, and we can Expect delivery on the promise of WEB services interoperability very soon.

How to Don't get trapped

The following subchapters give you some basic tips on how to write interoperable Web services using today's Web services F Rameworks. These tips could significantly ease your life as as the "lives" of other developers who would use your WEB services. Hopefully some of those tips would be outdated soon.

Keep your types simple-avoid advanced XML Schema constructs

The XML Schema standard is very complex and difficult to implement. Moreover, XML schema processing is quite time consuming, then many frameworks full XML schema sacrifice for support nCE. Some Advanced XML Schema constructs (e.g., choice) are quite-hard to express in a programming language, and few Web Servic ES frameworks support them. So the key success factor in WEB services interoperability are to use basic datatypes, such as primitive datatypes, arrays, and structures. As a best practice, decompose the complex types in your to simple and clean interfaces with basic interfaces. Also avoid using specific techniques (e.g. INOUT parameter) that passing ' t aren widely.

Provide XML Schema definitions for all your types

One common problem in the today's frameworks is their limitied ability to import multiple XML Schema and WSDL documents. It ' s always a good idea to provide complete XML Schema and WSDL definitions in one WSDL file rather than importing them fr Om various locations. Specifically, the Microsoft. NET framework is sensitive to XML Schema import functions.

Example:When you find this you need to include the multiple WSDL and XML Schema files in the A. NET service, you'll find it easier to pass The XML Schema definitions together with the WSDL definition to the commandline MS. NET wsdl compiler rather than To import the schemas into the WSDL file:

Wsdl.exe/language:cs/protocol:soap myservice.wsdl myschema.xsd javacollections.xsd

multiple WSDL Bindings

Some frameworks (e.g., MS. NET) generate multiple WSDL bindings that allow your to access a WEB service through multiple PR Otocols (e.g., HTTP GET, HTTP POST, and SOAP). The Client-side framework needs to know which binding to use and so we need to specify further (parameters Qualified name of the service and the name of the WSDL port when generating the programming language bindings from the WS DL document.

Example:we'll later run the Com.systinet.demos.weather.WeatherClient Java client to access the MS. NET Weather Service The "is" available on the XMethods site. Notice that's client must use a slightly different lookup method to specify a fully qualified service name (as a JAVAX.W Sdl. QName) and WSDL port name:

Lookup ("Http://www.vbws.com/services/weatherretriever.asmx?WSDL",

"Weatherretriever"), "Weatherretrieversoap", Weatherretrieversoap.class)

Default document style with literal encoding

Some Web services frameworks, including MS. NET, generate, by default, a document style Web service, using literal Encodin G. Although the Web service uses document/literal, the. NET Framework makes the service appear to is RPC style to. NET CLI Ents. This is isn ' t necessarily so for other Web service frameworks, and many users could find it difficult to access the Web service Using an RPC style client. So if you ' re writing an RPC Web service, force your framework to generate the RPC style WSDL.

Example:use the [soaprpcservice] directive in your MS. NET RPC Web Service implementations:

<%@ WebService language= "C #" class= "Msnetstockservice"%>

Using System.Web.Services;

Using System.Web.Services.Protocols;

Using System.Web.Services.Description;

[SoapRpcService]

public class Msnetstockservice {

[WebMethod]

Public double getquote (string symbol) {

if (symbol = = "SUNW") {

return 10;

}

if (symbol = = "BEAS") {

return 11;

}

if (symbol = = "MSFT") {

return 50;

}

return 0;

}

}

Use the unique soapactions for your methods

If you start the Your Web service development with a WSDL document definition, the consider using unique SOAPAction attributes for All your methods in the WSDL binding. Some frameworks rely on SOAPAction when routing SOAP messages to the WEB service implementation ' s methods.

Example:Consider the following WSDL binding fragment for the previously MS. NET Web Service:

<binding name= "Msnetstockservicesoap" type= "Tns:msnetstockservicesoap" >

<soap:binding transport= "http://schemas.xmlsoap.org/soap/http" style= "rpc"/>

<operation name= "GetQuote" >

<soap:operation soapaction= "Http://tempuri.org/getQuote" style= "rpc"/>

<input>

<soap:body use= "encoded" namespace= "http://tempuri.org/"

encodingstyle= "http://schemas.xmlsoap.org/soap/encoding/"/>

</input>

<output>

encodingstyle= "http://schemas.xmlsoap.org/soap/encoding/"/>

</output>

</operation>

</binding>

Code examples

Now we'll show a few WEB services interoperability examples. We'll use a simple banking application this is capable the keeping track of customers, accounts, and account balances. We'll also use the MS. NET Weather Service, which is listed on the XMethods site as a real-life example of Internet Web SE Rvice access, so you'll need to be connected to the Internet while running this demo.

Note:If you are haven ' t already downloaded the software used to create the tutorial of examples, please refer to the installation chap ter in Part One. You'll also need to download the demo sources. We assume ' ve unpacked this archive into the C:\wasp_demo directory. All Java sources mentioned in the tutorial examples can is found in the SRC subdirectory of the unpacked demo sources arch Ive. They all reside in the Com.systinet.demos package. Similarly all scripts used in the demo are located in the bin subdirectory. You don ' t need to download and use the software to understand these articles, but we strongly recommend it.

Accessing a Microsoft. NET service from Java

We ' ll start with the Java client/.net service example. As we mentioned earlier, we'll access the weather service listed on the XMethods site. Click on the link and try the service online using the MS. NET invocation framework. Next Look in the WSDL document for this service. You'll notice that it defines three bindings (Weatherretrieversoap, Weatherretrieverhttpget, and Weatherretrieverhttppost).

Now let's create a Java client for this service. Run the Run_weather_client.bat script that's located in the bin directory of the demo sources archive. Please "we ' re using a lookup method" that specifices the fully qualified service name and the WSDL port. This lookup method allows us to specify that we want to use the SOAP binding.

Lookup ("Http://www.vbws.com/services/weatherretriever.asmx?WSDL",

"Weatherretriever"), "Weatherretrieversoap", Weatherretrieversoap.class)

Calling a Java service from a Microsoft. NET client

The opposite scenario is pretty straightforward. The "Start" Web service runtime with the Startserver.bat command, and then compile and deploy my simple Bank Web serv Ice by invoking the Deploy.bat command. Now we ' re ready the three different MS SOAP clients accessing our service.

Note:You are need to use MS IE 6.0 or higher to run this demo.

We'll run a MS JavaScript SOAP Client.Invoke the Run_web_client.bat script. Specify an SSN number (with can use 001-0001-01, 002-0002-02 or 003-0003-03), and click the Get Accounts button, which popu Lates the Accounts ComboBox. Choose the ComboBox and retrieve the account balance by clicking the Get Balance button. Look at the JavaScript code in src\msjsclient.html for further details. The code is very self-explanatory.

Note:You'll need to download and install the MS SOAP Toolkit 2.0 in order to successfully complete the next example. You'll also need MS Excel on your machine.

Now let's the same functionality accessed from Microsoft Excel(using Visual Basic). The Open the Src\bank.xls spreadsheet and use the same steps described, previous to example the navigate. Can find the SOAP client code in the Visual Basic Editor (tools->macro->visual basic Editor) in the Sheet1 Modul E.

Note:You'll need to download and install the MS. NET Framework SDK to run the C # part of this example

The last example demonstrates how to access my Java Web service from a C # client. Run the Run_csharp.bat script to generate a C # static proxy from the service WSDL and to compile and run the client applic ation. This example was going one step further than we previous examples in, it passes a Transfer structure from C # to Java. The previous examples pass is simple data types. Notice the simple XML Schema definition of the Transfer type (it includes the Balance element):

<xsd:schema targetnamespace= "http://idoox.com/wasp/tools/java2wsdl/output/com/systinet/demos/bank/" >

<xsd:complextype name= "Transfer" >

<xsd:sequence>

<xsd:element name= "type" type= "xsd:string"/>

<xsd:element name= "accountnumberbeneficiary" type= "xsd:string"/>

<xsd:element name= "comment" type= "xsd:string"/>

<xsd:element name= "balance" type= "ns0:balance"/>

<xsd:element name= "Amount" type= "xsd:double"/>

<xsd:element name= "timestamp" type= "Xsd:datetime"/>

<xsd:element name= "AccountNumber" type= "xsd:string"/>

<xsd:element name= "Transferid" type= "Xsd:long"/>

<xsd:element name= "commentbeneficiary" type= "xsd:string"/>

</xsd:sequence>

</xsd:complexType>

<xsd:complextype name= "Balance" >

<xsd:sequence>

<xsd:element name= "changed" type= "Xsd:datetime"/>

<xsd:element name= "Transfer" type= "Ns0:transfer"/>

<xsd:element name= "comment" type= "xsd:string"/>

<xsd:element name= "balance" type= "xsd:double"/>

<xsd:element name= "AccountNumber" type= "xsd:string"/>

<xsd:element name= "Transferid" type= "Xsd:long"/>

</xsd:sequence>

</xsd:complexType>

</xsd:schema>

The. NET WSDL compiler would generate the appropriate structures in C #. The stub in the Src/ms/javaservice.cs for more details. Run the Java client by invoking the "Run_java_client.bat script, and you'll notice that it does the same thing."

Note:Both clients share the same Web service, and Both clients make withdrawals to the same account. So if you run the demo multiple times, you can easily get out of funds. Then you'll get the transferprocessingexception which says something like ' insufficient funds '. One nice thing "ll notice is" that C # is able to transparently rethrow the exception with the same message on the client Side. Restart the Web services runtime using the Startserver.bat to renew your funds.