1 Reply Latest reply on Apr 11, 2013 12:44 PM by dward

    Best Practices for using JBPM as Service Orchestration component with SwitchYard - Process Variables?

    jeffdelong

      One of the challenges with Service Orchestration is the typically the services being orchestrated have distinct data requirements. With BPEL orchestrating Web services, an Assign Activity is used to define a set of Copy statements (which use XPATH) that each individually map some part of one message into another message (using BPEL variables to hold the message data).

       

      jBPM has not in-built capability to map or transform process variables, however, so in trying to orchestrate services using jBPM alternate mechanisms must be engaged. SwitchYard does of course provide excellent transformation capabilities, so one approach is to maintain a "canoical" representation of the data in jBPM and then create a set of SY services that sit between the BPM Component and the end service whose sole function is to transform the data from the canonical form into the service specific form.

       

      The next question then is what should be the format of the canonical data, XML or Java object. Assume the services have a mix of Java interfaces and WSDL interfaces, one approach is to keep the canonical data in jBPM process variable as a String representation of XML, and transform to Java services using JAXB or Smooks and to other XML using XSLT.

       

      Or keep the canonical representation in jBPM as a custom Java object, and then transform to XML using JAXB or Freemarker Template with Smooks, and Java using ?

        • 1. Re: Best Practices for using JBPM as Service Orchestration component with SwitchYard - Process Variables?
          dward

          I don't think there's a one-size-fits-all answer to this.

           

          If orchestration is being done where most of the endpoints expect XML/SOAP, then perhaps the canonical domain object should be an XML string.  However, in cases where most of the endpoints are bean services (or anything else expecting java objects, like perhaps JMS endpoints), then perhaps the canonical domain object should be a java object.

           

          I guess the things to consider would be:

          1. maintainability
            • of the canonical model itself
            • with regard to adaptability/aligment with (most?) of the collaborating endpoint interfaces
            • forwards/backwards compatibility, and versioning
          2. performance
            • what is in-memory vs. what crosses process/network borders?
            • expense of any possible serialization/deserialization points
            • expense of querying/walking xml (xpath) graph vs. java object graph
            • expense of any possible transformation points

           

          These thoughts are just my gut-reaction to the question...