Analysis of WSD Requirements by WS Arch

Analysis of WSD Requirements by WS Arch

General observations:
1) Independent design - reqs, scenarios, components, interfaces -  of
     overlapping problem space will certainly result in redundancy and
     defintion skew. This is happening with WS Arch and WS Desc.
2) Minimally, WS Arch should consider adopting a number of WS Desc reqs
3) Maximally, construct a similiar situation between WS Arch and WS Desc
     based on the earlier partitioning of interaction modeling into Usage
     Scenarios (WS Arch owned) vs Use Cases (WS Desc). Hence WS Arch would
     push down requirements on other WS WGs much like the TAG is pushing down
     the definition of the Web onto WS Arch.

     Question: Should overlaping requirements be
     1) defined independently (current situation)?
     2) held joinly as peers? - involves an joint actitity
     3) owned by WS Arch and pushed down on WS Activity WGs?
     My biased answer:
     (1) is easiest, inconsistencies can be identified (start from (3) below)

Actions:
1) Verify glossary terms are consistent & shared. They define: Message, Operation,
Interface (aka Port Type), Interface Binding, Endpoint, and Service.


2) Consider adoption of non-overlapping, high-level WS Desc requirements:
--------------
R004 The WG specification(s) MUST describe constructs using the [XML
Information Set] model (similar to the SOAP 1.2 specifications
[SOAP 1.2 Part 1]).

PROPOSED ACTION: Move R004 to D-AC010.2 which is now D-AC011.3.2(?). Reword
to be WG agnostic.
---------------
R100 The description language MUST allow other type systems besides XML
Schema (http://www.w3.org/2001/XMLSchema) via extensibility.

PROPOSED ACTION: Adopt this unless we feel that the CSF D-AC010.1 sufficiently
covers this. Adopt as AC-011.3.3 (?)
--------------
R098 The WG specification(s) schema and examples MUST be written in XML Schema
and SHOULD be written in the latest public W3C XML Schema Recommendation.

PROPOSED ACTION: Not sure - may be too low level except as a good push-down req
--------------


3) Redundant, scope-changed, or slightly askew WSD requirements relative to WSA:
--------------
R070 The WG specification(s) MUST allow providing a mapping from the
description language to [RDF]. (See AC009)
--------------
R001 The description language MUST allow any programming model, transport,
or protocol for communication between peers. (AC011, AC021)
--------------
R099 Processors of the description language MUST support XML Schema (See
AC010.1)
--------------
R007 The WG specification(s) MUST provide detailed examples, including
on-the-wire messages.  (See AC012)
--------------
R003 The WG specification(s) SHOULD use available XML technologies. (See
AC010)
--------------
R105 The WG specification(s) SHOULD support Web Services that operate
on resource constrained devices. (See AC021)
--------------
R010 The WG specification(s) SHOULD use consistent terminology across all
sections of the specification(s). (See AC012)
--------------
R013 The WG specification(s) MUST be simple to understand and implement correctly.
The description language MUST be simple to use. (See AC005)
--------------
R014 The WG specification(s) SHOULD be compatible with existing Web
infrastructure. (See AC011)
--------------
R012 The description language MUST support the kind of extensibility actually
seen on the Web: disparity of document formats and protocols used to communicate,
mixing of XML vocabularies using XML namespaces, development of solutions in a
distributed environment without a central authority, etc. In particular, the
description language MUST support distributed extensibility.  (See AC003 and
AC011)
-------------



4) Potential high relevance to WSA. These WS Desc Requirements may impact
WS Arch work:
--------------
R022 The description language MUST allow describing application-level error
Messages (AKA faults) generated by the Web Service.
--------------
R054 The description language MUST clearly separate the description of Messages
from the Message exchange pattern and InterfaceBinding.
--------------
R116 The description language MUST allow describing abstract policies required
or offered by Services.
--------------
R083 The description language MUST separate design-time from run-time
information.
--------------
R117 The description language SHOULD allow specifying QoS-like policies and
mechanisms of a Web Service. For instance, an indication of how long it is
going to take a Web Service to process the request.
--------------
R036, R097, R094 "These are assertions of what type of message interactions
will be supported (described). Listed are: one-way (self to self), request-
response, solicit-response, faults, asynchronous, events (output-oriented)."
--------------
R081 The description language MUST describe EndPoint location using URIs.
--------------
R046 The description language MUST allow describing Messages independent of
specific wire format.
--------------
R046, R085 "Service types are groups of interfaces - ST groupings can be
extended"
--------------
R114 The description language MUST allow unambiguously mapping any on-the-wire
Message to an Operation.
--------------
R068 The description language MUST allow binding of transport characteristics
independently of data marshalling characteristics.
--------------
R052 The description language MUST allow describing InterfaceBindings to other
protocols besides those described in the specification.
--------------
R111 The WG MUST provide a normative description of the InterfaceBinding for
HTTP/1.1 [IETF RFC 2616] GET and POST.
--------------
R028 The description language MUST allow describing the structure of incoming
and outgoing SOAP 1.2 messages [SOAP 1.2 Part 1], including the contents, encoding,
target, and optionality of SOAP 1.2 Header and Body blocks, SOAP RPC blocks, and
SOAP Faults.
--------------
R031 The WG specification(s) SHOULD support SOAP 1.2 intermediaries.
--------------
R075 The description language MUST allow identifying versions of Services. "(Not
just description files)"
--------------
R115 The WG specification(s) SHOULD define the equivalence of Service descriptions.
--------------

Received on Wednesday, 12 June 2002 05:12:27 UTC