April 22, 2011, 4:38 p.m.
posted by apollo
Applying SOA and Web Services for Integration.NET and J2EE Interoperability
Web services are typically created for the purpose of exchanging data between applications or services, or for exposing an object method for access by another software program. A Web service contract defines how the Web services messages are mapped between various applications, technologies, and software systems.
In an ideal world, a Java bean could seamlessly invoke any .NET Framework object developed using Visual Basic, C#, or Visual C++, but because of platform and language differences, this is not possible. In a nutshell, the .NET platform is designed for close compatibility with the Windows operating system, and it takes full advantage of native Windows features such as multithreading, memory management, file system access, and other system-level APIs. On the other hand, the J2EE platform takes advantage of the Java virtual machine's portability layer to provide the same features and functionality across all operating systems on which it runs.
Web services can be used to provide interoperability across applications developed using .NET and J2EE, but there are limitations because of the level of functionality currently available in Web services and because of significant differences between the .NET architecture and the J2EE architecture.
Figure places the .NET and J2EE environments side by side, highlighting the fundamental difference in their designs with respect to operating system integration. .NET is designed to integrate very closely with the Windows operating system, while J2EE is designed to work on any operating system, including Windows.
Comparing J2EE and .NET architectures.
Because of key differences, interoperability between the .NET platform and the J2EE platform is limited and can only be achieved at a fairly high level of abstraction. The best approach is to define service contracts (i.e., WSDL interfaces) that either exchange coarse-grained data objects or encapsulate multiple method invocations into a single WSDL service. For example, if both applications need to share customer data, then you should define an XML Schema for the customer record, use it to define the appropriate WSDL operations, and generate SOAP messages based upon it. The WSDL file and the associated XML Schema are crucial because they define the shared data model.
As Figure illustrates, when both a .NET system and a J2EE system, for example, are able to share and understand the same WSDL file, they can interoperate. Because Web services do not include all the features and functionality of J2EE and .NET, however, the interoperability is constrained to what can be achieved using Web services. In particular, features of J2EE and .NET pertaining to object lifecycle management and persistent sessions aren't supported because Web services standards do not include these features.
The WSDL contract allows disparate systems to interoperate.
The WSDL contract describes how to process the SOAP message.
Because SOAP messages are XML documents, each participant needs to be able to understand XML. The WSDL files agreed to by both parties result in the generation of a SOAP message (assuming, of course, that the data type incompatibilities can be resolved) that both sides can understand and exchange to accomplish interoperability. This illustration shows that both ends of the connection need to have access to the same WSDL definitions so that both SOAP nodes can process the messages according to the common WSDL definition and ensure that interoperability via SOAP can be achieved.
In some cases, a binary protocol such as .NET Remoting or RMI/IIOP can support additional QoS without relying upon the availability of the full range of WS-* specifications. Binary protocol options are often provided in enterprise service bus (ESB) products. The ESB support of binary protocols relies upon the same WSDL contract as the SOAP over HTTP option, but uses additional transport bindings.