- From: Todd Wolff <twolff@bluestemsoftware.com>
- Date: Thu, 30 Mar 2006 14:08:58 -0600
- To: <public-ws-addressing-comments@w3.org>
- Message-ID: <000801c65435$c96fe030$6601a8c0@LatitudeD500>
Kudos to the committee for at long last standardizing asynchronous messaging over a synchronous protocol, i.e. HTTP. This 'last minute' addition will perhaps do more to simplify the architecture of web services based applications than anything else you have contributed. Nice job. One observation, and please forgive me if this has already been addressed within the discussions following the release of the latest working draft. It would appear that by adding an extension element to an existing binding rather than creating a new binding type, the choice of whether to send a request synchronously or asynchronously, i.e. assuming Anonymous is optional, will be impossible to make within the 'application layer.' Using BPEL4WS as an example, an application, i.e. a process in this case, indicates binding selection implicitly via endpoint assignment. Unless I am missing something, how would a process designer choose to invoke an in-out operation synchronously rather than asynchronously, and vice versa, if the service invoked has only one endpoint, i.e. a SOAP/HTTP endpoint? BTW, assuming this is a valid problem, I understand that creating a new binding type is not trivial and may not be an option at this stage in the game. If that's the case, I would MUCH rather keep the existing solution as-is rather than remove it altogether. It is a HUGE improvement over the current mess, i.e. request response using two one way operations. Todd Wolff Bluestem Software LLC
Received on Thursday, 30 March 2006 23:52:16 UTC