[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: WS-I profiles
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]