Understanding the Current State of Technology
| Chapters 1, "Java EE Platform Interoperability Essentials," and Chapter 2, ".NET Platform Interoperability Essentials," covered the essentials of Java and .NET technologies and how they enable interoperability. Subsequent chapters (Chapters 3 through 12) introduced different integration and interoperability technologies. This section assesses what these integration and interoperability technologies can do and cannot do to make reliable, available, and scalable business applications. ReliabilityThere are two essential reliability requirements that developers are concerned with. First, the service requests are reliably sent to the target recipient. Similarly, the processing results are reliably returned to the service requester. Second, the business data from one system should be accurately transmitted and delivered to another system without loss. This section discusses the current states of messaging interoperability technologies and how data types should be mapped between Java and .NET platforms. JMS and MSMQMessaging technologies such as JMS and MSMQ are designed to allow business applications to exchange business data reliably. However, these messaging technologies are vendor-specific (they have different underlying data transport implementations), and they are not practically interoperable between two different vendor implementations. There may be a misunderstanding that both JMS and MSMQ are message queue-based technologies, and they can interoperate if a common queue name is used. Developers should not assume that a Java application using JMS can interoperate directly with a .NET application using MSMQ. For example, business data written to a JMS queue using Weblogic JMS implementation cannot be retrieved by using IBM WebSphere MQ JMS API or MSMQ because they use different underlying data transport and data formats. MSMQ InteroperabilityMSMQ is a reliable messaging mechanism available in the .NET platform. It is possible to wrap a WebSphere MQ client (or JMS client, architecturally speaking) by ActiveX Control, so that a WebSphere MQ client (which is a Java application) can exchange business data reliably with a MSMQ client (.NET application). In the case of WebSphere MQ, IBM provides MQ classes for .NET, which allows a .NET application to create some administrative commands (also known as Programmable Control Facility) to the WebSphere MQ Queue Manager using send and receive APIs. Refer to [DotNetMQ] for details. Data Type AccuracyNot all data types have identical data type mapping in Java and .NET. Business data will not be rendered correctly if the data types are wrongly mapped between Java and .NET applications. Data type accuracy is an important element in ensuring data reliability in Java EE .NET interoperability. For example, unsigned integer type is supported in .NET but not in Java. Thus an XML schema with an unsigned integer type will not be interoperable without proper data mapping or data conversion. Array handling also varies in .NET, which will create only the header element if an empty array is serialized but will not serialize any XML element if a null array is serialized. In contrast, Java will serialize the XML element for both types of array. Thus when dealing with data types mapped to an XML schema, it is important to understand the differences between Java and .NET and their exceptions. Table 14-1 depicts the data mapping between XML Schema, Java data types and .NET data types. Java SE (Java 2 Platform, Standard Edition) version 5.0 now supports a natural mapping of XML Schema to Java types using JAXB (Java Architecture for XML Binding), which is defined by JSR 31. The JAXB data types under the package javax.xml.datatype are prefixed by the namespace xs in Table 14-1. For example, the integer type int in an XML schema will be resembled by int in Java and Int32 in .NET. In other words, int (in Java) will have the same data type value as in Int32 (in .NET).
Enterprise Service BusEnterprise Service Bus (ESB) provides reliable messaging features for interoperability. A business process (say, implemented by a .NET application using synchronous Web services) can issue a service request to another business process (for example, implemented by a Java application using asynchronous Web services) via the ESB. A typical synchronous service call does not generate receipt acknowledgement as in an asynchronous messaging protocol. If there is a service failure in the underlying data transport (for example, SOAP over HTTP), the synchronous service request is lost. Using the ESB, the multi-protocol messaging middleware can intercept a synchronous incoming service request and reliably route (bind to the underlying JMS for reliable message routing) to another business process, which only accepts service requests asynchronously. Some ESB implementations (such as Mule ESB) can also invoke a synchronous call asynchronously. Please refer to Chapter 9, "Messaging," for more details. Not all ESB products support .NET platform. For example, IONA Artix (www.iona.com/products/artix/features.htm) and Sonic ESB (www.sonicsoftware.com/products/docs/sonic_esb.pdf) support both Java and .NET platforms, but Mule ESB (http://mule.codehaus.org/) only supports Java platform and does not support .NET client. Mule ESB version 1.1 is capable of orchestrating Web services generated from a .NET application. Developers may want to research specific vendor product implementation details. WS-Reliability and WS-ReliableMessagingWS-Reliability is an OASIS standard specification (www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrm) that provides a standard and interoperable way to guarantee message delivery to business applications or Web services. This includes guaranteed message delivery (such as acknowledgement messages or resending messages), no duplicates of messages sent or delivered, and guaranteed message ordering using a sequence number mechanism. Currently, RM4GS is a sample software implementation produced by Fujitsu, Hitachi, and NEC (refer to http://xml.coverpages.org/ni2004-03-11-a.html), but there is no .NET implementation yet. There is a summary of the WS-Reliability specification available at [LuefPichler]. WS-ReliableMessaging is a similar Web services specification from Microsoft, IBM, BEA, and TIBCO for supporting SOAP messages to be sent and received reliably over different data transport mechanisms, particularly SOAP over HTTP. There are two major components: core messaging protocol and a related policy assertion specification. WS-ReliableMessaging uses a unique identifier (aka URI) for each message sequence to ensure message ordering and no duplication of messages. It also supports message acknowledgement. However, it leaves message persistence to the responsibility of the design implementation. Several implementations are available in both .NET and Java platforms, for example, Microsoft WSE version 3.0 (http://msdn.microsoft.com/webservices/webservices/building/wse/default.aspx?pull=/library/en-us/dnwse/html/newwse3.asp) and Apache Sandesha (http://ws.apache.org/sandesha/). Reliability by Integration StrategiesTable 14-2 summarizes the reliability features by comparing synchronous integration, asynchronous integration, and bridge integration strategies. The reliability features are also discussed in Chapter 11.
Reliable delivery is often a feature provided by asynchronous integration and bridge integration strategies. The synchronous integration strategy does not provide reliable delivery of messages. It also does not have a message ordering mechanism. Receipt acknowledgement is a mechanism used in asynchronous integration strategy to ensure that messages or service requests are sent to the recipient reliably. Synchronous integration strategy does not use receipt acknowledgement (because the service requester communicates with the service provider in a "block" mode and exits from the interaction when a return value is received). Some bridge integration implementations also support receipt acknowledgement. Exception handling (such as mapping Java exceptions to .NET exceptions), data type mapping (such as converting an unsigned integer from .NET to an integer in Java), and shared logging (such as centrally storing the log messages for both Java and .NET applications) usually require customization by all integration strategies. Bridge integration implementation usually provides a shared logging mechanism for both Java and .NET applications. Application security is always a complex design issue for interoperable solutions. Web services security (www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss) provides a standard mechanism for Java EE .NET interoperability using Web services. This applies to all integration strategies. To achieve single sign-on, the recent Web Services Metadata Exchange (WS-MEX) specification addresses specific Java EE .NET interoperability requirements. Please refer to Chapter 13, "Java EE .NET Security Interoperability" for details. AvailabilityTo ensure the service provider is highly available to provide the business system functionality, developers can usually consider the following availability design options:
Java EE Application Server ClusterThe Java EE application server supports clustering of application server instances and can allow session information (such as HttpSession) to be persisted and failed over in case of a service failure. Figure 14-2 depicts a logical architecture using Sun Java System Application Server Enterprise Edition version 8.1 as an example. A cluster of three application server instances is created and is administered by an administration server (Domain Administration Server). A Java EE application can be deployed to all application server instances under the same cluster via the Domain Administration Server, without the need to deploy the business application individually to each server instance. Figure 14-2. Sample Java EE application server cluster logical architecture A service request from either a .NET client or a Java EE client is routed to different application server instances via a load balancer (or using a Web server load balancer plug-in). An application cluster provides the benefit of session failover. Although each Java EE application server vendor implements the cluster and the session failover slightly differently, they all achieve the same result. .NET Session FailoverCompared to Java EE application clustering, .NET application has a different approach (also known as a database-centric approach) to handle session failover. Developers can create session information and session states and store them in SQL Server. The SQL Server is deployed as a highly available relational database and is shared by multiple machines running Windows 2003 Server cluster. It is possible to create shared session states in the SQL Server so that the shared session between .NET and Java applications can be available. Refer to [NETStateManagement] and [NETSessionFailover] for details. End-to-End AvailabilityAlthough developers can utilize the clustering and session failover in both Java and .NET platforms, this does not necessarily mean that end-to-end availability can be achieved. For example, consider a scenario of a clustered Java EE application server, clustered ASP.NET server, and a highly available SQL Server. A .NET application issues a service request (say, purchase order) for the Java EE application to process. The Java EE application supports high availability in a cluster environment, which denotes that if an application instance fails, the session information can be recovered by another application instance in the same cluster. The end-to-end availability design needs to be considered for multiple architectural components. The design complexity may exist for the following scenarios:
There is also an operating overhead associated with high availability (for example, additional system overhead to synchronize the session data between the application server instances). What's more, if the Java EE application does not persist session information, it seems that there is no obvious benefit of using Java EE application server clustering for high availability and session failover. Availability of Integration StrategiesTable 14-3 summarizes the availability features by comparing synchronous integration, asynchronous integration, and bridge integration strategies. The availability features are also discussed in Chapter 11.
It is noted that both synchronous and asynchronous integration strategies share similar availability features because they both utilize the underlying infrastructures (such as the clustering capability from the Java EE application server container). Typically, messaging technologies (such as JMS or MSMQ) and bridge middleware support high availability. Business transactions can also be persisted using messaging technologies or bridge middleware so that they can be recovered after service failure. With the availability of WS-Management technology (refer to Chapter 15, "Managing Java EE .NET Interoperability Applications," for more details), the capability to detect availability status has become more important in proactive service management. The detection of availability status allows design of some preventive actions to facilitate availability of the business applications (for example, restart the server instance when certain exception is met). WS-Management can support both synchronous and asynchronous integration strategies. For bridge integration, the detection of availability status and any remedial action to ensure availability depends on the vendor implementation. ScalabilityThe scalability of the interoperable solutions implies that the solution can be deployed on large configurations. It is important to remember that deploying business applications on faster CPUs or adding more CPUs and physical memory does not necessarily make the interoperable solution scalable. Moreover, because Java and .NET applications are likely to run on different hardware machines, there needs to be a consistent system performance measurement methodology (for example, measuring the performance of a round-trip from a .NET client to a Java application) to consider several performance enhancement design options. This puts the benchmarking and performance statistics into the proper context instead of using an apple-to-orange metric. The following section introduces some options to measure Java and .NET application performance. Measuring PerformanceThere are a few options to measure the performance of a Java and .NET application. These timing functions are provided by the Java and .NET platforms. To measure the end-to-end performance throughout, developers need to aggregate the timing statistics from these basic timing functions for measurement.
Listing 14-1 shows an example of how to add a timer function in Java applications. This approach applies to all integration strategies but requires a central place to store the time statistics. Listing 14-1. Java Program Excerpt to Measure System Performance
Listing 14-2 shows a .NET sample program excerpt that performs a timer function to measure system performance. Listing 14-2. .NET Program Excerpt to Measure System Performance
Listing 14-3 shows an alternative .NET sample program excerpt that performs a timer function to measure system performance. The difference is that Listing 14-2 uses the Counter() function, while Listing 14-3 uses the Environment.TickCount package to achieve similar objectives. Listing 14-3. Another .NET Program Excerpt to Measure System Performance
When measuring the performance of a Java EE .NET interoperable solution, it is not helpful to take a measurement of individual Java or .NET application alone. The end-to-end application performance (such as round trip from the .NET client to the Java EE application server) needs to be measured. For example, in a scenario where a .NET application creates a purchase order and submits to a Java EE application server, a timer function can be customized to measure from the creation of a purchase order (from the .NET client) to the completion of processing the purchase order (return the processing result from the Java EE application server). When benchmarking the performance of a Java EE .NET interoperable solution, one should compare different integration strategies for the same set of business requirements and environment constraints. This gives a better assessment of the interoperable solution. It is also useful to measure the resource utilization such as CPU and network. In the sample Supply Chain scenario discussed earlier in the chapter, performance architects may consider benchmarking the application performance of using different integration strategies. It is plausible that asynchronous integration strategy is optimal for Java applications running on a slow entry-level hardware platformwhen compared to using a synchronous integration strategy. Micro-TuningThe performance of an application can be tuned and enhanced in two general directions: (1) a top-down approach; (2) a bottom-up approach. In the top-down tuning approach, performance engineers can scale the solution on a high-end machine with more CPUs, more physical memory, and larger data storage without examining each technical component in detail. If the interoperable solution does not scale as expected, performance analysis architects can drill down and identify bottlenecks. In analyzing the performance of a Java EE .NET interoperable solution, performance architects should also consider changing the integration strategy (say, from a synchronous to asynchronous strategy) based on the application. In the bottom-up tuning approach, performance architects perform a fine-grained analysis of the application and make changes to a specific technical component. For example, they increase the hardware depending on the application requirements for resources (such as CPU and memory). They are referred to as micro-tuning strategies here. [HansenLai] makes a few generalizations regarding micro-tuning strategies for XML Web services based on a vendor-specific JMS benchmarking. These generalizations can serve as general guidelines for tuning Java applications.
Rammer and Turner in [RammerTurner] provide an interesting discussion on improving .NET application performance by changing the underlying integration strategies. Rammer and Turner's summary is also a good guideline for choosing the appropriate .NET integration strategies.
Scalability by Integration StrategiesTable 14-4 summarizes the scalability features by comparing synchronous integration, asynchronous integration, and bridge integration strategies. The memory and CPU factors are relatively more prominent than other factors in enhancing the system performance of an interoperable solution. The scalability features are also discussed in Chapter 11.
|
to run"); } } 
EAN: 2147483647
Pages: 170