Assembly, Composition or Orchestration

This podcast from David Chappell tries tries to address a though question: what is SCA? What makes this challenging is that the terms assembly, composition and orchestration are abstract concepts which do not really have clear boundaries in peoples minds.

So what is the difference between orchestration and assembly?!?

Orchestration defines a set of steps/activities which represent a business process (step 1: verify the user account, step 2: verify inventory, step 3: process credit card, step 4: send email to the user). Some of these steps can be performed sequentially, some of them in parallel, exceptions can occur, manual intervention might be required, etc… Some orchestrations can be simple, some can be very sophisticated. Orchestrations are modeled using a standard language called BPEL. [ (Updated based on the comment from Greg Pavlik) Note: Orchestration logic is not usually captured in one monolitic business process. It can include subprocess steps (which can be distributed physically across the enterprise or across enterprises). The process itself or some of it steps can be implemented in Java or C.]

But what is assembly then?

As part of step 1, the BPEL process needs to integrate with an LDAP service. As part of step 2, the BPEL process need to integrate with an SAP system. As part of exception processing, it needs to integrate with a workflow sub-system. These integration points (links between BPEL processes and external systems) are called bindings. Bindings usually include location of the different services, protocols to use, security, logging and reliability requirements. The SCA Assembly spec defines a language for modeling these bindings.

[(Updated based on the comment from Greg Pavlik) Note: In the case where a process include subprocess or other component written in a variety of languages, the binding problem extends beyond linking to external systems to the need for linking to internal parts.]

The benefit of SCA is that is makes bindings much easier to monitor, manage and change – not super sexy but the potential for a significant step forward in terms of deployment and change management.

Author: @feedly

Read more. Know more.

5 thoughts on “Assembly, Composition or Orchestration”

  1. I like the way you are clarifying things here: very straightforward and simple description of terms and concepts.

    I think there is an intermediate form of composition supported by SCA that often causes some confusion. A composite service can contain multiple components, each (potentially) implemented with different technologies. For example, one might have a composite that includes both a BPEL process and Java class. When people first encounter this, they often ask “is this a replacement for BPEL?”.

    The answer is “of course not”: SCA itself provides no mechanism for control flow, for state management, asynchronous message correlation, etc. Packaging different technologies together within the composite is a good practice only when they are complementary parts of a single service or business function.

    The simple model is the best: an orchestration is packaged in a composite and leverages the binding capabilities to exchange messages with the outside world. In other words, this step provides sufficient definition to create a runnable service. It doesn’t add any semantics to the service itself.

  2. Another easy way to explain SCA concepts to an system analyst may involve an old SA term: Data Flow Diagram.

    SCA Composite tells how data / event / message flows from one component to another. And, the recursive version of composite fits into multi-level Data Flow Diagram quite nicely as well.

Comments are closed.