W3C home > Mailing lists > Public > www-ws-arch@w3.org > April 2003

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

From: Newcomer, Eric <Eric.Newcomer@iona.com>
Date: Wed, 9 Apr 2003 11:16:49 -0400
Message-ID: <DCF6EF589A22A14F93DFB949FD8C4AB20138E066@amereast-ems1.IONAGLOBAL.COM>
To: "Anne Thomas Manes" <anne@manes.net>, "Jeckle, Mario" <mario@jeckle.de>, "Hugo Haas" <hugo@w3.org>
Cc: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, <www-ws-arch@w3.org>, <Savas.Parastatidis@newcastle.ac.uk>, <RogerCutler@chevrontexaco.com>

The intention of the original diagram I sent around that started the discussion was not to strictly illustrate runtime processing, but more to represent relationships among different major categories of technology.  

OSI is an instance of a single technology, that is, it's a networking stack, and the relationships among its layers did indeed have runtime implications as well as conceptual meaning.

But for the WSA document what I'm trying to achieve is more of a conceptual meaning from the diagram, since we are dealing by definition with applications of XML that are not executable.  


-----Original Message-----
From: Anne Thomas Manes [mailto:anne@manes.net]
Sent: Tuesday, April 08, 2003 8:45 AM
To: Jeckle, Mario; Hugo Haas
Cc: Champion, Mike; www-ws-arch@w3.org;
Savas.Parastatidis@newcastle.ac.uk; RogerCutler@chevrontexaco.com
Subject: RE: The stack diagram (was RE: Discussion topic for tomorrow's

I haven't really been following this discussion too closely, so feel free to
ignore my comments if you've already settled this issue, but ...

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)

The SOAP layer runs on top of the transport layer, not on top of an XML
processing layer. (which is why you need to add the strange L to the
transport layer)  At runtime, XML processing is above the SOAP message
layer. And description is not part of the runtime process. Aggregation might
be part of the runtime process, as could discovery, but I think it normally
comes at a different stage in the process. The lower levels relate to a
single message transfer process. Aggregation works at a completely different

The three role diagram (provider, consumer, broker) shows the relationship
of discovery and description. I don't think these concepts belong in a stack
diagram (which normally illustrates runtime processing).


> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Mario Jeckle
> Sent: Tuesday, April 08, 2003 8:04 AM
> To: Hugo Haas
> Cc: Champion, Mike; www-ws-arch@w3.org;
> Savas.Parastatidis@newcastle.ac.uk; RogerCutler@chevrontexaco.com
> Subject: Re: The stack diagram (was RE: Discussion topic for tomorrow's
> call)
> Hash: SHA1
> |I think that showing this makes the diagram confusing.
> I must confess I certainly did not my very best in fine tuning the
> diagram to be as intuitive as desirable for our WSA document.
> Therefore I repainted the middle part without changing the semantics.
> |I think I prefer my big background box in a different color.
> I still think having the colored box in the background may be desirable
> from the standpoint of emphasizing XML's role as base technology, but I
> think it is some kind of misleading in terms of interpreting Messaging,
> Description, and Aggregation as *part* of this base technology which is
> certainly not true and intended.
> Furthermore Security and Management both may have components which rely
> on XML, but both also deploy components which are completely independent
> of XML. This dichotomy would be hard to show ...
> |Hmmm... that makes showing an XML technologies box even more tricky.
> |Maybe we should just color-code the boxes on whether they are based on
> |XML or not, and use gradients where appropriate.
> Very good idea! I colored the diagram roughly (colors not not imply any
> semantics!) to make it more expressive.
> Also I integrated the influence of the underlying transport protocol to
> the messaging layer.
> The new diagram is attached.
> Cheers,
> Mario
> - --
> Prof. Mario Jeckle
> University of Applied Sciences Furtwangen
> Dept. Business Applications of Computer Science
> W3C Representative of DaimlerChrysler Research and Technology
> URL: http://www.jeckle.de
> MailTo:mario@jeckle.de
> MailTo:jeckle@fh-furtwangen.de
> My public key: http://www.jeckle.de/marioJeckle.pub
> Version: GnuPG v1.2.1 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> iD8DBQE+krqR46tt20EwGqwRAmtjAKDVNf+1QKGDrmJxrM3Pn1x6Z4yZ8QCgm2hd
> FNi/kFGaCMI7hPsEf/QmNp0=
> =M1+h
Received on Wednesday, 9 April 2003 11:17:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:06 UTC