Java, .NET, But Why Together?

| Posted by Ted Neward Follow 3 Followers on Oct 05, 2006. Estimated reading time: 12 minutes |

Twelve years ago, Sun Microsystems announced, to little fanfare, a new programming language and environment for use in making Web pages more dynamic and "alive". Now, of course, the Java programming language is an ubiquitous tool, used for far more than just bringing Web pages into a more dynamic environment, but also for creating and populating those pages (through servlets and JSP), providing a platform for transactional processing of business logic (Enterprise Java Beans, or EJB), accessing messaging systems (Java Message Service, or JMS), accessing relational databases (JDBC), and even accessing mainframes (Java Connector API). And this story is hardly finished; every day the community around Java grows stronger through open-source efforts and projects, even as the "official" Java platform continues to build and grow and enhance itself through the Java Community Process.

Six years ago, Microsoft announced, with great fanfare, a set of new programming languages and environment for use in all sorts of programming situations. .NET has since seen two releases, one a major release involving significant changes to the runtime and the three most popular languages (C#, C++ and Visual Basic) for programming on it, as well as a raft of new features for both client and server tiers: transactional support (System.Transactions), generics (for both C# and Visual Basic), directory services, management (WMI), and more. And this story is hardly finished; even as Microsoft is planning new technologies for its next release (NetFX 3.0, to ship with Vista), a burgeoning community is growing, enhancing the .NET environment with new projects and ideas, open-source and commercial.

Over the years, there has been a fair amount of discussion about both of these environments, much of it highly inflammatory to one side or another, and almost none of it very useful. After all, statements like "My language is better than your language", or "My platform runs faster than your platform", or "You guys suck", are perhaps fun topics to toss around during cocktail parties and conference panels, but they’re hardly a productive discussion leading to meaningful software development. Even once past the politics, posturing and tomato-throwing, to try and have meaningful discussions of Java and .NET working together, the typical conversation moves to high-level buzzwordology like "Web services", "Enterprise Service Bus" or "Service-Oriented Architecture", with almost nothing concrete to show for it. Even then, once past the high-level discussion and into the low-level details, the talk is typically of SOAP and WSDL and WS- protocols, or of exchanging data through messages, or of hosting the JVM inside the CLR, or vice versa.

In other words, to paraphrase the popular phrase, "You went ahead and talked about how to do it, without ever really talking about why you should do it."

Historically, the discussion of Java/.NET interoperability has been relegated to the backburner of architecture, under the subject heading of "Only When Required"-interoperability happens only because a particular company has both a .NET and Java system that needs to talk to one another. What’s been left out of that discussion, however, is any discussion of motivation beyond that-why developers might want to use Java and .NET together, even where they might not have to.

On the surface of it, this is a dangerous subject. Any suggestion that one platform might be "better" at something than the other is likely to draw accusations of favoritism or ignorance, if not outright indignation at the merest slip of a hint that the other platform "can’t" do something. (This even ignores the basic problem of figuring out the definition of what "better" means in the first place.) Rather than downplay or seek to avoid it, let’s face it squarely: Such accusations or criticisms are not to be ignored-in fact, they should be welcomed, as part of the larger discussion of where and when and how such decisions should be made. Having said that, however, it’s still important to open the discussion, examine the ideas, and allow readers to form their own, critical, opinions.

In this first of a series of articles on the subject of Java/.NET interoperability, that’s exactly what we’re going to do.

* * *

When thinking about what Java and .NET both do well, there are several scenarios that come to mind that are worth exploring further:

Office Client, J2EE Server

Microsoft Office, for better or for worse, is one of, if not the most popular (by which we mean, installed on more computers) software platforms ever released in the history of computers. Now in its second decade of delivery, Office also represents a powerful platform from which users can enter, manipulate, and view data from a wide variety of disparate sources. Given that a phenomenal amount of data interesting to these users currently resides in J2EE-backed enterprise servers, it makes a very good case to look at ways to bring that data into the Office platform for easier manipulation and examination. Even more interesting is to examine ways the Office platform can make use of existing business logic already written in Spring or other lightweight Java containers, through out-of-process communication tools.

The August 2006 issue of MSDN Magazine (available online at runs several articles about Office development (and for that reason is strongly suggested as background material for anybody unfamiliar with Office’s programmatic capabilities), and in the article "What You Need To Know About Using Office As A Development Platform", a chart displays the full list of the Office platform’s capabilities. Rather than reiterate that list completely, a subsection neatly lists a few points of extensibility with Office that play nicely with the Java platform:

  • External automation. Thanks to the power of COM Automation, and now its logical successor, Visual Studio Tools for Office (VSTO), the major components of Office-Word, Excel, Outlook and so on-can be "driven" by an external-facing API, so that documents can be created from within a general-purpose programming language. Given Excel’s powerful charting and calculation capabilities, or Word’s editing and spellchecking capabilities, it’s intriguing to consider what a Java application could do with these two in a hosted environment, be it on the server (a Web application could drive Word to create customer mailers or printed report text with certain data elements filled in from the J2EE server, in much the same way a Velocity engine fills in templates for display to HTML, for example), or on the client, hosted via the Eclipse Rich Client Platform, which is capable of hosting COM Automation components already. (In fact, Eclipse can create new Word documents out of the box, on a Windows machine with Office installed already, of course.) This can be particularly powerful if users only need to view Word documents, rather than author them, as Microsoft makes available a free Word viewer-the Java Web application can create the Word document, then ship it across HTTP for viewing across the Web, in a richer format than HTML could provide.

  • Add-ins. Office is also capable of hosting "add-ins", software components that "plug in" to run inside of Office, usually by making themselves available through the menu bar or context menus. A .NET component could register itself as an Excel spreadsheet add-in, and use some form of Java connectivity (Web service, proprietary remoting toolkit or even in-proc hosting) to contact the Java business components for validation, data retrieval, or storage. Lots of companies use Excel as an invoicing and/or accounting solution, for example, and could thus use the Java components as an easy way in and out of the company’s larger, Java-based, Accounting package running on the enterprise server, accessed through a Java Connector inside of an EJB Session Bean.

  • Excel user-defined functions. Excel has long had the ability to "call out" to user-defined functions from within its calculation engine, though historically those functions have had to be written in unmanaged (raw C++) code, which introduces a dangerous instability into the application. Creating an Excel user-defined function that is a thin wrapper around existing business logic defined in the application server-say an inventory check called from within an Excel spreadsheet template for generating purchase orders-gives Excel a powerful "online" experience it lacks for most Excel users.

  • Smart tags. This is the name Microsoft has given that feature where a small box containing a drop-down arrow appears next to something of interest to the document. Smart tags frequently contain an opportunity to configure or customize a particular element within an Office document; for example, when Word auto-corrects what it believes to be a typing mistake, holding the mouse over the corrected word brings up a smart tag, allowing the user to drop the selection list down and "undo" the correction, in the event that it’s not an actual mistake. Smart tags are a form of add-in, and so could be used as another visual aid to help users silently bridge the gap between client and enterprise server.

Office also provides some deployment support for components and documents written/deployed with these programmatic elements in them, so in many cases updating the functionality inside these components can be as easy as releasing something onto a shared download server. Obviously a major consideration for its use will be the licensing costs of Office, but fortunately most business environments will already have Office deployed, reducing the cost significantly if not entirely.

Windows Workflow from within a Spring or J2EE container

Windows Workflow is a new framework Microsoft is releasing as part of the "NetFX 3.0" release, which will ship with Windows Vista. Workflow is intended to provide a means by which core business process functionality-be it on a small scale, such as the interaction between pages in a website, or on a large scale, such as the major processing steps in filing an insurance claim-can be created, viewed, tracked and edited by non-developers. Workflow developers (be they traditional .NET developers, or domain experts) use a flowchart-like environment to design workflows, made up of activities that represent each logical step in the process. This environment will normally be available from within Visual Studio, but can be hosted from within custom applications, as well, thus enabling a company to put the Workflow designer in an environment completely outside of the traditional "programmer" toolset. The resulting workflow design artifact, represented either in an XML format or in code, is then compiled by the workflow compiler into a regular .NET class and processed by the WorkflowRuntime, which can be hosted in a variety of environments, including ASP.NET, a console application, or a GUI app. Workflows can be sequential or driven by external state changes, even across long spans of time.

Given the fact that the WorkflowRuntime was designed to be flexible regarding its hosting environment and context, one immediate idea is to use Workflow and Spring (or another J2EE container) in some conjoined fashion-either the WorkflowRuntime hosting the Spring container and creating custom Activities that call into the Spring Beans to carry out certain business functionality, or by hosting the WorkflowRuntime inside of a Spring Bean to carry out a workflow in response to an incoming Spring-answered remote call. Particularly in the latter case, end-users can design business processes using an intuitive environment, yet run inside the traditional enterprise server world. Similarly, Workflow aficionados are already describing how Workflow can be used to structure the navigation of Web pages within an ASP.NET application in a manner not unlike that of the Struts action mappings file; hosting Workflow inside of the servlet container to do the same would be an equivalent approach, and again provide a visibility into the "flow" between servlet/JSP pages that currently stands obscured by XML syntax.

Windows Presentation Foundation Client to Java Service

Last but certainly not least stands what will likely become the most compelling case for using .NET and Java together: using the new Windows Presentation Foundation technology to provide a rich and powerful UI over the data model provided by an extensive and powerful Java service (be that Spring, EJB, or some combination thereof). WPF’s declarative programming model, based on XAML, marks a significant contrast to the prior code-based UI programming models of the recent past, and in many ways makes it easier to create complex user interfaces than what Swing or SWT can currently do. And, since XAML is a text-based format, it becomes feasible to generate XAML dynamically and download it to the client tier for execution, just as HTML does today.

The canonical scenario will have WPF front-ends talking to Java back-ends through Windows Communication Foundation (WCF), Microsoft’s new communication pipeline that unifies all of their distributed communication programming models into a single framework. In addition to support for many of the latest WS-* specifications, WCF also provides a rich extensibility model for communicating in various ways, including through REST-ful formats (sometimes called Plain Old XML, or POX), or even potentially using other transport media like UDP. Sun has made this approach even more feasible with its Tango project, which holds seamless integration with WCF as a specific design goal.

* * *

It goes without saying that this list is hardly the sum total of possible interoperability scenarios between Java and .NET; in fact, in the interest of keeping this article to a manageable length, we’ve blithely ignored several other possibilities:

  • Using the Eclipse Rich Client Platform as the client, hosting either a custom RCP view that talks over DCOM to a .NET/COM+ Serviced Component or to a WCF service.
  • Using Swing clients and/or JavaWebStart to create a portable, downloadable, zero-deployment client application solution over an Excel computing engine hosted on a Windows Server 2003 machine.
  • Using DirectX to provide native 3D effects (including sound) inside of an SWT application.
  • Using Microsoft Speech Server to provide an Interactive Voice Recognition (IVR) "front-end" to a Swing or J2EE application.

And so on, and so on, and so on.

It may sound like all this is far-fetched and unreasonably sensationalist, the kind of scenarios spun up out of the minds of Marketing guys with too much time on their hands and not enough sense. Why bother with Excel when Java has formula engines? Why bother with WCF when we have JAX-WS, or with WPF when we have Java3D? Lest we be accused of favoritism or blatant Marketecture, let’s be frank and clear: just about anything .NET can do, Java can do as well, and vice versa. But let’s also be honest about one fact in particular: both platforms have particular areas of interest that they do very well. To the developer willing to set aside political dogma in favor of an open-minded discussion, playing each to its strengths can lead to some powerful benefits. Or, to quote Karl Marx rather liberally, "From each platform, according to its abilities, to each project, according to its needs."

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Continuity... by Zubin Wadia

Great article Ted.

The "WPF -> Java" model, while extremely appealing, can still fall victim to versioning issues. In my opinion, unless there is formal communication between the .NET and Java camps about future roadmaps - one could have some serious continuity issues on their hands down the line. There is no guarantee that future releases of NetFX and JSE/JEE would maintain the "interoperability index" at the level it is today.

Two developments would change this perspective for me:

1. MS and Sun opening up an "Interoperability Community Process" (ICP).
2. A third-party vendor producing a dual-platform IDE.

I look forward to more certainly from both camps as it will take the "Re-combinant Innovation" era to a whole new level!



Re: Continuity... by Floyd Marinescu

Zubin, if we're talking about WPF to Java, wouldn't the 'interoperability index' be as long lived as your particular interoperability solution? You could have WPF integrate with Java via web services, or in proc, or a variety of other means. The inter-tier communication solution is written by the project, and it seems to me that the brittleness of that solution depends on the interop solution the project chooses, or am I misunderstanding your point?

Re: Continuity... by Zubin Wadia


The point I am trying to make here is that the 'inter-tier communication' standard we elect to use must be supported in future iterations of .NET and Java vs. just one platform.

For example - what if the Tango project mentioned by Ted doesn't support the latest version of WCF because it is still being updated? That would mean that I may not be able to take advantage of the latest features on the .NET platform because my Java tier is getting upto speed. This scenario, ofcourse can apply conversely also.

Needless to say, these mis-matches occur on homogeneous platforms too - but I believe the probability of it occuring with a hybrid setup is higher. Atleast for now.



ah...been there done that - and its great! by Roger Voss

For over three years have been taking a hybrid .NET/Java approach as Ted Neward advocates in his article.

ah...been there done that - and its great!

Using .NET WinForms was very much the superior choice for my particular projects over Java Swing as the rich client technology. Yet Java was hands down the superior choice to use for my middle-tier - asynchronous JMS messaging was the secret sauce for my event-driven distributed software systems.

Re: ah...been there done that - and its great! by ZedroS Schwartz

Why do say WinForms were the superior choice ? Could you develop a bit more ?

I've heard here and there that Spring was now pretty mature and efficient, especially since Matisse, so I wonder.

Thanks in advance

Re: ah...been there done that - and its great! by ZedroS Schwartz

Oups, I was speaking of Swing and not Spring...

Re: ah...been there done that - and its great! (why Winforms vs Swing/SWT?) by Roger Voss

For user-interactive client applications that I've developed in the context of my enterprise distributed software systems, I've used .NET WinForms instead of Swing (or SWT) for these reasons:

1) Out of the box the Visual Studio provides tools and support to wrap legacy COM/ActiveX controls for use in .NET host applications. This is particularly easy with respect to the IE browser control (which one of my apps makes use of). There are 3rd party tools for doing this with Java-based desktop apps but I didn't find them to be as good a tool set as what Microsoft provides.

2) My apps take over the computer and are used in kiosk-like manner 24/7. User's can't bail out into the Windows desktop, etc. I use a number of Windows system API calls to achieve the manner of lock down required. I use Windows API calls to solve other thorny issues as well. The Java JNI is much more cumbersome to use than the interop features that Microsoft provides for C# .NET.

3) Three years ago when I started building these distributed software systems Matisse for Java Swing development did not exist. Yet Visual Studio had a reasonable forms designer for .NET WinForms. It made building C# .NET forms applications about as easy as creating forms apps in old Visual Basic. Admittedly Matisse has very nice and very advanced constraint behavior in its forms creation and forms runtime. Yet now the .NET 2.0 WinForms designer has closed that particular gap so I have no compelling reason to switch to Matisse and Swing.

4) Java 5 and C# 2.0 are pretty close language feature-wise with the edge going to C# 2.0. So switching to Java does not provide me with a language that has any substantial superiority. The vast open source libraries that Java has is very useful to my programming in the middle-tier yet just hasn't been an important consideration to the programming I do for the rich client apps.

5) In order to make it easily feasible for my rich client apps to run 24/7 without becoming sluggish due to memory fragmentation, it is essential to have a runtime that has garbage collection and heap compaction. The JVM certainly provides that, but so does the .NET CLR. So again have no compelling reason to switch to Java.

6) The messages exchanged with the Java middle-tier are text-based XML. XML is plenty easy to work with in .NET. My JMS vendor provides a .NET client for both Win32 .NET Framework and for WinCE Compact Framework. It has been entirely straightforward to build messaging software that spans between .NET and Java. So there is nothing in the communication layer or data marshalling that compel me to seek a Java solution for the client.

7) I use log4j to do logging with my Java middle-tier software, but log4net gives me very similar capabilities for my .NET client software.

8) The fact that the .NET runtime is a larger installable download image than the Java JRE is a non-issue. This is behind-the-firewall software and corporate admin folk take care of outfitting client machines with whatever runtime items are specified.

The problem with Java on the desktop is that Sun has always discouraged fostering an effective Windows-specific tool environment. In their heart of hearts they don't want developers creating Java apps that only run on Windows. Alas, this position does not align with the goals of corporate developers. We have no problem conceding that Windows is the predominate platform for delivering rich client applications. We do like the advantages of Java and .NET like approach. As things stand, though, .NET is superior to Java in accommodating rich client development on the Windows platform in particular. If it were important to develop enterprise rich client apps that could run multi-platform, then Java Swing would enjoy an advantage. Yet such is really only a concern for the consumer market where Mac OS X is significantly in use. (Linux desktop is so utterly marginal that it doesn't count for anything of note in either market segment.)

Re: ah...been there done that - and its great! by Jonathan Allen

Swing doesn't use native controls. This makes it look and feel differently than any other windows application. There is also a significant, as in noticable, performance cost that tends to annoy users.

Re: ah...been there done that - and its great! by Jonathan Allen

Why did you choose JMS over Microsoft Message Queues or IBM Message Queue?

Re: ah...been there done that - and its great! (JMS vs MSMQ or MQSeries) by Roger Voss

JMS (at the time at least), was a superior messaging spec than what is implemented for MSMQ. Message properties for routing and filtering and topics for pub/sub (as opposed to point-to-point only). MSMQ also had a weak heterogeneous story - with Microsoft relying on other vendors to provide client support for other platforms. Most especially JMS is part of the J2EE spec and can be processed by Message-Driven-Beans (which are dirt simple to write). Microsoft never made a comparable MSMQ messaging container for ASP.NET. They've always treated messaging as a red-headed step child.

MQSeries was IBM and am not using any IBM software stack, as in didn't want to bring in WebSphere as I preferred JBoss. Also, again a weak heterogeneous support story (wanted .NET and C/C++ clients - and even WinCE for my embedded computers).

Ultimately I chose Tibco EMS as my JMS implementation. Tibco has had a strong track record in MOM via its Rendezvous product that is used a lot on Wall Street. EMS already had an excellent .NET client and Tibco agreed to provide a .NET Compact Framework client (which they've now had that out for quite some time and it works very well indeed on our embedded WinCE computers). Tibco also had C client binds and indeed some vendors we integrate with do indeed use C/C++.

Refer to my article for an extensive write-up:

Using JMS For Distributed Software Development

MQSeries was IBM and am not using any IBM software stack, as in didn't want to bring in WebSphere as I preferred JBoss. Also, again a weak hetrogeneous support story (wanted .NET and C/C++ clients - and even WinCE for my embedded computers).

Ultimately I chose Tibco EMS as my JMS implementation. Tibco has had a strong track record in MOM via its Rendevous product that is used a lot on Wall Street. EMS already had an excellent .NET client and Tibco agreed to provide a .NET Compact Framework client (which they've now had that out for quite some time and it works very well indeed on our embedded WinCE computers). Tibco also had C client binds and indeed some vendors we integrate with do indeed use C/C++.

Re: ah...been there done that - and its great! by Ted Neward

What's worse (although not necessarily the problem of the individual Java developer), Swing takes a huge investment in time/resources away from other projects at Sun as they try to make the Windows L&F match precisely what Microsoft releases in each successive Windows release.

Re: ah...been there done that - and its great! (JMS vs MSMQ or MQSeries) by Jonathan Allen

Thanks, that was very informative.

Re: ah...been there done that - and its great! (why Winforms vs Swing/SWT?) by ZedroS Schwartz

Thanks a lot.

I have a better understanding now.

Regarding the issue of tighter Java/Swing/Windows integration, the main issue would be to have all the features platform independent (as required Java), which for your needs would be pretty hard to achieve.

Re: ah...been there done that - and its great! (why Winforms vs Swing/SWT?) by Mark Pollack


I feel like Ross is reading my mind ;) I came to the same conclusion/solution as he did in many areas and in particular using messaging as the interop solution between .NET and Java. (Also using TIBCO EMS). In previous work I coded up Java Swing clients to communicate with C++ server side apps via messaging and had a positive experience.

Just to elaborate more on the JMS part of this thread. Platform/Language interop is certainly and old story from the perspective of many MOM/EAI dealers. JMS certainly helped in the standardization process on the Java side but sadly on the .NET side there isn't a defacto set of messaging interfaces (but at least the delivery semantics are nailed down). Each vendor independently reinvents/reinterprets the JMS API in .NET/C# form. There is the open source project NMS, which is loosely associated with the ActiveMQ project, but I haven't yet tried it out.

I think the critical part of the JMS interop approach comes down to two things, the robustness of the marshalling and keeping objects in sync between .NET/Java since there is very likely some form of data binding is going on to marshal the message payload to a higher level representation. The approach I've used is to write business object in Java and then use the Java Language Conversion assistant to get a .NET version - automated via nant. The JMS marshaller works via reflection to serialize the object into nested map messages. This works very well from my experience. I'm curious if anyone has tried 'plain-ol' XML marshalling?

Just a heads up for those who want to try this out in practice, I'll be committing the Spring.NET equivalent of the Spring.Java messaging infrastructure this week and soon after the reflection based marshaller. Just a blatent plug here...this is going to be the topic of a talk I?m giving at the next Spring conference, The Spring Experience, this December.


p.s. One big thing I've seen regarding the .NET/Java decision on the client side is simply the 'culture' of the shop. Sociology and politics play just as important a role, as always, and I'm believe you can go either way in most cases and have happy users.

XML data duck typing by Roger Voss

One of the most paramount concerns in working with enterprise distributed software systems is the issue of tight coupling between nodes. This particular issue is one reason I prefer messaging vs invoking methods on a remote interface. Interface binding leads to very tight coupling. Tight coupling leads to difficulties in attempting to evolve a distributed system over time. In practice it is seldom feasible to rev tightly coupled nodes in lock step with one another. And the practice of versioning interfaces eventually becomes too burdensome if attempted pervasively.

When messaging is applied with certain tactics it can bring about some significant relief on this front.

Now as I was first starting out with my JMS distributed system development, I was conveying relatively complex XML documents around. These were being described in XSD and then tools like JAXB for Java and XsdObjectGen for .NET were used to generate suitable marshaling code. The documents could then be marshaled into .NET or Java object graphs with ease. This works pretty well (though Ted Neward can speak to some significant limitations and caveats) and the nature of XML Schema, as described by XSD, makes it possible to evolve document schema over time while not disrupting existing code that binds intimately to the resulting object graphs. (Yet one may sometimes still need to regenerate the code when the XSD changes which can require updating deployed code.)

However, I eventually drifted away from this practice and now use an approach that I dub XML data duck typing - a play on the term duck typing that Dave Thomas is well known for using in his Ruby talks.

Basically I was finding that processing nodes tended to have interest in subset information as gleaned from XML documents. This was just a natural evolutionary outcome of organic expansion/enhancement of the distributed software systems. Indeed it was very advantageous to encourage this tendency (a single message could have multiple nuances of effect based on what node processes it).

So I now write components such that they just use XPath to glean the information that they care about from XML documents. I have a technique and a few helper methods that make this a very easy and systematic approach. The upshot of this, though, is that a given node in the distributed system could care less how radically an XML document is evolving over time so long as the info it cares about can continue to be successfully gleaned. If it looks like a duck and quacks like a duck then...

Dropping the code generation tools and just going with XPath-based XML data duck typing has been a breath of fresh air as it breathed a new level of loose coupling into the distributed systems.

BTW, Ted Neward is all over this entire subject matter in a talk he is giving at developer conferences that he dubs XML Services. You can catch him speaking on this at both Java and .NET conferences.

Also, on the subject of data-driven communication vs behavior-driven communication I refer folks to Ted's book:

Effective Enterprise Java
Addison-Wesley Professional
Author: Ted Neward

For a quick taste can take a look at my PowerPoint slide show, where I reference and embellish several items from Ted's book:

Data-Driven Communication vs. Behavior-Driven Communication

Re: XML data duck typing by Mark Pollack


First off sorry to quote your name wrong.... I actually tried to correct it but I couldn't post to my own reply and re-replying posted in the wrong order it seems.

Anyway, it is very interesting to hear about your experience with xpath/xsd and jms transports. What I would like to know is now that you dropped the xsd based code generation tools what data structure is exposed to the business logic, is it the xml fragment that you selected via XPath? Do you bind to any object at that point? At what point does it look more oop like?

Our project didn't have much of a need for picking out a subset of the data to process but did have a big need to be able to quickly determine if a particular message was of interest. As such the project 'jamsel' ( was born. This lets you use the sql subset suppoted by the jms spec used on the property headers but can be applied to the contents of any data structure, in this case a map message. This doesn't pick out the nested map-message node of interest, but has served our needs well when we started, also ~3 years ago. We don't have a hardcore EAI application, mostly client server with some other well defined integration points. In a more EAI/distributed environment I think the XML route is preferable but a little more tedious when you are really interested in sending objects around as xsd isn't an oo environment (which was our case) XPath is clearly a more standard choice for selection of nodes than our home-brewed approach.

In either case you have a self decribing data structure (nested map messages/XML) that is pretty easy to navigate and find out the subset of what interests you. Javadoc of an particular business object is particularly nice if there is a tech savvy business user that wants to review what is being sent around, but I never had much call for that.

As you and Ted rightfully point out, this is a great approach in distributed systems. TIBCO etc, and other messaging/EAI vendors have been promoting that party line for a long time but for whatever reason it never seems to reach a critical mass of popularity, maybe that is gonna change with Ted and others talking about it more.


Re: XML data duck typing by Roger Voss

What I would like to know is now that you dropped the xsd based code generation tools what data structure is exposed to the business logic, is it the xml fragment that you selected via XPath? Do you bind to any object at that point? At what point does it look more OOP-like?

Well, XPath queries can be very surgically precise in specifying what is gleaned, so typically am pulling out scalar values - and sometimes a list that can be iterated. These extracted data are mapped into an appropriately defined Java class (or classes).

I use Spring Framework to create my Message-Driven-Beans, where I derive my primary MDB class (which implements the MessageListener interface) from Spring's AbstractMessageDrivenBean class. Doing this enables the ability to call getBean() as an instance method, which can then be used to instantiate POJO beans ala Spring's dependency injection approach (including injecting dependencies from JNDI). So my MDB classes will have a very modest implementation of onMessage() that just calls subsidiary POJO beans to do everything. The various POJO beans are what are made subject to unit test and also thereby easily debugged under my IDE.

In this snippet of code, the very first thing done is data is gleaned from the received XML message into an RtlsInfo object (RTLS - Real-Time Location Service). That Java object is then processed in various fashion by other POJO beans. (For this particular message the MDB is only transactional against the distributed cache - in other cases, though, the MDB's onMessage() might be declared transactional so that the message could be rolled back into the queue in the event of failure.)

* The MDB entry point for processing a received JMS message.

* Calls a method to parse message body and extract the relevant
* parameter values and then publishes a suitable feedback message.
public void onMessage(Message msg) {
if (log.isTraceEnabled())
log.trace(format(">> %s.%s():%n%s",clsName,"onMessage",msg));
try {
if (!(msg instanceof TextMessage)) {
final TextMessage txtMsg = (TextMessage) msg;

final RtlsInfo info = rtlsGleanInfo.gleanInfo(builder.get(),txtMsg.getText());

final UserTransaction tx = getMessageDrivenContext().getUserTransaction();
if (rtlsFeedbackCheckCache.checkCacheForSending(info,tx)) {
final String feedback = rtlsPrepareFeedback.prepareFeedback(info);

} catch(Exception e) {
// getMessageDrivenContext().setRollbackOnly();

As you and Ted rightfully point out, this is a great approach in distributed systems. TIBCO etc, and other messaging/EAI vendors have been promoting that party line for a long time but for whatever reason it never seems to reach a critical mass of popularity, maybe that is gonna change with Ted and others talking about it more.


In my distributed architecture, there isn't really much OOP-think that goes on. Is mostly topology, data flow, event flow, with a lot of emphasis on filtering, routing, bridging, and transformation. OOP is pretty much just relegated to the internal design of distributed components.

I've been programming in OOP since 1986, when I was using MPW Object Pascal on the Macintosh. From that I went to working on the C++ application framework that was used to make PageMaker portable between Mac and Windows. I've been doing distributed stuff off and on since 1994.

I only learned to jettison OOP in respect to my distributed architecture at the onset of my current systems (which were initiated about three years ago). So it took me a while to lay down the OOP-think hammer.

Follow-up on TIBCO Enterprise Messaging Service by Jonathan Allen

Java vs .Net by Marc Adler

We have been having the same issues in the big Investment Bank that I work for. I have blogged a bit about this at Some of the comments may be related to capital markets. I would be interested to find out what people at similar IBs have gone through to get .Net adopted.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

19 Discuss