OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Fwd: [emergency] WS-I profiles


>Mailing-List: contact emergency-help@lists.oasis-open.org; run by ezmlm
>List-Post: <mailto:emergency@lists.oasis-open.org>
>List-Help: <mailto:emergency-help@lists.oasis-open.org>
>List-Unsubscribe: <mailto:emergency-unsubscribe@lists.oasis-open.org>
>List-Subscribe: <mailto:emergency-subscribe@lists.oasis-open.org>
>Delivered-To: mailing list emergency@lists.oasis-open.org
>From: "Alessandro Triglia" <sandro@oss.com>
>To: <emergency@lists.oasis-open.org>
>Date: Tue, 4 Sep 2007 13:44:42 -0400
>Thread-Index: AcfvDfUnIgGoAblOSVGJ3qCct9LrPQACATDg
>Subject: [emergency] WS-I profiles
>X-SpamScore: 0
>X-Rcpt-To: <rexb@starbourne.com>
>X-DPOP: Version number supressed
>
>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


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]