Section 2.4. Summary


2.4. Summary

The main points of this chapter include the following:

  • BPM is replete with competing standards, but a sound architectural approach divides a BPM application into the right parts and selects the correct standard for each.

  • The requirement of a BPM application is the ability to design, run, administer, and monitor processes that incorporate system and human interactions.

  • Two types of architects benefit from this discussion. Product architects learn, at a high level, a good approach to developing a BPM product. Services architects learn the essential nature of a BPM product platform, enabling them to build good solutions on it and to educate their customers about this emerging technology.

  • Design, the modeling of processes by business and technical analysts, requires a graphical notation language and a graphical design tool, such as ITpearls' Process Modeler. BPMN is the best standard notation language.

  • To run a process requires a runtime engine that can load designs and manage the execution of instances. However, there is no way to run a notational drawing; it is just a design artifact. A runtime engine requires an executable language, just as a computer processor requires programs that use the processor's instruction set. To bridge this gap, a mapping from notational to executable language is needed. The design tool should offer an export option that uses the mapping to generate executable code. With respect to standards, BPEL is the best and most widely adopted executable language, and our chosen notational language, BPMN, includes as part of its specification a detailed mapping to BPEL.

  • Administration and monitoring is crucial for the success of a production application. An administrative console, along with a sufficient data model and a standard system management interface language, helps administrators track and change the managed objects of the runtime engine, including process definitions, processes, activities, manual tasks (worklist items), and users and roles.

  • Human interactions are manual work items that are performed by particular users or users with a specific role within the organization. The process initiates this work and waits for an event for the work's completion. The users view and execute their pending tasks in a graphical worklist console. Because tasks are long-lived, their state is kept in the administration database. A special Worklist web service manages human interactions on behalf of the process.

  • System interactions are connections to internal or external systems. External systems are typically web service-based partner processes. Internal systems are other applications on the corporate network with which the process needs to interface. The number of integration technologies is high, and it would be foolhardy to try to support each of them individually. The best approach is to offer the most common technologies natively (XML, web services, inline Java) and provide an adapter plug-in model for the rest (e.g., MQ, database, or mainframe).

  • A process is a web service! Its event points are, in effect, service operations. For this reason, the BPM integration architecture must include a special web services listener that accepts SOAP requests and injects them into the process engine.

  • The processes of this architecture are those of a particular corporation and are designed from a local perspective. The global perspective of choreography and collaboration (discussed in Chapters 8 and 9) helps build protocols with which our company must comply.

  • Of the 17 major BPM standards, only 3BPMN, BPEL, and WS-CDLbelong in our architecture. The emerging BPQL and BPDM look promising for a future iteration.



    Essential Business Process Modeling
    Essential Business Process Modeling
    ISBN: 0596008430
    EAN: 2147483647
    Year: 2003
    Pages: 122
    Authors: Michael Havey

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net