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: Katia Sycara <katia@cs.cmu.edu>
Date: Fri, 4 Apr 2003 10:58:55 -0500
To: "Newcomer, Eric" <Eric.Newcomer@iona.com>, Heather Kreger <kreger@us.ibm.com>
Cc: www-ws-arch@w3.org

Bundling everything in one diagram is confusing. We should also definitely
have separate diagram(s) for execution flow.

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Newcomer, Eric
Sent: Thursday, April 03, 2003 6:37 PM
To: Heather Kreger
Cc: www-ws-arch@w3.org
Subject: RE: The stack diagram (was RE: Discussion topic for tomorrow's

We talked about merging description and aggregation, that may happen during
the editing phase underway.

One diagram can't represent everything.  It would be really great if we
could adopt this one (or something similar) for the overall representation
of the kind of "specification categories" we're including the architecture,
and their relative position to each other in the stack.

David Booth included several diagrams on discovery in his text on that; I
expect some or all of them to remain.

I would also like to see a diagram that depicts the execution flow
relationship -- unless I have misunderstood I think this is what Mike is
interested in including.

If we try to have all diagrams serve every purpose then we will never have
any diagrams ;-)  A blueprint represents a different view than a map and
serves a different purpose.  I think we need both blueprints and maps.


-----Original Message-----
From: Heather Kreger [mailto:kreger@us.ibm.com]
Sent: Thursday, April 03, 2003 2:09 PM
To: Newcomer, Eric
Cc: www-ws-arch@w3.org
Subject: RE: The stack diagram (was RE: Discussion topic for tomorrow's

How does publication and discovery factor in? There are architectural
issues and specifications to be factored in for this too.

The specifications in aggregation are also descriptions, the difference is
they are describing 'one service'
or the behavior of 'a bunch o services'.

where does policy factor in?

Here's the orgional IBM Web services stack:
(Embedded image moved to file: pic19973.jpg)

And here is the updated one we submitted to the WSA. This one has details
for description for the relevant
goals of WSDL (interface and implementation), policy, presentation,
aggregation, and agreements.

It seems that you're working your way thru to recreating one of these.

(Embedded image moved to file: pic08594.jpg)

BTW, I like the idea of using XML as a backplane. Here it supports the
description substack.

Heather Kreger
STSM, Web Services Lead Architect for SWG Emerging Technologies
Author of "Java and JMX: Building Manageable Systems"
919-543-3211 (t/l 441)  cell:919-496-9572

"Newcomer, Eric" <Eric.Newcomer@iona.com>@w3.org on 04/03/2003 01:30:40 PM

Sent by:    www-ws-arch-request@w3.org

To:    "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>,
Subject:    RE: The stack diagram (was RE: Discussion topic for tomorrow's


I'd really like to adopt Mario's version of the current stack diagram as
the way we visually represent the relationship among the various
specifications we include in the architecture.

The other three-stack diagram is useful more for the purpose of
representing some kind of flow between the major functional areas during
execution.  And I'd like to try to postpone that kind of diagram for a
later exercise, after we can gain agreement on the current stack diagram

Does that make sense?  The original three-stack diagram includes flow
arrows, which I interpret as indicative of execution flow, or execution
time relationships.  This is something different to me than an
architectural layering diagram that is meant to depict layers of
abstraction rather than execution time relationships.

Neither one can show everything, and neither probably can do the entire
job.  What I'd like to propose therefore is concentrating on the abstract
layering diagram initially, and then coming back to the three-stack diagram
in the context of how to represent the execution time relationships.


-----Original Message-----
From: Champion, Mike
Sent: Thursday, April 03, 2003 9:51 AM
To: www-ws-arch@w3.org
Subject: The stack diagram (was RE: Discussion topic for tomorrow's

> -----Original Message-----
> From: Hugo Haas [mailto:hugo@w3.org]
> Sent: Wednesday, April 02, 2003 10:33 AM
> To: Newcomer, Eric
> Cc: Jeckle, Mario; www-ws-arch@w3.org
> Subject: Re: Discussion topic for tomorrow's call
> * Newcomer, Eric <Eric.Newcomer@iona.com> [2003-04-02 10:01-0500]
> > Regarding security, it was positioned as an "orthogonal"
> (maybe not exactly the right term) concept, meaning it
> applies to all layers, as does management.
> >
> > I am not sure it is helpful to additionally list it in any
> of the layers since the right hand security box is intended
> to imply that security applies to all layers.  This would
> have to be explained in accompanying text.

We had a "3 stack"  diagram in an earlier version of the WSA document:
http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/3Stack.gif that I
provides a better visual framework than what we are talking about here.
http://lists.w3.org/Archives/Public/www-ws-arch/2003Apr/0002.html  I agree
with the comments about security and management being orthogonal, but I
the way the old diagram strung messaging, description, etc. horizontally.

I also like the suggestion that the XML Base Technology be a "backplane" or
"foundation" (depending on how we draw the diagram) behind or under

I'll see if I can somehow render my thoughts ...

Anyway, for the telcon today, it would be very good if people who want to
propose a picture have one prepared and on the web (or in the archive, of
course) so that they can paste the URL into IRC so that we can look at them
in real time.
Received on Friday, 4 April 2003 10:59:16 UTC

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