2.3 QoS capabilities framework

 < Day Day Up > 



2.3 QoS capabilities framework

This section documents the most frequently observed Quality of Service (QoS) concerns that must be considered in implementing integration solutions. These QoS manifest themselves with differing degrees of importance and specificity in different integration scenarios.

The following QoS concerns are defined in this section:

  • Operability

  • Availability

  • Federation

  • Performance

  • Security

  • Standards compliance

  • Transactionality

2.3.1 Operability

This QoS concern focuses on the systems management requirements of the deployed solution. It focuses on issues such as monitoring, logging, traces, recovery, and manageability of the solution during operations in a production environment.

2.3.2 Availability

Availability is a measure of the time that a service is functioning normally as well as a measure of the time the recovery process requires after the service fails. In other words, it is the downtime that defines service availability. This downtime includes both planned and unplanned downtime.

High availability generally requires that a topology provide some degree of redundancy in order to eliminate single points of failure. This allows the downtime caused by a component failure to be minimized (ideally zero). It can also allow a service to continue functioning normally during the downtime of a component for planned maintenance or backup procedures, for example.

2.3.3 Federation

Federation is fundamentally about enabling services to interoperate across trust boundaries. It lets access control functions span across multiple domains, crossing application, product, platform, site, business unit, and organization boundaries.

Federation requires that each partner domain is trusted to authenticate the identity of its own users. Mechanisms are needed for passing resource and user authentication and authorization information between domains.

2.3.4 Performance

The performance of a service is measured in terms of throughput and latency. Throughput represents the number of requests served in a given time period. Latency is the round-trip time between sending a request and receiving the response. Higher throughput and lower latency values represent good performance of a service.

Scalable topologies are able to service higher loads by adding the appropriate processing power. This be achieved using techniques such a using a faster machine, using a special purpose machine, or creating a cluster of machines.

Other performance improvement techniques include caching, batching and connection pooling.

2.3.5 Security

Permission to access the participating applications may be associated with the requesting application itself, or this application may carry the credentials of a user initiating the actions. Consequently, access control can be applied as far as the requesting application (a transit of trust) or only from an integration hub (a trusted source) that authenticated the original request.

Securing messages transported and ensuring that integration is achieved only with authorized applications under the correct user credentials is a must. The integration solution needs to provide:

  • Data protection through encryption

  • Authentication of users and subscribing applications. In cases where non-repudiation of the end-user is required, authentication of the end-user

  • Authorization of the user for participation in an integration activity

2.3.6 Standards compliance

Standards compliance is concerned with identifying and applying the appropriate standards to a scenario. Standards compliance is an important factor for controlling development and integration costs. Even private standards are beneficial, but widely accepted public standards have the added advantage of enabling interoperability in the broadest contexts.

2.3.7 Transactionality

A transaction can be viewed as an activity between two or more parties that must be completed in its entirety with the mutually agreed outcome. Transactionality enables multiple application operations to be coordinated to provide an atomic deterministic end result.

Resource managers are used to control access to the resources involved in a transaction. A transaction manager is responsible for coordination and transaction control. Transactional considerations include:

  • ACID versus compensating transactions

  • Flat versus nested transactions

  • System versus client commit control

  • Local versus distributed transactions



 < Day Day Up > 



Patterns. Broker Interactions for Intra- and Inter-Enterprise
Patterns. Broker Interactions for Intra- and Inter-Enterprise
ISBN: N/A
EAN: N/A
Year: 2004
Pages: 102

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