BEAParticipate: ALBPM Architectural Overview

I started my day in a session about what’s coming up in future versions of ALBPM; unfortunately, most of the information hasn’t been publicly released, so you’ll have to wait to read about it at a later date. BEA will be holding BPM steering group meetings in July, so if you’re an ALBPM customer and want to get involved in defining future versions of the product, this is your chance. I’d love to sit in on these, although I can’t imagine the size of the NDA that I’d have to sign first.

I’m back listening to Mariano Benitez with an architectural overview of ALBPM for administrators and operators; I think that he’s nervous now based on his reaction to my post yesterday. 🙂

We’re going to cover the components of the ALBPM solutions, the enterprise infrastructure, and the deployment alternatives. I’ll leave out a lot of the technical details since it would only be of interest if you were actually digging into ALBPM at this level in order to plan a deployment, in which case you’re probably in the room with me right now.

In short, an ALBPM project can be made up of many processes, where a process consists of the process flow, points of integration and the presentation layer. Also associated with a process are the roles used by the process (which map to enterprise security), service endpoints, and deployment methods. ALBPM allows you to define the organization as it pertains to the business processes: participants and groups, organizational units, and roles.

Taking a look at the ALBPM enterprise infrastructure, it’s (not surprising) three layers:

  • There’s a number of data sources, including a directory repository (which maintains configuration information about the deployment as well as organizational models used both in process definition and for authentication), the engine back-end database for all information on work in progress, historical instance data archived from the work-in-progress database, a real-time BAM data store with one day’s worth of data aggregated for dashboard views, and an OLAP data store for more complete historical analytics. Either Oracle, MS SQL Server or DB2 can be used for the data sources, and although multiple execution engines don’t require a separate database for each, they do require at least a separate schema. For performance, however, I would assume that you’d tend to split any production engine data stores and the analytics data stores onto separate database servers for performance reasons.
  • In the middle layer is the main process execution engine — the heart of the system — plus a few other services such as data warehousing to load the analytics data stores. There are a number of basic services provided by the engine that are used to execute running process instances; no big surprises here on an architectural level if you’ve seen the process engine of other BPM vendors, although every engine has its specific advantages.
  • Layered above the engine are various web applications, such as the main Workspace UI application that can be used both for processing and monitoring work. Listening to highly-technical engineers talk about user functions is always pretty funny: Benitez refers to the action of processing work as “invoking instance operations”, so you can be sure that he’s not going to be writing any user documentation. To be fair, I used to talk like that when I wrote code, too.

We unfortunately had to rush through the deployment scenarios, but saw that it’s possible to deploy ALBPM either as a standalone BPM box or in a J2EE container (simple or clustered).

Leave a Reply