New SOA-EERP Standards to Establish Service Quality, Rating and SLA

by Boris Lublinsky on Apr 07, 2010 |

OASIS SOA-EERP Technical Committee has just announced a 60 day Public Review of the three draft specifications:

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.

Related Editorial

Application Performance Management Buyer's Guide

The Rise of the Composite API Platform, a ‘Best-of-Breed’ API Management Solution

Enterprise-class API Patterns for Cloud & Mobile

A Unified Mobile Architecture for the Modern Data Center

APM Survival Guide from a Veteran Performance Geek

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

Service Exchanges by James Watson Posted

Re: Service Exchanges by Paulo Suzart Posted

SOA-EERP Standards to Establish Service Quality by Michael Poulin Posted

Interesting approach by Paul Peters Posted

Knowledge representation by Anders W. Tell Posted

Service Exchanges by James Watson

This idea of a service bazaar has existed for around 10 years. I don't see what this will do to make it happen. Can anyone imagine letting a computer pick their vendor based on some XML documents? Is the 3rd party responsible for rating these vendors going to go through extensive functional testing to validate that the vendor's services work properly? If the service doesn't do the right things, it really doesn't matter if it does it fast and reliably. It's still wrong. Who are these 3rd parties and why should I trust them? We can't even trust bond rating agencies.

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 by Paulo Suzart

It resembles the UDDIs discussions where people ad its death. Many vendors has attached UDDI as a mean for decouple service enpoints, support runtime governance, etc. This is a way to change the vision of Service Bazar or Yellow page.

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 by Michael Poulin

Well, an idea of having a Service Market even within the enterprise is a good idea in my opinion. How, making a service bazaar is not. Service Consumer, according to OASIS SOA RM and RAF-draft (and Boris knows this precisely) is required to settle a Service Contract with the Provider beforehand; information in the Service Contract is based on the non-structured human comprehensive information about service's Business Functionality and results (Real World Effect - the results may have much wider consequences that just a return to the requester; they do change the state of Real World). This, DO AGREE with James:the idea of "letting a computer pick their vendor based on some XML documents" is contra-progressive. We were there with ebXML and found that automation works in the primitive cases only (or participants of the potential service interaction have to to share extremely large and deep language semantics applied to the domain of business functionality. No shared semantics of such scale, no interaction.

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).

</service>

Interesting approach by Paul Peters

Have to agree as from the nonetheless.. The rest are implementation specifics, where web services took over from B2B. This looks like a very lightweight way to have a simple B2B model around service wildgrowth.
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.

Knowledge representation by Anders W. Tell

As someone who has followed the ebXML journey closely it seems as we are quite a bit from a scenartion where we can automate contract negotiations with little on not human involvement.
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
Sentior strategist