Enterprise Interoperability: .NET and J2EE


Tim Mallalieu and Jeromy Carriere
Microsoft Corporation

January 2004

Applies to:
   Microsoft® .NET Framework
   Microsoft® Windows Server™ 2003
   Microsoft® Host Integration Server
   Microsoft® BizTalk Server®
   Microsoft® SQL Server®

Summary: Compares several options to achieve interoperability in an enterprise architecture, including Web services, Message Oriented Middleware, and direct application bridging solutions. Discusses the support Microsoft offers for these options through such products as the .NET Framework, Visual Studio .NET, Windows Server 2003, Host Integration Server, BizTalk Server, and MSMQ.


Interoperation Strategies
Message-Oriented Middleware
Integration Brokers and Orchestration
Web Services: A Standards-Based Approach to Interoperability
Why Web Services?
Interoperability Standards
Architectural Patterns for .NET/J2EE Interoperability with Web Services
Direct Application Bridging Technologies
Making Decisions


"Interoperability: The capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units."
—ISO/IEC 2382 Information Technology Vocabulary

IT organizations today must be strategic partners with their businesses. They must provide significant value to the enterprise, while acting tactically to lower cost of ownership and time to market of the strategic vision. The business challenge is to provide agile technology and services that improve efficiencies in day-to-day business processes.

In the past, improved efficiencies were realized through point solutions that addressed core needs, such as Customer Relationship Management (CRM), Human Resources (HR), and logistics. Today productivity gain is realized through the modeling of the core business processes for the information worker, including the integration of existing systems and external parties into these processes. The way that we do that today is by taking an interoperability view of the world—we can treat portions of applications on separate platforms as atomic units of work that may be orchestrated into meaningful processes.

In order to provide these services the IT organization must:

  • Overcome the hurdle presented by disparate point solutions that typically abound in the enterprise. Most organizations chose best-of-breed point solutions to various problems and have legacy systems in place. A proactive approach to accommodate a multiplicity of solutions establishes an operations framework that contemplates the issues associated with disparate systems and provides the mechanisms for building appropriate bindings between them.
  • Provide a flexible infrastructure that can change with the evolution of the core business processes. By approaching business functionality using building-block services, you arrive at a more flexible software environment that can more readily change with the needs of the business.
  • Reduce time to market of new functionality and demonstrate clear value at the lowest possible cost. This ultimately means that we must strive to maximize re-use and embrace existing functionality instead of "ripping and replacing."
  • Extend the system-level interaction of the business to trading partners and customers. This generates challenges in terms of security, protocol, and end-point–friendly messaging schemes and platform dependency.

Interoperation Strategies


Figure 1. Interoperability of heterogeneous systems

The diagram above depicts various technologies that may participate in a heterogeneous interoperation environment, along with some of the specific technologies that may be employed to achieve interoperation. The diagram incorporates a variety of application types (from .NET clients to mainframe applications to J2EE middle-tier applications), technology classes (Web services, bridging, Message-Oriented Middleware, workflow engines), and products (Microsoft® SQL Server™, Microsoft BizTalk®, IBM WebSphere® MQ, and so on.). Any given system will likely incorporate a subset of these application types, technology classes, and products to achieve its system-wide functional and quality goals, including interoperability.

Three broad classes of interoperation technologies will be discussed here: Message-Oriented Middleware, XML Web services, and direct application bridges. Each of these strategies has specific characteristics that determine its usability and fit for a specific collection of architectural constraints and considerations.

  1. Message-Oriented Middleware. In many cases, solutions that utilize a centralized messaging hub model make the most sense. This is particularly true in situations where ultimate flexibility is required in producer/consumer relationships, message reliability is critical, business processes accommodate asynchronous integrations, and interoperation is generally constrained to a single enterprise. This category encompasses solutions such as Enterprise Application Integration (EAI) and messaging systems available from third-party vendors, for instance, IBM (WebSphere MQ, formerly MQSeries) and TIBCO (Rendezvous). Microsoft's MSMQ is a member of this class of products.

    The Integration Broker is the next logical evolutionary step in the world of Message-Oriented technologies. Integration Broker products perform such tasks as routing, transformation, and message processing, and provide an integration hub through a variety of adapter technologies. The ultimate goal of these products is to enable orchestration: the definition, hosting, and monitoring of integrated business processes. Microsoft BizTalk Server 2002 is such an integration broker/orchestration engine, and provides a competitive solution to problems of document transport, data transformation, application integration, and process automation.

  2. XML Web Services. XML Web services provides a common, platform-agnostic medium by which atomic units of work (services) may be integrated, aggregated, and orchestrated across vendors, systems, and organizational boundaries. Companies that have historically been competitors (including Microsoft, IBM, and BEA) are backing specifications from consortia such as the World-Wide Web Consortium (W3C) and Web Services Interoperability Organization (WS-I) in their delivered products.

    Microsoft's primary strategy for application interoperability rests with the XML Web services approach, as it represents the most flexible and maintainable solution, and applies to the broadest profile of interoperation scenarios. Microsoft's suite of products, including the Microsoft® .NET Framework and Microsoft Visual Studio® .NET, have been applied successfully in the delivery of Web services on Microsoft® Windows® 2000 Server. Microsoft Windows Server™ 2003, version 1.1 of the .NET Framework, and the Microsoft Web Services Enhancements build upon this foundation to deliver enterprise-class services.

  3. Direct Application Bridges. Generally, systems that demand performance over flexibility and broad interoperability are most suited to a bridging approach to interoperation. Bridging refers to a broad category of solutions that encompasses approaches such as mainframe integration, .NET/COM interoperability (as supported by the .NET Framework), and third-party Java/COM or Java/.NET bridges—as well as the extreme case of high-performance, application-specific, wire-level protocols. Microsoft® Host Integration Server provides access to mainframe and AS/400 resources, such as DB2 databases and CICS and IMS applications.

The following sections elaborate on these three classes of interoperation technologies. Each section below describes the generalities of the interoperability strategy, and then provides specific details on the Microsoft products that realize or support the strategy, along with case studies of the application of the products. The section on Web services includes more details on realizing an effective implementation through architectural patterns.

Message-Oriented Middleware

A mature and often applicable answer to the challenges of interoperability is Message-Oriented Middleware (MOM). MOM provides asynchronous, message-based facilities to integrate applications in loosely coupled producer-consumer relationships. MOM infrastructure can provide a high-performance, reliable, and audited fabric for interoperation among heterogeneous systems. Although MOM infrastructure can help ensure consistency of interoperation, it cannot, without further componentry (such as a workflow engine), orchestrate full-featured business processes that enlist the appropriate pieces of functionality regardless of platform and application.

In an effort to incorporate MOM approaches into complete solutions, businesses have augmented basic MOM capabilities to use pseudo-synchronous messaging infrastructures and complex, homegrown RPC strategies for integration. Ultimately, these messaging systems do not adequately solve the problem of interaction beyond the companies' existing infrastructure—a consideration of importance to many, but not all, enterprises. That is, MOM systems work best within an existing message bus environment and inside of the firewall. When trying to get MOM infrastructures to work beyond the corporate boundaries, different MOM infrastructures utilize different protocols and architectures and require different firewall policy configurations. Ultimately one starts to tackle an interoperability problem between MOM infrastructures.

We will discuss Web services below, but it is relevant to note here the potential synergies between messaging frameworks and Web services. Messaging frameworks are good solutions to asynchronous and event-based interactions: those interactions where the emerging Web services protocols are weakest. MOM vendors such as Fiorano are now rallying to embrace Web services, so that companies that have message bus infrastructures can now expose that infrastructure through Web services. Such a combination provides the best of both worlds as one gets a ubiquitous interoperability framework (Web services) as well as a rich asynchronous messaging infrastructure.

On the Microsoft platform, one can leverage BizTalk Server and MSMQ to provide queued services and integration broker services. BizTalk server supports Web services, both from a client and server perspective. This is an interesting option, as one can leverage message routing, transformation services, workflow, and integration with MSMQ and other Message Bus infrastructures from BizTalk server.

In addition, IBM has recently released an interface that allows .NET to use the capabilities of the WebSphere MQ product line. There are similar third-party technologies that allow .NET applications to integrate with TIBCO Rendezvous-based systems.

Here are a couple of integration examples with MSMQ and BizTalk Server:

Integration Brokers and Orchestration

Beyond the transport- and message-level concerns of interoperation is a tier of considerations that reflect upon the broader issues of organization-wide policy and process. A breadth of vendors deliver products to orchestrate—define, host, and monitor—business processes, on top of capabilities for routing, workflow, and message transformation.

Orchestration is designed to empower developers, IT analysts, and information architects to stipulate in a framework the control flow associated with the automation of a business process. The orchestration environment handles all of the hard issues associated with executing a long-running dynamic process, such as transactions, compensations, control flow, and message correlation. A business rules engine is a business intelligence and policy automation engine that defers all sequencing and control flow features, and is used to define and modify dynamically changing business policies in the form of rules. The combination of these technologies for control flow and business rule automation provides great value:

  • It separates business logic from the application layer, thus reducing maintenance costs throughout the application lifecycle.
  • It allows the business user to implement complex logic more quickly, reducing the cost of systems programming and requiring no downtime, thereby providing both a faster return on investment (ROI) and lower total cost of ownership (TCO). Business policies on an orchestration are defined, modified, and maintained in an efficient manner that ensures high performance throughout the lifecycle of orchestration instances, and this is done without using or affecting the orchestration engine.
  • It allows a business user to be involved in the business process through its entire lifetime and compose, change, and manage these policies by providing easy-to-read and declarative rules. The rules are expressed in natural language using vocabularies, or annotations of business rule elements with friendly display names. The business user does not have to worry or know about the technical details involved with the implementation, and is given a mechanism by which he can change the policy anytime during the lifecycle of the orchestration, and have it propagated immediately through the entire system.
  • It provides an inference mechanism that allows the result of rule actions to trigger other relevant rules to reflect the change in state of the environment. The execution mechanism of the rules engine infers that additional rules need to be executed, depending on the state of business objects that are set by previous rule executions.

The Microsoft .NET platform in general, and BizTalk Server 2002 specifically, can help dramatically decrease the resources and time required to implement complex integration projects. With industry-leading support for standards like XML and SOAP, as well as for S/MIME and PKI, BizTalk Server 2002 provides secure and reliable integration regardless of application, platform, or transport. BizTalk Server 2002 provides award-winning tools, a comprehensive adapter library, and proven global-class scalability.

Web Services: A Standards-Based Approach to Interoperability

"[the] architecture of Web services is not fully crystallized. Without guidance, standards may fragment... "
—Gartner Group, March 12, 2001
"Standards... allow Web services to overcome the barriers of different programming languages, operating systems, and vendor platforms so multiple applications can interact."
—eWeek, August 13, 2001

In the previous section we framed the need for an interoperability framework that would facilitate system-level interaction. We have also asserted that XML Web services can provide that framework. This begs the questions: Why Web services? And how can we ensure that Web services will truly provide a consistent interoperable environment across platforms?

Why Web Services?

Today there is an emerging, simple, and broadly adopted set of standards and technologies that allows an IT organization to realize the level of interoperability that is ultimately required. This set of standards and technologies is broadly identified as XML Web services. SOAP XML messages over HTTP can extend beyond the boundaries imposed by corporate firewalls using a paradigm that has been in place since the proliferation of the Web. Also, XML Web services provide a simple, technology-agnostic solution that eliminates, for the most part, the platform and vendor dependencies that were prevalent with many EAI architectures.

XML Web services allow the IT professional to aggregate components from various systems as atomic units of work to realize the desired use cases. Companies such as Microsoft, IBM, BEA, Verisign, and Sun are working fervently to provide a set of standards for XML Web services that contemplate all aspects of enterprise-level interoperability, such as security, reliability, and transactions.

Given the challenges of trying to operate across security boundaries and across platforms, leveraging a protocol that has already solved some of these challenges seems like a logical step. The HTTP protocol provides a protocol and a paradigm for remote invocation (Web page requests) across secure boundaries. The interaction model for HTTP was conceived as user-to-computer, but there was no reason that it cannot be computer-to-computer. The HTTP model also yields a loosely coupled model for the interoperability framework, desirable because it yields greater agility in terms of one's operations environment.

Given an applicable protocol, a medium for describing the interaction is needed. XML provides such a medium. XML provides a technology-agnostic structured grammar that can be leveraged to provide a means for describing remote service interaction. Indeed, in the late 90's, the SOAP protocol was defined as describing an exchange medium between peer systems (in the sense that no system is necessarily distinguished in its capabilities). SOAP is a standard whose specification has been ratified by the W3C organization. The 1.2 specification describes SOAP as follows:

"SOAP is fundamentally a stateless, one-way message exchange paradigm, but applications can create more complex interaction patterns (e.g., request/response, request/multiple responses, etc.) by combining such one-way exchanges with features provided by an underlying protocol and/or application-specific information. SOAP is silent on the semantics of any application-specific data it conveys, as it is on issues such as the routing of SOAP messages, reliable data transfer, firewall traversal, etc. However, SOAP provides the framework by which application-specific information may be conveyed in an extensible manner. Also, SOAP provides a full description of the required actions taken by a SOAP node on receiving a SOAP message."
—SOAP 1.2 Specificiation Overview, W3C

The net result: HTTP and SOAP together was a combination well suited to the provision of a Web-based system-level invocation model, which we now call Web services. From a timing perspective, this was a great fit: The Web model had already established itself as a valid programming model in the enterprise, the need for interoperability between platforms was paramount, and thus we found ourselves with the vision of Web services as our interoperability framework.

Interoperability Standards

XML Web services have been widely acknowledged as a meaningful way to provide interoperability. XML is a self-describing medium that facilitates a technology-agnostic interchange of information. Through the use of SOAP, XML can be used to create Web services that provide both synchronous and asynchronous remote invocation.

The issue with the Web services story as it stands is that SOAP alone does not represent a consistent definition for interoperability. There are a number of standards that need to be defined to ensure that there is a consistent framework in the enterprise that facilitates true interoperability.

To date, many of the standards that are centered on the Web, including the SOAP standard, have been driven through the W3C organization. In response to a need for flushing out and further defining the specifications to promote interoperability, a new organization was created: the WS-I. The WS-I is an industry consortium focused exclusively on interoperability of Web services. The consortium works across industries and standards bodies to provide the guidance and mindshare required to drive Web services Interoperability adoption.

The work of the WS-I, in conjunction with the various standards bodies and vendors, has led to a number of specifications, standards, and profiles. These define the core infrastructure for Web services and contemplate the enterprise-level services that are needed, including security, distributed transactions, and reliable messaging.

Today one can download implementations of the various specs from a number of vendors. Microsoft provides the WSE (Web Services Enhancements) on the MSDN site; IBM provides the WSTK on their developer site. These packages extend the base-level Web service implementations from their respective vendors to realize the extensions and constraints delivered by the WS-I.

The following is a description of some of the key standards for Web services:

  • SOAP. SOAP is a specification that describes an exchange medium between peer systems. The SOAP specification has been ratified by the W3C.
  • WSDL (Web Services Description Language). WSDL is a specification of a means for describing a Web service such that client services can consume the service. The WSDL specification has been ratified by the W3C:

    "WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate..."
    —WSDL description, W3C specification

  • WS-I Basic Profile

    The WS-I has produced the WS-I Basic Profile 1.0 to constrain usage of the W3C Web services specifications (including SOAP and WSDL) to enhance interoperability.

  • UDDI (Universal Description, Discovery, and Integration). UDDI is a SOAP-based specification for locating Web services and programmable resources on the network. The UDDI specification has been ratified by the W3C.
  • WS-Security (Web Services Security). WS-Security defines a standards-based SOAP enhancement that contemplates a means for enforcing security during Web services calls. By defining a standards-based security approach, one can enforce security across platforms. WS-Security contemplates the following:
    • Message Integrity
    • Single Message Authentication
    • Message Confidentiality

On the Microsoft platform, there are a number of implementation options in terms of Web services. The Microsoft .NET Framework is built from the ground up around a vision of interoperability and agility through Web services. Microsoft® ASP.NET provides the technology by which Web services are exposed in the .NET Framework. Creation of a Web service in ASP.NET and Visual Studio .NET is as simple as selecting the Web service project and adding an attribute WebMethod to any public method that you want to expose through your Web service.

The following are some examples of the application of Web services:

  • Using XML Web Services, Honeywell Seamlessly Integrates E-Commerce Sites.
    The ACS division ($8 Billion, 40,000 employees) within Honeywell was challenged with integrating seven different Web applications (e-commerce Web sites). They wanted to use a single user profile and consistent security infrastructure across the Web sites, despite the fact that they were built on different platforms (Java, Microsoft Windows® DNA, and .NET). The ACS group built a number of Web services that could be used by all the sites to integrate the core services they desired. The solution was built in 4 weeks by a team of 3-4 developers, and helped the company realize a $500,000.00 savings.

    "The perfect solution for Honeywell really was the .NET Framework. It allowed us to deploy a solution rapidly without removing our legacy applications. We didn't have time or money to start over, and we had a lot of extremely valuable customer history in our back offices."
    Paul Orzeske
    Vice President of Digitization,
    Automation & Control Solutions,
    Honeywell International

  • Merck & Co., Inc. Uses Visual Studio .NET and Web Services to Integrate with Leading-Edge Vendors and Legacy Systems.
    Merck is a leading, research-driven, pharmaceutical products and services company that invents, develops, and manufactures health products for human and animal health conditions. There is a monitoring phase for products, which requires the capture of information about patients using the products. Merck wanted to build a new monitoring solution, while simultaneously defining the framework and tools for future application development. The Merck environment, however, is a heterogeneous environment with applications implemented and deployed on Oracle, Java, and Microsoft Technologies. The new framework would have to interoperate across the various platforms and technologies. Merck defined a foundation services implementation that used Web services and BizTalk Server for integration and interoperability between the different platforms.
  • Allstate Connects with Countrywide Producer Network Through XML Web Services.
    Using Microsoft .NET technologies to extend and combine the functionality of its host systems, Allstate delivered a solution that meets the unique needs of its countrywide producer community. Except for a thin integration layer, the entire solution was created using the Microsoft Visual Studio .NET development system and is based on the .NET Framework. The integration layer, which runs off-the-shelf J2EE application connectors under IBM WebSphere, is exposed for access by the solution through a common Extensible Markup Language (XML)–based interface.

    "Exposing the functionality of our host systems was a one-time requirement—necessary, but not delivering value in itself. Real strategic value comes from being able to combine and extend the functionality of our host systems to build solutions that meet new business needs."
    Kevin Rice
    Enterprise Architect

  • Bear Sterns Exposes AS400 Stock Order Functionality to Client Applications Using XML Web Services.
    Leading investment banker, Bear Stearns, wanted to provide a means to facilitate its IT staffers provision of stock-trading functionality in new client applications to be used by its employees. The developers could implement the client applications in different technologies, so a single cross-platform means of exposing this functionality was required. Additionally, the functionality that existed was implemented on an AS400 system. Bear Sterns decided to use XML Web services that provided a facade in front of the AS400 functionality, and which could be consumed by a variety of client applications, regardless of client technology and platform.

Architectural Patterns for .NET/J2EE Interoperability with Web Services

Because interoperability between .NET and J2EE using Web services is a strategic approach for many organizations, this section offers a deeper look at making such interoperability successful. Said success will, in large part, be derived from the effective application of proven architectural patterns.

A typical representation of the breakdown of an n-tier architecture is shown below.


Figure 2. A typical n-tier architecture

This standard view of application architecture is user-centric; realization of use cases is often a software implementation that is tightly coupled to the core interactions of the use case. Even in OO paradigms, wherein the domain models exist to map the core entities, the business logic and workflow that drive a use case are typically encapsulated in the core implementation. When one starts to change to a more loosely coupled architecture that lends itself well to the foundations of a service-based architecture, a number of changes occur with regards to the standard model. See Figure 3 below.


Figure 3. A service-based architecture


  • Users are no longer the only clients. Rather, other systems and applications are now the clients, and they may exist inside or outside of the firewall.
  • Facades still exist, but now define units of work that are orchestrated into a given use case.
  • Presentation layer components delegate into service facades instead of pure business facades.
  • A new notion, the service agent, is present that provides the connection and delegation logic to the desired service.

Functionality is now exposed through a Web service facade and can be consumed by Web service clients. The clients can be service agents from an application presentation layer, they may be smart client applications running on a user's machine, or they may be other server applications that need to interact with the given functionality in order to fulfill a given business process.

The common theme in the second diagram is the use of agents and facades. By using agents and facades, one gains a degree of flexibility by loosely coupling clients from servers and allowing the agent to handle discovery, binding, and delegation. In this manner, a delegation point may be in process today and may be changed to make a Web service call on a partner network tomorrow. The agent is the only point with the mitigation logic that defines what service to bind to.

One should also note that the application logic contemplates good n-tier architecture where logic is separated to the appropriate logical layer. The agent-facade interaction typically happens at a point where one crosses a logical layer. As such, this helps us define the appropriate way to look at effective interoperability practices across platforms.

On the Microsoft platform, we can employ the Agent and Facade patterns at the delegation points between the logical layers. In the Java world, the same applies, but it depends on whether one is using Enterprise JavaBeans (EJB) or not as to the best approach for final implementation.

Depending on whether the Web service is to be exposed internally or externally, one may decide to create a separate service layer that still delegates into the business layer, or one may elect to change the business interface so that it becomes the service facade. The decision criterion revolves around whether one wants to constrain the deployment to a single physical tier wherein the Web service and thus Web server resides on the same machine as the business logic. A pro-actively more secure approach is to add a service layer that is logically distinct and delegates into the business layer in order to retain the option of having two physical tiers when the functionality is exposed to external consumers. The compromise here is that one will extract a performance penalty for the over-the-wire call to the separate tier.


Figure 4. Separating the business and service layers

Exposing Java Applications as Web Services

Making the assertion that the Java implementations of existing applications embrace good design patterns and follow decoupling at the logical layers along the lines of the core J2EE design patterns, we can identify logical points at which we can expose functionality as a Web service.

The standard J2EE design patterns advocate the use of business delegates to bridge from the presentation tier to the business tier. The return data is the model data (typically some data transfer object / data structure) used by the presentation tier to render the resultant user interface.

Based on the two choices of exposing functionality by a facade in the business layer or adding a server layer, one can take two approaches in the Java community.

  • Web service facade on the business layer. Some vendors facilitate exposing a simple java class or stateless session bean as a Web service. In the case where one can expose a stateless session bean as a Web service, the session bean should be an implementation of the session facade pattern, where it just forwards the request to a business object behind it. One can similarly expose the explicit business object by using one of the technologies that can expose a plain java class as a Web service.
  • Creating a separate service layer. In the case where one makes a simple service layer, one should create a Business Delegate class that knows how to delegate into the business layer and make the appropriate invocation against the business object or facade. The Business Delegate class in turn gets exposed as a Web service on its own. In this case, as the Business Delegate knows how to delegate to the business layer (as EJB client for example), one can extract the service layer contents to a separate tier with little difficulty.

Exposing .NET Applications as Web Services

As with Java applications, the assertion is made that the applications to be exposed adhere to best practices design and separate application functionality into the various logical layers. ASP.NET is the primary technology for exposing Web services in the .NET Framework. When on Windows Server 2003, one can actually expose registered COM+ objects as a Web service through the COM+ explorer. As a result, if one had .NET components registered with COM+, one could conceivably expose them as Web services in that manner. This would not be the most efficient approach, as one must incur the marshalling expense for crossing the COM/CLR process boundary, and then incur the standard cost of serialization to XML. The best approach is thus to provide, as in the Java option, a service layer or a service facade.

Creating a Web service in Visual Studio .NET is as simple as creating a project of type Web service and then adding the desired method and attributing it as a WebMethod. Indeed, when one creates a Web service project, a sample Web method is present that one can rename, and just change the implementation for the minimum effort.

The Web service in ASP.NET should only contain delegation logic. In the case of a service layer, the Web method should have the same method signature as the concrete method that provides the final implementation desired. The method should, however, delegate to a Business Delegate class, which is a concrete class with an identical message signature to the Web Method and which knows how to bind to the desired business method. The Business Delegate provides a decoupling point between the two that is exposed as a service and the final business logic.

One can employ this implementation style to both design approaches, the two-layer and the single-layer approach.

  • Two Layer (service-layer approach). In the service-layer approach, the Web service (.ASMX file) is part of the logical service layer as is the Business Delegate. The Business Delegate either uses a Web service call or .NET Remoting to invoke the remote method in the business layer.
  • Single Layer. This requires the ASP.NET worker process and Microsoft® Internet Information Services (IIS) to be active on the business layer. The Business Delegate directly invokes the business method. In order to refactor the implementation so that one can move to two physical tiers, one needs to search and replace all direct invocations at the Business Delegate level.

Portability of Types

Although complex data structures can solve many problems, they can also make interoperability more difficult. Some data structures on one platform may be different (from a serialization perspective) or non-existent on an alternative platform. Today, this is most prevalent in collection classes, such as the Java Hashtable and .NET Datasets. There can also be situations where the type exists on the alternative platform but the degree of precision varies, thus resulting in calculation discrepancies.

The solution to this problem is to embrace the Data Transfer Object (DTO) pattern, which creates simple structures that can be collected in simple collections such as arrays for porting across platforms. The DTO can then be defined in terms of lowest common denominator types that are friendly across platforms.

The best mitigation strategy for .NET interoperability is to build test harnesses for your applications and to test often. When one can reproduce functionality on a given platform, the next step is to apply that test against the client platform and vice versa to ensure interoperability. This test should be included in unit, regression, and standard acceptance scripts to help eliminate interoperability issues.

Direct Application Bridging Technologies

In specific cases—those that demand performance over broad interoperability, and can accept tighter coupling and reduced flexibility—a direct application-to-application bridging technology is most appropriate. This a diverse class of solutions, from .NET/COM interoperability as supported by the .NET Framework, through third-party products for .NET/Java and COM/Java integration, to products for mainframe integration.

Also in this class of interoperation are wire-level protocols—generally delivering extremely high performance, but at the expense of difficult integration, a homegrown infrastructure, and reduced flexibility and maintainability. We will not address wire-level integration further in this article.

.NET / COM interoperability

There are two predominant programming models on the Windows platform: the older COM infrastructure and the current generation, the .NET Framework. .NET objects must coexist with the COM infrastructure in order to leverage existing components, to utilize COM+ services, and to expose new functionality to older COM applications. COM interoperability is a core feature of the .NET Framework and runtime environment that facilitates marshalling back and forth between the two environments. COM interoperability is a first-class feature of programming on the Windows platform today.

.NET / Java interoperability

Java-to-.NET bridging solutions provide RPC-level services and native proxies to facilitate RMI-.NET Remoting interaction. The two primary vendors with bridging solutions are JNBridge and Intrinsyc Software. The perception of the benefit of the bridging solutions is that performance will be better and one can get a tight coupling between the two platforms. Performance can be better than Web services today because the overhead of XML serialization and de-serialization, coupled with the size of the XML documents that are passed over the wire, exacts an expense for a SOAP call. As serialization schemes improve on the various platforms, the performance delta will ultimately be minimized.

The disadvantages of the bridging protocols are that they are reliant on vendor solutions and do not adhere to a given open standard. The ability to do things like distributed transactions and security across the platforms becomes dependant on the vendor instead of forcing functions through standards bodies.

Java / COM interoperability

The substantial presence of COM in application development necessitates interoperability with the Java platform. Many Java applications are deployed in environments that also host applications that only expose COM interfaces. Fortunately, bridging schemes are available for Java to COM interoperability. Moving forward, a more extensible and flexible solution is to expose the COM functionality through Web services by using managed Web services and COM interoperability.

Some of the Java/COM bridging solutions are:

Host integration solutions

Most enterprises have significant legacy investments. In many domains, core business functionality exists on mainframe systems that must be integrated with the distributed platform.

Microsoft provides Host Integration Server as the tool that provides integration with mainframe systems such that one can create distributed transactions across the two platforms or expose non-transactional access to the mainframe.

Host Integration Server 2000 provides the following categories of components:

  • Data integration components, which provide desktop or server-based applications with direct access to host data. Host Integration Server 2000 provides a comprehensive set of data access services, including direct data access to relational and non-relational mainframe and AS/400 data through open database connectivity (ODBC), object linking and embedding database (OLE DB), and COM automation controls.
  • Application integration components, which allow host-based and Web- or Windows-based applications to communicate directly with one another. Host Integration Server 2000 delivers solutions for integrating both synchronous and asynchronous transactions.
  • Host Integration Server 2000 management components, which provide a wide assortment of tools to manage the components of Host Integration Server 2000. This includes tools for performing both interactive and scripted local and remote Web-based and traditional client/server management of Host Integration Server components.
  • SNA network components, which connect SNA networks with PC-based LANs. Host Integration Server 2000 allows users running Windows, Macintosh®, UNIX®, the Microsoft MS-DOS® operating system, and IBM® OS/2 to share resources on mainframes and AS/400 systems without requiring system administrators to install resource-heavy SNA protocols on the PCs or install costly software on the host.

In the definition of a service-based architecture for the enterprise, one can leverage Host Integration Server and provide Web service facades to the enterprise that expose the functionality and information existing on the mainframe. As an example:

Turner Broadcasting Sales, Inc. uses Host Integration Server to efficiently access its international traffic system

To provide its global commercial traffic staff with fast, flexible access to the AS/400-based international traffic system, Turner Broadcasting Sales has implemented Microsoft Host Integration Server. This solution enables one person to handle all administration for 200 users, provides secure, reliable, easy user access through a Web browser, and delivers automated reporting capabilities.

Making Decisions

Figure 5 and the table below provide basic guidance for the decision-making process in the context of interoperability. The graph is intended to informally demonstrate the relationships between two key factors in an interoperability scenario; it's clearly not a rigorous decision-making tool. The table below highlights considerations that generally act as overriding concerns, driving specific solutions to the interoperability problem.


Figure 5. Technologies for interoperability

Ultimately, best architectural practices guide us towards XML Web services as a flexible, standards-based approach. Where Web services are unsatisfactory for business or technical reasons, a Message-Oriented Middleware-based approach may provide a more suitable infrastructure. In some cases, direct application-to-application bridges prove to be the appropriate solution, based on performance demands and a tolerance for tighter intercomponent coupling. In any case, a service-oriented architecture strategy, comprising loosely coupled cooperating services, will prove to be the most flexible and agile model, regardless of the underlying interoperation mechanisms employed.

QuestionYesNo, and No Other Factors Override
Require high volume exchange, with very low latency? (For example, thousands of transactions per second.)Use common technology on both sides. Consider application bridging for performance.Apply XML Web services.
Are existing systems unavailable for code change or wrapping?Use implicit bridging or external synchronization (shared database, replication).Apply XML Web services.
Is reliable messaging required? Use Message-Oriented Middleware.Apply XML Web services.
Complex process flow, multiple inputs and outputs, complex message transformation, protocol transformation, message tracking, or auditing required?Use an interoperation broker (for example, BizTalk Server) to deliver these capabilities. Expose entry and exit points as Web services if required.Apply XML Web services.
Are distributed transactions required across the interoperability layer?If possible, re-architect to avoid tight-coupling, basing the new design on use cases. Otherwise, leverage distributed transaction support in a native technology (J2EE or .NET), or apply emerging specifications for transactions in Web services.Apply XML Web services.


The notion of interoperability is a key element for the enterprise. It is extremely rare to find a mature enterprise that can boast of homogeneity of infrastructure. the norm is a heterogeneous environment comprising multiple operating system platforms and technology solutions. Through interoperability, the IT organization becomes an agile machine that can cost-effectively turn strategically and tactically to meet the needs of the business. The level of pro-action and business response is a mark of this agility. The agile business will demonstrate a solid competitive advantage and customer responsiveness, in a repeatable and predictable fashion.

There are a number of mechanisms for interoperability. The standards-based XML Web services approach has the best long-term potential, and is achieving tremendous popularity and adoption. Microsoft recognizes the potential of Web services as the enabling technology for the agile enterprise and is thus incorporating the technology as a first-class feature of all of its product offerings—from the base operating system to development tools to applications and services. Aside from Web services, the use of Message Oriented Middleware and bridging solutions may be applicable depending on the specific organizational and technology needs. Some support has been provided in the Making Decisions section above to facilitate making a choice best suited to the needs of the enterprise. Microsoft provides technologies that support these various options through its core product offerings, such as the .NET Framework, Visual Studio .NET, Windows Server 2003, Host Integration Server, BizTalk Server, and MSMQ.


Case Studies

Performance and cost savings

Leading Careers Web Site Scales to 687 Million Page Views a Month on Windows 2000 Server

Messaging Service Provider Implements XML Web Services Using Visual Basic .NET, Decreases Integration Effort by 75 Percent

(Virgin.com) Web Site Traffic Increases by Almost 50 Per Cent with Microsoft .NET

Law Firm Builds Client Collaboration Portal in Six Weeks Using Microsoft Visual Studio .NET and .NET

HR Solutions Firm to Save More Than $12 Million Per Year with New Customer Service Application

Solution Provider Cuts Development Time in Half Using .NET

Host integration

Turner Broadcasting Sales, Inc. Uses Host Integration Server to Efficiently Access Its International Traffic System

MSMQ and BizTalk

United Kingdom Uses XML to Connect Businesses with Government Departments

London Drugs Uses BizTalk Server to Integrate Packaged and Home Enterprise Applications

Web services

Using XML Web Services, Honeywell Seamlessly Integrates E-Commerce Sites

Merck & Co., Inc. Uses Visual Studio .NET and Web Services to Integrate with Leading-edge Vendors and Legacy Systems

Allstate Connects with Countrywide Producer Network Through XML Web Services

Bear Sterns Exposes AS400 Stock Order Functionality to Client Applications Using XML Web Services

Other References

A Young Persons Guide to SOAP

Web Services: Building Reusable Components with SOAP and ASP.NET

MSDN Soap Resources Page

XML Processing and SOAP Specification @ W3C.Org

XML Schema Specification @ W3C.Org

Understanding SOAP


Microsoft .NET and J2EE Interoperability Toolkit, Microsoft Press

Application Interoperability: Microsoft .NET and J2EE, Patterns and Practices

WS-I Introduction


Understanding GXA

Web Services Framework (W3C Web Services Workshop)

WSDL Schema

The Web Services Idea

WSDL Specification