Subscribe to WebSphere: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get WebSphere: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

IBM WebSphere software products Authors: Liz McMillan, Pat Romanski, Yeshim Deniz, hyper filter, Timothée Bensimon

Related Topics: Java EE Journal, WebSphere

J2EE Journal: Article

Professional IBM WebSphere 5.0 Application Server

Professional IBM WebSphere 5.0 Application Server

Professional IBM WebSphere 5.0 Application Server provides a perspective on the philosophy and rationale behind WebSphere Application Server, taking readers through the programming and deployment model and familiarizing them with the WebSphere Studio Application Developer tool set. The book explains how to use the application server to build business applications, and how to integrate businesses. The following excerpt is from Chapter 10 on Enterprise Process Management and introduces the concept of Process Choreography as a mechanism for more efficiently creating, running, and changing business processes.

In the early '90s, many companies invested in traditional client/server architectures by building fat-client applications with rich graphics that offloaded legacy-system processing time.

Business Process Management
Business Process Management (BPM) is about modeling, implementing and managing the execution of automated business processes. Automated means that the process is driven by an application that orchestrates the interaction of the various human resources and software components which are required to perform the business process. With a few "green field" exceptions, BPM application development generally is a "meet-in-the-middle" process, which comprises these two elements:

  • A high-level requirements specification of the business functions that an enterprise wants to offer or perform to achieve a business goal within certain constraints (cost and time limits, quality of service, and so on). Often this requirements specification is derived from the results of a more or less formal business process analysis effort. In other cases, the functions to be provided are dictated by public standards or external partners. In any case, the process specifications are likely to change frequently.
  • A set of existing application components that encapsulate operational data or perform business functions that need to be integrated into process execution. These components can be legacy applications, packaged applications, new J2EE components, or web services provided by external partners. Since they were not built specifically for use in a particular business process, some adaptation needs to be done to fit these components into the overall process.

    The goal of BPM application development is to fill the gap between these two ingredients and make it easier to do the following:

  • Incorporate existing application components and resources into the process and manage the interactions of human process participants.
  • Add new business logic and modify previously defined behavior of the process without affecting other components used by the process.
  • Manage execution of the processes from a business user's perspective. This includes capability to suspend execution of the process or parts of the process if necessary.
  • Monitor status of the process at any point in time, providing information about progress of the overall process, status of individual process tasks, and resources used by the process.
  • Analyze business process execution, providing an execution trace of the process that offers sufficient information to analyze performance of one or more processes. This can be used to evaluate process performance, compare it to the objectives defined earlier and to enable process optimization based on lessons learned.

    Further background and explanation of business process management would be be going into too much detail. It suffices to say that the challenge in the application server space is to meet these BPM goals in a way that is complementary and appropriate for application server-based business solutions. This really means that we need to expose and present these capabilities in a way that is natural and reasonable to those engaged in J2EE centered development activities. The preceding statements are actually useful as a manifesto and set of guidelines for any infrastructure base that intends to support BPM. In our case, the infrastructure base is J2EE and web services.

    As is usually the case, existing specifications for J2EE 1.3 could be pushed to the limits and used to implement many of the concepts just described. However, to more appropriately address these challenges, additional services and capabilities are called for. Let's see some of the services supported by WASD, starting with Process Choreography, and later Business Rules.

    Process Choreography
    The model for execution of a business process is often called a workflow. In software, workflow represents the automation of a business process or part of a business process. Sometimes workflow is referred to as just flow, when talking about a specific automated business process. WASD has a new feature called Process Choreographer. The workflow capabilities of WebSphere are categorized and measured under this umbrella. Process Choreographer in the runtime involves execution and management of flow-based applications. WebSphere Studio Application Developer, Integration Edition (WASD IE) offers tooling that assists developers creating flow-based applications for later execution in the WASD runtime.

    WebSphere's support for workflow brings about the true integration of the Java and J2EE worlds with the workflow world. Accessing non-Java artifacts during business processes is possible and simplified through the use of service-oriented architecture. However, when new activities are necessary, they can be constructed in Java using the full power of the J2EE programming model.

    Workflow can be depicted graphically using a directed graph. The graph nodes represent individual steps in a flow. The graph edges or connectors describe the execution order of those steps (including conditional and concurrent execution), as well as the data that is needed by the activities. Each of the activities references an "activity implementation" which can be a sub-flow or an elemental operation, for example, a method of an EJB or a web service. People can be assigned to activities if humans perform the respective steps. Actions performed by humans demand that the infrastructure have in place an organizational model and demand that the workflow runtime have access to that. Figure 1 shows a very simple process as a series of steps shown in WebSphere Studio Application Developer, Integration Edition. Each step executes a different kind of activity just for purposes of demonstration. More refined and complete examples will follow later in this chapter.

    At runtime, the business process engine executes instances of business processes, either in memory for short running flows, or with persistent state for long running flows. The individual activity implementations are invoked when needed, the state of the business process is tracked, work items are assigned to people if and when needed, and access to this information is provided via a worklist handler interface and associated GUI. The Process Choreographer capabilities of WebSphere can be used to describe a variety of "executables," from short running scripts involving a couple of service invocations up to long running business processes involving B2B interactions and people.

    Many existing IBM products use flows of various types as their execution model - some examples are WebSphere MQ Integrator (formerly MQSeries Integrator), Lotus Workflow, WebSphere Adapters (formerly MQSeries Adapter Offering), Enterprise Access Builder, and MQSeries Workflow. Each of these products is specific to certain environments and certain types of flows. WebSphere MQ Integrator, for example, is optimized to flows that manage the routing and handling of messages in a messaged system.

    WebSphere's Process Choreographer adds a general-purpose flow engine (Business Process Container) to the application server, which allows for the seamless management and efficient execution of all kinds of flows in the application server. Business processes, a term we will use interchangeably with flows, are deployed as part of EAR files, and are managed by the WAS administration console. WebSphere's Process Choreographer is based on a business process engine written in pure Java that was designed with extensibility, flexibility, and performance in mind. With these design principles in place, it is intended that numerous kinds of flows can be executed using this technology to solve many business process problems in a wide variety of environments. The next section provides more details on the possible role for automated business processes.

    The Role of Business Processes
    Automated business processes can play a key role in architectures which are based on the application server. This section will elaborate upon some of those architectures, and suggest some of the features that are necessary and available in WebSphere's Process Choreography support. These features make the creation of solutions which conform to the suggested architectures possible.

    First, if we look back to our discussion of the business model earlier in this chapter, we will see that the premise was made that the basic elements of the business process are implemented with session beans. The simplest application of flows involves implementing that session bean using flow technology. What happens is that the basic steps necessary to execute a business process are scripted using a flow. This flow probably also involves conditionally calling and leveraging EJBs that are in the solution architecture. Most simple flows are generally short-lived in nature and are synchronously executed. These synchronous flows are called micro-flows or non-interruptible processes.

    Secondly, we begin to see more complex business processes being represented by workflow. These processes involve a flow that choreographs or scripts the usage of a number of sub processes. These sub processes may also be non-interruptible processes or just traditionally created session beans. What is important is that the system supports the ability to conditionally execute various sub processes based on business rules. These more complex flows may also run for longer periods of time and are able to live beyond the lifetime of a given server instance. Activities in these flows often contain asynchronous invocations also. These are what would be characterized as macro-flows or interruptible processes. An interruptible process is shown in the Figure 2. It shows four major activities and suggests that each activity implementation is a session bean calling some entities. Obviously, actions that are more complex are allowed in the activity implementations. This will be further detailed later in the chapter. The smiling faces in the figure represent human-interaction as part of one or more of the activities performed within the business process.

    Next, we begin to see these basic short- and long-lived business processes taking on various additional roles, leveraging some different features along the way. It is possible that flows will have a series of user-interactions which are necessary to complete one or more of the steps in the business process. This requires workflows to play a more direct role in the presentation of the business process. The business process then is reacting directly to an ongoing stream of inputs driven by user interactions.

    Some business processes will begin executing based on an inbound message rather than some direct invocation from within an existing servlet or session EJB. There is a role for flows in message-oriented applications. The flow continues to drive a series of steps that execute a business process. The difference is that the flow is started by an inbound message. In message-based flows, the results of a flow are also often transmitted with messages as well.

    These basic patterns for flow usage begin to suggest some powerful ways to implement the processes that make up our business model. Beyond an individual organization, flows that span businesses or business units should also be considered. The same basic building blocks apply. A business process that spans businesses is called a public process. Each step in the public process may indeed involve utilizing some of the patterns we have just described.

    With this set of possibilities in place, the details on the more basic elements that make up the business process programming model can be described. This is the topic of the next section.


    About the BOOK
    Professional IBM WebSphere 5.0 Application Server, by Rob High Jr., Eric Herness, Chris Vignola, Tim Francis, Jim Knutson, and Kim Rochat

    ISBN: 1861005814
    Price: $79.99
    Publisher: Wrox Press
    Available: January 2003

  • Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.