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
will address some basic web services interoperability issues
that are useful for developers. We will focus on the two most
popular platforms - Java and Microsoft C#.
Introduction More and more we're finding that WSDL lies at the
heart of Web services interoperability. WSDL is the description
language for Web services. Usually a WSDL document is
automatically generated by Web services framework tools (e.g.,
Axis, 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 convenient
access to Web services. Thus the key to enabling seamless Web
services interoperability is the ability of one Web services
framework to consume the WSDL documents generated by other
frameworks. The WSDL interoperability effort is just taking off.
You can see further details at
http://soap.systinet.net/interop/wsdl/index.html. How to not get
trapped The following subchapters give you some basic tips on
how to write interoperable Web services using today's Web
services frameworks. These tips may significantly ease your life
as well as the lives of other developers who will use your Web
services. Hopefully some of those tips will 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, so many frameworks sacrifice full XML Schema support
for performance. Some advanced XML Schema constructs (e.g.,
choice) are quite hard to express in a programming language, and
few Web services frameworks support them. So the key success
factor in Web services interoperability is to use basic data
types, such as primitive data types, arrays, and structures. As
a best practice, decompose the complex types in your interfaces
into simple and clean interfaces with basic data types. Also
avoid using specific techniques (e.g. INOUT parameter passing)
that aren't widely supported. Sample Architecture Let we see the
architecture of my sample application which uses web services
along with messaging concepts. Here 3 web services are used. Two
web services, Place Order and Get Order are developed and
deployed in Java environment and another one, Send Message is in
C# environment.
The Ordering System calls the Place Order web service to place
an item to order. The Place Order web service stores that item
and notifies the Java Expeditor Client through JMS. After the
intimation message has come from JMS the Java Expeditor Client
calls the Get Order web service to retrieve the ordered items
and details. The same Place Order web service calls the another
web service, Send Message to send the message to MSMQ, then the
Notification message is sent to the C# Expeditor Client from
MSMQ. After the intimation message has come from MSMQ, the C#
Expeditor Client calls the Get Order web service to retrieve the
ordered items and details. Here functionality of the Java
Expeditor and C# Expeditor Client are same except that they are
developed in different platform to illustrate the
interoperability of web services. So here its proved that web
service Get Order, which is developed and deployed in Java
environment is accessed from the C# Expeditor client and the web
service Send Message, which is developed and deployed in C#
environment is accessed from Place Order web service of Java
environment.
Accessing Java Web Service from C# To invoke the Get Order web
service in C# Expeditor Client application, we are going to Add
Web Reference to the Get Order web service. The steps to be
followed to do this are, 1. In Project menu, click Add Web
Reference… 2. In the URL box type
http://localhost:8888/axis/servlet/AxisServlet (or u can give
the web service URL) 3. Now it will show the list of services
that are available. From that select Get Order (wsdl) link. 4.
Click Add Reference button. We need to create a proxy client to
access this web reference. For that we need the wsdl file of
that particular web service. Save WSDL file The AxisServlet
generates the wsdl file for the web service. To get the wsdl for
Get Order Web service, Type this URL in browser:
http://localhost:8888/axis/servlet/AxisServlet. Click on wsdl
link belongs to Get Order Web service. It will display the wsdl
xml content. Save this content with .wsdl extension. Create
Proxy Client For the creation of proxy client we can utilize the
wsdl tool of Microsoft Visual Studio. Now, open the Command
Prompt (preferably the Visual Studio.NET Command Prompt, which
verifies the PATH environmental parameters are set correctly).
Navigate to the directory containing the GetOrder.wsdl file.
Type the following at the command prompt: wsdl
/o:GetOrderService.cs GetOrder.wsdl Now the GetOrderService.cs
file will be created. This is the proxy class for the referenced
web service. So, add this file into the assembly of your C#
project. By making instance to this proxy client we can call the
Get Order Web service as the following code, GetOrderService
GOService = new GetOrderService (); string strOrders; strOrders
= GOService.getOrder (); Accessing .Net Web Service from Java
For accessing the .Net web service we can use the
org.apache.soap package and it sub package rpc. We need to
provide the Service URL, Target namespace and the Soap Action
which is present in the wsdl file. By using the Call class we
can invoke the Web service method as in the following code:
String URLString = "http://localhost/WebService1/Service1.asmx";
String TargetNamespace =
"http://localhost/WebService1/Service1"; String SOAPAction =
"http://Walkthrough/XmlWebServices/sendMessage"; URL url = new
URL (URLString); //setup a the invocation Call call = new
Call(); call.setTargetObjectURI (TargetNamespace);
call.setMethodName ("sendMessage"); call.setEncodingStyleURI
(Constants.NS_URI_SOAP_ENC); Response resp = call.invoke (url,
SOAPAction);
Messaging Concepts In the given architecture, u can see the JMS
and MSMQ messaging concepts are used. Here the brief notes on
these concepts.
JMS JMS is a set of interfaces and associated semantics that
define how a JMS client accesses the facilities of an
enterprise-messaging product. Enterprise messaging is recognized
as an essential tool for building enterprise applications and
Ecommerce systems, and JMS provides a common way for Java
programs to create, send, receive, and read an enterprise
messaging system's messages. You can learn more about JMS in the
following URL:
http://www.chrispeiris.com/articles/JavaMessageService.html MSMQ
Microsoft Message Queuing (MSMQ) technology enables .net
applications running at different times to communicate across
heterogeneous networks and systems that may be temporarily
offline. Applications send messages to queues and read messages
from queues. You can get more details on MSMQ from
http://www.microsoft.com/windows2000/technologies/communications/
msmq/default.asp Conclusion In this part of the Web services
tutorial we learned how to write interoperable Web services. All
examples were focused on the integration of MS .NET and Java. We
demonstrated that Web services technology gives us the
opportunity to pick the best technology for each particular
piece of our system. Some of us may want to know how to create
web services in Java and C#, and also more details on
integration of JMS and MSMQ with web services. Those things we
are not discussed here. If you have doubts on those areas,
please feel free to contact me at
senthil.krishnamurthy@aspiresys.com
|
