|
ways to achieve this can be to compress the XML — especially when the CPU overhead required for
compression is less than the network latency.
Other factors affecting Web service performance
There are still more factors that can affect Web service performance that are outside the control of
the
Web service application, such as:
· Web server response time and availability.
· Original application execution time like EJB/Servlets in Web application server.
· Back-end database or legacy system performance.
Approaches to provide proactive Web service QoS
Service providers can proactively provide high QoS to the service requestors, by using different
familiar approaches like caching and load balancing of service requests. Caching and load balancing
can be done at both Web server level and at Web application server level. Load balancing prioritize
various types of traffic and ensure that each request is treated appropriately to the business value
it represents.
A Web service provider can perform capacity modeling to create a top-down model of requesttraffic,
current capacity utilization, and the resulting QoS. A service provider can also categorize
Web service traffic by the volume of traffic, traffic for different application service categories, and
traffic from different sources. This will help in understanding the capacity that will be required to
provide good QoS for a volume of service demand and for future planning like capacity and type of
load balancing Web application servers and/or Web servers (for example, the number of servers
required for setting up a clustered server farm).
Service providers can provide differentiated servicing by using the capacity model to determine the
capacity needed for different customers and service types and by ensuring appropriate QoS levels
for different applications and customers. For example, a multimedia Web service might require good
throughput, but a banking Web service might require security and transactional QoS.
Transactional QoS
Transactional QoS refers to the level of reliability and consistency at which the transactions are
executed. Transactional QoS is crucial for maintaining the integrity of a Web service. Transactions
are very important for business processes to guarantee that a set of related activities are treated
and completed as a single unit of work. If an exception occurs while executing a transaction, the
transaction has to be recovered back to a consistent state. This property is called the “atomicity” of
a transaction. Other than property of atomicity, transactions in a stricter sense should satisfy
consistency, isolation and durability properties. All these four properties are together called “ACID”
properties (see the sidebar).
There are several approaches to provide transactional QoS. The most popular approach, which is
traditionally used in Web application architectures is the two-phase commit. Two-phase commit
provides a transaction coordinator which controls the transaction based on the idea that no
constituent transaction is allowed to commit unless they are all able to commit. This approach of
using a transaction coordinator to ensure atomicity is used in Java Transactional Service (JTS),
CORBA OTS, and in most database management systems
But there are new complications when we are thinking of transactions involving Web services. The
Web services used by a particular application or Web service are often distributed remotely over the
Web as well as owned by different parties. Having a central transaction coordinator, which dictates
the rules and performs the commits and rollbacks, in a Web services environment is very tedious to |
