Title: Message
Eric:
more comments below...
primer:
p11: a Web Service is identified ... on the header...
-> in the header of what ? every message that his this service, in an
initialization message?
>> In the simplest case,
where the composite Web services take responsibility for managing their own
context, it would be every message in an interaction. Meaning that the
appearance of the context URI in the header of the message indicates that
the Web service requester is asking the Web service receiver to participate
in the same composite application, by definition sharing the same
context.
[<JJ>] I see, let me try to re-phrase this in my
own words to see if I hear you correctly. You are in effect
suggesting to "externalize" or otherwise "separate" the notion of
application (and therefore application state) from the services. You
basically attach the "application state" to the request, such that when a
service receives a request, it first look at the context and says, for this
request, I am working for this "application" and here is what I am supposed
to do. I like that idea a lot. That would in effect favor the re-use of web
services across a lot of different application types and helpthe web
services designer/implementer to make them far more generic (otherwise I can
really see this kind of logic being embedded within the web service
itself).
primer and ws-cf:
I
am trying to establish a distinction between coordination and composite apps
and I am having difficulty. It seems that a coordinator is both a part of a
composite app (providing its services to the CA), and managing several
CAs.
>> The main difference a
coordinator brings is that it provides a software agent to manage context on
behalf of the Web services participating in a composite application.
In this case, instead of simply sharing context, Web services also register
themselves with the coordinator so that the coordinator can take care of
quality of service items such as persisting the context, ensuring every Web
service in the composite has a consistent view of the context, and that the
coordinator can also drive additional protocols across the participants that
register (such as transactional protocols).
[<JJ>] Again, to see
if I hear you correctly, the coordinator really manages one application type
(therefore is part of the CA definition), but of course can deal
with many application "instances" at the same time. Of course
coordinators (and therefore applications types can be composed). I am not
sure that what I am saying here is correct when I look at figure 3 of the
primer in details. I don't know if you would have some time to explain this
figure in detail.
What is the relationship between coordination and orchestration?
(participants, activities, coordination points, ...). Is coordination a
special form of orchestration?
>> Coordination plays a
supporting role to orchestration, managing context where system and/or
persistent data needs to be shared among serviecs in the composite, and
recovery protocols in the case of failure handling during the execution of
an orchestration flow.
[<JJ>] Yes, I can see that,
thanks.
Cheers,
Jean-Jacques
tel: 425-649-6584
Cell:
508-333-7634
-----Original Message-----
From: Newcomer,
Eric [mailto:]
Sent: Friday, October 31,
2003 9:06 AM
To: ws-caf
Subject: [ws-caf] Document
submission
Dear WS-CAF TC
Members,
On behalf of
the companies sponsoring the WS-CAF collaborative effort, Arjuna
Technologies, Fujitsu Software, IONA Technologies, Oracle Corporation, and
Sun Microsystems, I am very pleased to submit the WS-CAF set of
specifications (WS-Context, WS-Coordination Framework, and WS-Transaction
Management, along with the Primer) to OASIS under royalty free terms and
conditions.
The WS-CAF
companies listed above are the authors and copyright holders of these
specifications, which from this point forward will be under control of the
OASIS WS-CAF Technical Comittee. The purpose of submitting these
specifications is to allow them to be progressed toward OASIS standards by
the TC.
Regards,
Eric
Newcomer
IONA
Technologies
