RE: webservices stack

Hi,

	Putting in a six stack as Colin has done makes sense. The ibm-ms-framework
(img2) still does not solve how "common" services like security can be
expressed. It puts security at the wire level, but security has to extend
beyond the wire and into description and discovery.

	Also the ibm-ms-framework (img2) is a road-map which is different from
technology stack. Just because it is Microsoft's roadmap does not make it a
technology stack :-( I am not saying the diagram has no value, the diagram
explains a lot and is a good (if not excellent) abstraction.

	I have attached my view of this stack. WOuld appreciate comments.

	Another important point missing from the ibm-ms-framework (img2) is the
workflow/orchestration piece, choreography piece and even the trx across
boundaries. Routing is not exactly workflow or orchestration. We haven't
even understood dynamic choreography !

	IMHO, the SOAP routing protocol is not where routing should be. It might be
an example but not a good example. I think it is too anemic and is missing a
lot of pieces. ebXML TRP has better support for routing, still has a lot far
to go.

	Henrick is right. The actual transport is all of these is TCP and possibly
UDP. Everything else is application protocol.

	just my 2c

cheers

|-----Original Message-----
|From: www-ws-request@w3.org [mailto:www-ws-request@w3.org]On Behalf Of
|Henrik Frystyk Nielsen
|Sent: Sunday, June 24, 2001 1:32 PM
|To: Colin Adam; www-ws@w3.org
|Subject: RE: webservices stack
|
|
|
|Putting the whole thing into a single stack seems somewhat confusing and
|tends to cause problems representing features that span multiple
|"layers" like security, QoS, etc.
|
|Another way is to separate the concepts into groups that can interact in
|various manners.  I don't know if you have seen the "three stack
|diagram" which was also presented at the WS [1][2] but that is an
|example of how this can be done.
|
|A more specific comment on your layering: HTTP and friends are not
|transports - they are application layer protocols that define some
|services. SOAP is just a really simple application layer protocol that
|defines a really simple application (the SOAP processing model) at the
|core and relies on extensions for adding various services. SOAP Routing
|Protocol is an example of how routing functionality can be added to SOAP
|[3].
|
|Henrik Frystyk Nielsen
|mailto:henrikn@microsoft.com
|
|[1] http://www.w3.org/2001/04/wsws-proceedings/ibm-ms-framework/img2.htm
|[2]
|http://www.w3.org/2001/04/wsws-proceedings/ibm-ms-framework/framework.pp
|t
|[3] http://www.gotdotnet.com/team/xml_wsspecs/soap-rp/default.html
|
|>I have been trying to put together a webservices stack, mainly
|>using as a template the "stack" (as reported by james snell at
|>IBM developerworks) which came out of the W3C webservices workshop.
|>
|>It reads
|>
|>1. internet - IPv4 Ipv6
|>2. transport - http etc
|>3. messaging - soap, xml protocol
|>4. routing reliability transactions  ???
|>5. workflow, discovery, registries - UDDI ebXML registry,
|>WSFL, XLANG 6. service negotiation - trading partner agreements
|
|