BEA comments on WSD Requirements

Apologies for being a couple days late.

In general, I found that some of the requirements were written to specify a
design.  Examples of this are R118 and R058.  This typically isn't the way
that requirements should be written.  A better way to phrase R118 might be
"The description language MUST provide for re-use of a group of
interfaces.".  This could be followed by a comment like "Probably a
construct like a Service-type is the correct approach".

Specific comments.  I've tried to make the first sentence the suggested
requirement for the document.

1. The description language SHOULD provide for validation of WSD documents
that are entirely abstract and MUST not contain non-abstract information and
provide for validation of WSD documents that are entirely concrete and MUST
not contain abstract information.   Currently, this is accomplished in 3rd
party specs like UDDI saying this is a best practice.  But there is no way
of validating this at a schema or a wsdl level.  This makes it difficult for
applications to guarantee the separation of abstract from concrete
information in WSDL.  An example is in complex choreographies, where the
message exchange pattern is published and MUST NOT contain any operation
URIs.  Another example is the use of deployment WSDL, where the abstract
information is fixed and the deployer can only fill in URIs for the service
and abstract information MUST not be added to the deployer's WSDL.

Currently WSD does not meet this requirement, and there may be valid
reasons - such as the difficulty in solutions like using multiple
namespaces.  But it certainly is a desirable requirement that should be at
least documented and also weighed against other requirements.

2. The WG should provide Use Cases for it's work when the trade-offs between
various use cases have been used to determine functionality and
requirements.  Almost every discussion about which design approach to take
in WSD centers around use-cases and hence requirements.  Examples include
the Service-type discussion, the use of Schema constructs discussion, etc.
Yet the final description of how a developer or tool should be used to
accomplish a particular set of functionality is rarely documented in a form
that can be used by external parties.  I'm not suggesting that documented
use cases have to be provided for every single use case.  I'm suggesting
that cases where people have extensively discussed different approaches
should at least have the "winning" use case documented.  This should be a
very light-weight process.  We have originally tried to reconcile this work
with the web services architecture group, but that hasn't worked out to
well.  I believe the capture of use cases/usage scenarios is still very
important for helping others understand wsd motivation and usage.

I was somewhat unsure about including this comment in a "requirements
document" review.  Various requirements on the WG, as opposed to the
description language, led me to believe this review could include
discussions on requirments on the WG.  If it turns out this is an
inappropriate review form for this comment, I'm open to other forums.

3. The description language message definitions MUST describe constraints on
XML based Message content.  Ironically, I couldn't find any requirement that
said that talked about providing schemas that constrain the content of
messages!  For example, R004 means that the document format is in XML, not
the format of the messages.   R021 doesn't seem to go into the details of
the constraints.  One could provide a human readable description of a
message and satisfy R021.

4. The description language definitions MUST describe constraints upon
service locations for http: URIs, and SHOULD describe constraints for URI
schemes in addition to http:.  The spec provides for HTTPURLs, but it
doesn't provide for more generic address format constraints.  Imagine I have
a non-http URL and I want the same http: specific functionality.

5. The description language message definitions SHOULD describe constraints
on non-XML based message content.  I think this is sufficiently met with the
MIME support, though I'm not 100% sure based upon some of the SwA and DIME
discussions.

6. Remove R110.  seems way too specific.

7. The description language MUST support message parts that are in the
address and the body.  The WSDl 1.1 http:urlReplacement element says that
ALL the message parts are in the URL.  But imagine the use case of POSTing a
purchase order.  The purchase order ID might be in the URI, whilst the POST
body contains another message part.

8. The description language MUST support optional message parts in the
address.  I don't see a way of using http:urlReplacement and having some
parts being optional.  But maybe I just missed this and some examples would
clear it up.

9. The description language SHOULD provide for description of optional
message parts.  I know this has been the subject of much discussion, so it
seems like this is just housekeeping to add this in.

10. The description language SHOULD provide a construct for references to
identifiable elements.  For example, the wsu:portReference is extremely
useful above beyond choreography.  Further, it makes great sense for a group
owning the definition of a data structure to also provide for references to
those data structures.  For example, what are the relationship between
elements in the reference structure and the message parts?  One example
would be how does one "pass" a portreference that contains an extension that
maps to a header when invoked, ie a conversation ID.  Or how does a
reference deal with bindings, like a reference that requires HTTP POST vs
HTTP GET.  I realize that the group hasn't currently chose to do the work of
defining a portReference, though one can always hope it changes it's mind.
As with other requirements that are SHOULDs but not met for various reasons,
this one seems worthwhile including.

Cheers,
Dave

Received on Thursday, 2 January 2003 17:29:10 UTC