Title: RE: [asap] from the OMA TP meeting in London, UK
Thanks guys for putting this together. It
really helps.
Gavenraj Sodhi,
MBA
Computer Associates
Product Manager, eTrust
Mobile: +1 949 350 8808
-----Original Message-----
From: Keith Swenson
[mailto:]
Sent: Wednesday,
November 12, 2003 4:34 PM
To: Michael Shenfield; Jeffrey
Ricker
Cc: ASAP
Subject: RE: [asap] from the OMA
TP meeting in London, UK
Michael, again, well done!
We must be very very clear about the distinction
between an asynchronous service, and other things that allow a service to be
accessed asynchronously. My fear is that the term
"asynchronous" is likely to be a greater problem than
"factory" was. Unfortunately, I can not think of a better
term. But to get the message out, we need to be very clear:
WSRM: this is about installing and managing web services.
There is no concept of opening up an interface for public use that would allow
a server to be started, and monitored later. WSRM gives a priveledged
access to the server. (I don't want the public installing software on my
server.) A Service Instace has nothing to do with installing software,
just like creating an object instance has nothing to do with installing
class. Somehow we need to make this clear.
WS-CAF: This is about transactional behavior when
multiple web services interact. We would expect to use WS-CAF in order to
start an Asynchronous service transactionally. (I am tickled to see that
IBM and Microsoft (at least some members) are planning to cooperate in this
effort. We would greatly welcome their input and cooperation at any
level.)
WSBPEL: This is about describing patterns of
interactions. Theoretically, ASAP could be described with BPEL, but the
whole point of ASAP is that systems can be linked without having to digest
BPEL. BPEL does not define the values of the "status" variable.
It does not proscribe that if an observer URL is registered, SOAP messages must
be sent to it when the status changes. If we decide not to proscribe
specific operations to call, and instead say any method can start a service,
and any mehod can return status, then we have to describe those calls, and we
do indeed run directly into the area being standardized by WS-BPEL. We
must avoid this.
WS-Reliability: your big company friends forgot this
one, and it is important. WS-Reliability is critical for asynchronous
messaging so that messages are assured to arrive. Again, an ASAP service
should use this for message reliability.
Part of the reason that I am so vehement about
sticking to the charter is that we must be careful not to overlap these
areas. Typically I have that opposition to ASAP comes from
two directions:
1. the "that is already being standardized"
crowd does not understand that ASAP is about a service that is started, and can
be contacted separately and multiple times before is it finished. It is
about a specific pattern of interaction that can be standardized to make
linkage between systems easy and reliable. The clarification message is
that it is the "service" which operates asynchronously, not the
messages. None of these standards is dealing with the definintion of the
properties of such a service.
2. the "that is not necessary" crowd
believes that a simpler solution is possible that will more flexible.
These people typically do not want to implement the overhead that is necessary,
or at least don't want to constraining choices. Flexibility is the enemy
of linkability, and standards are all about constraining choices. Simply
put, these people don't want to discuss a standard in this area, but they
should respect our desire to create one, and recognize that this is not an
overlap with existing efforts.
On the subject of face to face: I am happy to
host in San Jose. Another alternative is meet in Florida around the time
of the BPEL working group meeting there which is currently planned for Dec 9
& 10.
-Keith
-----Original Message-----
From: Michael Shenfield [mailto:]
Sent: Tuesday, November 11, 2003
11:48 AM
To: Jeffrey Ricker
Cc: ASAP
Subject: [asap] from the OMA TP
meeting in London, UK
or rather from the pub at Hilton Metropole where the
OMA (Open Mobile Alliance) TP is going on :)
This week I am attending OMA TP meetings in UK and
went for drinks and chat with MWS people from Microsoft and IBM. When
discussing async web services I mentioned OASIS ASAP and asked why they ignore
it. They replied that both companies are concerned that there are already 3
OASIS groups that refer to async services in the specs (WSRM, CAF, WSBPEL) and
as their specs are close to completion they're afraid that ASAP will either
reinvent the wheel or go in the opposite direction.
I think it is a very good point and we should first
carefully analyze all AWS related references in other OASIS specs before issuing
working draft or defining scope, etc. Typically this is done through liaison
reports or F2F meetings for review and discussion. Unless we go through this
exercise, I don't think we can count on wide adoption of ASAP given the small
size of the group and lack of participation from industry heavyweights. I
propose to have a F2F meeting (2 days) on the second week of December and
resolve the major issues. I can host the meeting in my Toronto office but would
prefer iWay to host it in NYC so I'll have a chance to meet my former IBI/iWay
peers :)
Cheers,
Mike
To unsubscribe from this mailing list (and be removed
from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/asap/members/leave_workgroup.php.
