| Here are some main Quality of Services requirements that are specific to Java EE .NET interoperable applications. It is crucial that architects and developers incorporate these requirements in their interoperability designs or add to their evaluation criteria for their Java EE .NET interoperability products. Security is another important attribute of the Quality of Services requirements. Please refer to Chapter 13 for more details. Reliability Reliability for Java EE .NET interoperable applications requires service requests or business data from a sender (say, a service requester) to be transmitted to the target recipient (say, a service provider) successfully and accurately. The target recipient should be able to acknowledge receipt if necessary. The business data needs to be accurate and without errors. Successful transmission can be achieved by resending the service requests and business data until there is a receipt acknowledgement from the recipient or by persisting them in a reliable data store so that the target recipient can pick them up. Reliability can be producer-centric or consumer-centric. In the producer-centric scenario, the sender (producer) needs to ensure that the target recipient (consumer) receives the business data. Otherwise, the sender resends the business data until the target recipient sends an acknowledgement. If the target recipient is offline or unavailable, the sender is responsible for resending the business data whenever the target recipient service becomes available. In the consumer-centric scenario, the target recipient (consumer) is responsible for retrieving the business data from the sender (producer). This requires the sender be highly available for information retrieval. The reliability capability may vary depending on the interoperability technology used. For example, if an IIOP bridge is used, the bridge needs to ensure the connection from the Java EE or .NET application must be reliable. It should be able to persist all service requests or business data for resend and also log all activities for audit review. If a SOAP-based Web service is used, reliable messaging can be achieved by leveraging emerging technologies, such as Enterprise Service Bus, or implementation using WS-Reliability because any delivery failure will be re-sent by the messaging infrastructure. In essence, reliability for Java EE .NET interoperable applications is expected in different layers or tiers in the application architecture, which includes the following: The underlying communication mechanism or data transport layer for both Java and .NET applications needs to be reliable. When a sender exchanges some business data with a recipient, the contents of the business data should be reliably transferred. For example, if the business data contain a data type of a large scientific quantity (for example, 23.1234567891 x 10-49) or a complex data type (for example, a custom customer account data object), the recipient should receive them verbatim without any data type conversion or XML encoding errors between Java and .NET applications. There should be a receipt acknowledgement capability for the Java EE or .NET applications. One of the common design criteria is to enable the timeout on the message or acknowledgement of delivery to avoid applications waiting for an extended period of time. Any error or exception thrown should be reliably reflected on the other end. For example, if the recipient application throws a runtime exception (for example, the SOAPFault exception), the sender should be able to catch the exception reliably for appropriate error handling, instead of discarding or ignoring the errors. There should be a logging mechanism at both ends of the Java and .NET applications for audit trail and for compliance reporting purpose. Guaranteed delivery is not the only characteristic of reliability. Once-and-only-once (also known as idempotence) requirement may also apply to the QoS requirements, meaning that the message can only be delivered one time to its destination. Should a message consist of multi-parts, individual parts of the message may have to be delivered in the proper order. Alternatively, there should be aggregation logic available at the receiving end. Message routing across heterogeneous Java EE, .NET, and legacy applications often needs to be accompanied by the business flow orchestration. An Enterprise Service Bus solution can be deployed to address complex B2B scenarios. Reliable messaging, in cases such as financial data transfer, also requires a high level of security. Therefore, it is important to perform a comprehensive QoS check to ensure that your architecture adequately addresses individual QoS requirements.
Availability Availability for Java EE .NET interoperable applications requires that the underlying application infrastructure (such as the operating system and the application server container) be online for services (that is, available) all the time. The availability of business applications or services can be measured in percentage over a period of time (for example, 99.99 percent available during 365 days of operation), or in downtime statistics (for example, 53 minutes downtime throughout the 365-day year). Business applications and services can usually achieve high availability by clustering the Java EE or .NET application server containers and enabling session failover from a failing application. Achieving high availability for Java EE .NET interoperable applications is complex. It requires Detection of Availability Status There is a mechanism to detect or look up whether the target recipient (Java EE or .NET application) is online or not. Persistence The service request or business data can be persisted for resend later after the target recipient resumes operations from service failure. End-to-end Availability For distributed Java and .NET interoperable applications, availability means both the Java and .NET applications should be online and available for service simultaneously. If either side is offline or unavailable, the other side needs to take exception handling routines such as persisting the service request for later resend. Uptime Availability for Java EE .NET interoperable applications counts the uptime for both ends of the applications. It is not the average availability percentage of both Java and .NET application servers. For example, if the sender running Java EE applications is 99.99 percent available, and the recipient running .NET application is 99.91 percent available, it cannot simply be assumed that the availability for Java EE .NET interoperable applications is 99.99 percent or the average 99.95 percent. Middleware The availability for Java and .NET interoperable applications using an IIOP bridge or Enterprise Service Bus will be highly dependent on the availability of the middleware technology. Thus it is critical to ensure that the bridge is highly available and has recovery or self-healing features to support high availability. Some bridge or bus middleware technologies use software clustering, fault tolerance, or application recovery to ensure availability.
Scalability and Performance Individual Java EE or .NET applications usually can be tuned for better scalability and performance. However, a Java EE .NET interoperable application depends on the scalability design and performance of both a Java and a .NET application. The same scalability design and performance enhancement strategy do not necessarily work for both platforms. Scalable Java EE .NET interoperable applications can handle a large volume of service requests and business transactions or can generate higher transaction throughput. An ideal scalability scenario for a Java EE .NET interoperable application is that the performance should be able to scale linearly. For example, there is an existing interoperability solution using Web services approach. If extra physical memory is added (say, 2GB of memory) or the hardware is upgraded (perhaps to 3GHz processor from 2GHz processor) to the existing Java and .NET application servers, they should be able to scale up to handle additional SOAP messages (perhaps 20 percent additional transaction processing rate) simultaneously. In reality, there are different scalability and performance factors for the Java EE .NET interoperability solution. These include Memory Factor The Java EE .NET interoperability application should be able to optimize performance by leveraging the available physical memory. .NET and many Java application servers today are able to benefit from the physical memory with proper setting of the configuration parameters. Architects and developers may want to see whether the interoperability strategy has any cache design for better system performance. CPU Factor Interoperability applications that require intense computing resources should be able to leverage high-end CPU power for linear scalability. For example, message encryption and decryption (such as XML Encryption) require high CPU processing power. If the interoperability application uses an IIOP bridge or Enterprise Service Bus with XML encryption and decryption, a high-end CPU processor will help to improve system performance. Interface (or I/O) Factor Some interoperability solutions may use a relational or object database to persist all service requesters. In such a case, the interoperability application should be able to leverage the underlying database technology to scale up or to enhance input/output performance, instead of creating its own scalability implementation. Multi-Threading Factor Either the Java EE or .NET interoperable application should be able to incorporate multi-threading support into their design so that they can use multi-threads to process a large volume of service requests. Not all application design supports multi-threading by default, as the application design needs to handle synchronization issues. One example is that using asynchronous messaging strategy for Java EE .NET interoperability allows multiple threads of the application to process more service requests. Distributed Architecture Factor The interoperability application design needs to support multiple instances on the same machine or across different machines. This distributed architecture design allows multiple instances of the interoperability application to run simultaneously and can scale up horizontally to handle a large volume of service requests simultaneously. For example, the asynchronous message strategy using Enterprise Service Bus can allow multiple instances of the interoperability application to run because service requests are encapsulated in messages and can be processed by multiple subscribers (service providers).
Manageability Manageability refers to a Quality of Service attribute that an application or service can be instrumented, monitored, and recovered if it runs into an exception. Because Java applications can support JMX (Java Management Extension APIs) but .NET applications do not, the manageability for Java EE .NET interoperable applications needs to rely on a common measurement and manageability technology (for example, management proxy) or standard (for example, WS-Management). Interoperability strategy using IIOP Bridge and Enterprise Service Bus can play an important role in providing manageability because they can capture system management information from the application centrally. There are a few important manageability requirements that the interoperability solution should support: Visibility The Java EE .NET interoperable applications should be able to expose their operation states (for example, active or error) or management information (for example, CPU utilization) for instrumentation and system monitoring. There should be monitoring capability in the interoperability strategy for online status or for service reporting. Detection of Problems The interoperability solution should be able to detect if there is any service problem or system failure in both the Java and .NET applications. This may require the interoperability solution to poll the system status or the application itself to send system heart-beat periodically. For example, some Enterprise Service Bus interoperability solutions support JMX and can report any service problems from either the Java EE or .NET application to the management server (running MBean server). Remediation The capability to recover the failing system or execute corrective management actions is very crucial to managing Java EE .NET interoperable applications. Adaptability The management solution should be easily extendible to additional enterprise applications regardless of their origins, Java EE, .NET, or legacy. Additionally, manageability should be controlled depending on the environment, development, Quality Assurance, staging, and production. Enabling or disabling certain application or system-level logging should be performed outside of the actual application, that is, in the configuration files or centralized management console. Effectiveness There should be a balance between logging and application state tracing and the overall system performance. Logging Logging information provides basic input to managing the integration points between a Java EE .NET interoperate solution. The solution should be able to collect logging information from individual Java EE and .NET service components, as well as from the integration points (such as Bridge) and correlate for application management of the interoperable solution.
|
