J2EE and .NET: Presentation Tier Interoperability

By Binildas C.A.

In this article, Binildas C.A. sheds light on this important, yet sparsely documented, area of interoperability considerations. He also discusess about some of the solutions available to work hassle-free with .NET and J2EE. The article converges at a point, and rightly so, to propose web services as a technology for attaining client side interoperability, and in that attempt, addresses two important approaches: top-down and bottom-up. As proof of the proposed technology, practical demonstration of the two approaches, and the successful implementation of a solution, the writer showcases a sample architecture based on BEA WebLogic Server and .NET C# client.

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 few main operating qualities which give J2EE its edge over competing platforms. Though it is comparatively easier 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 have 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 like C and C++, and other object-based programming languages like Delphi, Java/J2EE have 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 work 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. 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 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, browser, or even 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 coordinate, both need to agree on a set of protocol aspects. This is because different platform stacks have their own representation of service and data. We need to normalise or mediate between these heterogenous representations to enable the desperate parties to communicate. These are major aspects to consider: • Data formats: When evaluating a data format, take note of the differences across various platforms. For example, an int in Java occupies 32 bits, and 16 bits in C++. Unicode representation is a blessing when it comes to representing characters, since it is possible to represent all character sets using its 2 byte representation of char. Hence, 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 normalisation mechanism between these disparate channels? • Network paths: Interoperating across companies and trading partners are not easy since corporate firewalls block binary protocols. This is perhaps one primary reason for the lack of popularity with solutions that use Java RMI or Microsoft DCOM. • Hardware platforms: 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 longer 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 those aspects mentioned, 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 will be 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 which is still acceptable, even though it is not so popular. Even though CORBA is powerful, it is not popular due to its complexity, and most times, it requires the effort of many experts to solve the intricacies between ORBs. • RMI/IIOP: While RMI cannot be considered an interoperability protocol, RMI/IIOP is interoperable even though the deployments are a handful. 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: Apart from solutions mentioned above, there are many proprietary ones for interoperability. Since we are not including 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 by leveraging the already available open transport channels and sending data 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 standardising 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 interoperability solution available today, unless performance or other key considerations warrant a binary solution. As this article focuses on interoperability between a J2EE server and .NET client, a discussion on the range of variations available within the web services programming model is beyond our discussion scope. 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 are too open and broad. That 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 Organisation. 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 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 straightforward. 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. This is precisely 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. 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 with 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 is generally the super set of all 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. 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 this approach, the service definition exposes what it mandates, and it is up to the client run-time 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 roundabout way. One scenario is when we need to send a very complex data structure, which we suspect will be supported by all client run-times. In such 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 implies we start from an “agreed schema”, set up the service implementation, and then expose the service description. The client may have some or full idea about the “service types” involved. Most of the times, such approach will result in a kind of document-oriented web service. Vendor tools can again help in automating this process. Most relevant steps to follow include: • Create schema that represents the XML form of the data • Technology-specific data classes based on the above schema • Technology-specific serialisation/de-serialisation class that carries out the 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 scenarios above. We will use the same application available in the examples folder in the WebLogic installation, and expend it for both 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 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. In fact, the return type which is a simple string is going to be a flattened representation of a more complex type. The former two methods (buy and sell) are examples for the top-down approach, and 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 simple, 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 with the other two methods. To demonstrate 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 perform: • Agree on a schema for the complex collection type • Create the XSD-based data types on server and client ends • On the server, convert Java data types based on XSD to XML representation and serve • On the client, access service as an XML string, and based on XSD, convert them to .NET data types and continue working with them Implementing the Demonstration Deployment of the server component and exposing them as web service is easy. Follow WebLogic Server Web Services programming examples referenced in Links & Literature 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 available automatic methods to convert 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, existing classes map to the correct schema without requiring an intermediary. If this is the case, we can create mapping files for existing classes, as this removes the step of taking data from existing Java classes into Schema-based Java classes. Since this article has intended to show the architectural building blocks for attaining interoperability and not demonstrate 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 while DataClient will access the getAllProducts service. To build these clients, we first need to generate client side stubs for the web service. The commands used are displayed in Fig. 2. Fig. 2: Generating client side stubs These commands will generate TraderService.cs (C#.NET files). Now, coding the EJBClient is simple. By 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 with only two lines of code: 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 typed DataSet, it is possible to bind the XML data using the two lines of codes and display it in the format shown in Fig. 4. Fig. 4: DataClient 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 in Fig. 5. Fig. 5: Generating Typed DataSet Before building the server, do make necessary changes in the build.xml file, corresponding to the line: Summary The article described the integration of .NET technology in the client side to access web services implemented in BEA WebLogic platform. It walks readers through architecting a solution for client side interoperability, following either the top-down or bottom-up approach. The code examples demonstrate both J2EE-based server implementation and .NET-based client side bindings. The tail piece helps choose best of the breed solutions across technologies for different problems at hand. It also prompts readers to follow the most appropriate architectural steps for attaining the required level of interoperability.