Introduction
This article provides an overview of the Business State Machine component and its capabilities and discusses the usage of BPEL processes as an alternative. The series builds a vending machine by using more Business State Machine capabilities. We make our vending machine collect money, introduce actions, and test it using a component test.
Overview
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). 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 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.
This state machine has three states and two transitions.
InitialState1 state 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.
FinalState1 state 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.
Running state is referred to as a simple state. In this case, the Running state can be entered through the powerOn operation and exited through the powerOff operation. As we will see later, we can have multiple operations entering and exiting a single state.
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.
Implementation
We will complete the following steps to develop BSM using Integration Developer.
Ø Create Artifacts.
Ø Create BSM.
Ø Implement BSM.
Ø Test BSM.
Ø Create Artifacts.
Ø Create BSM.
Ø Implement BSM.
Ø Test BSM.
Create Artifacts:
Create a library called ‘EAI_Library’ and create two interfaces as shown below.
Create BSM:
Create a Module called ‘EAI_VendingMachineModule’ and create a Business State Machine.
Right click on Integration Logic àNew àBusiness State Machine.
Give the name as ‘BSM_VendingMachine’ and click on next.
Select the interface ‘VendingMachineMaintenanceInterface’ and operation name ‘powerOn’. Select the input ‘SerialNumber’ for correlation information.
Now the initial BSM Looks like below.
Implement BSM:
Create three variables called SerialNumber (String), DepositAmount (Int), and TotalAmount (Int) under Variables section.
Select the wire and Right click àAdd àOperation.
Select the newly added operation àProperties àSelect interface ‘VendingMachineMaintenanceInterface’ and operation ‘powerOff’.
Select wire near PowerOn operation and click on Add an Action.
Rename as initialize and select Properties àDetails àJava, and then add the following code.
Select the Running status then add the entry and add the following code under properties à Details àJava.
Drag and drop a Simple activity from Pallet and rename as Collecting.
Add ‘VendingMachineInterface’ interface to the BSM.
Drag a wire from Running status to Collectingstatus. Select VendingMachineInterface interface and deposit operation.
Add and action to deposit operation and writ the following code.
Drag a wire from running ‘Collecting’ status to ‘Collecting status to implement a loop. Add an operation deposit and add an action then add the following code.
Drag a wire from collecting status to runningstatus. Add an operation coinReturnand add an activity rename as ReturnMoneythen add the following code.
Select and activity for PowerOff operation rename as Shutting Down and write the following code at property window.
Now select the CorrelationProperty1 àProperties àDescription then click on Add button.
Enter the XPath to select correlation variable from each operation.
Now the final correlation property will be look like below.
We have implemented Business State Machine, Open assembly diagram and drag and drop ‘BSM_VendingMachine’ on assembly diagram.
Test BSM:
We have completed Business State Machine implementation. Now we can test this by using component test method. Start the WPS server and Deploy the ‘EAI_VendingMachineModule’ module.
Open Assembly diagram and right click on ‘BSM_VendingMachine’ select Test Component.
Now it will open Integration Test Client, select the interface ‘VendingMachineMaintenanceInterface’ and operation powerOn, enter SerialNumber as 111 the click on continue.
Then click on invoke symbol, it will open new invoke test run, select ‘VendingMachineInterface’ and deposit interface then give SerialNumber as 111 and DepositAmount 100 then click on continue.
Repeat the above step for test returnCoin and PowerOffoperations. The final result will be look like below.
The successful transaction logs will be printed to SystemOut log and console as shown below.
Conclusion
In this article, we learnt to implement the vending machine using BSM. This provided our first self-transition, the addition of variables, and actions. We then used the component test. 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.
Download
File Name | Description | Size | Download |
BSM Sample.zip | BSM Sample | 15 KB | |
BSM in WPS.pdf | BSM in WPS Document | 1.02 MB |
