7 Replies Latest reply on Sep 8, 2009 7:13 AM by objectiser

    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

        • 1. Re: Process versioning and web service endpoints
          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.


          • 2. Re: Process versioning and web service endpoints
            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
            


            • 3. Re: Process versioning and web service endpoints
              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?

              • 4. Re: Process versioning and web service endpoints
                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.

                • 5. Re: Process versioning and web service endpoints
                  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.



                  • 6. Re: Process versioning and web service endpoints
                    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) ?

                    • 7. Re: Process versioning and web service endpoints
                      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.