Service Oriented Architecture (SOA) provides an excellent strategy when a customer's environment requires full application interoperability. Such a situation might involve a credit card verification company with a dozen flagship applications. That company will want to expose consumables regardless of which flagship application is used. This is a decoupled approach, where data flows freely regardless of use case.

SOA presents a standardized programming model that helps expose this manner of business functionality to a variety of scenarios and use cases. SOA aggregates similar business processes through services that support low coupling, which enables reuse across business applications and client contexts.

One should remain aware that this approach can present numerous and potentially complex issues once the developers and architects start working tactically. Issues of security and protocols beg particular rationalization.

Relevant links and collateral:

	Top Ten SOA Issues
	Microsoft's SOA Resources for Developers

Sometimes developers and architects simply want a client to interact with a service as it exists now. In such cases, a bridging approach works well. Consider this approach when: Faced with hybrid scenarios where updates occur and are deployed in the same trusted zone. Compatibility and performance concerns arise, such as when you're asked, "Does my Web services security work with yours?"

A Web services-based model may involve handling large amounts of data through XML over HTTP.

Binary interoperability methods take objects from one platform and serialize them into a binary stream. This stream travels across the network and is then deserialized on another platform where the binary data maps successfully to local data types.

Services-based programming models—such as SOA—feature potentially large implications in terms of SOAP, XSD, and protocols. As stated, sometimes developers and architects want a client to interact with a service as it exists now. For example, a Java solution may expose its functionality as Enterprise JavaBeans (EJB). Through bridging you can build a proxy that links this to the .NET callers through the .NET remoting protocol.

Developers do not need to learn about new protocols—they use a development tool that generates the needed proxies, open up a C# source file, and then start coding in exactly the same classes, methods, and types they are already accustomed to. This eliminates the need to learn a whole new realm of technology.

Intrinsyc Software's suite of J-Integra products is a powerful, effective, and widely supported middleware technology built to enable interoperability between Java, CORBA, and Microsoft COM and .NET components. Many Fortune 1000 companies use the J-Integra solution to effectively integrate and harness the most powerful features of Java and Microsoft technologies.

Relevant links and collateral:

http://j-integra.intrinsyc.com/products/

JNBridgePro is a class-level Java and .NET interoperability tool that provides full two-way access to any object and access to any instance or static member across the platform boundary. JNBridgePro bridges .NET with J2SE or J2EE—including J2EE facilities such as EJB, Java Message Service (JMS), and Java Naming and Directory Interface (JNDI)—and supports all the leading J2EE application servers.

The classic scenario here is where a customer uses a JMS-based messaging provider like Sonic or MQSeries from IBM and developers may want to have a .NET client or application participate in this messaging environment.

A question we often hear is, "Do you support a JMS interface with .NET? Specifically, can you take a JMS-based message provider and use a .NET assembly that implements the JMS API and interact with that?" Although the answer is that we don't, we can use a bridging product that interacts with the JMS client. Users will work with a .NET client that will supply JMS-like APIs. Standard JMS messaging types simply flow across this bridge.

There is good news in a number of specific cases, however, because some out-of-the-box solutions present ready solutions. In the case of MQSeries from IBM, the Microsoft MSMQ-MQSeries Bridge spans the gap between Microsoft Message Queuing (MSMQ) and MQSeries. Additionally, vendors such as IBM and Sonic provide a .NET client.

Regardless of the specific message bridging used, the approach provides an abstract means of interacting with JMS-based queues without breaking the existing programming model.

Relevant links and collateral:

	Implementing Asynchronous Interoperability
	Interoperability Technologies: Data Tier

"What code can I reuse?" That's the question the Java developer or architect will ask in this case. A situation may call for incorporating core business logic or IP within a .NET version and using native .NET technologies toward an implementation in WinForms, rather than a Java Web interface or Swing. Examples include search functionality, algorithms, or business orchestrations.

This Common Business Logic approach involves the reuse of source code across .NET and Java platforms using the Microsoft J# programming language. It uses the Java language syntax (Language Spec 2.0) and can be compiled with the /strict flag to keep pure Java language syntax. Of course, the Java source code must conform to the constraints of J#. Any Java code that doesn't directly access platform APIs can be recompiled to Microsoft Intermediate Language (MSIL) to run on .NET.