Introduction
Java 2 Platform, Enterprise Edition (J2EE) is a mature middle tier technology that has become the norm for building production quality enterprise applications. Scalability, reliability, extensibility, security, etc. are a few of the main operating qualities which gives J2EE its edge over competing platforms. Even though it is comparatively straight forward to develop, deploy and maintain applications in the J2EE stack, many a times the J2EE components need to interoperate with other technologies.

Recent trends in development has witnessed Java/J2EE's rising popularity in enterprise class server side application development from its historical stronghold in client side applets and applications. In assessing different solutions such as C and C++, and other object based programming languages like Delphi, Java/J2EE has been found the most stable and proven. Microsoft's Integrated Development Suite (IDS), composing its IDE, Visual Studio, along with a tight integration of programming languages like Visual Basic and Visual C++, has made this development environment the best for fast paced application development. ATLs and MFCs add to this suite. When evaluating for use in native applications that require speed and richness, these technologies are still preferred. Microsoft's .NET offerings that works across Windows 3.1 through Windows XP offer enhanced power to the developer desiring to implement an interoperable solution.

In this article, we will combine the richness and performance of .NET with the stability and maturity of J2EE, shedding special focus on client side interoperability with examples deployed in BEA WebLogic Server 8.1 and .NET platform respectively.

This article would be of interest to Technical Managers and Architects, Project Managers and Leads, and Developers. Since this paper is on interoperability, an exposure to multiple technologies (especially J2EE and .NET) is desirable.

Requirements to Deploy and Run Examples
Here is a list of requirements for deploying and running the examples in this article:

• Windows XP
• BEA Weblogic Platform 8.1 SP3
• Microsoft Visual Studio .NET Enterprise Architect

The scope of this article is limited to:

• Discussing client side interoperability in general
• Discussing Architectural principles of client side interoperability using Web Service
• Demonstrating interoperability with code examples

The following are not covered under the scope of this article:

• Describing Web Services
• Best Design/Coding practices
• All the possible ways of client side interoperability

Interoperability in the Presentation Tier
Irrespective of advancements in the server side platform, an end user is interested in availing a service from the point of usability. A service, for example, can be accessed by a partner's system, a browser, or even a thick client built using another technology. It is when this service system becomes open that a series of aspects need to be considered:

Interoperability Considerations
In order for two parties in different technologies and platform to co-ordinate, both parties will need to agree on a set of protocol aspects. This is because, different platform stack will have its own representation of service and data, and we need to normalize or mediate between these heterogenous representations to enable the desperate parties to communicate. The following section lists out the major aspects to be considered:

• Data Formats: When evaluating a data format, be careful to take note of differences across various platforms. For example, an int in java occupies 32 bits, whereas it occupies 16 bits in C++. Unicode representation is a blessing when it comes to represent characters, since it is possible to represent all character sets using its 2 byte representation of char. So if the same value is represented differently by different platforms, how can we integrate applications in different technologies?
• Transport channels: transport channels can differ when systems try to interoperate. When HTTP is the accepted transport mechanism, another application can well send messages through an SMTP channel. What is the normalization mechanism between these disperate channels?
• Network paths: interoperating across companies and trading partners are not easy since corporate firewalls block binary protocols. This is perhaps one of the primary reasons for lack of popularity with solutions that use Java RMI or Microsoft DCOM.
• Hardware platforms: even though hardware layers are well shielded by the abstractions above it, it is worth paying attention to the differences in WORD representation between different hardware. Most 32-bit client side machines today are being replaced by 64 bit processors. Perhaps good news that long in java no more needs to be externally synchronized (A read or write operation in a long type in java takes place in two instruction sets in a 32 bit processor!).

Apart from the above micro aspects, there is the next level of considerations:

• Performance and standards compliance
• Manageability and reliability

Interoperability Solutions
Interoperability is closely linked with distribution. If there is no distribution, there is no problem of interoperability. Although not an axiom, this reflects a normal case. Let us briefly discuss the available solutions:

• COM/DCOM: Microsoft Transaction Server (MTS) with its COM/DCOM protocols is a solution for distribution and interoperability. However, MTS is proprietary and rests on inelegant Microsoft extensions to C++ and other languages with COM/DCOM bindings.
• CORBA: CORBA was one of the earliest solutions, and is still an accepted solution, even though it is not so popular. Even though CORBA is powerful, it is not accepted due to the fact that it is complex, and most times require the effort of many experts to solve the intricacies between ORBs.
• RMI/IIOP: Although RMI cannot be considered an interoperability protocol, RMI/IIOP is interoperable even though the deployments are not many in number. Moreover, IIOP is not a Java specific protocol.
• .NET Solutions: .NET aids interoperability with its support for Remoting. The advantage here is that the channel used for remoting is easily configurable.
• Proprietary Solutions: Over and above the above mentioned solutions, there are a lot of proprietary solutions for interoperability. But since we are not going to include these proprietary solutions along with open solutions, we are not going to consider them as true interoperable solutions.
• Partly open, and Ad-hoc: The best method of implementing a partly open solution is leveraging the already available open transport channels and sending data too in an open format. Since HTTP is already available as an open channel, and XML is all about open data, combining these two will provide an ad hoc solution.
• Web Services: Web Services promise true interoperability. This is done by standardizing and abstracting most aspects of a service interface in the form of a Web Service Description Language (WSDL).

Using Web Service for Presentation Tier Interoperability
Web Service is the best of available interoperability solutions today, unless performance or other key considerations warrant a binary solution. Since this article focuses on interoperability between a J2EE server and a .NET client, a discussion on the range of variations available within the Web Services programming model is beyond the scope of this article.

Steps for Interoperability
To ensure interoperability, we need to concentrate on the following aspects, amongst other items:

• XML Schema for describing data
• SOAP for formatting the message
• HTTP for transport protocol
• WSDL for description
• UDDI for discovery

The primary specifications upon which Web Services are based is too open and broad that it opens up the scope for a lot of ambiguities once it gets implemented as a Web Service solution. To reduce these ambiguities and achieve interoperability, Web Service vendors formed a consortium called Web Service Interoperability Organization. This standards body drafted their first specification called the Basic Profile 1.0 (BP 1.0). This profile aims to bring about a set of conformance rules that clear up ambiguities in the above standards. Even though no one is required to adhere to BP, doing so will make interoperability less painful.

There are primarily two approaches in integrating a .NET client and a J2EE server - Top-Down approach and Bottom-Up approach. Let us briefly explain the difference between these two:

• Top-Down approach: Although not usable across all cases, the Top-Down approach is the most conventional and straight-forward. Experience has shown that there are cases where we cannot extend this approach, because what works for one Web Service stack may not work for another. And this, precisely, is the motivation behind the Bottom-Up approach. In the Top-Down approach, similar to CORBA where we start from an IDL, we start from the WSDL in Web Services. The service description is fully described in the WSDL and any client can use this WSDL file and follow any of the different binding options available. By binding options we mean, either statically generating client side stubs and binding at compile time or generating dynamic proxies at run time by introspecting the WSDL file on the fly. The main problem in Top-Down approach is data compatibility. Standards are evolving, and it takes some time before the latest standard is reflected in implementations. Even then, it will not happen exactly at the same point in time. This gives the notion of the common denominator, which by and large is the super set of all the data types supported by all the implementations in consideration. It is highly important that we stick to this super set whenever we design interoperability solutions. And it is with this design approach in mind we need to architect for either of these approaches. To solve this problem, we should look at exchanging only primitive data types, such as strings, integers and so on. All Web Service stacks support these data types, providing the greatest levels of flexibility and client access. In the Top-Down approach, the service definition exposes what it mandates, and it is up to the client runtime to agree to the service format.

• Bottom-Up approach: In the Bottom-Up approach the client has to agree and bind to the service definition, but in defining the service bindings we will do a round about way. One scenario is when we need to send a very complex data structure, which we suspect will be supported by all client runtimes. In such a case, we package the data as a string. The best solution here is to populate a string with an XML representation of the data. This XML encoding should follow an agreed schema. This again means, we start from an agreed schema, set up the service implementation, and then expose the service description. The client may have some and/or full idea about the service types involved. Most of the times, such an approach will result in a kind of Document Oriented Web Service. Vendor tools can again help in automating this process. Most relevant steps to be followed are:

• Create schema that represents the XML form of the data
• Technology specific data classes based on the above schema
• Technology specific serialization / de- serialization class, which will carry out above translations

Client applications that consume the Web Service need to understand the formats and valid values so as to process the service return types.

Architecture for Presentation tier interoperability
In this sample architecture, we will design for both the above scenarios. We will use the same application available in the examples folder in the Weblogic installation, and expend it for both the scenarios.

We will have three methods in our service interface, as shown below:

public interface Trader extends EJBObject{

TradeResult buy (String stockSymbol, int shares) throws RemoteException;

TradeResult sell (String stockSymbol, int shares) throws RemoteException;

String getAllProducts() throws RemoteException;
}

The notable point in this interface is that TradeResult is a complex type. When such a complex type is visible in the service interface, it eventually means that the client needs to understand this complex type when it binds to avail the service. Web Service standards are mature to the extent that this level of interoperability is possible in many cases.

The third method does not have any visible complex type, but in fact the return type which is a simple string is going to be a flattened representation of a more complex type.

The first two methods (buy and sell) are examples for the Top-Down approach, whereas we will build the third method (getAllProducts) in the Bottom-Up approach. The service will be implemented as a stateless session bean in the Weblogic J2EE platform. The client will be built in .NET using the C# programming language.

Fig. 1: The Sample Architecture

While the first two methods are straight forward, let us explore the rationale behind the third method. In fact, the third method is intended to return a collection of Product complex type. Perhaps, this type too is not that complex that we can return them similar to TradeResult as in the first two methods. But for demonstration of the concept, let us assume that the collection of Product complex type is not simple, and we have taken an architectural decision to flatten this collection as an XML string. For this, let us quickly list down the steps to be performed:

• Agree on a schema for the complex collection type
• Create the XSD based data types on server and client ends
• On the server, convert the java data types based on XSD to XML representation and serve
• On the client access the service as an XML string, and based on the XSD, convert them to .NET data types, and work on with the data types.

Implementing the Demonstration
Deployment of the server component and exposing them as Web Service is straight forward (follow WebLogic Server Web Services programming examples referenced in the resources section for more details). One point which needs to be mentioned here is the conversion to XML, based on XSD.

As usual, the data for Product types might be streamed from a database. Once the data and XSD are available, we normally need to use any of the available automatic methods to convert the data to XML format.

Many Java XML products can map a field in the class to an element or attribute in the XML Schema. Sometimes the existing classes map to the correct schema without needing an intermediary. If this is the case, we can create mapping files for the existing classes, as this removes the step of taking the data from the existing Java classes into the Schema-based Java classes. Since the intention behind this article is to show the architectural building blocks for attaining interoperability and not demonstrate the various implementation mechanisms, this part is intentionally omitted by hard coding the XML structure with data in the server side implementation.

In the client side we have two components, EJBClient and DataClient, both implemented in .NET. The EJBClient will avail the buy and sell services whereas the DataClient will access the getAllProducts service. For building the clients, we first need to generate client side stubs for the Web Service. The commands used are shown in Figure 2.

Fig. 2: Generating Client side Stubs

The commands will generate TraderService.cs (C#.NET files). Now, coding the EjbClient is straight forward. Executing EjbClient.exe, we can invoke Buy and Sell.

Fig. 3: EJBClient in .NET

The DataClient is designed to show the XML data retrieved from the server in a DataGrid control. This is done in just two lines of codes:

products1.ReadXml(memStream);
dataGrid.SetDataBinding(products1, "Product");

where products1 is a typed DataSet in .NET, and memStream is a MemoryStream type, which is an in-memory representation of the XML data. Even without generating a a typed DataSet, it is posible to bind the XML data using the above two lines of code and display it in the format shown in Figure 4.

Fig. 4: Data Client in .NET

A Typed DataSet is easily generated from the XSD, which helps especially when working with the DataSet to do type safe coding, using the command shown in Figure 5.

Fig. 5: Generating typed DataSet

Before building the server, do make necessary changes in the build.xml file, corresponding to the line:

<property file="C:/bea/weblogic81/samples/server/examples/src/examples.properties"/>

Summary
The article described the integration of .NET technology in the client side to access Web Services implemented in BEA Weblogic platform. It walks the reader through architecting a solution for client side interoperability, following either the Top-Down approach or the Bottom-Up approach. The code examples demonstrate both J2EE based server implementation and .NET based client side bindings. The tail piece helps choose best the breed of solutions across technologies for different problems at hand and prompts the reader to follow the most appropriate architectural steps for attaining the required level of interoperability.
Feedback on this article can be mailed to editors@jaxmag.com

Resources

Microsoft Web Service Development center
BEA Dev2Dev Web Services center
SOAPBuilders Interoperability for interoperability testing between SOAP implementations
Web Services Description Language Specification
SOAP specification
UDDI
HTTP 1.1
WS-I Basic Profile 1.0
Programming Weblogic Web Services
Code Download for this article

About the Author
Binildas is a Senior Technical Architect at the Software Engineering Technology Labs (SET Labs) of Infosys. A graduate in Engineering and a post graduate in Systems Management, he is also a Sun Certified Programmer, Developer, Business Component Developer and Enterprise Architect, and a Microsoft Certified Professional.