BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Java, .NET, But Why Together?

Java, .NET, But Why Together?

This item in japanese

Bookmarks

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 http://msdn.microsoft.com/msdnmag/issues/06/08/default.aspx) 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
Style

BT