| Quality of Services is essential to providing production quality and robustness for business applications. Both Java and .NET platforms have features that developers can use to build reliable, highly available, and scalable interoperable solutions. On the positive side, a well architected Java EE .NET interoperability solution can optimize the current hardware infrastructure for best system performance and high availability and can allow business data to be reliably exchanged. This is like putting the interoperability solution on steroids. However, a fast and highly scalable producer (whether a Java or .NET application) can be impeded or severely impacted by a poorly designed consumer, which causes the system to crash or lose business data. If the consumer cannot handle large volume business transactions during the peak hours (that is, consumer is not scalable), then the entire interoperable solution will not function effectively, and it will likely break the service level agreement. Chapter 11, "Addressing Quality of Services," discusses some of the myths and truths about Quality of Services. It argues that Quality of Services need to be addressed early in the application design of the interoperable solution, instead of solely relying on the Java or .NET platform capability after application deployment. This chapter begins with a sample business scenario and discusses the current state-of-the-art technologies that enable reliability, availability, and scalability (RAS). In particular, it discusses scalability and performance, which are two key and visible aspects of Quality of Services. They easily change the perception of how good or how bad an interoperable solution is. Business Scenario Consider the familiar Supply Chain Business scenario where a buyer is sending a purchase order to the supplier. The buyer is using a .NET client to place a purchase order in the shopping cart for procuring some merchandise from a supplier. The .NET application runs on Windows 2003 Server with lots of physical memory on a high-end fast processor. The supplier back-end system is a Java-based application running on an entry-level Solaris operating environment. Developers need to determine which interoperability and integration strategies should be used to achieve the goals of Reliable delivery of the service request to the recipient and return of the processing result Reasonably fast end-to-end system performance Highly available end-to-end interoperable solution
Technical Challenges One design approach for RAS features is to leverage the platform features of providing reliability and high availability. In other words, developers and architects can rely on application server clustering for availability and the resilience of the middleware (such as bridge, Enterprise Service Bus/ESB, and message queue) to achieve reliability. This leaves the core design job to focus on the scalability aspect by micro-tuning the network bandwidth, I/O, CPU, and memory. A hardware upgrade (such as adding more physical memory and more CPUs on both the producer and the consumer machines) is a common example of up-scaling the interoperability solutions. However, such a RAS design approach may be good for traditional business applications on standalone machines but may not be appropriate for Java EE .NET interoperable solutions. There are a few important issues: System Performance Symptoms RAS problems may manifest themselves in slow system performance symptoms, but the root cause resides in the application design. For example, a slow consumer (say, a Java application running on an entry-level machine) may manifest a problem in long network latency or slow system performance on the consumer side, but the root cause could be an XML data serialization issue, where the consumer gobbles incompatible data types from a .NET client. Hardware Upgrade Hardware upgrade does not necessarily address the RAS problem in an interoperable solution. CPU and memory upgrade would enhance system performance for CPU-intensive and memory-intensive tasks such as XML encryption to some extent. Nevertheless, upgrading from a 2-CPU machine to an 8-CPU machine in the Java back-end system does not necessarily mean that the interoperable solution can improve the system performance by four times. Application Architecture Issues A Java application running on a Java EE Application Server cluster does not necessarily ensure the Java EE .NET interoperable solution is highly available, unless both the producer and consumer sides have design elements to support session failover and shared session data (say, persistence of session data). Another example is when a single, point-to-point connection from a Java client to a .NET application is fast. However, the connectivity may not be scalable when hundreds (or thousands) of Java clients are connected simultaneously if the .NET application is not well architected. Thus it is extremely important to ensure the end-to-end interoperable application architecture is scalable. Performance Issues Performance problems in the interoperability middleware may be a manifestation of a design issue in the overall Java EE .NET interoperability solution. For example, a bridge integration solution may have many performance issues if the bridge client is not well designed. Sometimes, the synchronous Web services integration solution may not be appropriate for the application requirements, and CORBA-IIOP bridge integration is more efficient if the former requires intensive data serialization as well as high overhead of data marshaling and unmarshaling. Thus it is useful to revisit the interoperability application design for performance problems.
Design Factors for RAS The technical challenges discussed suggest that RAS could be very specific to Java EE .NET interoperable solutions. Chapter 11 identifies the core requirements for RAS. Those RAS requirements apply to Java EE, .NET and the interoperability solutions. In a real-world environment, not all RAS requirements are needed. Thus it is useful to have a general "rule of thumb" when architecting end-to-end Java EE .NET interoperable solutions. The following outlines some key design factors when architecting reliability, availability, and scalability of the interoperable solutions: Reliability Receipt Acknowledgement The interoperable solution requires a receipt acknowledgement of the service request. Automatic Retries The interoperable solution requires automatic resending of the service request or automatic reprocessing of the transactions after service recovery. Verification of Business Transactions The interoperable solution requires verification of the producer or consumer. Moreover, the interoperability middleware (such as bridge and ESB) should verify the XML schema and data types being exchanged.
Availability Session Failover If both the .NET and Java applications are deployed on clusters, how will the interoperable solution handle session failover? If the Java application session fails over to another application server instance, the .NET client should be able to recover the session data. The .NET client should be also explicitly programmed to retry connecting to the Java application a few times in case a session failover is detected. Persistence Does the interoperable solution require persistence of the service request and business transactions in a data store? If yes, does it need to persist data in every component (for example, .NET client, MSMQ node, bridge middleware, Java application server, or JDBC resources)? The middleware (or integration point) should provide system-level support for persistence, or developers have to customize the persistence processing logic in each design element. If data are persisted at every design element, they should be recovered after the recovery of a faulty service component. The design details may involve complex data synchronization and two-phase commit issues.
Scalability Data When exchanging business data between .NET and Java applications, are both primitive data types and custom complex data types involved? The data types should be mapped correctly, and any incompatible data types should have data type conversion. Do all the data need to be serialized or encrypted? XML data serialization and XML encryption/decryption have performance implications. Middleware How scalable (say, the number of simultaneous client connections and messages processed per second) is the bridge or ESB middleware? Infrastructure Can the machine (such as CPU and memory) and infrastructure (such as network bandwidth) be upgraded? How much faster can the Java or .NET applications run if additional CPUs or physical memory are added? How many simultaneous connections can the producer/consumer make (using the existing network adapter card or server infrastructure)?
The next section discusses the current state of the interoperability technologies for RAS and how they can be best used to meet the RAS requirements. It also compares how different integration strategies support reliability, availability, and scalability requirements. |
