W3C home > Mailing lists > Public > www-ws-arch@w3.org > July 2002


From: Mark Baker <distobj@acm.org>
Date: Tue, 23 Jul 2002 23:32:36 -0400
To: Hao He <Hao.He@thomson.com.au>
Cc: www-ws-arch@w3.org
Message-ID: <20020723233236.G14925@www.markbaker.ca>


On Wed, Jul 24, 2002 at 09:44:36AM +1000, Hao He wrote:
> On Mon, Jul 22, 2002 at 04:19:34PM +1000, Hao He wrote:
> > Components: requestor and provider
> Technically these aren't components, but are instead roles that a
> component could play.  I believe that in the context of the implicit
> architecture of SOAP 1.1 + WSDL, a web server (origin, gateway, or
> proxy) is still a component, as it is the thing to which the connector
> is attached.
> <hh>How about a browser or an application that does not necessary have a web
> server built in?
> It can also act as a requestor.  </hh>

Yes, you're right.  I was only talking about the server, but clearly the
client is a component.  I was talking there about your typical "SOAP 1.1
+ WSDL" Web service, so technically this isn't a WSDL-specific
observation.  But there's other issues, which I get to below ...

> > Data element: typed data item, messages
> The only data element I could think of was a URI, which WSDL is used to
> describe the interface of.
> <hh>Does not WSDL also describe the type of parameters and messages one can
> pass around? </hh>

Yes, but that's the information it itself provides, not what it starts
with.  To identify data elements, I've found it useful to think about
the system without the technology, then add it in and ask yourself what
data it needs from the system when it's added.  AFAICT, for WSDL, that's
just a URI.

FWIW, this is confusing because architectural elements are meant to be
extracted from systems, not specifications.  i.e. until you see it
running, you don't really know if the elements you're identifying are
the real deal.  So this task involves a little bit of hand-waving, but
I think we're doing ok.  At the end, we'll have to piece them together
(for example, SOAP and WSDL) and verify that with current practice.

Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com
Received on Tuesday, 23 July 2002 23:20:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:57 UTC