RE: webservices stack

Hi,

The layers seem to overlap quite a bit, or my terminology around the word
'process' is not quite as nuanced as yours seems to be.

What is the exact division of responsibility between the Process Message
Layer, the Business Process Layer and the Inter-Process Layer? The
multi-partner capability also seems like a feature of a layer rather than a
layer all by itself. Perhaps if you could annotate with a concrete example,
it would make the stack come to life.

I would think that transactions in this world would focus on
compensation/delayed compensation rather than coordinated transactions ala
XA?

I agree with you on SOAP-RP. It somehow seems (borrowing from RIP and OSPF)
that there are other areas for routing to focus on as well.

Best,

--amit

-----Original Message-----
From: www-ws-request@w3.org [mailto:www-ws-request@w3.org]On Behalf Of
Krishna Sankar
Sent: Sunday, June 24, 2001 5:55 PM
To: Henrik Frystyk Nielsen; Colin Adam; www-ws@w3.org
Subject: 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
|
|

Received on Sunday, 24 June 2001 22:27:50 UTC