WS-I profiles

["Alessandro Triglia" <sandro@oss.com>]

Hi

Here are the links to a couple of specifications ("Profiles") published by
the Web Services Interoperability Consortium (WS-I), which I think are very
interesting in the context of our current discussion on conformance.

- "Basic Profile 1.1"

http://www.ws-i.org/Profiles/BasicProfile-1.1.html

- "Attachment Profile 1.0"

http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html

Note that I am not referring to the special characteristics that these
specifications have as "profiles" of other specifications (WSDL 1.1, SOAP
1.1, etc.).  I am only referring to their conformance-related aspects.

Also note that I am not implying that the approach followed in these
specifications should be followed literally in our specifications.  However,
I do believe that they contain several excellent ideas and that we could
think about borrowing some of them in our future work.  Indeed, I believe
that the OASIS draft guidelines on conformance are very close to the
approach followed in these specifications.

Here are a few passages that I consider relevant to the present discussion:


-----------------------------------------
Testability

When possible, the Profile makes statements that are testable. However, such
testability is not required. Preferably, testing is achieved in a
non-intrusive manner (e.g., examining artifacts "on the wire").


Strength of requirements

The Profile makes strong requirements (e.g., MUST, MUST NOT) wherever
feasible; if there are legitimate cases where such a requirement cannot be
met, conditional requirements (e.g., SHOULD, SHOULD NOT) are used. Optional
and conditional requirements introduce ambiguity and mismatches between
implementations.


Conformance targets

Where possible, the Profile places requirements on artifacts (e.g., WSDL
descriptions, SOAP messages) rather than the producing or consuming
software's behaviors or roles. Artifacts are concrete, making them easier to
verify and therefore making conformance easier to understand and less
error-prone.
-----------------------------------------



-----------------------------------------
Conformance to the Profile is defined by adherence to the set of
requirements defined for a specific target, within the scope of the Profile.

-----------------------------------------


-----------------------------------------
Requirement levels, using RFC2119 language (e.g., MUST, MAY, SHOULD)
indicate the nature of the requirement and its impact on conformance. Each
requirement is individually identified (e.g., R9999) for convenience.

For example

R9999 WIDGETs SHOULD be round in shape.

This requirement is identified by "R9999", applies to the target WIDGET (see
below), and places a conditional requirement upon widgets; i.e., although
this requirement must be met to maintain conformance in most cases, there
are some situations where there may be valid reasons for it not being met
(which are explained in the requirement itself, or in its accompanying
text).
-----------------------------------------


-----------------------------------------
Each requirement statement contains exactly one requirement level keyword
(e.g., "MUST") and one conformance target keyword (e.g., "MESSAGE"). The
conformance target keyword appears in bold text (e.g. "MESSAGE"). Other
conformance targets appearing in non-bold text are being used strictly for
their definition and NOT as a conformance target. Additional text may be
included to illuminate a requirement or group of requirements (e.g.,
rationale and examples); however, prose surrounding requirement statements
must not be considered in determining conformance.
-----------------------------------------


-----------------------------------------
Conformance targets identify what artifacts (e.g., SOAP message, WSDL
description, UDDI registry data) or parties (e.g., SOAP processor, end user)
requirements apply to.

This allows for the definition of conformance in different contexts, to
assure unambiguous interpretation of the applicability of requirements, and
to allow conformance testing of artifacts (e.g., SOAP messages and WSDL
descriptions) and the behavior of various parties to a Web service (e.g.,
clients and service instances).

Requirements' conformance targets are physical artifacts wherever possible,
to simplify testing and avoid ambiguity.
-----------------------------------------


-----------------------------------------
The following conformance targets are used in the Profile:

MESSAGE - protocol elements that transport the ENVELOPE (e.g., SOAP/HTTP
messages)

ENVELOPE - the serialization of the soap:Envelope element and its content

DESCRIPTION - descriptions of types, messages, interfaces and their concrete
protocol and data format bindings, and the network access points associated
with Web services (e.g., WSDL descriptions)

INSTANCE - software that implements a wsdl:port or a uddi:bindingTemplate

CONSUMER - software that invokes an INSTANCE

SENDER - software that generates a message according to the protocol(s)
associated with it

RECEIVER - software that consumes a message according to the protocol(s)
associated with it (e.g., SOAP processors)

REGDATA - registry elements that are involved in the registration and
discovery of Web services (e.g. UDDI tModels)
-----------------------------------------


Alessandro