Myths and Truths about Quality of Services

Here are some myths and truths about the QoS:

• Myth 1

  Both Java EE and .NET platforms themselves take care of the Quality of Services (QoS). There is no need for developers and architects to worry about the QoS.

  Truth

  Both platforms provide essential elements for QoS and require experienced design and implementation to enable business applications and services to be reliable, highly available, and scalable.

• Myth 2

  QoS is a systemic quality for deploying Java EE and .NET applications in the data center. As long as there is reliable, highly available, and scalable infrastructure, developers and architects should be able to scale up (or scale down) the Java EE .NET applications reasonably without major service management issues.

  Truth

  Hardware and system infrastructure in the data center is certainly important to support QoS. It can provide basic availability. However, though machines are clustered for high availability, the infrastructure does not provide application-level session failover. There is also a limitation to scale up a business application simply by increasing resources. For example, adding another two CPUs and 2GB of physical memory do not necessarily double the system response time for a business application running on a 2-CPU machine with 2GB of memory. This is particularly critical for Java EE .NET interoperability because they are running on different infrastructures (hardware and operating systems) and do not share the same QoS capabilities. These applications need to be designed to support better reliability, availability, and scalability.

• Myth 3

  Good performance for Java EE .NET interoperability generally refers to high throughput and lower latency. With the availability of high performance and relatively low cost hardware infrastructure, developers do not need to worry about application design for performance.

  Truth

  Low-cost hardware can certainly boost up the performance throughput of Java EE .NET interoperable applications to a certain extent. Good performance for Java EE .NET interoperable applications is heavily dependent on design (for example, XML payload and parsing design) and interoperability strategy (for example, use of .NET Remoting versus asynchronous messaging using Web services). This may vary for different business requirement scenarios.