Re: [wsbpel] implicite links of the runtime engine (was: Implicit<sequence> macro)

[Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>]

Title:

David RR Webber - XML ebusiness wrote:
> Bernd,
>
> Excellent insightful comments - the difference between theory and practice
> is vital to how OASIS delivers specifications.
>
> Thanks, DW.
> ================================================================
> Message text written by "Eckenfels. Bernd"
> > Hello Assaf,
> >   
> > But models fall short 
> > in one respect -- they don't provide you with sufficient constraints to 
> > get any level of interoperability. We might as well exchange UML 
> > diagrams -- our tools would represent the same process definition but 
> > there's no way we could get our products to talk to each other.
> >   
> This gets us back to the usacase and requirements discussion. 
>
> Personally I have chosen BPEL4WS as a blueprint for a runtime engine, cause
> I had the feeling it was (compared to BPML) the more advanced technical
> language for a process engine. However, interoperability was not a main
> concern.
>
> I simply do not expect much exchnage of executable process descrptions
> between tools of different vendors. There could be some flow from modelling
> tools to runtime engines (across vendors), but I think this greatly depends
> on the additional features a vendor may require, and the degree of support
> or the specific WSDL bindings.
If you look at initiatives like Siebel's UAN, as well as various vertical
industry organisations, there is a definite use case involving portability
of (executable) process definitions. This is independent of modelling tools,
as you point out.
> However, I see a lot of potential interoperability on the abstract process
> level. Here BPEL must be compared to other WS choregrphy solutions, and
> even BPSS.
This is a good point. My initial reaction to the abstract BPEL is that it
isn't expressive enough, especially when compared to BPSS. We need to substantiate
the purpose of abstract BPEL, by establishing the "interesting" or "defining"
use cases to be supported. 

Also, we have the W3C WS-Choreography working group with whom we should cooperate.
Perhaps they can take on the higher-level business protocol (a la BPSS),
with a mapping to lower-level constructs (BPEL)?
> > Deciding to use WSDL is not a good constraint for a model, but it's a 
> > perfect constraint for a language that deals with interoperability of 
> > Web services.
> >   
> +1
>
> Yes this is true for a sufficient open definition of WebService. I
> definitely need support for B2B Messaging, which has no (well defined) WSDL
> binding yet, which is actually not even expressed in WSDL. Our engine for
> example is able to invoke
> ejb session beans or scriptlets as activities in the bpel process. We use
> WSDL to describe the signature of those functions, but we do not use the
> heavy weigt XML communication to access those activities. It shows, that
> WSDL is perfectly able to describe those kind of bindings, but I doubt that
> it is very interoperable.
I have found it useful to distinguish between abstract WSDL (portType etc)
and concrete WSDL (service, port etc.). The messaging model presented by
"abstract WSDL" is quite useful, although too simplistic for B2B messaging.
However, a lot of B2B protocol issues can be regarded as plumbing problems...

Best regards,
-Ron