Re: Straw-man Proposal for our mission statement

I agree with this as well. I'm not against using WSDL - I'm against tying
this set of choreography specifications to WSDL as a normative and
exclusive target.


Regards,

D-


*************************************************
Dr. Daniel Austin
Sr. Technical Architect / Architecture Team Lead
daniel_austin@notes.grainger.com <----- Note change!
847 793 5044
Visit http://www.grainger.com

"If I get a little money, I buy books. If there is anything left over, I
buy clothing and food."
-Erasmus


                                                                                                                                 
                      Steve Ross-Talbot                                                                                          
                      <steve@enigmatec.        To:       "Jean-Jacques Dubray" <jjd@eigner.com>                                  
                      net>                     cc:       "'Yaron Y. Goland'" <ygoland@bea.com>, "'Assaf Arkin'"                  
                                                <arkin@intalio.com>, "'Burdett, David'" <david.burdett@commerceone.com>,         
                      05/29/2003 12:07          <Daniel_Austin@grainger.com>, <public-ws-chor@w3.org>                            
                      PM                       Subject:  Re: Straw-man Proposal for our mission statement                        
                                                                                                                                 
                                                                                                                                 




+1 from me too.

Steve T

On Wednesday, May 28, 2003, at 07:27  am, Jean-Jacques Dubray wrote:

>
> +1
>
> Jean-Jacques
>
>
>
>>> -----Original Message-----
>>> From: Yaron Y. Goland [mailto:ygoland@bea.com]
>>> Sent: Dienstag, 27. Mai 2003 21:12
>>> To: Jean-Jacques Dubray; 'Assaf Arkin'
>>> Cc: 'Burdett, David'; Daniel_Austin@grainger.com;
> public-ws-chor@w3.org
>>> Subject: RE: Straw-man Proposal for our mission statement
>>>
>>> Based on this thread I would like to put forward a proposal to the
> group
>>> for
>>> a set of requirements that I hope can bring this thread to a
> successful
>>> conclusion:
>>>
>>> "The WS-Chor specification MUST NOT adopt a design that prevents it
> from
>>> taking full advantage of all features in WSDL 1.2. The WS-Chor
>>> specification
>>> MAY adopt a design that enables the use of alternative message
> description
>>> than WSDL 1.2 where and when the working group decides this is
> appropriate
>>> and does not conflict with any other requirements."
>>>
>>> I would then propose that we table this issue until we finish with
>>> the
>>> requirements and start doing design so we can look at exactly what an
>>> abstract design would require and then decide if we want to try it.
>>>
>>>                      Yaron
>>>
>>>> -----Original Message-----
>>>> From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
>>>> Sent: Wednesday, May 21, 2003 1:16 PM
>>>> To: 'Yaron Y. Goland'; 'Assaf Arkin'; 'Jean-Jacques Dubray'
>>>> Cc: 'Burdett, David'; Daniel_Austin@grainger.com;
> public-ws-chor@w3.org
>>>> Subject: RE: Straw-man Proposal for our mission statement
>>>>
>>>>
>>>> The cost of abstraction is way overestimated here. The abstraction
> is
>>>> already built, it is called a message and a message exchange
> pattern.
>>>> Now we have the choice to directly use the WSDL message definition
> or
>>>> rather define something like:
>>>>
>>>> <message name="ProcessPO">
>>>> <message name="AckPO>
>>>> <mep name="ProcessPO">
>>>>
>>>> <binding message="ProcessPO" type="WSDL" version="1.2">
>>>>                     <portType="">
>>>> </binding>
>>>> <binding MEP="ProcessPO" type="ebXML" version="2.0>
>>>>         <BPSS
>>>> URI=http://oasis.org/bunchOfStandardsCollabs/aPOCollaboration">
>>>>         <businessTransactionActivity name="ProcessPO>
>>>> </binding>
>>>> <binding message="AckPO" type="PlainOldFax" >
>>>>         <fax number="555-1234"/>
>>>> </binding>
>>>>
>>>> so please, let's reasonable on our assertions.
>>>>
>>>> I am currently on travel in beautiful Berlin, with limited email and
> web
>>>> access. So I will respond more thoroughly to the emails this
> week-end.
>>>>
>>>> Cheers,
>>>>
>>>> JJ-
>>>>
>>>>
>>>>>> -----Original Message-----
>>>>>> From: Yaron Y. Goland [mailto:ygoland@bea.com]
>>>>>> Sent: Montag, 19. Mai 2003 18:50
>>>>>> To: Assaf Arkin; Jean-Jacques Dubray
>>>>>> Cc: 'Burdett, David'; Daniel_Austin@grainger.com;
>>>> public-ws-chor@w3.org
>>>>>> Subject: RE: Straw-man Proposal for our mission statement
>>>>>>
>>>>>> +1 on tying to WSDL and +1 on Asaf's point that there is a cost to
>>>>>> abstraction. The only way to 'abstract' away dependency on
> something
>>>> is to
>>>>>> completely re-invent the thing being depended on and then define
> how
>>>> your
>>>>>> re-invention maps to the original. This is an extremely expensive
>>>> process
>>>>>> that causes significant harm to interoperability and should only
> be
>>>>>> undertaken when there is no other choice. The 'abstractions'
>>>> introduced
>>>>>> between WSDL and SOAP have caused so much interoperability pain
> that
>>>> two
>>>>>> different organizations had to be formed to sort out the resulting
>>>> mess.
>>>>>> What we need is a little less abstraction and a lot more
>>>> interoperability.
>>>>>>
>>>>>>                         Yaron
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: public-ws-chor-request@w3.org
>>>>>>> [mailto:public-ws-chor-request@w3.org]On Behalf Of Assaf Arkin
>>>>>>> Sent: Monday, May 12, 2003 9:30 PM
>>>>>>> To: Jean-Jacques Dubray
>>>>>>> Cc: 'Burdett, David'; Daniel_Austin@grainger.com;
>>>> public-ws-chor@w3.org
>>>>>>> Subject: 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
>
> This email is confidential and may be protected by legal privilege. If
> you are not the intended recipient,  please do not copy or disclose
> its content but  delete the email and contact the sender immediately.
> Whilst we run antivirus software on all internet emails we are not
> liable for any loss or damage. The recipient is advised to run their
> own antivirus software.
>

This email is confidential and may be protected by legal privilege. If you
are not the intended recipient,  please do not copy or disclose its content
but  delete the email and contact the sender immediately. Whilst we run
antivirus software on all internet emails we are not liable for any loss or
damage. The recipient is advised to run their own antivirus software.

Received on Thursday, 29 May 2003 15:22:39 UTC