BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
Most software architects are familiar with componentization, service-oriented architecture (SOA), and workflow or service bus processes and how composite application concepts unite these basic terms. There still may be some tricks in achieving the loose coupling and application agility that are primary goals for SOA and composite applications.
Business Process Execution Language (BPEL) can frame your entire composite application strategy if it's used correctly. To make BPEL composites work, don't use BPEL in too fine-grained a manner, don't write integration into components and don't think hierarchically when composite applications come to mind. To get this to work, it's important to start with concepts, then adopt an organized development methodology.
Business Process Execution Language concepts
A composite application is built from Web service components that are connected using standard interfaces. This property is well-understood, but a collateral property of composite applications, often missed, is just as critical.
A well-designed composite application can be treated as a Web service, a component, and used to build higher-level processes. This successive composition model can greatly ease composite/SOA development andapplication lifecycle management (ALM) burdens. It can also resolve the biggest BPEL challenge -- execution efficiency.
BPEL is well-known as a means of coupling coarse-grained elements, which means supporting business processes that don't involve a lot of workflow exchange. The deeper into component integration you go and the more workflow is managed, the harder it is to make BPEL performance-effective.
BPEL should start with enterprise architecture (EA) because of the course-grain requirement. Most SOA development focuses on a single-level composition of components and uses Web Services Description Language to define and discover component interfaces/functionality. BPEL is then used to describe how the components should be combined. Since BPEL is a process-level language, it's a good way of aligning IT components with business activities, which also lets BPEL flow from EA models.
There are two sure ways to kill BPEL benefits:
- Use BPEL to integrate even low-level application components, where component workflows are frequent and performance-critical.
- Write components explicitly linked with each other to hard-code the integration.
The issues arise from the difference between business-process granularity and software component granularity.
BPEL can frame your entire composite application strategy if it's used correctly.
Web services orchestrated with BPEL should be fairly course-grained to avoid generating incredible overhead in workflow processing and complexity in application orchestration and ALM. In many cases, this creates a conflict with software design, where componentization is encouraged at a lower level. To avoid this problem, remember that the general model of a BPEL service is one of an orchestration component that links to subordinate functional services.
It's possible to build orchestration components using a more execution-efficient technique, even by directly binding to components without further BPEL processing. In this way, multiple fine-grained software components can be converted into course-grained, BPEL-suitable services that are then workflow-processed to gain maximum flexibility.
This technique relies on the recursive or hierarchical nature of BPEL. As with other programming languages, BPEL can create services. This means it's possible to create reusable compositions of components defined in BPEL. Even if you elect to do full service-bus or workflow-engine integration at all levels of the hierarchy of BPEL services, there's a use for creating BPEL services from component groups because it insures related pieces are orchestrated and organized the same way regardless of where they are composed.
Experienced teams of application and enterprise architects can create optimized BPEL composites by taking the service/component analysis from both sides. From the top, EA defines the business-process alignments, particularly where formal federated IT plans exist. Since most business processes don't expect minute-to-minute operating coordination, this level of definition is a good starting point for course-grained processes that can be orchestrated using BPEL and a service bus.
Business Process Execution Language development
At the same time, application architects can review component availability and frame development plans for optimum componentization based on a combination of re-use goals and future flexibility and agility. This fine-grained componentization will nearly always be too fine-grained to map directly to BPEL service-bus integration.
Teams can then conference to define how a meet-in-the-middle can be accomplished. A good EA plan is essential for establishing the workflow between course-grained components. Application architects, knowing the component mapping to the course-grained BPEL services, can determine how component workflows within the BPEL services can be supported efficiently enough to sustain application performance -- anything from direct binding to BPEL-arbitrated workflow.
More on composite applications
Composite apps and middleware
SaaS, composite apps work together
Composite apps' business value
Remember, direct binding always reduces flexibility, but using an orchestration component rather than inter-component direct references will help; you only have one thing to change to recompose a workflow inside a BPEL service. Never directly reference one component from another.
This is the same point where it's possible to identify component groups that seem to move among BPEL-level services as a unit. Consider creating a higher-level BPEL service from these groups with that same notion of an orchestration component to bind the group together. BPEL will define the interfaces and properties of the group and hide the complexity from application developers who build from components down the line.
You can perform ALM integration with this process in any of the traditional ways. Where Federated IT definitions guided BPEL composite design at the high level, it may be easier to align governance between ALM and EA through course-grained services. If alignment is considered by application architects during the composite application design, it should be easy to carry policies and validation processes from the highest level of EA to application deployment and redeployment.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.