OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [wsbpel] Issue - 77 - Under specified operation definitions

"Ugo Corda" <UCorda@SeeBeyond.com> writes:
> Fine, so the WSIF client would not be able to manipulate the "Header"
> abstract message in my example (in other words, WSIF behaves the same
> way BPEL does).
> As I pointed out before, other WS frameworks do not behave that way,
> and they allow users to directly manipulate the "Header" abstract
> message in my example (I know for sure because a customer of ours 
> brought us that type of example asking us to support it in BPEL).

You're right that this has nothing to do with WSIF.

> You might say that using WSDL 1.1 that way is a bad idea. I am not
> arguing with that. All I am saying is that it is perfectly legitimate
> to use it that way according to WSDL 1.1 (the spec actually explicitly
> calls out that case in sec. 3.7, when it says "The referenced message
> need not be the same as the message that defines the SOAP body").

I'd be the last person to say don't use WSDL .. :-). However, WSDL
suggest a certain separation of abstract behavior from binding-dependent
behavior. The point I'm making is that BPEL must *only* depend on
the abstract behavior of a Web service as defined by its portType and
not on anything else referred to in the bindings. That's the only
way to really enable the multiprotocol abstractions enabled by WSDL -
otherwise BPEL (or whoever is using WSDL) is intrinsically tied to
one binding ..

I don't think there's a way around this- BPEL can either adhere 
to the principles of WSDL or not. I would obviously recommend that
it absolutely adhere to them. If its going to, there's no way to
allow a BPEL process to access/manipulate any binding-dependent 
information as such information is simply not available until 
much later in the lifecycle of process authoring/deployment/execution.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]