Process versioning and web service endpoints

[heiko.braun]

do have one endpint per deployed process version?
i.e. when a process version increments we get a new web context? how
is this going to relate to each other?

i.e. 'helloworl-516' -> http://localhost:8080/helloworld-516

[heiko.braun]

Gary said:

No the endpoint is defined in the wsdl for the service representing the BPEL process, so it will only change between versions if the user updates it.

Although anything is possible in the brave new world of JBossWS - but this would introduce the issue of how apps would locate the relevant endpoint - i.e. they would need to know which version they are supposed to use, and therefore which URL to use.

[heiko.braun]

well, the service URL in the WSDL file is replaced by JBossWS.
Are you saying that we should keep the webcontext+path info from the
WSDL
and simply replace the host information?

i.e.

<wsdl:service name="HelloService">
 <wsdl:port name="HelloPort" binding="tns:HelloSoapBinding">
 <soap:address location="http://foo.bar.com/bpel/processes/helloWorld
"/>
 </wsdl:port>
 </wsdl:service>

would turn into a real endpoint at

http://serverhost:port/bpel/processes/helloWorld

[heiko.braun]

Imagine this case:

New process version is deployed, old ones set to "RETIRED".
However running instances will not be terminated immediatly,
only creation of instances based on the old process definition is not
allowed.

Doesn't this mean we need two endpoints for the time old and new
version coexist?
Otherwise chances are that a new deployment (version increment)
deploys changes to
the endpoint (wsdl modifications) and existing client to the prior
version don't work anymore.

Makes sense?

[objectiser]

The problem with changing the endpoint URL for each process version is that (1) it may impact clients - i.e. they will need to understand which URL to use for which process instance, and (2) the WSDL interface may not have changed between versions.

Whereas using the URL in the WSDL enables the developer to decide when and how the service clients will be impacted by a URL change. They only need to make this decision when the WSDL is no longer backward compatible with existing process instances.

Although it leaves room for developer/admin error, this could be resolved using governance tooling to determine when such a URL change is necessary.

[heiko.braun]

I think this requires more investigation. There will be two versions of the same process running in parallel anyway (ODE's retire & expire semantics). However if that requires a different endpoint or not is still unclear.

Currently I can see two approaches:

a) leverage a single endpoint and use reference properties (i.e. WSA correlation)
b) create separate endpoints for each version

In case a) the correlation would be an additional one to the instance correlation ODE's already does. I need to verify if that implies version resolution, which it probably does.

In case b) the version becomes irrelevant and ODE simply needs to correlate the instance. In this case changes to the WSDL wouldn't have side effects on running instances.

At the end it's probably a matter of best practice. To me it makes complete sense to have new versions with separate endpoints in some cases, i.e. when the process reflects business derivations.

But if you simply fix problems within a process, and the semantics don't change, a separate endpoint becomes inconvenient.

[objectiser]

Agree - so at the moment the choice of when the endpoint should change needs to be a design decision, initially based on user decision, but could eventually be automated using tools that understand when a change is not backward compatible.

Not sure why the WSA correlation is required over and above the BPEL correlation in approach (a) ?

[objectiser]

Just did a test with ODE1.3.3 to test how it deals with endpoints on versioning.

When a BPEL process is updated to the next version, if its URL has changed then the old URL no longer functions - it is not retained for use by the older versions of the BPEL process.

So it looks like only the WSDL and associated WS service endpoint for the latest version of the BPEL process will be active.