FW: The stack diagram (was RE: Discussion topic for tomorrow's call

Mario,

First a point of credit.  The snippet of code you cited

>George wrote:
>| <snip>
>| A stack diagram implies a layered design pattern (think OSI stack), which
>| indicates that the layer on top calls the layer below to further the
>| process. It's a runtime processing diagram. It seems to me that we're
>trying
>| to convey too much information in this stack diagram. (combining runtime
>| processing with other things)
>| </snip>

as actually from Anne.  I was responding to her comment and, in fact, was
making the point that the *stack* should be definitional.  I think we
(including Anne) have agreed on that point.

>I'm not clear if the wording "Services" is appropriate here for the WSDL
>including layer. Doesn't this imply that there is no service without
>WSDL which is certainly untrue.

If the a web service does not include a "service" I am pressed to ask what
it is that is being defined.  But I won't stop there and propose that we
seriously consider making it literally a WSDL defined service.  In other
words a web service is anything that can be defined through WSDL.  If we
find that WSDL does not provide for all the cases that should be web
services (and I think that may be the case) then we need to indicate where
it is deficient to meet the current and future needs of web services.  To
have any possibility of achieving the *flip a bit* world envisioned by Assaf
(see Assaf's itervening response to Roger), then a common language for
defining those services is needed.  Without a language in which to describe
a service, evolution to a ubiquitous, open interchange is a practical
impossibility.  We need to enable that evolution.

An architecture is the process of specifying constraints (maybe other things
as well but for the sake of discussion let's just take that perspective).
Let's introduce one constraint: WSDL.  The intent is not to limit web
services to whatever WSDL happens to define today but to set the stage for a
common framework and mechanism through which web services can evolve.
Perhaps it is not possible to create a WSDL robust enough to handle the
"lousy web service" or "simple web service" which Roger discusses, but
perhaps that's may just have to be the case - they are not *web services*
(but I am not sure that needs to be the case).  XML has been discussed as
the backplane or as you suggest as a *base technology* with explanation (in
my proposed diagram I listed them to offer a different visualization to test
the response).  We build on that *base* through WSDL.  I know this may seem
to be going against the grain but I believe that it is a critical decision
that can make the difference between a broad, easily-implemented but chaotic
approach or one that introduces a discipline and thus some restrictions but
that will enable the full realization of the potential of web services.
Let's not accept that WSDL is optional but that it is the key to achieving
generally accessible web services and attack what is a proper web service
(and hence requirements for WSDL) from that perspective.  (Maybe including
Eric's issue about "recursive" services as well as Roger's "lousy web
services").

I also think that the tie between the transport and SOAP leads to an
unintended emphasis.  Again, the stack is definitional not capable of
adequately demonstrating all possible relationships in an operational mode.
We can provide examples that show the different operational relationships.

George

Received on Wednesday, 16 April 2003 01:06:17 UTC