[GRAAP-WG] Inconsistencies in the WS-Agreement Specification (GFD.107) and WS-Agreement Schema (ws-agreement.xsd)

Oliver Wäldrich Oliver.Waeldrich at scai.fraunhofer.de
Fri May 7 08:32:34 CDT 2010


Dear Knud,

> In the written part of your standard, you do do repeatedly define 
> terms comprising *one or more* service terms (cardinality 1..*) and 
> *zero or more* guarantee terms (cardinality 0..*)" (page 4, page 14). 
> Therefore I interprete that a single GuaranteeTerm without any 
> ServiceDescriptionTerm / ServiceReference / ServiceProperty ain't 
> intended to be possible. Whatever, the coding integrated in the 
> standard document (page 17/18) as well as your provided 
> ws-agreement.xsd allow terms comprising ONLY a single GuaranteeTerm.

That is correct. Usually an agreement only makes sense when it includes a
description of the service that is to be provided. Additionally, you can
define measurable properties that are associated with the service (service
properties) and guarantees that are defined using the service properties.
Even though the WS-Agreement schema does not enforce this incremental
structure, the textual description illustrates this mechanism. Personally, I
think that this point (cardinality of service description and guarantee
terms) should be addressed during the domain specific template design, not
in the specification itself. Since templates can include creation
constraints to define the structure of an agreement in a fine granular way,
this mechanism can be used to ensure that a specific agreement MUST include
one service description term and a guarantee.

> Another point is that in the textual description, you engage 
> ServiceTerm as super class of ServiceDescriptionTerm, ServiceReference 
> and ServiceProperty while the entity ServiceTerm ain't used in you 
> example coding (page 17/18) nor in the provided XSD.

The ServiceTerm type is defined as an abstract type. It is the abstract base
class for the service description terms, service properties, and guarantee
terms. The example code at the mentioned pages illustrates the usage of the
concrete types. Therefore, the abstract base type is not part of the pseudo
code.

Best regards,
Oliver

-----Ursprüngliche Nachricht-----
Von: graap-wg-bounces at ogf.org [mailto:graap-wg-bounces at ogf.org] Im Auftrag
von Knud Mikkat
Gesendet: Donnerstag, 15. April 2010 16:48
An: graap-wg at ogf.org
Betreff: [GRAAP-WG] Inconsistencies in the WS-Agreement Specification
(GFD.107) and WS-Agreement Schema (ws-agreement.xsd)


Dear Ladies and Gentlemen,

I'm currently workin on an OWL based ontology for Service Level Agreements
based on WS-Agreement for my bachelor thesis at Karlsruhe Institut of
Technology (KIT). Studying the standard you provided as well as the XML
schema, I faced some (imo) inconsistencies.

In the written part of your standard, you do do repeatedly define terms
comprising *one or more* service terms (cardinality 1..*) and *zero or more*
guarantee terms (cardinality 0..*)" (page 4, page 14). Therefore I
interprete that a single GuaranteeTerm without any ServiceDescriptionTerm /
ServiceReference / ServiceProperty ain't intended to be possible. Whatever,
the coding integrated in the standard document (page 17/18) as well as your
provided ws-agreement.xsd allow terms comprising ONLY a single
GuaranteeTerm.

Another point is that in the textual description, you engage ServiceTerm as
super class of ServiceDescriptionTerm, ServiceReference and ServiceProperty
while the entity ServiceTerm ain't used in you example coding (page 17/18)
nor in the provided XSD.

My question is now whether the GFD provided implementation (no ServiceTerm
class, single GuaranteeTerm possible) or the standards' text shall be
referenced to for futur work. Attached you can find some pseudocode to
underline my thoughts.

Best regards,
Knud Mikkat

-- 

Knud MIKKAT
Student der Informationswirtschaft (B.Sc.)
Karlsruher Institut für Technologie (KIT)




More information about the graap-wg mailing list