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

["Eckenfels. Bernd" <B.Eckenfels@seeburger.de>]

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.

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.

> 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.

Greetings
Bernd