Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Microsoft .NET and Java: Achieving Interoperability : Page 3

Although Web services are the technology most people immediately assume will solve their interoperability problems, one size does not fit all. But regardless of your needs or expectations, an interoperability solution probably exists to fulfill them. Read this quick overview to begin exploring the various methods for achieving interoperability between Java and .NET.


advertisement
Resource Tier Interoperability
Interoperability solutions using Web services, .NET Remoting, or CORBA are typically synchronous in nature, and occur between two parties (a client and a service). In typical calls, the client calls the service, some data is returned, and the call is finished.

In applications that need to behave in a more asynchronous fashion, interoperability at the resource tier—which implies using either a database or a message queue—may be the answer. Using a database or message queue to connect platforms based on .NET and J2EE can be one of the easiest ways to achieve interoperability between the two. Database solutions typically share a table between the two platforms, and each uses its preferred method for connecting to the database (ADO.NET for .NET, JDBC for the Java platform). Investing in stored procedures at the database tier can also help in reducing duplication of code.

Interfacing with message queues works in a similar way, although each platform will normally have to obtain a driver from the message queue vendor in order to establish a connection. This may be a JMS (Java Message Service) driver for the J2EE platform, or a specific set of classes for .NET. For example, IBM offers WebSphere MQ 5.3 drivers with similar style interfaces for both Java and .NET. Many message queue vendors now also offer the ability to communicate via more standardized interfaces such as Web services.

In addition to providing good support for asynchronous style calls, using the resource tier can prove beneficial for n-n style interoperability, where multiple clients need to communicate with multiple servers. In the majority of the previous interoperability solutions, each client needs to know the location of each server. In a scenario using an intermediary database or message queue, although both sides must agree on the format of the message, the client does not necessarily need knowledge of the service location—which both negates the need for location-based information and can also help provide support for failover and load balancing.

For all the advantages that a database or message queue provides however, they really are designed for asynchronous style communication. Using them in a synchronous style call (for example, where an ASP.NET page required a response before displaying the result to the user) can lead to potential performance issues. In addition, using either a database or message queue introduces yet another piece to the interoperability puzzle. For situations where many machines have a requirement for interoperability, it may be worth the investment in administration and additional machines; but in a scenario where just one client needs to interoperate with a single service, this solution just introduces potential overhead.

In his article, "Java/.NET Interoperability via Shared Databases and Enterprise Messaging," Kyle Gabhart investigates the approach of using either a database or message queue to achieve interoperability between Microsoft .NET and Java.

Compare, then Decide
It is fair to say that there's no universal answer for interoperability today. While Web services offer incredible potential moving forward, applications already in place today may require more of a tactical approach. To help you differentiate between the various approaches, Table 1 lists some of the advantages and disadvantages of each.

Table 1. Interoperability Comparison Matrix: The table shows some of the advantages and disadvantages of each interoperability solution.

 

Integrated Platform Support



XML / SOAP Interoperability

Binary Interoperability

Designed for Synchronous Style Calls

Designed for Asynchronous Style Calls

Requires modifications to existing server side components

Extensible without re-compile

Web services

Yes

Yes

No

Yes

No**

Yes***

Yes

.NET Remoting

Partial

Yes*

Yes

Yes

No

Partial

No

CORBA Interoperability

Partial

No

Yes

Yes

No

No

No

Resource Tier

Yes

Optional

Optional

No

Yes

N/A

No

* Uses CLR data types, not XSD
** Assuming HTTP as the transport
*** The majority of modifications are required to ensure the data types exposed are XSD compliant

We hope that this special report offers you some insight into the merits and suitability of the various interoperability approaches.



Simon Guest is a Program Manager in Microsoft's .NET Enterprise Architecture Team. He specializes in enterprise interoperability and integration and works with enterprise customers, vendors and system integrators. Simon is the author of the Microsoft .NET and J2EE Interoperability Toolkit from Microsoft Press in which he covers many interoperability options outlined in this article, with code samples on the accompanying CD. You can reach him here.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap