RE: "Marchitecture" text for stack diagram

UDDI is not a "repository" of WSDL descriptions. It is simply a registry.
Your tModel entry points to the WSDL file, but the WSDL file must be stored
elsewhere. I suggest:

"and UDDI serves as a discovery service for the WSDL descriptions"

Also, I'd say that "the process of discovering service descriptions that
meet specified criteria" is fairly mature -- UDDI V2 is an OASIS Standard.
(It was just approved.)

Anne

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Mike Champion
> Sent: Thursday, May 01, 2003 1:14 AM
> To: www-ws-arch@w3.org
> Subject: "Marchitecture" text for stack diagram
>
>
>
> In fufullment of my action item to produce text that the "stack
> diagram" at
> http://lists.w3.org/Archives/Public/www-ws-arch/2003Apr/0254.html would
> support.
>
> ================================================================
> Marketing documents from Web services vendors often contain a three-part
> diagram to show how the different Web services "standards" relate to one
> another: WSDL describes the format SOAP messages, and UDDI serves as a
> repository for the WSDL descriptions.  The problem with such diagrams is
> that they don't convey the multiple dimensions of the Web services
> standards "space" and can't easily be extended to handle new standards,
> e.g. for security, management, choreography, and so on. In order to show
> the big picture of the Web services architecture as we envision it, the
> picture needs to be somewhat more complex.
>
> First and foremost, XML is the "backplane" of the WSA.  One can
> imagine Web
> services that don't depend on the SOAP envelope framework or processing
> model, or that don't employ WSDL to describe the interaction between a
> service and its consumers, but XML is much more fundamental.  It provides
> the extensibility and vendor, platform, and language neutrality
> that is the
> key to loosely-coupled, standards-based interoperability that are the
> essence of the Web services value proposition.  Furthermore, XML
> helps blur
> the distinction between "payload" data and "protocol" data,
> allowing easier
> mapping and bridging across different communications protocols, which is
> necessary in many enterprise IT infrastructures that are built on
> industrial-strength but proprietary components.  Thus, the "base
> technology" of the WSA consists of some key XML specifications, including
> XML 1.x, XML Schema Description Language, the xml:base specification, [ed
> note: others?  XPath??  Not DTD, unlike what the diagram shows,
> since DTDs
> are forbidden in SOAP messages, right?].
>
> This leads to the next key concept in the WSA: services are invoked and
> provide results via messages that must be exchanged over some
> communications medium.  The WSA encompasses a wide, almost
> infinite variety
> of communications mechanisms: HTTP (the dominant protocol of "the Web"),
> other internet protocols such as SMTP and FTP, generic interface
> APIs such
> as JMS, earlier distributed object protocols such as IIOP, and so on.  In
> principle, Web services invocation and result messages could be passed
> around by "sneakernet", RFC 1149-compliant carrier pigeons, or mechanisms
> that have not yet been invented.  WSA says almost nothing about this
> communication layer other than it exists -- it does not specificy that it
> be at any particular level of the OSI reference architecture protocol
> stack, and allows Web services messages to be "tunnelled" over protocols
> designed for another purpose.
>
> WSA does have quite a bit to say about the messages themselves, if not
> about the mechanism by which they are communicated. SOAP is the key
> messaging technology in the WSA: While very simple information transfer
> services can be implemented without it, secure, reliable, multi-part,
> multi-party and/or multi-network applications will require some
> standardized way of packaging and annotating messages so that
> "intermediaries" can provide authentication, encryption, access control,
> transaction processing, routing, delivery confirmation, etc. services at
> the infrastructure level rather than forcing the producer and consumer to
> handle all these features.  SOAP's envelope (and attachment)
> structure and
> its processing model have proven to be a very robust and powerful
> framework
> within which to do this.
>
> Interoperability across heterogenous systems requires a mechanism
> to allow
> the precise structure and data types of the messages to be commonly
> understood by Web services producers and consumers.  WSDL is the obvious
> choice today as the means by which the precise description of Web
> services
> messages can be exchanged.  [Ed note: Obviously we have open issues with
> respect to whether description mechanisms such as shared code "qualify"
> here.]  In the future, more sophisticated description languages
> that handle
> more of the *semantic* content of the messages are likely to become
> technologically viable, and such languages (perhaps based on RDF and OWL)
> will fit well in the WSA framework.
>
> Beyond the description of individual messages such as WSDL provides, the
> WSA envisions a variety process descriptions: the process of discovering
> service descriptions that meet specified criteria, the process of
> describing multi-part and stateful sequences of messages, the aggregation
> of processes into higher-level processes, and so on.  This area is much
> less technologically mature than other parts of the WSA, but
> there is much
> work going on and the WSA incorporates them at an abstract level.
>
> Two concepts cut across all these aspects of the WSA: Security and
> Management.  These cannot be pigeonholed into the boxes of messaging,
> description, or process because they cut across all levels.
> [It's getting late and inspiration fails ... maybe someone can
> finish this
> paragraph for me.]
>
> ====================================================================
>
> If there's time on the agenda today, I'd like to get feedback on this in
> the context of our "stack diagram" discussion last week. Is the
> combination
> of this text and the diagram a good candidate for inclusion in
> the document
> [net some wordsmithing, of course] or do we need to approach this in
> another way?
>
>
>
>
>
>
>
> --
> Mike Champion
>

Received on Thursday, 1 May 2003 10:23:42 UTC