- 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
+1. Bundling everything in one diagram is confusing. We should also definitely have separate diagram(s) for execution flow. --Katia -----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 call) 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. Eric -----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 call) 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" kreger@us.ibm.com 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>, <www-ws-arch@w3.org> cc: Subject: RE: The stack diagram (was RE: Discussion topic for tomorrow's call) Mike, 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 proposal. 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. Eric -----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 call) > -----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 think 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 like 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 everything. 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