Bridging the gap between BPM and SOA: look to the repository

Business process management (BPM) and SOA don't have to live in two different worlds. In a new Q&A tutorial, enterprise architect extraordinaire Todd Biske provides practical advice about pairing BPM modeling tools with service oriented architecture.

The key lies in the registry/repository of services created to support SOA: "One of the most important things to consider is the ability of the BPMN tooling to take advantage of service metadata that exists in a registry/repository," Todd explains. "Whether modeling within the tool is being done by process analysts or by developers, the ties back to your service repository are important."

Then consider the two roles that engage in this collaborative process:

Process analyst: These individuals may be working with a BPMN model, which will consist of flow objects, connecting objects, swimlanes, and artifacts. The two items that have relevance within SOA are the activities (part of the flow objects), and the swimlanes, which represent ownership boundaries of functional domains, Todd points out. "If you have this taxonomy in your service registry/repository, it would be great to have it accessible to you during your modeling efforts." Service invocations should be shared across processes, and integrated into the registry/repository.

Developer: It is up to these folks to "take that model and turn it into something that can be managed by the runtime BPM engine," Todd explains. Developers ensure that automated information-generating activities are correctly mapped to the message flow, via the connection between the service registry/repository and the BPM tool.