LiveCycle ES incorporates many of the concepts made popular by WS-BPEL (Web Services - Business Process Execution Language). These include the idea of a "service orchestration". A service orchestration is a group of services that are chained together to act as though it itself is a service with its own WSDL. Some people make the argument that the right term should be "choreography", since an orchestra needs a conductor and a (dance) choreography does not.
LiveCycle supports both short-lived and long-lived orchestrations. Long-lived orchestrations typically involve human actors while short-lived ones don't. BPEL does not support the concept of human actors. Therefore, the BPEL4People extension to BPEL was proposed. Adobe is involved with this standard.
Architects of applications built on LiveCycle ES need to note that short-lived orchestrations have a performance overhead when compared against a client application making direct API calls to individual LiveCycle services. In most cases, this is about 20%.
If you are invoking just one service within LiveCycle (render a PDF form), direct API calls have the performance advantage. However, if you need to invoke several LiveCycle services, the convenience and simplicity of orchestrations trump that performance advantage.
Leave a comment