The web service simulation
discussed in the previous section is suitable introductory demonstration
of discrete event simulation, but it is artificially simple. An SOA process reacts to several events during
its lifetime: the event that starts it, as well as any number of intermediate
events, which affect its behavior downstream. Further, a process can be
both a server and a client, producing and consuming services and
participating in long-running multi-party conversations. And nowadays,
the processes seldom call each other directly, but rather indirectly by
putting messages for each other on queues in an ESB.
The
ideal SOA simulator allows us to model such processes. Regrettably, a
few tools today support these requirements. There are numerous BPM
modeling tools that offer the simulation of BPMN models. Given BPMN's
SOA-friendly event framework and its similarities to BPEL, these tools
might seem to be a good bet for SOA simulation. But most of them
recognize only one sort of event: the one that starts the process. Once
an instance has started, every step that follows is treated as if it
were either a human task or a synchronous service call. Intermediate
events, if they are supported at all, are simply stepped through,
perhaps with a configurable wait duration. Deferred choice, in which the
process waits for exactly one of several events before continuing, is
more often than not modeled as an XOR split, with weighted probabilities
determining the winning path (for example, if there are three paths,
one has a 50% chance, the others 25% each). Granted, for most BPM
processes, events are second-class citizens anyway, so the emphasis on
human tasks is appropriate. However, for hardcore SOA simulation, these
are a poor fit.
The
following is a description of the sort of SOA simulator we need. A first
cut at this simulator, is available for
download. (Refer to the section ‘About the Examples' for its link.) The
simulator is a BPEL 1.1 simulator: it is designed to generate events,
inject them into BPEL 1.1 processes, and step through the activities
that follow, all the while measuring performance statistics such as
queue sizes and process cycle times.
Key features of the ideal SOA simulator are the following:
Advanced Event Generation:
Allow the designer to control how and when events are generated. Allow
the designer to generate both starting and intermediate events and to
control correlation. Allow the designer to generate events from either
probability distributions or event logs or both. Provide built-in event
log parsing and exponential arrival generation.
Processes Calling Processes:
Allow the simulation to run multiple types of processes, rather than
just one. Allow these processes to communicate with each other in the
same conversation.
Event-Driven Execution:
When a process reaches an intermediate wait point, let the
user-designed event generator trigger it rather than stepping through it
automatically. When a process reaches a deferred choice, wait for an
event from the event generator to select which path to take rather than
choosing a path based on a pre-configured proportion.
Queues Flexibility:
Allow the designer to create message queues and to configure their
capacity and polling intervals. Allow a process to use one or more
inbound and outbound queues. (An inbound queue feeds events into a
process; an outbound queue takes service requests from a process.) Allow
processes to share queues. Allow the event generator to send messages
to the process on a queue rather than calling the process directly.
Coloring:
Allow the event generator to pass hints to the process to affect its
behavior and branching. For example, let an event specify which case to
take in a switch or how many iterations to take in a while.
Many simulators let analysts configure these statically, as attributes
of the process. Coloring gives us the flexibility to drive them
dynamically, on a case-by-case basis, as part of the event framework.
Start State:
Allow the designer to start the simulation either from the initial
state at time zero, or from an intermediate state with processes
pending, queues partially populated, and events pending. Starting from
the intermediate state is useful, for example, to simulate the effect of
going live with a new process in an already busy environment.
Realistic Timings:
Count as part of the statistical measures such real-world constraints
as the time required to put a large message on a queue or remove it from
a queue (that is, serialization cost) and the processing time needed to traverse a BPEL process graph.
The building blocks of this solution are the event generators, queues, and processes, shown in the following figure:
Like the web service simulation, the ideal SOA simulator uses a simple event loop to drive its execution:
Set start state
Call event generator to create first arrival event
Create poller events for each queue
While clock < endTime
Get next event from event list
Advance clock to event's time
Process event (and update statistics)
Output statistics
The difference is
in the types of events and the way in which they are processed. There
are four main types of events in the ideal simulator:
1. Arrival Event:
A starting or intermediate event created by the event generator, bound
for a specific process. The arrival event performs two actions: it adds a
message to the inbound queue on which the process is listening, and it
schedules its next arrival.
2. Partner Event:
The event created when a process performs an asynchronous invocation.
In its processing logic, the partner event adds a message to the
outbound queue that the BPEL process uses to call the partner link's
interface.
3. Inbound Queue Poll Event:
An event that, when processed, gets the next message from an inbound
queue and injects it into a BPEL process. The message was placed earlier
on this queue by an arrival event. The inbound queue poll event also
reschedules itself, using the polling interval that is configured for
this queue.
4. Outbound Queue Poll Event:
An event that, when processed, gets the next message from an outbound
queue, placed there earlier from a partner event, and discards the
message. (There is no need to do anything with the message. The event
simply consumes it.) The outbound queue poll event also reschedules
itself, using the polling interval that is configured for this queue.
The BPEL simulator included for download is decidedly not
for casual users. It is non-graphical, meant to be run either from the
command line or from within Eclipse. To build a simulation requires a
little Java coding and the construction of a properties file, and the
statistical summary produced does not include color charts or graphs.
Power users who embrace the tool will feel at home. The best way to
start with the tool is to run the simulation scenarios described in the
next section, study their results, and explore how they are setup
technically.
