[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]