Applying SOA and Web Services for Integration.NET and J2EE Interoperability





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.[5] A Web service contract defines how the Web services messages are mapped between various applications, technologies, and software systems.

[5] It must be noted that using Web services for remote object invocation is an inappropriate use of Web services. If you want to implement distributed objects, then you should use a distributed object technology, like Java RMI or CORBA. Web services is a documentoriented technology, not an object-oriented technology. Nevertheless, it is a fact of life that some analysts and vendors recommend that the best way for, say, a C# requestor to communicate with, say, a Java provider is using RPC-oriented Web services.

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.

Different Approaches to Web Services

It's interesting to note that the .NET platform was completely redesigned for Web services, thereby introducing a discontinuity for Microsoft developers. Applications written using VB6, for example, have to be rewritten to take advantage of .NET features, including Web services. The J2EE approach, on the other hand, did not involve a fundamental rewrite or redesign of the platform but instead viewed Web services as being similar to any other external technology (such as directories, databases, or security servers) for which a new J2EE API had to be developed. It's very interesting to consider which approach is bettera revolutionary re-architecting of the platform or a more evolutionary embrace-and-extend approach.


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.


Figure[6] illustrates the fact that when the .NET platform and the J2EE platform share a Web services contract, they communicate using SOAP messages.

[6] Note that UDDI is not shown in these illustrations because it represents an optional element of the Web services architecture. Web services descriptions can be shared without using UDDI.

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.


     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows