By Daniel Rubio
[Posted by Jack Vaughan]
Messaging is a popular technique for applications requiring asynchronous communication, and its same architecture which introduces an additional broker between client and server, also lends itself to support interoperability between Java and .NET applications, via a messaging provider.

A messaging provider adheres pretty strictly to the definition of middleware, its role is to sit between client and server hosts to support additional software services, one of which can be bridging platform disparities. Messaging providers come in many flavors and are produced by many vendors, strictly speaking in Java and .NET terms, in the Java camp there are a series of products designed around JMS(Java Messaging Service), while in the Microsoft-centric product line there is MSMQ.

Choosing between a messaging provider can be an elaborate process, but generally speaking all of them support a plethora of client/server platforms to bridge communication disparities, ranging from Java, .NET to others like C++ and C. In all cases, any messaging platform requires a concerted effort to install, configure and use, so with that said, we will concentrate our efforts on a what I have personally experienced to be the easiest to set up : MSMQ. This is not to say MSMQ is superior to other messaging platforms, but simply more ubiquitous than others, given its already included in Windows 2000, Windows XP, Windows Server 2003 and Windows Vista, contrary to many other products which require more elaborate steps to install.

In any of the aforementioned operating systems, first ensure you have MSMQ enabled going to the control panel and selecting the Add or Remove Programs icon, followed by Add/Remove Components, in the emerging window you will see a list, make sure Message Queuing is selected. You now have MSMQ ready for action on your system.

The next step is to create a queue, in messaging speak this is where the communications token — message — you wish to transfer between a Java and or .NET application is stored. The actual message can be varied in nature, it can have distinct formats — text, XML, binary — or have different behaviors — guaranteed delivery, transactional properties — in this particular case, I wont delve in the finer details of incorporating any elaborate messaging behaviors, but rather focus on storing a vanilla type message in MSMQ through either Java or .NET.

In .NET the process is very straightforward, since two of the many .NET classes are designed for just this purpose, one is named System.Messaging.MessageQueue and the other System.Messaging.Message. The following snippet shows the sequence:

Listing 1.1 Creating MSMQ queue and sending message from .NET

// Check if queue exists, if not create
if(MessageQueue.Exists(@”.\Private$\InteropQueue”))
      // Creates an instance MessageQueue, which points to existing InteropQueue
      mq = new System.Messaging.MessageQueue(@”.\Private$\InteropQueue”);
else
      // Creates a new queue called InteropQueue
      mq = MessageQueue.Create(@”.\Private$\InteropQueue”);

// Create a message to send, with text and label
System.Messaging.Message msg = new System.Messaging.Message();
// InteropMsg variable contains payload, assign to body
msg.Body = InteropMsg.Text;
msg.Label = “InteropMsgJavaNET”;
// Send it to the queue.
mq.Send(msg);
[End Listing 1.1]

In Java, the process is a little more elaborate since it requires connecting to MSMQ via a supporting library/mechanism, among them : COM, C++ or C. This means that your Java class would need to communicate through either one of these technologies to get through to MSMQ, since MSMQ does not support native Java or JMS calls.

So what you are left with when trying to create MSMQ queues from Java is using a separate API. Currently, there are a series of commercial offerings — sometimes referred to as bridges — to ease Java communication to COM(and hence MSMQ), but since this would take us down the avenue of proprietary API’s and product selection I won’t discuss it here.

An alternate route for those looking for non-commercial — read free — communication from Java to MSMQ would be using JNI(Java Native Interface), which is Java’s way of tapping C++ or C libraries, but we will leave JNI’s interoperability details for a later entry. An excellent write-up on this process by Dino Chiesa is found on his All About Interop blog.

Returning to the task at hand, once a message sits in an MSMQ queue, it can easily be consumed by either a Java or .NET client using a similar sequence to the one used for creating it. In .NET you once again use MessageQueue class for this purpose:

Listing 1.2 Consuming message from MSMQ queue in .NET

      // Creates a new queue called InteropQueue
      mq = MessageQueue.Create(@”.\Private$\InteropQueue”);
try
{
      // Call receive on queue
      msg = mq.Receive(new TimeSpan(0, 0, 5)); // 5 is wait time in seconds
      // Assign to variable
      msgInterop = msg.Body.ToString();
}
catch
{
      msgInterop = “No Message”;
}
[End Listing 1.2]In Java, the message consuming code would again entail using a communications bridge to COM or some other form JNI library to tap MSMQ’s C or C++ interfaces.

There you have it, a quick run-through on using messaging to achieve interoperability between Java and .NET applications. In the next entry, we will take a look at another non-web service alternative to achieving application interoperability: CORBA.

Daniel Rubio is a software consultant with over 10 years of experience in enterprise software development, having recently founded Mashup Soft, a startup specializing in the use Web services for Mashups. He is a technology enthusiast in all areas related to software platforms and maintains a blog on these topics at webforefront.com.

Related MQ/MSMQ messaging link
Dino Chiesa blog

By Daniel Rubio
[Posted by Jack Vaughan]
Messaging is a popular technique for applications requiring asynchronous communication, and its same architecture which introduces an additional broker between client and server, also lends itself to support interoperability between Java and .NET applications, via a messaging provider.

A messaging provider adheres pretty strictly to the definition of middleware, its role is to sit between client and server hosts to support additional software services, one of which can be bridging platform disparities. Messaging providers come in many flavors and are produced by many vendors, strictly speaking in Java and .NET terms, in the Java camp there are a series of products designed around JMS(Java Messaging Service), while in the Microsoft-centric product line there is MSMQ.

Choosing between a messaging provider can be an elaborate process, but generally speaking all of them support a plethora of client/server platforms to bridge communication disparities, ranging from Java, .NET to others like C++ and C. In all cases, any messaging platform requires a concerted effort to install, configure and use, so with that said, we will concentrate our efforts on a what I have personally experienced to be the easiest to set up : MSMQ. This is not to say MSMQ is superior to other messaging platforms, but simply more ubiquitous than others, given its already included in Windows 2000, Windows XP, Windows Server 2003 and Windows Vista, contrary to many other products which require more elaborate steps to install.

In any of the aforementioned operating systems, first ensure you have MSMQ enabled going to the control panel and selecting the Add or Remove Programs icon, followed by Add/Remove Components, in the emerging window you will see a list, make sure Message Queuing is selected. You now have MSMQ ready for action on your system.

The next step is to create a queue, in messaging speak this is where the communications token — message — you wish to transfer between a Java and or .NET application is stored. The actual message can be varied in nature, it can have distinct formats — text, XML, binary — or have different behaviors — guaranteed delivery, transactional properties — in this particular case, I wont delve in the finer details of incorporating any elaborate messaging behaviors, but rather focus on storing a vanilla type message in MSMQ through either Java or .NET.

In .NET the process is very straightforward, since two of the many .NET classes are designed for just this purpose, one is named System.Messaging.MessageQueue and the other System.Messaging.Message. The following snippet shows the sequence:

Listing 1.1 Creating MSMQ queue and sending message from .NET

// Check if queue exists, if not create
if(MessageQueue.Exists(@”.\Private$\InteropQueue”))
      // Creates an instance MessageQueue, which points to existing InteropQueue
      mq = new System.Messaging.MessageQueue(@”.\Private$\InteropQueue”);
else
      // Creates a new queue called InteropQueue
      mq = MessageQueue.Create(@”.\Private$\InteropQueue”);

// Create a message to send, with text and label
System.Messaging.Message msg = new System.Messaging.Message();
// InteropMsg variable contains payload, assign to body
msg.Body = InteropMsg.Text;
msg.Label = “InteropMsgJavaNET”;
// Send it to the queue.
mq.Send(msg);
[End Listing 1.1]

In Java, the process is a little more elaborate since it requires connecting to MSMQ via a supporting library/mechanism, among them : COM, C++ or C. This means that your Java class would need to communicate through either one of these technologies to get through to MSMQ, since MSMQ does not support native Java or JMS calls.

So what you are left with when trying to create MSMQ queues from Java is using a separate API. Currently, there are a series of commercial offerings — sometimes referred to as bridges — to ease Java communication to COM(and hence MSMQ), but since this would take us down the avenue of proprietary API’s and product selection I won’t discuss it here.

An alternate route for those looking for non-commercial — read free — communication from Java to MSMQ would be using JNI(Java Native Interface), which is Java’s way of tapping C++ or C libraries, but we will leave JNI’s interoperability details for a later entry. An excellent write-up on this process by Dino Chiesa is found on his All About Interop blog.

Returning to the task at hand, once a message sits in an MSMQ queue, it can easily be consumed by either a Java or .NET client using a similar sequence to the one used for creating it. In .NET you once again use MessageQueue class for this purpose:

Listing 1.2 Consuming message from MSMQ queue in .NET

      // Creates a new queue called InteropQueue
      mq = MessageQueue.Create(@”.\Private$\InteropQueue”);
try
{
      // Call receive on queue
      msg = mq.Receive(new TimeSpan(0, 0, 5)); // 5 is wait time in seconds
      // Assign to variable
      msgInterop = msg.Body.ToString();
}
catch
{
      msgInterop = “No Message”;
}
[End Listing 1.2]In Java, the message consuming code would again entail using a communications bridge to COM or some other form JNI library to tap MSMQ’s C or C++ interfaces.

There you have it, a quick run-through on using messaging to achieve interoperability between Java and .NET applications. In the next entry, we will take a look at another non-web service alternative to achieving application interoperability: CORBA.

Daniel Rubio is a software consultant with over 10 years of experience in enterprise software development, having recently founded Mashup Soft, a startup specializing in the use Web services for Mashups. He is a technology enthusiast in all areas related to software platforms and maintains a blog on these topics at webforefront.com.

Related MQ/MSMQ messaging link
Dino Chiesa blog

By Jack Vaughan
The open-source GlassFish J2EE 5 application server allows what may be described as a simplified object component architecture, certainly in comparison to some of its forbearers. Used in conjunction with JAX-WS it supports descriptor free programming, which is welcomed by developers looking for ease of services deployment. We talked recently with Sun’s Arun Gupta about GlassFish, JAX-WS, and how Web service creation can be streamlined. Gupta is a technology evangelist for Web Technologies and Standards at Sun Microsystems, Inc., as well as a charter blogger on TheServerSide Interoperability Blog.

Arun said he strongly believes in descriptor-free programming.

“In the past,” he said, “even experienced developers have found it challenging to write descriptors.” In new scenarios, the descriptors still exist and, if you like, you can bundle them with your application. But not having to write deployment descriptors and focus on your business logic gets you started quickly.

Arun recently posted a blog entry about deploying a service in GlassFish using JDK annotations. It is entitled JAX-WS: Deployment Descriptor-free Programming. A most impressive aspect of the design sample he uses for illustration is that, in his words, “it gives you the ability of going descriptor-free.”

As he puts it: “No deployment descriptors are required if you can live with the reasonable defaults defined by the JAX-WS specification.”

“Glassfish recognizes a class to be a Web service, and uses a default URL to be the end point,” he told us. In his example, that is: http://localhost:8080/Hello/HelloService?wsdl

Related
JAX-WS: Deployment Descriptor-free Programming

A few times on this blog now we have kind of waltzed around these questions: When are Web services a good fit? Where not?

In a recent article, writer Colleen Frye asked just such questions of Forrester analyst John Rymer. Like others, he admits that,  where performance is a key issue, Web services may not be the best option.

For loosely coupled application or component integration, where the interactions can be accomplished through messages rather than direct API calls, Web services may fit the bill, Rymer said. However, for tightly coupled integration or in-process integration, Rymer suggests other options like bridging middleware such as integration servers or Enterprise System Buses [ESBs]; extended J2EE platforms that implement .NET features; and language integration technologies.

The verbosity or latency of Web services - call it what you will - was there at the outset. One is careful to place too much emphasis on that, since hardware historically has had a way of catching up. But you’d antcipate that Web services would be largely frozen out of intense applications such as electronic trading today. How far does that boundary extend?

In a Forrester report last year, Rymer wrote that Web services technologies will eventually become more broadly useful. Binary Web services formats continue to be discussed as an option for in-process integration, but one wonders if they are much further along this year than last. What do you think?

Web services no interop cure - TheServerSide.NET

Written by Scott Balmos [Posted by Jack Vaughan] I’ve got to admit, Visual Studio 2005 is a nice IDE. But when it comes to working with complex SOAP-based applications which have multiple endpoints and shared core, it can be a downright pain. I’m specifically referring to the Web References system, which transparently manages the annoyance of generating type stub and proxy classes from a WSDL file. It is, unfortunately, another classic case of Microsoft’s thought process behind trying to help developers work more efficiently - the common cases are very easy, but the hard things are very hard.

When it comes to Web Services, more and more systems are becoming increasingly complex. Many of them offer multiple endpoints - commonly one per major sub-application - while sharing a common core endpoint for initial authentication, session management, etc. Likewise, these endpoints share a common set of core datatypes, again usually a User, Session, and other such types. But trying to use these complex endpoints with Visual Studio is a downright pain. The Web References function insists on creating separate .Net namespaces for each different endpoint, even if the WSDL files for the two endpoints share a common XSD file that defines the shared core datatypes. Consequently, .Net refuses to acknowledge that a User or Session object retrieved from the core authentication endpoint really is the same User object that is supposed to be passed as a parameter in the billing, or personnel management, or other such sub-application endpoint.

No true explanation, nor any true answer to this dilemma has been given. The best I’ve seen are some people succumbing to the pain of manually changing the namespaces around in the auto-generated stub files. But that fix is short-lived, as the stub files are regenerated (separate namespaces and all) the next time the Web Reference is updated - a major pain for early-access developers to a web service whose WSDL file is still possibly in flux.

I don’t know about you, but I tend to see this as more and more of a thorn in the side of Visual Studio (and, by inference, .Net) developers as more complex SOAP services are built. For as much as Microsoft is trumpeting XML this and Web Services that, to believe that the Visual Studio and .Net groups didn’t seriously consider the use case of a complex service having multiple service endpoints is frustrating at best.

As I constantly continue building my one major JEE 5-based system (12 sub-applications and SOAP endpoints, with probably over 400 SOAP methods defined across those endpoints), and writing test SOAP clients in C#, I know I’ll be constantly bitten hard by this oversight. I’ll keep you updated if I find any more permanent answer, and let me know if you know of anything better.

I also, of course, welcome any vague ideas you may have for future blog entries. And I am not limited to SOAP/XML only, or specifically .Net and J2EE interoperability. In the coming weeks, I’ll be commenting on using J2EE systems with PHP, Ruby, and various other systems.

I’ll close off my blog entry with one of my favorite, and most poignant, lines from The Red Green Show (for you Canadians and Americans that watch PBS): “Remember, I’m pullin’ for ya… We’re all in this together”.

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.

By Scott Balmos There are days where I wish to return to the world of ASCII only encoding. Life was simpler back then - in a naive way. Now, we have ASCII, UTF-8, UTF-16, and so on. Even within them, there are different names for different locales (Sun sometimes using different names than the ISO ones come mind). And as far as I have seen so far (please correct me!), SOAP and friends do not really specify encodings to use when passing data that smells like a string. This could seriously blow a major hole in the side of a ship if you want your SOAP service to be truly international in its language support.

Think about it - you have Java on the one hand using UTF-16. Thankfully, so does the CLR (.Net), which covers a decent majority of language interop cases. But what about other languages that use UTF-8, or even pure C/C++ with Favorite Multibyte String Library Of The Week bolted on?

The default choice for multilingual language handling with Linux apps is UTF-8, which covers a lot of the C/C++ programs written there. PHP uses UTF-8. Ruby’s support for Unicode is also minimal, likewise barely handling UTF-8. Python is in the UTF-8 camp also. So, unfortunately, it looks as if we’re heading to another language interop battle. Back to one of the other favorite political battles that Ted Neward was writing about - The Java/.Net “enterprise/large app” languages, vs. the “small app” scripting languages.

Take SOAP out of the equation completely at the moment. What about in the simple cases of a Unicode text file? Is it UTF-16? Is it UTF-8? You can’t really tell by the text file itself. You have to know the encoding beforehand.

Some cursory Googling around reminded me of RFC 1641, which is a spec for specifying the Unicode encoding in the MIME type of a datastream. It seems that it might generally be a good idea to possibly look into extending the SOAP spec to specify encoding type in a string datatype.

Of course that leaves it up to the implementing language to deal with the encoding and decoding magic. But at least it’d be a start. As it is now, we have to explicitly encode our string data into UTF-8 or elsewhere if we want to be “completely” interoperable with languages.

It’d definitely be nice to not have to worry about what encoding my various SOAP client programs use. Just bring in the data, let the string encoding bloodhound class sniff at it a few times, and if it’s an encoding different than my language’s native encoding, it chews up the string byte array and spits out one to me that is in my native encoding, without any extra effort on my part. Ideally, this would simply be an extension to the string data marshaller/unmarshaller in the SOAP stack.

Data types *are* supposed to be vaguely universal, aren’t they?

“Remember, I’m pullin’ for ya… We’re all in this together…”
Scott’s personal blog can be found at http://members.simunex.com/sbalmos/serendipity/.

A large part of the apparent complexity of WSDL has nothing to do with WSDL at all; it was rather caused by the inline inclusion of XSDs in the section, writes Tomas Restrepo. He advises to create schemas separately and then import them into your WSDL contracts, and uses Thinktecture’s WSCF tool in this regard.
http://www.winterdom.com/weblog/2006/10/03/InlineXSDInWSDLWithWCF.aspx