Tango in Web services: Java and .NET 3.0 interoperability

Written by Arun Gupta, Sun Microsystems
Posted by Jack Vaughan, TSS.NET 

W3C Web Services Architecture Working Group defines Web service as: A Web service is a software system designed to support interoperable machine-to-machine interaction over a network.

As is evident from the definition, the requester and provider of the Web service must be able to talk in an interoperable manner. In this blog, I’ll talk about Web Services Interoperability Technology (WSIT, pronounced same as “visit”, a.k.a. Project Tango), a Sun Microsystems initiative, an open source implementation of enterprise Web services technologies that deliver interoperability between Java Web services and Microsoft Windows Communication Foundation (WCF, a.k.a Indigo and available as part of .NET 3.0 platform) to help you build, deploy and maintain Composite Applications for your Service Oriented Architecture.

As an extension to JAX-WS, WSIT has four main categories, covering the key WS-* specifications:

  • Messaging (SOAP, MTOM, WS-Addressing)
  • Metadata (WSDL, WS-Policy, WS-Metadata Exchange)
  • Security (WS-Security Policy, WS-Security, WS-Trust, WS-Secure Conversation)
  • Quality-of-Service (WS-Reliable Messaging, WS-Coordination, WS-Atomic Transactions)

These are the features required by an enterprise developer to create a composite application. Apart from providing an implementation of the key WS-* specs, the distinct feature of WSIT is the letter “I” in WSIT, which stands for interoperability. The literal meaning of the word “interoperability” is: “ability of a system to work with or use the parts or equipment of another system”.

The definition is clear but the key point to highlight is that this definition assumes the two systems “just work”. And the definition does not mention any workarounds to be done by the user of the systems. The fact that two systems are working together seamlessly is completely transparent to the user. In Web services terms, this would mean that a .NET client can invoke a Web service on Java platform, and vice versa, and still perform the intended business logic. All this needs to be done without the client and service developers worrying about how the HTTP headers are going to be interpreted, whether an image attachment sent by one stack will be received correctly by the other, and if the two stacks are agree on on-the-wire representations for secure reliable sessions.

The WSIT implementation, available as part of GlassFish v2 builds, has been extensively tested to work with .NET 3.0 framework in an interoperable manner. The WSIT has successfully participated in multiple interop plug-fests where successive interoperability has been achieved. That means, in the initial plug-fests the focus was more on the basic specifications like MTOM and WS-Security. In subsequent one, more composite scenarios like secure reliable messaging and secure transactional scenarios are tested. In an interoperability plug-fest, held at Microsoft campus, in September, Sun achieved interoperability on all the simple and composite scenarios. Read more about the plug-fests here.

So if you are developing an enterprise application then WSIT not only provides you all the building blocks, with complete tooling support in NetBeans IDE 5.5 and deployment platform in GlassFish v2, but also provides an out-of-the-box interoperability with .NET framework 3.0.

So, next time you think about Java and .NET Web services interoperability, think, visit, and download WSIT. This is one platform that allows you to develop secure, reliable, transactional and interoperable Web services using industry-grade NetBeans IDE that can be deployed on GlassFishv2.

Here are is a collection of useful links:

Technorati: Web Services Interoperability Sun Microsoft WSIT JAX-WS GlassFish .NET WCF Indigo

A Dirt-Simple Web Service

Welcome to the Interoperability Blog, Part the Fourth, wherein we talk about that most obvious of interopability choices, the ubiquitous “Web service”. The basics of the Web service are well known by this point: data sent by a client is transformed into an XML message in the SOAP format over HTTP to a listener, which processes the incoming data, generates an XML response again in SOAP format, and returns that to the sender for consumption. Frequently the service is described using another XML-based format, WSDL, which can be used to generate proxies using a code-generation tool of the client’s choice.

A full description of how to use Web services is well beyond the scope of this blog entry; what we’ll do instead is focus on the practical interaction between Java’s latest standard for defining Web services, the Java API for XML Web Services (JAX-WS) and Microsoft’s Windows Communication Framework (WCF). In this particular case, we’re going to use BEA’s SimpleService example (which ships as part of the WebLogic Server 9.2 installation available for free download from BEA) as the service to talk to, and WCF as the client.

We begin by defining a simple service using JAX-WS metadata annotations, taking a standard Java class and using those annotations to define how the Web service is built. We’ll need the JAX-WS annotations:

import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;

Plus WebLogic provides an annotation type used to help describe the HTTP binding within the WebLogic Server:

import weblogic.jws.WLHttpTransport;

We define the class itself, using three class-level annotations to describe the way in which it should be exposed as a service. The class will be a simple one, with a single method that takes a String and returns it slightly modified (the ubiquitous “echo” service):

public class SimpleImpl
{
  public String echoMessage(String echoMsg)
{
    System.out.println("sayHello: " + echoMsg);
    return "Here is the message: '" + echoMsg + "'");
  }
}

In this case, I’ve removed the annotations so we can examine them individually. We’ll start with the simplest, the WebMethod annotation that we apply to the echoMessage method:

@WebMethod()
public String echoMessage(String echoMsg)
{
  System.out.println("sayHello: " + echoMsg);
  return "Here is the message: '" + echoMsg + "'");
}

This simply tells WebLogic (or any other JAX-WS-compliant container) that this method should be exposed as an operation in the WSDL generated by the container. The method is simple enough to not require any customization, so we’re done here.

Next, we need to annotate the class with a couple of annotations to describe how the class itself should be made available; first, we use the WebService annotation to indicate the name and namespace (which should always be specified) of the service:

@WebService(name="Simple",
   targetNamespace="http://example.org")
public class SimpleImpl
{
  @WebMethod
public String echoMessage(String echoMsg)
  {
    System.out.println("sayHello: " + echoMsg);
    return "Here is the message: '" + echoMsg + "'");
  }
}

After that, we use the SOAPBinding annotation to describe how the service should be described in WSDL using SOAP; in this particular case (as should be the case for all new Web services), the binding specified uses document/literal encoding, as opposed to the deprecated rpc/encoded style that was popular several years ago. This is good, because WCF also defaults to doc/literal, so WCF isn’t going to have to go through weird gyrations to support our service when it generates proxies:

@WebService(name="Simple",
   targetNamespace="http://example.org")
@SOAPBinding(style=SOAPBinding.style.DOCUMENT,
   use=SOAPBinding.Use.LITERAL,
   parameterStyle=SOAPBinding.ParameterStyle.WRAPPED)
public class SimpleImpl
{
  @WebMethod
  public String echoMessage(String echoMsg)
  {
   System.out.println("sayHello: " + echoMsg);
   return "Here is the message: '" + echoMsg + "'");
  }
}

Finally, as an optional benefit, WebLogic provides the WLHttpBinding annotation to describe how this class should be exposed in the WL9.2 container, in this case in a servlet context named “jws_basic_simple”, and with a service name of “SimpleService”. These names can both be found in the URL by which we retrieve the service, later:

@WebService(name="Simple",
   targetNamespace="http://example.org")
@SOAPBinding(style=SOAPBinding.style.DOCUMENT,
   use=SOAPBinding.Use.LITERAL,
   parameterStyle=SOAPBinding.ParameterStyle.WRAPPED)
@WLHttpBinding(contextPath="jws_basic_simple",
   serviceUri="SimpleService")
public class SimpleImpl
{
   @WebMethod
   public String echoMessage(String echoMsg)
  {
    System.out.println("sayHello: " + echoMsg);
    return "Here is the message: '" + echoMsg + "'");
  }
}

At this point, compile the code, deploy to the server, and the service is ready to go; for a test, point a browser at the URL by which WebLogic (as many other Web service containers do) exposes the generated WSDL by tacking “WSDL” as a query parameter at the end of the URl, as in: “http://localhost/jws_basic_simple/SimpleService?WSDL”.

What should be returned is a rather incomprehensible collection of XML that most of the time can be safely ignored. (WSDL is a complicated specification that, in theory, you never need to read. Unfortunately, there’s theory, and then there’s practice, but we’ll leave that aspect of practice alone for another day.)

At this point, now that we know that we can retrieve WSDL, we can point the WCF svcutil at the URL, and let it build us a proxy to use from a client App. (Just for grins, and to make a few heads spin, we’re going to write the client in Visual Basic.) Run svcutil like so:

svcutil http://localhost:7001/jws_basic_simple/ServiceSimple?WSDL

It creates two files in the current directory, output.config, a .NET configuration file that WCF will examine for details on how to talk to the service, and SimpleImplServiceDefinitions.cs, the actual proxy itself. Write some simple client code to :

Option Strict Off
Option Explicit On

Namespace WCFExample
Public Class Client
    Public Shared Sub Main()
     Dim cl As New SimpleClient

     Console.WriteLine("echo returns: {0}", _
      cl.sayHello("Greetings from WCF"))
    End Sub
End Class

End Namespace

Compile this with vbc, making sure to reference the System.ServiceModel and System.Runtime.Serialization assemblies (the easiest way being to copy them out of the WCF installation directory into the current directory and reference them using “/r” from the command-line). Make sure the WebLogic Server is running (start it by start it by selecting Start : All Programs : BEA Products : Examples : WebLogic Server : Start Examples Server if it’s not). Rename the output.config file to be named “Client.exe.config” (assuming the Client class is in Client.vb), and run:

echo returns: Here is the message: 'Greetings from WCF'

Voila—you have a dirt-simple Web service. Note that we’re ignoring some significant issues, such as how to pass data types more sophisticated than a String, but for now, we have a working Web service.

Beyond Web Services, a look at bridging Java/.NET apps

By Jack Vaughan
Interoperability concerns gained a new tenor a few years ago with the advent of Java, XML and .NET. Among the companies that arose as a result is JNBridge, which makes the JNBridgePro Java and .NET interoperability tool. This over-the-wire approach is far removed from XML Web services, although JNBridge does support SOAP-based approaches among its deployment options.

However, there is a real effort here to formulate an approach that  ‘lets the Java do java,  and the .NET do .NET.’

In effect, JNBridgePro builds its bridge by generating a set of proxies that expose classes’ APIs and manages communications between .NET and Java classes.

JNBridgePro 3.1 came out last month, supporting new capabilities that allow Java GUI controls to be embedded directly in .NET applications, or .NET GUI controls [including WinForms] to be embedded in Java apps. Also last month, the folks at JNBridge joined the Interop Vendor Alliance,  a group whose august ranks include no less than AMD, BEA, Microsoft, NEC, Quest Software, Sun Microsystems, Symphony Services, and others.

JNBridge’s approach is to enable developers to access Java objects and classes from .NET as if they were .NET objects and classes, or vice versa. JNBridgePro exposes objects, classes, members, or user interface components across the confines of the individual platforms.

Take it to the bridge
TheServerSide Interoperability Blog recently spoke with Wayne Citrin, JNBridge founder and CTO to get a view on interoperability today. From the get-go, he said, Citrin and his colleagues saw areas in interoperability that big vendors were unlikely to cover. And, while there was a lot of XML-oriented Web services standards committee work going on among those big vendors, JNBridge was among a set of vendors that looked beyond a XML solutions.

“I was talking to a number of people around the time that .NET came out. People were asking would [.NET] work with their EJBs [Enterprise Java Beans], said Citrin. The answer, of course, was ‘not really.’

Meanwhile Web services were posed as something of a Silvr Bullet. They were not every programmers favorite, however, and few denied XML Web services could create system overhead. In some apps, that overhead was foreboding.

Tied to text
Web services are ‘tied to text messages - tied to ASCII, and ASCII is very verbose,” said Citrin. “You throw in XML and these extra words and constructs.” That is one problem with XML.

“The whole service-oriented approach is really very narrow,” said Citrin. “You are, by design, exposing a narrow view - like peaking through a keyhole. What happens is that developers and customers sometimes really want to access an API, not a service.

“You have rich APIs like EJB or JMS. They are complex. These are not just a single service that you just access.”

Citrin aggress that it is not just a black and white picture, and that Web services have their places. “Web services are very useful for a lot of things,” he says, “it’s easy to  them put together and have them find each other. But they are not big on states. They are not big on references.”

Despite a massive push toward “SOA,” the fact may remain that developers and even their managers aren’t thinking about services. “A lot of people don’t want to think about services, said Citrin. “A lot of times what is offered on the other side isn’t a service. What you want is to get object references back, call backs, and exceptions - things that programmers do every day.”

“Developers want to access their Java code from .NET, or vice versa,” he summarizes.
 
Some useful related bridging links
http://www.jnbridge.com/jnbpro.htm
A view on in-process to cross-network bridging
http://www.jnbridge.com/jnbphow.htm
A view on in-process to cross-network bridging, cont.
http://www.jnbridge.com/architecture.htm
A JNBridgePro architecture diagram
JNBridge blog
http://www.jnbridge.com/blog