New SOA-EERP Standards to Establish Service Quality, Rating and SLA
OASIS SOA-EERP Technical Committee has just announced a 60 day Public Review of the three draft specifications:
- SOA-EERP Business Quality of Service Version 1.0.
- SOA-EERP Business Service Level Agreement Version 1.0.
- SOA-EERP Business Rating of Service Version 1.0
As defined in OASIS SOA-EERP whitepaper, End-to-End Resource Planning (EERP) Model and Use Case this set of specifications applies to
... service discovery, composition, simulation, and optimization techniques in a novel way to improve business results. As the software industry has applied SOA to eBusiness deployments, self-optimizing systems... have become more feasible and more useful... Modeling the business characteristics of a service is a prerequisite for estimating the business value of the process that uses those services; likewise, the reliability of the service provided needs to be understood. Finally, establishing agreements about the business service is essential to long-term value chain improvement.
The overall vision of the SOA-EERP technical committee is the creation of service "exchanges" to which service consumers can go to get an optimal set of services required for their need. Many service providers participating in the exchange may provide a similar service but with different business quality of service (bQoS) and Ratings. Ratings are provided by participating Rating Providers, for example, a third party rating organization, and can be issued either a number or a classification description. Finally, an EERP Portal accepts requests from a service requester, performs bQoS and rating queries, calculates optimal solution(s), and then returns the result to the respective service requester.
A set of XML vocabulary specifications, part of current review, address the exchange of information that models the business characteristics of a service, permitting assertions or queries related to the credibility of the service and its providers, and the establishment of agreements about the business service. Additional specifications can be applied to other areas. For example, bQoS may be applicable to the definition of characteristics of energy, goods bought and sold, and services such as medical, shipping, and more. The reputation (Rating) of a trading or business partner is useful in many contexts.
A bQoS specification is an XML vocabulary defined as an XML schema, allowing to specify selected business characteristics of a service. The main components of bQoS are:
- Price or cost for the service
- Performance, throughput and latency of the service execution
- Quality of service ...
Business rating specification is an XML vocabulary defined as an XML schema and allowing to specify business creditability, reliability and reputation of the service providers. The main components of a business rating are:
- A list of third party service Ratings. Each Rating contains either an aggregated numeric rating or an aggregated classification description representing the rating of the given business service.
- Credentials that the service provider owns or holds. Such credentials may be issued by organizations regulating the service and can include licenses, permissions, certifications, associations, or affiliations...
A business service level agreement specification (SLA) is an XML vocabulary defined as an XML schema and allowing to define a business service level agreement between the service requestor and service provider. Business SLA is a formal contract between a service consumer and its provider, guaranteeing quantifiable business quality of service (bQoS) at defined levels. The main components of a business rating are:
- Parties involved in the SLA for the service
- Parameters of service, which can be monitored for calculating the QoS metrics
- SLA Obligations of the service
- SLA Terms of the service
This set of OASIS specification signifies an important step in formalizing business value of services and can be used for a better evaluation of business impact of SOA implementations.
This just seems like another attempt to use technology to solve problems that can't possibly solve. Maybe I'm missing something.
Re: Service Exchanges
This spec seems to go even further drawing an enviroment really far. I'm with you James, maybe OASIS team should provide use cases to apply this bunch of new XML vocabularies.
I don't dismiss any material produced by these guys, they really owns a vision beyond we ofteen see. Lets wait to see how it is going to be realized.
SOA-EERP Standards to Establish Service Quality
Nonetheless, "the creation of service "exchanges" to which service consumers can go to get an optimal set of services required for their need" is an 'interesting' concept. I guess that <<service "exchanges">> are messages used in the interactions between service Consumer and Service but interactions happen after the service is chosen. If we target getting "an optimal set of services required for their need", term 'service exchange' at the edge of contradicting OASIS SOA RM standard - Consumer and Provider in SOA do not exchange Service; Service may be engaged or utilised. Again, if a Consumer needs a Service portfolio for its needs, it is only a portfolio of Service Contracts that contain more than SLA (quality, performance) and cost. The Service Contract, according OASIS SOA RM and RAF-draft, contains a set of Policies about: sub-set of to-be used Service interface, the interface behaviour models, service Business and Technical Execution Context where the Provider guarantees service' qualities and SLA for given Service Coontract, description of service's Business functionality and RWE, etc.
I think that QoS is really important as well as a Provider/Service reputation. Within a company, this, however, may be an overhead because we will be happy if a company has just a few redundant services for guaranteed business continuity; this is not a large service market in the company. Moreover, the statement like "The reputation (Rating) of a trading or business partner is useful in many contexts" requires strong justification. For example, if a Provider follows British law of Freedom of Information, such reputation may scare a US consumer and vise versa - a reputation of compliance with American SOX regulation may push Brittan Consumer away from the Service.
I still think that SOA is a sensitive Business matter that cannot be formalised by modern technical tools like XML Schema only; it needs much more mature level of shared semantics (which, BTW, hits the wall of human languages and cultures).
It is also much more flexible approach than it seems on first hand. Of course i've been keeping an eye out and sometimes pondering on a service bazaar (nice term). Using these SLA lists it is possible to e.g. create a Circle of Trust model for trading parties referring to standards they accept, such as colourcoding for flower trade, DUNS for company identifiers, European Article Numbers (EAN) and Global Trade Item Number (GTIN), even lists of Units of measure. Using the contract approach, it doesn't have to be so formal, and top brands like Gucci and Armani can even create their own SLA with which online stores can guarantee they are trading the real thing. This way adhoc communities or cooperatives can be constructed on the market place without too much trouble. Even if the corrections are manual, they bubble up to the outer border and are much easier to deal with.
On it's most elementary level i was thinking for many-to-many service marketplaces two ingredients were needed, identity federation and flexible certificates of any sorts to create add hoc contracts from which message format upto ISO certification. Using this bQoS with SLAs is however just that little bit more flexible.
Very nice, this even allows for some friend-of-a-friend approaches, or enforcing corporate social responsibility by being able to reference labels such as FairTrade.
Anders W. Tell
Maybe the biggest benefit is not a service bazaar but a mechanism for knowledge representation of SLA details, to be used fro future references and knowledge reuse. With such use cases we can streamline management of large number of SLA from different vendors etc.
/anders w. tell