Microsoft and Sun recently announced their Open Source Project Stonehenge at the JavaOne conference. Stonehenge is a reference implementation that shows how to bridge the two major development platforms Java and .NET using Web Services. This initiative definitely puts the spotlight on heterogeneity and the challenges that come with it.
Interoperability on the platform level is just the starting point of bridging the two worlds. It leads to further challenges down the road and several questions that come with it:

• Who needs interoperability?
• How does it affect team productivity?
• Is it all about application stacks?
• How effective can we diagnose problems?
• How to calculate TCO 1 + 1 = 2 or 3?

Who needs interoperability?
There are different use cases where companies need to think about interoperability

• Integrating different systems implemented on different platforms, e.g.: ERP with CRM
• Integrating 3rd party solutions that only run on a specific platform, e.g.: Enterprise Search Engines
• Integrate components inherited from acquisitions

The driving factor of interoperability in all these cases is gained productivity. Instead of re-implementing an existing system in order to bring it on to the platform of choice it is more productive to integrate with the other platform.

Individual platforms also have their individual strengths in different areas. Microsoft technologies for instance provide great flexibility and good tools to implement end-user applications whereas the Java platform has proven itself very strong in backend enterprise systems. Leveraging the best of both sides requires the integration of these two worlds.
Microsoft and Sun took the first step by providing a reference implementation that shows how to technically integrate .NET and Java by using Web Services. This is a first important step – but there is more than the technical integration that we need in order to successfully make interoperability happen.

How does it affect team productivity?
How often have you seen a .NET developer that debugs Java code in Eclipse on Linux? Or how often have you seen a Java developer in front of Visual Studio browsing through C# or VB.NET code?
Cross platform developers are a rare “species”. A typical cross platform development team therefore has developers specialized in either Java or .NET. An individual developer most often sees the other platform as a Black Box and as something that should be avoided if possible. Web Services allow calling from .NET to Java and the other way around. Debugging is easy on each side individually but it becomes a big obstacle having to debug transactions that cross platform boundaries. It either requires the developer to be both acquainted with Visual Studio and Eclipse as well as being familiar with both the Java and .NET code – which rarely is the case.
In a typical heterogeneous team it therefore always requires developers from both sides to analyze transaction flows. This is a tedious manual task by setting the correct breakpoints on each side and in each IDE, then stepping through the code. Debugging through code also only works in a single user environment as it is hardly possible to identify the correct thread on the server side implementation of a Web Service that belongs to the calling client side.

If the team collaboration works well – cross platform problem analysis is a doable task – but as outlined above it requires at least one resource from each side. Far too often – these team members don’t communicate well and simply play the “Blame Game” when coming across an issue by simply blaming the problem to be in the implementation on the other platform. This approach of resolving the problem negatively affects team productivity by introducing extra resolution cycles and it also increases tension between teams and team members.
These cross team issues are similar than thse we have seen between development and testing teams – two teams that work in different domains not having the insight into the others problem domain. This similar problem has been solved by providing testers with diagnostics tools that collect more meaningful information during their tests which help developers to quickly identify the root cause of problems. Getting this type of information not only took out the tension but also fastened the overall development cycle.

The logical conclusion therefore is to equip all teams in a heterogeneous team with tools that can collect and visualize the right set of data to speed up problem resolution, take out the tension and improve the overall team productivity.

Is it all about application stacks?
Integrating the different platforms from an implementation perspective is obviously the mandatory step to allow cross platform communication. This goal has been achieved with Web Services and the correct implementation of Web Service Standards by the different application stack providers.
Development tools like Visual Studio and Eclipse make it easy to create the application code (proxy classes) necessary to call from Java to .NET and vice versa. As long as everything runs fine during runtime developers on both sides can focus on their implementation without needing to worry about what is going on in the other cross platform teams.
In case problems come up, e.g.: calling a .NET Web Service from Java that returns a weird error its not possible for the Java Developer to go beyond the error message received in the Eclipse debugger. Tools on each side are very good in debugging, diagnosing and profiling problems on the respective platform. Cross Platform Support is however missing right now – preventing the Java Developer to follow the problem to the .NET side.

Why do we need cross platform tools?
Coming back to the example from above: When calling a .NET Web Service that throws an error or that executes slow can have multiple reasons. It could be a bug in the .NET Web Service implementation. It could also be a configuration issue in one of the used SOAP Application Stacks causing interoperability issues or it might be problematic input parameters from the Java side that causes unexpected or slow behaviours on the other side. One approach to analyze the problem is analyzing log files from both sides. The problem here is that there is no common log format and that there is no transactional context available that would allow transactional tracing and correlation of log entries.
In order to analyze cross platform problems we therefore need tools that support all involved platforms. Having this ability enables developers on both sides to understand the dynamics of the whole system better and fastens up problem resolution.

How effectively can we diagnose problems?
The first thing in problem diagnosis is to answer the question whether there is a problem or not. Problems can manifest in different ways

• Bad application performance to the end user
• Errors in log entries of individual components
• Resource issues in infrastructure impacting system components

When we know that we have a problem we need to figure out where the problem is. Looking at log files that indicate a problem is almost a best case scenario as it at least gives an indication where the problem surfaced the first time. Problems perceived by end users, e.g.: bad application performance or error pages are harder to track. Where was the time spent? Which component threw the error that made it to the user interface?
Getting alerts by monitoring individual system components can tell us that we run high on CPU on certain servers or that we consume too much network bandwidth. But which component is responsible for the exhaustive use of resources? Is it a bug in a component that runs on these servers or is it a calling service that makes too many calls to a certain component?

Existing Monitoring and Diagnostics solutions focus on a particular environment or single server instances. Application Servers usually come with their own diagnostics support and additionally export performance counters that can be picked up by Enterprise Monitoring Solutions that enable monitoring of the complete infrastructure. These tools are great to analyze general problems in the infrastructure or to analyze standalone problems within a server. All existing tools however lack in analyzing cross platform issues. There are tools that analyze log files from all different components and correlate events in different logfiles to identify individual transactions. This is the right way to go but it relies on having the log information that can be correlated.

Too often problem diagnosis in heterogeneous environments comes back to being done manually. Collecting all available log information and performance counters. As any manual task it’s not a task that is very effective and does not always lead to a successful problem diagnosis. In order to diagnose problems we require a common way of capturing information from all platforms that participate when executing a transaction. In case a transaction has a problem – all this information must be extractable and easy accessible to developers to analyze the problem.

How to calculate TCO 1 + 1 = 2 or 3?
The tool landscape for Java and .NET is a huge one. There are many specialized tools that help improve productivity by supporting all stakeholders involved in running an application.
When working in cross platform environments it’s necessary to ensure good tool support for each platform. Most of the tools on the market are very specialized on a single platform leading to the need of multiple tools in order to get the best support for each platform. More tools means more costs – especially when we want to ensure productivity.
Total Cost of Ownership for heterogeneous environments however is not just defined by the individual costs of the tools it requires. Additionally to buying individual tools there is extra cost involved to integrate them. Getting information from each of the tools is good – but the information is only really valuable when the information can be integrated in a similar way as our applications are integrated.
The lack of standards makes it very hard to actually integrate these tools to get the value out of it that each individual gives on a single platform.
Tools that support all platforms and that are able to provide the data collected on each platform in an integrated way will save costs that would otherwise be necessary to integrate individual island solutions.

Related posts:

1. Web Service Interoperabilty Issues I’ve been working on building a .NET Client Application to...
2. Performance Analysis: Identify GC bottlenecks in distributed heterogeneous environments William Louth made a good reference to one of his...
3. Getting ready for TechReady8: Load- and Web-Testing with VSTS and dynaTrace I’ve been invited by Microsoft to show dynaTrace’s integration into...

• Sun’s JavaOne 2009: Business As Usual
• JavaOne 2009 "Weird" Says the Father of Java