OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

asap message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [asap] from the OMA TP meeting in London, UK

Title: 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.


-----Original Message-----
From: Michael Shenfield [mailto:mshenfield@rim.net]
Sent: Tuesday, November 11, 2003 11:48 AM
To: Jeffrey Ricker
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 :)



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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]