Re: Straw-man Proposal for our mission statement

Burdett, David wrote:

 > So if anyone has an opinion for or against WSDL, can you please clarify
 > whether you refer to the WSDL services, WSDL interfaces or WSDL whole.

I don't think anyone is actually arguing in favor of a direct binding at 
the service level. If I am defining a choreography, IMO it shouldn't 
matter to me if people are connecting to it via HTTP, JMS, etc. - in 
other words, I shouldn't care what the concrete WSDL is. Ideally I'd 
like to be able to define the role in terms of abstract WSDL. I've heard 
several people express the idea that this role->WSDL binding should be 
at the level of a service type, assuming WSDL 1.2 re-introduces such a 
concept. (One of the difficulties in talking about the relation of WSDL 
to WS-Choreography is that WSDL 1.2 is a moving target).

Of course to execute a choreography you need concrete bindings, but that 
could be another layer.

--Jon


> I actually think that we should try and use WSDL interfaces, but we need to
> check that it does what we need it to do. The specific problem is the
> requirement for the WSDL interface to accept abstract message types, for
> example an order, without specifying exactly which format of an order it
> will accept as they can vary.
> 
> I suppose that really I need to do more work myself looking at the latest
> WSDL specs on this.
> 
> David
> 
> -----Original Message-----
> From: Assaf Arkin [mailto:arkin@intalio.com]
> Sent: Tuesday, May 13, 2003 2:52 AM
> To: Steve Ross-Talbot
> Cc: Jean-Jacques Dubray; 'Burdett, David'; Daniel_Austin@grainger.com;
> public-ws-chor@w3.org
> Subject: Re: Straw-man Proposal for our mission statement
> 
> 
> 
> Steve Ross-Talbot wrote:
> 
> 
>>I have made this WSDL non-WSDL a topic for discussion at the call 
>>later  today.
>>I'd like to get a summary of the views expressed so far ... any  
>>volunteers?
>>
>>Cheers
>>
>>Steve T
> 
> 
> Here's a list of what I've heard so far. I've tried my best to express 
> the view as briefly and broadly as possible, so people who support one 
> or more views can elaborate more. Listed from least to most likely to 
> focuse solely on WSDL:
> 
> 1. We need to define choreographies in abstract terms. Use of WSDL is an 
> implementation detail.
> 
> 2. We need to define abstract choreographies with bindings to multiple 
> technologies, including but not limited to WSDL.
> 
> 3. Using WSDL prevents us from supporting other specifications that 
> address RM, security, transactions, etc.
> 
> 4. You can't write a good choreography language using WSDL, but you can 
> bind a good choreography to WSDL.
> 
> 5. The interesting capabilities are already supported by WSDL and 
> specifications that extend WSDL.
> 
> 6. Being a W3C WG implies ...
> 
> Feel free to add, remove, expand, donate 2 cents, etc ...
> 
> 
> I want to add one request for clarification. I did that a few times 
> before, I hope a few people would be willing to take on it this time.
> 
> WSDL encapsulates two layers within the same specification that 
> personally I would have liked to see written as two different parts of 
> the same specification for better clarity (similar to the two parts in 
> XSDL and SOAP).
> 
> One layer deals with abstract service types as defined by their 
> interface implying what the service looks like but not any particular 
> service. The other layer deals with actual services as defined by their 
> end-points, protocol binding and the interface they support.
> 
> Someone may say "I don't like the specification to refer to WSDL 
> services" and someone else may say "I like the specification to refer to 
> WSDL interfaces". These two points of view are not contradictory in any 
> way. However they do become contradictory if we don't specify what part 
> of WSDL we refer to.
> 
> So if anyone has an opinion for or against WSDL, can you please clarify 
> whether you refer to the WSDL services, WSDL interfaces or WSDL whole. I 
> think that alone would bring a bit more agreement into the discussion.
> 
> arkin
> 
> 
>

Received on Tuesday, 13 May 2003 13:25:19 UTC