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

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

Keith,

Thanks 
for a summary (see my comments added below) and clarification of your POV. I 
think we should emphasize words "Access Protocol" in ASAP name to make a 
distinction with others. Given the charter and current direction of the group 
the main target is to define AP (workflow) rather than deal with asynchronous 
web service concepts. It's a valid task and doesn't overlap with other specs. As 
for the F2F, judging by the responses it doesn't look like we have a 
date/place that everyone can agree on. Probably at this time we should just 
continue teleconferencing. Unfortunately, I won't be able to make the next one 
(on Tue 11/18) as I am away at the client site.

Cheers,

 

 

Mike

-----Original 
Message-----
From: Keith Swenson 
[mailto:]
Sent: November 12, 2003 7: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.
[Michael 
  Shenfield] As far as I understand WSRM is about defining the protocol for 
  ensuring message ordering (MO) and guaranteed delivery 
  (GD) 

  
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.)
[Michael Shenfield] As far as I understand CAF is about 
  building multi-service composite apps or composite/aggregated web services. I 
  would expect the transactional aspect to be an important topic but not the 
  only one. 

  
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.