Quality of Service


A service interface defines the interaction between a service and a requester in a narrow sense, but the interaction can have many additional characteristics. In some contexts, Quality of Service refers only to reliability guarantees, such as the percentage of time a service is promised to be available. In our view, however, QoS refers to all runtime processing aspects that go beyond the service interface.

QoS also includes advanced aspects of runtime processing:

  • reliability guarantees

  • security mechanisms

  • service coordination, including transaction control

  • runtime update of address, binding, and message content

A particular service may be offered with different QoS characteristics, as when a company charges a different fee in exchange for a different level of reliability.

In describing the QoS issues, we hope to give you a sense of the flexibility and power of an advanced SOA runtime product.

Reliability Guarantees

Reliability guarantees may be described in a Service Level Agreement. The guarantees can be affected by the quality of the network hardware, and most are quantitative. For example:

  • During what percentage of time will the service be available, or during what hours?

  • What is the expected throughput - the number of messages to which the service will respond in a given duration?

  • What is the expected latency period - the waiting time between a service request and response?

  • What is the probability of a successful response within the latency period?

  • Is message receipt assured, even if the network fails?

Security Mechanisms

Security mechanisms are often affected by features of the SOA runtime:

  • Authentication: How does the SOA runtime ensure that a message is from a specified requester?

  • Authorization: How does the SOA runtime ensure that a specified requester is allowed to access a specified service?

  • Confidentiality: How does the SOA runtime ensure that the content of a message isn't viewed during transmission?

  • Integrity: How does the SOA runtime verify that a given message was unchanged during transmission and was delivered with all data in the appropriate order?

  • Non-repudiation: How does the SOA runtime verify the integrity of a given message and ensure that the message came from the specified requester? Non-repudiation proves (for example) that a party to a transaction made a promise, as in an online purchase.

  • Protection from denial-of-service attacks: How does the SOA runtime prevent a flood of messages from reaching a given service?

Service Coordination

Service coordination concerns how services work together to fulfill a business process. Coordination takes one of two forms: orchestration or choreography.

As Figure 2.6 illustrates, orchestration refers to a form of processing in which one service acts as a controlling hub in relation to other services, which act as spokes. The hub might receive a message from one spoke and make decisions based on that message, as by changing the format or content of the data and invoking some other spoke.

image from book
Figure 2.6: Orchestration

As Figure 2.7 shows, choreography refers to a more decentralized form of processing, where multiple services interact without submitting messages to a hub. This sort of processing is based on rules known to each service and may be enabled by establishing a local configuration file for each service.

image from book
Figure 2.7: Choreography

Often, orchestration is said to coordinate services in the same company, while choreography is said to guide the interactions of trading partners. Usage of the terms is inconsistent, and some analysts employ them interchangeably.

An important subset of service coordination is transaction control, which primarily concerns how services handle the update of databases. In general, a service may commit changes (ensuring that changes are permanent) or rollback changes (returning the database to a previous level of update). Among the QoS issues:

  • Is the service allowed to revise database changes that were made (but not committed) by the requester and possibly by other services?

  • Is the service prohibited from issuing a commit or rollback? A prohibition is likely if the requester is responsible for committing changes made by the service.

  • Does the service depend on a compensating service? A compensating service is one that will be invoked only if necessary to make up for a runtime change (in this case, a database change) that is later found to be undesirable. As invoked by a coordinating service, for example, Service01 commits a database change (to indicate that a purchase was completed); days later, the coordinating service receives a cancellation and invokes a compensating service to reverse the effect of the committed change.

Last, the term coordination sometimes refers specifically to a kind of orchestration that is detailed in the WS-Coordination specification, as described in Appendix A.

Runtime Update of Message Content or Destination

Some QoS issues are especially meaningful in the context of a network that handles a variety of services, computer types, and data-traffic patterns. Among the issues:

  • Can the flow of traffic be changed at run time? The change usually has one of two purposes: to provide faster access to higher-priority services or to equally distribute the data being directed to services that provide the same functionality but reside at different locations.

    The process of altering data traffic to conform more closely to a performance ideal is called load balancing. This process might occur in response to a configuration setting or to an operator's intervention.

  • Can a message be reformatted at run time - for example, to allow transmission to a computer that uses a different transport protocol? If so, a configuration setting may be involved.

  • Can a service be configured to send messages to a destination other than the requester - for example, to print a runtime error or to invoke an additional service in some cases but not others? If so, either a configuration setting or details in the message itself can cause the change.




SOA for the Business Developer. Concepts, BPEL, and SCA
SOA for the Business Developer: Concepts, BPEL, and SCA (Business Developers series)
ISBN: 1583470654
EAN: 2147483647
Year: 2004
Pages: 157
Authors: Ben Margolis

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net