o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);}
An OASIS SOA-EERP White Paper
End-to-End Resource Planning (EERP) Model and Use Case
Detailed Context and Example for SOA-EERP Technical Committee Specifications
The purpose of the OASIS SOA-EERP TC is to define standards for End-to-End Resource Planning (EERP) in a Service-Oriented Architecture context. EERP is a technology that optimizes deployment of services onto a SOA description of an application. This work is being carried out through continued refinement and the addition of interoperation protocols to Business Quality of Services (bQoS), Business Rating of Services (bRating), and Business Services Level Agreement (bSLA) specifications. See the TC Charter[1] for more information.
This white paper was produced and approved by the OASIS SOA-EERP Technical Committee as a Committee Draft and as part of Public Review Draft 01. It has not been reviewed and/or approved by the OASIS membership at-large.
Copyright © 2010 OASIS. All
rights reserved.
All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Table of Contents.......................................................................................... 3
Introduction................................................................................................... 5
EERP Technology......................................................................................... 7
Overview.................................................................................................. 7
Challenges in Implementing EERP............................................................. 7
Enablers for Optimization.......................................................................... 8
Use of EERP Techniques.......................................................................... 8
Terminologies used in EERP...................................................................... 9
Status of the Standards Process................................................................ 9
Conceptual Framework and
Message Flow................................................. 11
Overview................................................................................................ 11
Conceptual Framework and Actors......................................................... 11
Message Exchange Example................................................................... 12
Message Flow........................................................................................ 12
Message Sequence Diagrams.................................................................. 14
A Guided Tour through the XML
Vocabulary Specifications......................... 17
Overview................................................................................................ 17
The Three Specifications......................................................................... 17
EERP Business Quality of
Service (bQoS) Specification and Schema....... 18
Business Rating Specification
and Schema............................................... 20
EERP Business Service Level
Agreement Specification............................ 22
Use Case and Examples.............................................................................. 25
Overview................................................................................................ 25
The Use Case......................................................................................... 25
The Scenario.......................................................................................... 26
Actors.................................................................. 26
EERP Detailed Examples........................................................................ 26
Namespaces......................................................... 26
EERP bQoS Example........................................... 27
EERP bRating Example......................................... 28
EERP bSLA Example........................................... 29
References.................................................................................................. 33
This document introduces Service Oriented Architecture (SOA) End-to-End Resource Planning (EERP). We discuss the motivations, then describe the conceptual framework, model, specifications, and end with a detailed example of how the Technical Committee’s work to date is used applying EERP. As of this writing, the OASIS SOA-EERP TC has approved three XML vocabulary specifications as committee drafts; those committee drafts and this white paper are part of Public Review.
In this context, a service is a component capable of performing a task, or a type of capability described using WSDL, while SOA is referred to by W3C (World Wide Web Consortium) as a set of components which can be invoked, and whose interface descriptions can be published and discovered. The applications of these three specifications are any kind of business services, and they are not limited to only Web Services.
For a given service there may a number of potential suppliers. EERP optimizes deployment of services onto a SOA description of an application. Describing the required information—business characteristics of a service, the reputation of potential service providers, and business service-level agreements—enables analysis and optimization of business results in the space of possible service deployments.
The specifications can be applied to other areas. For example, bQoS might be used for describing the characteristics of energy or goods bought and sold, and the characteristics of services such as medical, shipping, and more. The reputation of a trading or business partner is useful in many contexts.
This whitepaper is coordinated with and part of the SOA-EERP Public Review.
As Service-Oriented Architecture (SOA)[2] has matured as a development, deployment, and governance paradigm, the performance of SOA deployments has received increasing attention.
According to OASIS Reference Model for Service Oriented Architecture [SOA-RM], Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. The service within SOA is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.
End-to-End Resource Planning (EERP) applies the well-known technique, such as Universal Description, Discovery and Integration [UUDI], WS-Discovery [WS-DD], and Devices Profile for Web Services [WS-DP], for service discovery and optimization in a novel way to improve business results. As the software industry has applied SOA to eBusiness deployments, self-optimizing systems as exemplified by EERP have become more feasible and more useful.
Different deployments of services onto a business process have varying business value. For example, a shipper might offer faster but more expensive service. EERP models the business process and the range of potential services, and then guides the selection and deployment of services based on the overall end-to-end business value.
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.
Many of these parts of EERP are useful separately. For example, descriptions of a service can be part of defining characteristics of specific services or goods bought or sold, from energy to medical services.
The following
issues are not addressed in Committee Draft[3] 4
/ Public Review 02 and are not part of the current work plan of the Technical
Committee:
v
The discovery, selection, assembly, and management of
services supporting business processes[4]
v
Monitoring and evolution over time of both the set of services
selected and of the performance of the business process itself
v
Determining and implementing the types of optimization to be
supported
The definition of
the interoperation protocol is on the work plan of the Technical Committee;
however Public Review 02 defines message content rather than message sequencing
and exchanges. Examples in later sections are not intended to indicate the
final work of the Technical Committee.
We define "optimization" as maximizing business value by enabling improved real-life eBusiness process and resource planning. Optimization can take place at both design time and run time. The focus of the SOA-EERP Technical Committee is on enablers for optimization and process improvement rather than on the complete EERP environment.
Enabling technology defined by the Technical Committee to date include definition of the framework for representing business service characteristics (how to represent cost, time, quality, and intended result), a means to describe the reputation of the service providers to solicit and report information, and a means to describe what we call business service-level agreement.
Services are performed by people, machines, and hardware/software applications, and represented by SOA services. The qualities of a business service are expressed by means of the Business Quality of Service (bQoS) specification. The nature of bQoS varies across industries and services.
Businesses improve their business processes in order to reduce cost, improve efficiency, and otherwise improve business results. The definition and annotation of business processes are outside the scope of the Technical Committee’s work.
Parties
interested in this work would include enterprises that deploy and manage
solutions that use SOA techniques and which want to develop effective business
processes and improve the performance and agility of those solutions.
The EERP
specifications can be applied to other areas. For example, bQoS may be
applicable for 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.
Extensive
applications of SOA-EERP techniques will likely be most cost-effective for
long-running business processes, although SOA-EERP enabling specifications will
also help in the definition, design, and deployment of SOA end-to-end business
processes.
Early versions of
EERP and the SOA-EERP specifications are currently deployed in industry portals
in China to facilitate service selection and business process improvement, For
example, www.10109555.com , which is China's largest agricultural
information service platform, has used early versions of EERP.
Business
Quality of Service (bQoS)
models the business characteristics of a service for estimating the business
value of one or a set of services in a business process. In contrast to the QoS
in the software/IT world, where the message is network/system oriented measurement that deals with network
performance and system availability, the contents of bQoS in this specification
is business oriented measurement that deals with business characteristics of a
service, such as price, performance, and quality.
Business
Rating (bRating) defines
service credibility, reliability and reputation which need to be understood for
estimating the overall business quality. It has two major categories: rating and
credentials. Rating is provided by the rating provider to show the ranking a
given service provider among the others. Credentials are provided by the
service provider itself to show the credibility of providing a given service.
Business
Service Level Agreement
(bSLA) is the agreement between the service requestor and the service provider.
It primary address the bQoS content, Rating and Credentials. These contents are
all business related. In contrast to the SLA (Service Level Agreement) in the
software/IT world, where SLA is the contract between the service provider and
the network/system provider, and the SLA is network/system oriented agreement
that deals with network performance and system availability. The bSLA in the EERP is business oriented agreement
that deals with price, time to deliver, and the quality/rating of the
service.
As of this
writing, Committee Draft 4 of the SOA-EERP specifications has been approved by
the Technical Committee. This white paper will be edited and released with the
specifications as part of Public Review 02. The specifications are:
v
SOA-EERP Business Quality of Service (bQoS) [EERP-bQoS]
v
SOA-EERP Business Rating of Service (bRating) [EERP-bRating]
v
SOA-EERP Business Service Level Agreement (bSLA) [EERP-bSLA]
These XML
vocabulary specifications address the exchange of information that models the
business characteristics of a service, permits assertions or queries related to
the credibility of the service and its provider, and the establishment of
agreements about the use of business service.
The SOA-EERP TC
will continue the standards development process toward to its ultimate goal of
standardizing protocols and message contents so users may apply EERP to guide
the selection and deployment of services based on end-to-end business
value.
This section
describes a conceptual framework in which the current Technical Committee XML
vocabulary specifications would fit. In addition to the current work in
progress, the conceptual framework describes work that would facilitate service
selection and business process improvement from end-to-end. See the Technical
Committee charter for the scope of the work.
We include
a diagram of the conceptual framework, and of messages flows with brief
descriptions to demonstrate how the current specifications fit into the overall
EERP architecture. We also include timeline and sequence diagrams to show how
an implementation would use these specifications in an end-to-end fashion and
build a continuous business process improvement loop.
Figure 1 is the conceptual framework for EERP. In this figure, the Business Quality of Service is abbreviated as bQoS, Business Rating is abbreviated as bRating, and Business Service Level Agreement is abbreviated as bSLA.
The service requester is the client system who asks the EERP system to find an optimal solution.
Service providers offer business services. Each service provider may offer the same service but with different bQoS and bRatings[5]. Services may be running on different platforms with different implementations, but they all support EERP exchanges of bQoS, bRating, and bSLA information in the XML formats defined by the Technical Committee.
The EERP Portal accepts the request from the Service requester, performs bQoS and rating queries, calculates optimal solution(s), and then returns the result to the service requester.
The Rating Provider is a party unaffiliated with either the requester or the target of the rating request, such as a third party rating organization, given a reference to a particular business service and provider, issues either a number or a classification description.
Note that this conceptual framework is just one way of
implementing the EERP technology. There are alternate ways to implement EERP
without the EERP Portal. For example, one could use the ebXML
Registry/Repository or similar means to exchange business quality of services
information, and begin negotiations for establishing Business Service Level
Agreements (bSLAs).
We show the message exchanges graphically then in tabular form. Public Review Draft 01 (PR01) describes the XML vocabulary for the content of the message inside a SOAP or REST request/response. For example, an EERP system might have the following messages exchange flow as shown in Figure 1 below.
Figure 1 -- EERP Conceptual Framework
Information
exchanged in messages 2 through 9 is defined by Committee Draft 4 of the
specifications. The results of these requests are used to calculate the optimal
deployment for a given set of services requests.
A list of
alternatives might be returned in message 10. Each step in the process would
have a service provider determined for each service and for each alternative.
Messages 11
and 12 are exchanged between the service requester and the selected service
providers to define the bSLA.
The service requester wants to search for the optimal end-to-end solution for a given set of services. The following sequence of messages would work. Note that the Technical Committee has not defined the messages in steps 1, 10, 11, and 12.
Step |
Message |
Description |
1 |
EERP Request* |
Service Requester sends EERP Request message to EERP Portal |
2 |
bQoS Request |
EERP Portal sends bQoS Request messages to all Service Providers to query the business quality of services |
3 |
bQoS Response Message |
Service Providers send bQoS Responses back to EERP Portal |
4 |
Rating Request |
EERP Portal sends Rating Request message to all Service Providers to query the credentials of the Provider |
5 |
Rating Response Message |
Service
Providers send Rating Response message back to EERP Portal |
6 |
Rating Request |
EERP
Portal sends Rating Request message to third party Rating organization to query the rating for the given Provider |
7 |
Rating Response Message |
The
rating provider, such as a third party Rating organization, sends Rating
Response message back to EERP Portal |
8 |
bSLA Request |
Based
on the behavior of the Service Requester, EERP Portal can send bSLA Request
message to the Service Provider to obtain the commitments from the Provider |
9 |
bSLA Response Message |
Service
Provider commits to the agreement and sends the bSLA Response message back to
EERP Portal |
10 |
EERP Response* |
The
optimization will take place in the EERP Portal, which is not part of these
three specifications. After the optimization
calculation on all the information that EERP Portal received from all Service
Providers, EERP Portal sends EERP Response message back to Service Requester |
11 |
bSLA Request* |
Service
Requester sends bSLA Request message to the Service Providers to obtain the
commitments from the Service Providers directly, instead of getting the bSLA
via EERP Portal. |
12 |
bSLA Response Message* |
Service
Provider commits the agreement and sends bSLA Response message back to
Service Requester |
* The contents of the indicated messages are not currently
defined by the Technical Committee
Optionally, a protocol might send a single message combining messages 2 and 4 with the response combining messages 3 and 5. These are shown in Figure 3 as messages 2+4 and 3+5.
We conclude this section with two sequence diagrams. The following is a message sequence diagram without the optional messages:
The following is a message sequence diagram with the optional messages:
As described
previously, the current work in the TC includes the following three
specifications:
v
SOA-EERP Business Quality of Service (bQoS)
v
SOA-EERP Business Rating of Service (bRating)
v
SOA-EERP Business Service Level Agreement (bSLA)
This
section gives brief descriptions on these three XML vocabulary specifications,
their relationship and provides high-level diagrams for their XML schemas.
XML schema diagrams are produced by Altova XML Spy. For readability, some detail is omitted. A key to the notation is available.[6]
EERP
applies service discovery, composition, simulation, and optimization techniques
in a novel way to improve business results. It takes as input a model of a
business process and the range of potential services, and then guides the
selection and deployment of services based on the end-to-end business value.
EERP
Business Quality of Service (bQoS) Specification is an XML vocabulary by which
a business application may communicate selected business characteristics of the
service it provides. Modeling the business characteristics of a service is a
prerequisite for estimating the business value of the process that uses those
services.
EERP
Business Rating of Services Specification is an XML vocabulary for information
exchange on business credibility, reliability and reputation of the service
providers. The credibility, reliability
and reputation of the service need to be understood for estimating the overall
business quality of the process that uses those services.
The
business characteristics of the service defined in the bQoS specification and
the business rating characteristics of the service defined in the bRating
specification together will enable EERP to determine the varieties of
optimization to be supported, and to select an optimal end-to-end
solution.
EERP
Business Service Level Agreement (bSLA) Specification is an XML vocabulary for
information exchange by which a business application can manage and evaluate services with agreed business
quality of service, obligations and terms.
Modeling
the business service-level agreements to manage and evaluate services and
establishing agreements about the business service is essential to long-term
value chain improvement. The details of
the business service level agreement defined in the bSLA specification will
enable EERP to determine the varieties of optimization to be supported, and to
effectively manage the end-to-end business process.
For
example, when a service requester sends an EERP request message to the EERP
Portal, the EERP Portal can query the business characteristics and the business
rating characteristics of each service within the business process for all
qualified service providers in the network, and calculate the possible
optimized alternatives for the requester. To achieve end-to-end business value
for the business process, additional message exchanges can be done to establish
the business service-level agreements, and to manage and evaluate
services.
The
Business Quality of Service (bQoS) of the XML vocabulary is defined in XML
Schema format that defines many quality measurement indicators. It has the
following major elements:
v
BQoSPrice indicates price or cost for the service
v
BQoSPerformance indicates time to complete the service, or
in the alternative, throughput and latency
v
BQoSQualities indicates additional properties and attributes
v Additional elements for quality of service
The Business Rating (bRating)
specification is for business reliability and reputation of the service and its
services provider. It can have one or more of the following elements:
v
ListOfRating element is for the rating provider to rating of service. Each Rating element in the
ListOfRating is issued by a rating organization that has either an aggregated
numeric rating or an aggregated classification description to represent the
rating of the given business service.
v
Credentials element defines the service credentials that a
service provider owns or holds. Credentials, such as licenses, permissions,
certifications, associations, or affiliations, are issued by organizations that
regulate the service. They are different from the credentials for
authentication in the security term; they demonstrate the credibility of a
given service offered by a service provider. Each individual element in
Credentials contains a single credential for the given business service.
v
Any additional elements for rating the service. For example,
this could be one or more elements of PerformanceQualityAssertionEvaluation
that provides a mechanism for Service Rating Entities to render their
evaluation for how well the Service Provider fulfills the Service Provider’s
own Quality Assertion(s) of its service.
Figure 5 is the
diagram of the XML Schema for Business Rating:
Figure
5 XML Schema for Business Rating
EERP Business Service Level
Agreement Specification defines business Service Level Agreement (bSLA) between
the service requestor and service provider for a given service. Business SLA is
a formal contract between a service provider and a client guaranteeing
quantifiable business quality of service (bQoS) at defined levels.
It can have one or more of the
following elements:
v
SLAParties describes the parties involved in the bSLA for
the service
v
SLAParameters describes the parameters for the service,
which are defined ways of monitoring of bQoS metrics.
v
SLAObligations describes the agreed bSLA obligations for the
service.
v
SLATerms describes the agreed bSLA Terms for the service.
v
Any additional elements for the agreement of the service.
Figure 6 is the diagram of XML Schema for
bSLA:
The following is the
diagram of XML Schema for SLAObligations element within the bSLA:
Figure 7 -- XML Schema for SLAObligations Element
This
section describes a use case to illustrate how these specifications, EERP bQoS,
EERP bRating and EERP bSLA, would be used.
A typical
EERP application system may be drawn as follows.
Figure
8 -- EERP Application Use Case
The Requester in our example is Sichuan My Gas Corporation (http://www.mygascorp.com.cn), a Chinese gas company that supplies natural gas to citizens living in the Sichuan Province, in Western China. It needs to order some gas meters for its customers.
The service is to provide a batch of gas meters. One of the Service Providers is Hangzhou MyGasMeter Technology Co. Ltd. (http://www.mygasmeter.com.cn), a gas meter producer that produces high quality IC-gas-meter in a timely fashion. Our example Service Provider is located in Zhejiang Province, in Eastern China.
The rating provider is 51Honest.org (http://www.51honest.org/), a rating organization that has the experience to evaluate and certify a service provider in the industry. 51Honest.org is located in Northern China.
Detailed example XML instances are listed in this section. These examples follow the schemas in Public Review Draft 01 for EERP bQoS, bRating and bSLA.
v
Service Requester: requests a service through the
EERP systems to find the optimal solution
v
Service Providers: offer the service, each with a
different bQoS and Rating
v
EERP Portal: a system that accepts the request
from the Service requester. It performs
bQoS and Rating queries, calculates the optimal solution, and returns the
result back to Service requester.
v
Rating Provider: a third party rating organization,
such as 51Honest.org, provides the rating service for the service providers
Unless overridden by a namespace declaration inside an XML fragment, this document uses the following namespaces:
Prefix |
Namespace |
s |
http://schemas.xmlsoap.org/soap/envelope |
eerp |
http://docs.oasis-open.org/ns/soa-eerp/eerp/200903 |
bqos |
http://docs.oasis-open.org/ns/soa-eerp/bqos/200903 |
bsla |
http://docs.oasis-open.org/ns/soa-eerp/sla/200903 |
rt |
http://docs.oasis-open.org/ns/soa-eerp/rt/200903 |
cbc |
urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2 |
udt |
urn:un:unece:uncefact:data:specification:UnqualifiedDataTypesSchemaModule:2 |
xsd |
http://www.w3.org/2001/XMLSchema |
This bQoS example demonstrates the use of the EERP bQoS specification. The business quality of service on the gas-meters, including price, throughput and some properties, are described in XML to meet the specification provided by the gas-meter producer, Hangzhou MyGasMeter Technology Co. Ltd. (http://www.mygasmeter.com.cn), the EERP Service Provider.
The bQoS instance has the following items:
1. The price of the gas-meters is CNY(RMB) 120,000.00 per batch, and1,000 gas-meters a batch delivery
2. The throughput is 1,000 gas-meters in one batch, one batch per week or 7 days
3. Some of the gas-meter properties are listed in our example: integrated IC-Card-Box, with a solid iron shell.
(1) <?xml version="1.0" encoding="UTF-8"?>
(2) <bqos:BQoS ...
(3) xmlns:bqos="http://docs.oasis-open.org/ns/soa-eerp/bqos/200903"
(4) xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
(5) <bqos:BQoSPrice >
(6) <bqos:Price>
(7) <bqos:Unit unitCode="EA">1000</bqos:Unit>
(8) <bqos:Amount currencyID="CNY">120000</bqos:Amount>
(9) </bqos:Price>
(10) </bqos:BQoSPrice>
(11) <bqos:BQoSPerformance>
(12) <bqos:Throughput >
(13) <bqos:Duration unitCode="DAY">7</bqos:Duration>
(14) <!-- batch production, generally 1000 sets a batch -->
(15) <bqos:Quantity>1000</bqos:Quantity>
(16) <bqos:Latency unitCode="DAY">0</bqos:Latency>
(17) </bqos:Throughput>
(18) </bqos:BQoSPerformance>
(19) <bqos:BQoSQualities>
(20) <bqos:Property>
(21) <bqos:PropertyName languageID="zh-cn">外壳</bqos:PropertyName>
(22) <bqos:PropertyValue languageID="zh-cn">铁壳</bqos:PropertyValue>
(23) </bqos:Property>
(24) <bqos:Property>
(25) <bqos:PropertyName languageID="en">IC-Card-Box</bqos:PropertyName>
(26) <bqos:PropertyValue languageID="en">integrated</bqos:PropertyValue>
(27) </bqos:Property>
(28) </bqos:BQoSQualities>
(29) </bqos:BQoS>
This bRating example illustrates ratings and credentials for the gas-meter producing service. In this example the service provider is Hangzhou MyGasMeter Technology Co. Ltd. (http://www.mygasmeter.com.cn):
The bRating message has the following items:
1. Credit rating on provider is 980.1, rated by 51Honest.org (http://www.51Honest.org), a third-party organization in northern China
2. License on gas-meter production is issued in December 1997, by the Zhejiang Bureau of Quality and Technical Supervision in the P. R. of China (http://www.zjbts.gov.cn/), a government agency.
3. Certificate on gas-meter product is the first Dual-Explosion-Proof Certificate in November 1997. The Certificate is issued by a third-party organization, the National Supervision and Inspection Center for Explosion Protection and Safety of Instrumentation (NEPSI) in Shanghai in the P. R. China (http://www.sipai.com/sitiias/nepsi.asp)
(1) <?xml version="1.0" encoding="UTF-8"?>
(2) <BRating xmlns="http://docs.oasis-open.org/ns/soa-eerp/rt/200903" >
(3) <ListOfRating>
(4) <Rate Type="Credit" >
(5) <RatingIssuer>
(6) <IssuerName languageID="zh-CN">信星计划51Honest.org </IssuerName>
(7) <IssuerUri>http://www.51Honest.org</IssuerUri>
(8) </RatingIssuer>
(9) <RatingNumeric>980.1</RatingNumeric>
(10) <RatingDate>2008-12-31</RatingDate>
(11) <RatingReferenceUri/>
(12) </Rate>
(13) </ListOfRate>
(14)
(15) <Credentials>
(16) <Credential Type="License" >
(17) <CredentialIssuer>
(18) <IssuerName languageID="zh-CN">浙江省质量技术监督局</IssuerName>
(19) <IssuerUri>http://www.zjbts.gov.cn/</IssuerUri>
(20) </CredentialIssuer>
(21) <CredentialClass languageID="zh-CN">中华人民共和国计量器具生产制造许可证</CredentialClass>
(22) <License languageID="en-us">ZJJHJDJ-JL1997120001</License>
(23) <CredentialDate>
(24) <DateIssued>1997-12-01</DateIssued>
(25) </CredentialDate>
(26) <CredentialReferenceUri/>
(27) </Credential>
(28) <Credential Type="Certification">
(29) <CredentialIssuer>
(30) <IssuerName languageID="en">National Supervision and Inspection Center for Explosion Protection and Safety of Instrumentation ( NEPSI ) in Shanghai, P.R.China</IssuerName> <IssuerUri>http://www.sipai.com/sitiias/nepsi.asp</IssuerUri>
(31) </CredentialIssuer>
(32) <CredentialClass languageID="en">the first Dual-Explosion-Proof Certificate</CredentialClass>
(33) <License languageID="en-us">NEPSI-FB1997110001</License>
(34) <CredentialDate>
(35) <DateIssued>1997-11-01</DateIssued>
(36) </CredentialDate>
(37) <CredentialReferenceUri/>
(38) </Credential>
(39) </Credentials>
(40) </BRating>
This bSLA example shows the following agreement on the gas-meters between Hangzhou MyGasMeter Technology Co. Ltd. (http://www.mygasmeter.com.cn), an EERP Service Provider, and Sichuan Mianyang Gas Corp. (http://www.mygascorp.com.cn), an EERP Service Requester:
The bSLA will have the following terms:
1. The service will charge CNY(RMB) 120,000.00 per batch of gas-meter products
2. The reservation fee for guarantee will charge CNY(RMB) 10.00 per batch
3. The Committed Time for delivery is 7 days (one week) or a little longer per batch, but not later than April 1, 2009
4. The committed throughput is 1,000 gas-meters in one batch, per week (7 days)
5. The penalty will be CNY(RMB) 10.00 per batch, if entry #3 and #4 of the bSLA cannot be met and is not fulfilled by the service provider
(1) <?xml version="1.0" encoding="UTF-8"?>
(2) <BSLA xmlns="http://docs.oasis-open.org/ns/soa-eerp/sla/200903"
(3) xmlns:bqos="http://docs.oasis-open.org/ns/soa-eerp/bqos/200903"
(4) xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
(5) ...>
(6) <SLAParties>
(7) <!--
(8) Service Provider=杭州西湖电子
(9) -->
(10) <ServiceProvider SPID="1">
(11) <ServiceUri>http://www.mygasmeter.com.cn</ServiceUri>
(12) <ServiceProviderName>Hangzhou MyGasMeter Technology Co. Ltd, Zhejiang Prov., P.R.China</ServiceProviderName>
(13) </ServiceProvider>
(14) <!--
(15) ServiceRequester:服务请求人 四川燃气公司
(16) -->
(17) <ServiceRequester>
(18) <ServiceRequesterUri>http://www.mygascorp.com.cn</ServiceRequesterUri>
(19) <ServiceRequesterName>Mianyang Gas Corp., Sichuan Prov., P.R.China</ServiceRequesterName>
(20) </ServiceRequester>
(21) </SLAParties>
(22)
(23) <SLAParameters>
(24) <ServiceProfileUri>http://UnkownServiceURL (http://www.mygasmeter.com.cn)</ServiceProfileUri>
(25) <ServiceOperations>
(26) <hasCommittedCost>true</hasCommittedCost>
(27) <hasCommittedTime>true</hasCommittedTime>
<hasAvailabilities>true</hasAvailabilities>
<hasCommittedThroughput>true</hasCommittedThroughput>
<hasOtherTerms>true</hasOtherTerms>
(28) </ServiceOperations>
(29) </SLAParameters>
(30)
(31) <!-- bSLA Obligation elements -->
(32) <SLAObligations>
(33) <Obligation>
(34) <ServiceLevelObjective>
(35) <CommittedCost>
(36) <bqos:Unit unitCode="EA">1000</bqos:Unit>
(37) <bqos:Amount currencyID="CNY">120000.00</bqos:Amount>
(38) </CommittedCost>
(39) </ServiceLevelObjective>
(40) <ActionGuarantee>
(41) <ReserveFee>
(42) <bqos:Unit unitCode="EA">1000</bqos:Unit>
(43) <bqos:Amount currencyID="CNY">10.00</bqos:Amount>
(44) </ReserveFee>
(45) </ActionGuarantee>
(46) </Obligation>
(47) <Obligation>
(48) <ServiceLevelObjective>
(49) <CommittedTime timeZone="CST" description="+08:00 China Stand Time, Beijing Time or HK Time">
(50) <bqos:Duration unitCode="DAY"> 7</bqos:Duration>
(51) <CommittedCompletionTime>2009-04-01T00:00:00</CommittedCompletionTime>
(52) </CommittedTime>
(53) </ServiceLevelObjective>
(54) <ActionGuarantee>
(55) <ReserveFee>
(56) <bqos:Unit unitCode="EA">1000</bqos:Unit>
(57) <bqos:Amount currencyID="CNY">0.00</bqos:Amount>
(58) </ReserveFee>
(59) </ActionGuarantee>
(60) </Obligation>
(61) <Obligation>
(62) <!-- No. 3 delivery after 7 days, BUT before 2009-04-01 -->
(63) <ServiceLevelObjective>
(64) <CommittedTime >
(65) <bqos:Duration unitCode="DAY"> 7</bqos:Duration>
(66) <CommittedCompletionTime>2009-04-01T00:00:00Z</CommittedCompletionTime>
(67) </CommittedTime>
(68) </ServiceLevelObjective>
(69) <ActionGuarantee/>
(70) </Obligation>
(71) <Obligation>
(72) <ServiceLevelObjective>
(73) <Availabilities >
(74) <Availability isAvailable="true">
(75) <From>2009-01-01T00:00:00Z</From>
(76) <To>2010-01-01T00:00:00Z</To>
(77) </Availability>
(78) </Availabilities>
(79) </ServiceLevelObjective>
(80) <ActionGuarantee/>
(81) </Obligation>
(82) <Obligation>
(83) <ServiceLevelObjective>
(84) <CommittedThroughput >
(85) <bqos:Duration unitCode="DAY">7</bqos:Duration>
(86) <!-- batch production, generally 1000 sets a batch -->
(87) <bqos:Quantity unitCode="EA">1000</bqos:Quantity>
(88) <bqos:Latency unitCode="DAY">0</bqos:Latency>
(89) </CommittedThroughput>
(90) </ServiceLevelObjective>
(91) <ActionGuarantee/>
(92) </Obligation>
(93) <ActionGuarantee>
(94) <ReserveFee>
(95) <bqos:Unit unitCode="EA">1000</bqos:Unit>
(96) <bqos:Amount currencyID="CNY">0.00</bqos:Amount>
(97) </ReserveFee>
(98) <Penalty>
(99) <bqos:Unit unitCode="EA">1000</bqos:Unit>
(100) <bqos:Amount currencyID="CNY">10.00</bqos:Amount>
(101) </Penalty>
(102) </ActionGuarantee>
(103) </SLAObligations>
(104) </BSLA>
[EERP-bQoS] OASIS Committee Draft 03, “SOA-EERP Business Quality of Service Version 1.0, 12 September 2010.
http://docs.oasis-open.org/soa-eerp/bqos/v1.0/SOA-EERP-bQoS-Spec-cd04.pdf
[EERP-bRating] OASIS Committee Draft 03, “SOA-EERP
Business Rating of Service Version 1.0”, 12 September 2010.
http://docs.oasis-open.org/soa-eerp/rt/v1.0/SOA-EERP-bRating-Spec-cd04.pdf
[EERP-bSLA] OASIS Committee Draft 03, “SOA-EERP Business Service Level Agreement Version 1.0”, 12 September 2010.
http://docs.oasis-open.org/soa-eerp/sla/v1.0/SOA-EERP-bSLA-Spec-cd04.pdf
[SOA-RM] OASIS Standard, “Reference Model for Service Oriented Architecture v1.0”, 12 October 2006.
http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf
[UUDI] OASIS Standard, “Universal Description, Discovery and Integration v3.0.2”, 19 October 2004, http://www.oasis-open.org/committees/uddi-spec/doc/spec/v3/uddi-v3.0.2-20041019.htm
[WS-DD] OASIS Standard, “Web Services Dynamic Discovery (WS-Discovery) Version 1.1”, 1 July 2009. http://docs.oasis-open.org/ws-dd/discovery/1.1/os/wsdd-discovery-1.1-spec-os.pdf
[WS-DP] OASIS Standard, “Devices Profile for Web Services Version 1.1”, 1 July 2009.
http://docs.oasis-open.org/ws-dd/dpws/1.1/os/wsdd-dpws-1.1-spec-os.pdf
[2] While we describe services and their characteristics in the context of the Reference Model for Service-Oriented Architecture [SOA-RM], we are not assembling or otherwise manipulating services in the descriptions in this white paper.
[3] As defined in the OASIS Technical Committee Process http://www.oasis-open.org/committees/process.php
[4] Other OASIS Technical Committees and other standardization work have addressed many of these challenges. For example, the Web Services Device Discovery and Device Profile OASIS Standards address discovery and criteria by which a selection can be made. The OASIS Service Component Architecture addresses assembly of SOA services.
[5] The specifications as of this writing do not define the relationships between service providers and multiple bQoS and Ratings.
[6] The XML Schema
diagrams were drawn using Altova XMLSpy. For an explanation of the symbols used
in these diagrams, see http://www.e.govt.nz/standards/e-gif/authentication/data-formats-v1.1/chapter15.html or http://www.diversitycampus.net/Projects/TDWG-SDD/Minutes/SchemaDocu/SchemaDesignElements.html.