The Business State Machine (BSM) component in IBM® WebSphere® Process Server (hereafter, referred to as Process Server) provides a way to define and work with business "nouns". These nouns are things like "orders" or "trips" that have a life cycle controlling their behavior. For example, the cancel operation on a trip will not be supported once the trip is completed, and will further need to process things differently for a trip that has been reserved versus one that has not. BSM provides a way of developing, debugging, and monitoring these nouns as a state machine.
BSM provides support for business items that have a life cycle. These are items that have states that are driven by events, and typically have loop-based logic (returning to previous states). Throughout this series of articles we are going to look at a vending machine. A vending machine can be turned on, collect money, dispense a product, and return change. It follows this loop over and over again until it is turned off. It has other loops as well. For example, the vending machine must ensure that the customer has deposited enough money before the requested product can be dispensed. Furthermore, if applicable, change may need to be returned to the customer.
It is typical for this type of application to be represented using a state machine. A state machine basically consists of states with transitions between them. These transitions can occur in a number of ways. A BSM, like other components in Process Server, is a Service Component Architecture (SCA) component. Its interface is defined using the Web Services Definition Language (WSDL). Any number of WSDLs can be predefined and associated with the BSM as it is developed. And, all of the operations defined in these WSDLs must be used in the BSM. For BSMs, WebSphere Integrated Developer (hereafter, referred to as Integration Developer) provides a way of graphically developing the BSM. The editor's representation is based on the Unified Modeling Language (UML) definition of state machine modeling and design. We will show how the state machine is represented in the editor as we build and extend the vending machine.
The BSM editor works with an XML representation of the state machine called the State Adaptive Choreography Language (SACL, pronounced sachel). The SACL file is used to generate a Business Process Choreography (BPC) BPEL process. This process is long running so that it manages persistence of the state of the state machine. The fact that a process is generated does not impact the development, debugging, or monitoring of a BSM. However, when administering a BSM either through the BPC Explorer or the BPC Explorer runtime API, the core functionality and interaction with the state machine is represented by a long running BPEL process.
Because BSM generates a BPEL process, this leads to the question of when one approach should be used over the other when designing business applications. At the highest level the processes can be thought of as "verbs" that work with state machines that are "nouns." However, in cases where the state machines are--and will--remain simple, it may be better to use a process. For example, a state machine without any loops (returning to an earlier state), would probably make more sense being developed as a process. However, if there is a lot of looping, the state machine provides a much more natural way to develop, debug, and monitor.
Now let's start our vending machine, so we can explore the core state machine concepts supported by BSM and how they are presented in Integration Developer.
As we discussed earlier, a vending machine will be used to illustrate the BSM function throughout these articles. In this article we will build the most basic vending machine. Advanced concepts, such as conditions, actions, timeouts, and composite states will be discussed further in subsequent articles.
The simplest use case for the vending machine is the maintenance interface. This interface controls powering the vending machine on and off, as shown in Figure 1.
Figure 1. Simple state machine that powers on and off
This state machine has three states and two transitions.
InitialState1state is an initial state that is indicated by the green circle icon. Since this is where the state machine starts, every state machine must have exactly one initial state.FinalState1state is a final state that is indicated by the blue circles icon. The state machine ends when it reaches a final state. There can be multiple final states, but since the state machine always ends when reaching a final state, defining multiple final states in a BSM has no effect on the application functionality or logic. Multiple final states would only be used when different entry actions are needed (covered in an upcoming article) or, more often, to make the state machine more readable.Runningstate is referred to as a simple state. In this case, the Running state can be entered through thepowerOnoperation and exited through thepowerOffoperation. As we will see later, we can have multiple operations entering and exiting a single state.
The transitions in this example are caused by operations that are on the WSDL interface (or interfaces) associated with the BSM.
You can use the interface editor to define operations. For this example the interface (in the interface editor) is shown in Figure 2 below.
Figure 2. Vending machine interface
Both operations are one-way operations, each with a single parameter (serialNumber) that is used to uniquely identify the vending machine. In other words, because the state machine is persistent, we need to be able to make sure that operations are applied to the correct instance of the state machine. This means that each operation has to pass the unique information that identifies the state machine instance. In database terms, this is the BSM's primary key. BSM uses the same terminology as BPEL by calling this the correlation information.
The correlation information is defined in the editor by clicking on the background of the state machine and selecting the Correlation tab under the Properties view (see Figure 3).
Figure 3. Correlation property tab
In this case, our correlation is being done on a single variable (referred to as a property) called serialNumber which is of type String. The properties for the vending machine correlation id are shown in Figure 4.
Figure 4. Setting the correlation property values
The correlation property has to be assigned for every operation defined in the BSM's interfaces to ensure that the operation is applied to the correct process instance. This value can be assigned to any part of the incoming parameters, so while the serialNumber may be the correlation ID for the BSM, other incoming operations may refer to this as employee ID. BSM (like BPEL) provides the ability to create a property alias, by specifying the parameter and part to use for the correlation value. In our example, we have an alias for each operation, and we indicate that the correlation serialNumber should be specified from the serialNumber parameter on each operation. While this example is very straightforward, others can be very complex, especially when the correlation information is from a message with complex parts.
Returning to our example, the two transitions are identified by the operations that cause them. The gear icon is used to indicate operations in the editor. Thus, when we call the powerOn operation a BSM is created and associated with the serialNumber we passed in (since it is aliased to the serialNumber correlation property). The state machine is then in the Running state. If we try to call the powerOn operation again with the same serial number it will fail, since the Running state does not have a transition associated with powerOn coming out of it. The only operation that will work is the powerOff operation, which will cause the transition from Running to FinalState1 to occur. At this point the BSM is destroyed, which means that the serial number can now be reused. Calling powerOff with the wrong serialNumber will either cause the wrong BSM to power off or will fail if a BSM with that serial number does not exist.
The transition that comes out of the initial state is unique. There can only be one transition out of the initial state, and the operation specified for this transition should only be used this once. This transition must have an operation, since the correlation for the state machine must be set when the state machine instance is created.
Now we have a vending machine that we can turn on and off. This state machine will run, and we can test it using the BPC explorer.
Testing the vending machine in the BPC Explorer
You can start the BPC Explorer through the BPC Explorer option in Integration Developer, or through an external Web browser. To start it inside of Integration Developer (see Figure 5), right-click on the server from the Servers view, choose Launch, then BPC Explorer.
Figure 5. Opening the BPC Explorer in Integration Developer
If the server hasn't been started, this option will be grayed out. To start the BPC Explorer in a Web browser, use this address: http://localhost:9080/bpc, where localhost and 9080 are the default hostname and port values, respectively. This default page, shown in Figure 6, will bring you to a screen showing the human tasks assigned to you.
Figure 6. List of tasks waiting for user when opening BPC Explorer
Human tasks are separate from the long running processes that are generated for BSMs and are not covered in this article. To find the vending machine BSM, click on the top left item, My Process Templates, as shown in Figure 7.
Figure 7. Process templates showing active state machine instances
The term template is used to identify the long running process definition, while instance represents a specific instance of the long running process that is currently running. For BSMs, the process instance is created when the operation out of the initial state is called; likewise, the process instance is destroyed when a final state is reached.
On the screen above, there is only one template for our BSM. The name of the template matches the name we gave the BSM, VendingMachine. While in our example there is only the BSM, this view will show all of the process templates for all BPEL and BSM applications on the system.
To create an instance of the vending machine, click the check box in front of VendingMachine and then click the Start Instance button, see Figure 8.
Figure 8. Creating a state machine instance in the BPC Explorer
This screen (Figure 8) is where you specify the parameters to use to create the BSM. Process Name is a name used to identify the process associated with this instance of the BSM. The serialNumber is the parameter for the powerOn operation that creates the state machine. If there were more parameters for the powerOn operation, they would be shown here as well. Recall from our BSM design, that the serialNumber is used for correlation and, therefore, must be unique.
When you click Submit, a BSM instance is created, and the BPC Explorer automatically navigates back to the My Process Templates screen. At this point, there are a number of ways to look at the state machine instance we just created. One is to click the check box in front of VendingMachine and click the Instances button. This will show you all instances of the template, whether you created them or not. The other is to click the Started By Me option in the left navigation portion of the BPC Explorer. This shows the instances you created with any template. In our example, Figure 9 shows the same single instance.
Figure 9. Active vending machine process instances
In this article, we focus on testing the BSM, so we aren't going to go into the details of what can be done from this screen, but we will focus on a couple of items.
Understanding some basic BSM operations
The state shown in the BPC explorer has nothing to do with the state of the BSM instance. This state has to do with the instance itself. For BSMs, the Terminate button will terminate the instance immediately. This can be especially useful when trying to install another version of the BSM. If the server is not in development mode, BPEL will not allow a template to be replaced when it has running instances. In production, the BSM, just like BPEL, can have a "valid from" date specified, which will cause all instances created after the valid from date to use that version of the template. The valid from is found in the properties view of the overall BSM (reached by clicking on whitespace in the BSM editor), shown in Figure 10.
Figure 10. Optional "valid from" setting in the state machine properties
For our examples the "valid from" is not used.
We must also be able to execute other operations on the BSM. To do this, click on the process name (test1). This will bring you to the screen shown in Figure 11 with details about the instance.
Figure 11. Available actions that can be performed on an active state machine
You can also terminate the instance from this screen, but to call an operation, click on the Events tab (even though it is grayed), shown in Figure 12.
Figure 12. Issuing an operation to an active state machine instance
This will show you all of the operations that you can call on the BSM. Notice that all operations are shown, whether they are valid in the current state of the BSM or not. For example, the powerOn operation is shown in Figure 13, but using it will either cause a new BSM to be created (if a unique serial number is used) or a failure because the Running state doesn't support it (if the same serial number is used).
To use an operation, click on the operation name. For our example, clicking on powerOff goes to a new page where we can enter data for the specific operation.
Figure 13. Sending a
powerOff event to the vending machine
We can enter the serial number and click on Submit. This serial number must be the same as what we used earlier to create the BSM instance. Once this operation is accepted, the BSM ends. The BPC Explorer returns to the screen with the list of operations, but since the state machine instance is no longer available, the operation list is replaced with "No items found". If we return to the Started By Me view, the BSM instance is no longer shown.
In this article we discussed the differences between BPEL processes and BSMs, with specific regards to how state machines provide a good solution for "nouns" that are event driven and have looping. We created a basic vending machine and tested it using the BPC Explorer. In the forthcoming articles in this series, we extend the vending machine so that it collects money and dispenses products. We will also look at other ways to test and debug the BSM.
-
A guided tour of WebSphere Integration Developer, Part 3
-
Implementing two-way interactions between a business state machine and a human task using WebSphere Process Server
- WebSphere business integration zone
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
- Try: WebSphere Integration Developer (in the SOA Sandbox: Connect)
- Demo: Process automation, adoption pattern
- Webcast: Develop innovative applications efficiently using the right application foundation in today's economy
- Briefing: WebSphere flexible business processes
- Buy: WebSphere Integration Developer (in the SOA Sandbox: Connect)
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
