Re: Straw-man Proposal for our mission statement

Jean-Jacques Dubray wrote:

>I don't understand your argument, why won't you get everything for free
>as long as you have a binding to WSDL whether it is direct or let's say
>indirect for the lack of a better word. The advantage of the later is
>that in addition of getting everything the ws-arch has to offer, you can
>also re-use the formalism of ws-chor for other technologies.
>  
>
I just don't see those other technologies as being interesting that's 
all. My personal opinion. In a W3C working group I would prefer to pick 
all the relevant technologies that the W3C maps out as interesting as 
part of the WSA. So far I've only heard of WSDL. If it boils down to one 
technology and that makes my life easier, all the better. What other 
technologies do you suggest we look into?

>Having a "binding" framework that relates ws-chor to WSDL garanties that
>the design of ws-chor is now decoupled from the evolution of WSDL, we
>would only change the binding not the core choreography language.
>
>We can clearly see the limitations of a tight coupling between BPML or
>BPEL and web services, now that WSDL is shifting from operations to
>MEPs, one has to adjust the corresponding specs.
>
Here is how I understand it. Correct me if I'm wrong.

Option 1: based on WSDL

Can't use other technologies. Need to be updated when WSDL gets updated.

Option 2: abstacted with binding to WSDL

Can use other technologies. Needs to be updated when WSDL gets updated. 
Extra level of indirection.

I think it's obvious why I would prefer no#1, but just for the sake of 
being verbose.

Either way if I use some normative specification and that specification 
evolves I would want to use the new version, be it WSDL, XSDL, XPath, 
whatever. So either way we need to update the specification. It may 
affect language section 4 or it may affect binding appendix A, but 
that's all the same. I don't see a real big differentiaor between 1 and 
2 to suggest one is better than the other. And as you guess I've already 
planned for it so I know what it entails and it doesn't seem like a big 
issue to me.

Option 2 is simply more complicated to support and require invention of 
an abstract layer and invention of a binding layer which makes the 
specification, implementations, interoperability, RI, etc more 
complicated. That's good if it actually buys you anything. What does it 
buy you?

I've heard before the argument that if we only wrote the spec to not so 
directly rely on WSDL we could also use IDL. Well, by the time we go to 
finish the spec the problem was already taken care of and you have 
IDL-WSDL mapping that's well defined and readily available. It was in my 
opinion - then and now - a waste of time to consider anything other than 
WSDL.

We've talked about simplifying the language which as I read it means do 
less features now, do the rest later on. I'm going to buy a hat. If 
we're going to have to change the specification because using WSDL is no 
longer the only interesting option before we get around to writing a new 
version of the specification anyway, I'm going to eat it. Wish me luck ;-)

arkin

>
>Jean-Jacques Dubray____________________
>Chief Architect
>Eigner  Precision Lifecycle Management
>200 Fifth Avenue
>Waltham, MA 02451
>781-472-6317
>jjd@eigner.com
>www.eigner.com 
>  
>

Received on Tuesday, 13 May 2003 00:32:13 UTC