Simulating SOA : The Ideal SOA Simulator

9/30/2012 2:28:24 AM
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.
  •  Simulating SOA : Simulation, and Why it Suits SOA
  •  Programming .NET Components : Building a Distributed Application (part 7) - Providing a Host as a System Service
  •  Programming .NET Components : Building a Distributed Application (part 6) - Remote Callbacks
  •  Programming .NET Components : Building a Distributed Application (part 5) - Creating Remote Objects
  •  Programming .NET Components : Building a Distributed Application (part 4) - Administrative Type Registration, Administrative Configuration Example
  •  Programming .NET Components : Building a Distributed Application (part 3) - Programmatic Configuration Example, Administrative Configuration
  •  Programming .NET Components : Building a Distributed Application (part 2) - Programmatic Type Registration
  •  Programming .NET Components : Building a Distributed Application (part 1) - Programmatic Channel Registration
  •  Programming .NET Components : Remoting - The .NET Remoting Architecture
  •  Wireless Router Apple Airport Express
    Most View
    Samsung 840 SSD 250GB - Most Of The Good Things
    Tech Preview 2013 (Part 1) - Next-Gen Gpus
    Chillblast Fusion Firebird - Offers The Fastest Framerates
    The Tour Apple Announment
    Asus Q200 – Cheap Touchscreen Notebook (Part 1)
    Laptops Test - The Original Act Flights Back (Part 1)
    MSI GX60 Review - Radeon HD 7970M In A $1,200 Gaming Notebook (Part 6)
    The NZXT Kraken X40 Compact Liquid Cooler Review (Part 2)
    PlayStation Goes Fourth (Part 2)
    Nintendo WII U - Modern HD Gaming Console (Part 2)
    Top 10
    Mitsubishi Hybrids – One Direction
    Race To The Clouds – Honda R&D’S ’91 NSX (Part 2)
    Race To The Clouds – Honda R&D’S ’91 NSX (Part 1)
    Volkswagen Plug-In Hybrid Up – Double Act
    Pre/Power Amplifier Marantz SA8005/PM8005 Review (Part 2)
    Pre/Power Amplifier Marantz SA8005/PM8005 Review (Part 1)
    Smart TV Finlux 50FME242B-T Review (Part 2)
    Smart TV Finlux 50FME242B-T Review (Part 1)
    The Best Money Can Buy: Motherboards (Part 2) - Asus Rampage IV Black Edition, Asus Crosshair V Formula-Z
    The Best Money Can Buy: Motherboards (Part 1) - ASRock X79 Extreme 11, Asus Intel Z97 ROG Bundle, Gigabyte Z97X-GAMING G1