Best Practices and Pitfalls

The following identifies some best practices and pitfalls that are relevant to designing reliability, availability, and scalability features of a Java EE .NET interoperability solution.

Best Practices

• Always do a sanity check for end-to-end availability during the design review of a Java EE .NET interoperable solution. Examine each technical component to see how the application or service is recovered.

• Accuracy in measuring .NET application performance. The system packages System.DateTime and System.TimeSpan are accurate only within about 10 milliseconds for most applications. However, if XML object serialization is used, use the QueryPerformanceCounter API to obtain a more accurate representation of how much time is elapsed.

• Use MTOM rather than SwaRef (SOAP with Attachment) because MTOM should have better performance, and the use of XOP encoding (processing overhead) is expensive.

• Secure MTOM (using message encryption for MTOM messages) has overhead. Do not try to use message encryption for all types of data or business transactions unless required.

Pitfalls

• Do not compare Java and .NET application performance directly. This is like an apple-to-orange comparison. When comparing application performance in the context of Java EE .NET interoperability solutions, always compare the performance between integration strategies using the same set of business requirements, constraints, and hardware environment.

• Do not attempt to cluster every application and machine by default. Always consider the objectives for the clustering because clustering introduces considerable overhead and may not actually meet the overall technical objectives.

• Logging is a useful feature to track business transactions and system events. Some transaction logging can also help to recover transactions in case of service failure. However, turning on the highest level of logging by default does not necessarily make the application available. It will deteriorate system performance considerably.

• When exchanging data types between Java and .NET applications, there is a general lack of error control or exception handling to catch invalid data types during XML serialization or data transmission between Java and .NET clients.