RE: Mapping Specs to the Architecture

I would have to concur with DO here. I think that performing this mapping is not in our scope, and puts us into the troutpond of choosing winners and losers and having to actively be comparing and contrasting all the specs which swirl about in this space. I think this work is better served by our respective corporate product stategists and the slew of techno journalists. I would be more comfortable with the focusing on exlplicitly describing the properties of the WS/SOA architecture and describing its functional converage using well-known methods and notation, such as UML. I would not like to see Frank's diagram polluted and potentially distorted by mapping to existing specs. I think our valued role is to demonstrate to the community the architectural components including their inter-relationships, roles and responsibilities. I think finding additional specification gaps in the architectural landscape will not be hindered by proceeding down the path of our primary deliverable - the Arch document.
 
Mike

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On Behalf Of ext David Orchard
Sent: March 11, 2003 01:50 PM
To: 'Ugo Corda'; 'Cutler, Roger (RogerCutler)'; www-ws-arch@w3.org
Subject: RE: Mapping Specs to the Architecture


So I mentioned one "proactive" area in the f2f.  It was arrived at by the systematic approach of comparing REST vs SOA architectural styles, and seeing which properties had been potentially lowered using SOA.  I then proposed this area, and I got some positive feedback and frankly some negative feedback.  In some circles, it was classified as a "trout pond", and I was actually surprised it didn't spawn (so to trout-speak) more discussion.  BTW, the area was how to do caching of SOA responses for higher network perf.  I don't really know how to proceed with this.
 
I think a very relevent question to ask wrt mapping specs to architectureis: are we documenting functional areas, specifications that fit these areas, or both?  For example: imagine we want to talk about transaction context propagation.  Shall we talk only about ws-transaction and ws-coordination, or shall we also talk about btp?  For choreography, shall we talk about bpel4ws, wsci, wscl, bpss, bpml, bpmi, various research projects?
 
If standards process to date can be my guide, we will end having an inclusive, rather than exclusive list.  The "stds" body won't want to make the hard choice of picking winning specifications.  Which means, to be blunt, my company isn't too terribly interested.  We have made our bets on which things will "win".  Why would we want to be part of an effort that legitimizes things that we don't believe in?  Of course, other companies have made different bets and have the same concerns that we have wrt their choices.  Or will we try to slice and dice, and offer each "constellation" of specs?  Companies A, B, C believe in XYZ specs.  Companies D,E,F believe in 123 specs.  hmmmmm, the mind boggles as to how or why this would be useful to external companies or developers.
 
Cheers,
Dave

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On Behalf Of Ugo Corda
Sent: Monday, March 10, 2003 7:24 PM
To: Cutler, Roger (RogerCutler); www-ws-arch@w3.org
Subject: RE: Mapping Specs to the Architecture


I think we did some type of informal work in this area when thinking about which new W3C WGs we could spawn as a result of our investigations. That way we first started talking about security, then orchestration, and finally reliability. Our process has not been very systematic so far, but more based on some of the most urgent and obvious current needs.
 
I agree that a more systematic process could pull up areas that the industry has not being chatting about yet. The risk, of course, is going too much ahead of the industry's currently expressed needs and spending efforts on areas that could be found to be too specialized and niche-related, of low current relevance, etc. 
 
I have the impression that many people in the industry are starting to get the idea that Web services consist of a never ending sequence of new identified technology areas and associated standards (not yet available) and wonder whether Web services will ever be in their grasp. I find myself wondering many times how far standards organizations are from having WS covered. In order to get an at least approximate answer to that question we might need a more systematic exploratory work.
 
Ugo

-----Original Message-----
From: Cutler, Roger (RogerCutler) [mailto:RogerCutler@chevrontexaco.com]
Sent: Monday, March 10, 2003 11:13 AM
To: www-ws-arch@w3.org
Subject: Mapping Specs to the Architecture



I had a chat with TimBL about the WS Arch work in which he asked a very interesting question.  He wanted to know whether we were producing a diagram that would make clear what parts of the architecture currently have specs in place, what parts have specs in progress and what parts need specs but there is nothing in sight.  I don't think that this kind of thing is explicitly a part of our requirements, and in fact I think that we have not thought too much about this particular audience -- the people that launch or coordinate the spec efforts as opposed to the spec writers themselves -- but I think that the expectation is a pretty reasonable one.

I made some really dumb response like, "Gee, got me.  I suspect that it's a little early to see results like that but we may be doing things that could go in that direction".  But now I wonder -- could specs be mapped onto the spaghetti diagram that we have been working on?  If not, does that indicate that some other view is needed?  It seems to me that some specs go onto that diagram pretty naturally, but that some involved with the "ilities" might not.  Or perhaps that is just because the diagram is incomplete??