I wanted to continue yesterday’s discussion by describing some differences between discrete-event simulations and systems that might be implemented to carry out business logic. The first diagram below shows a model of privately owned vehicles and commercial vehicles passing through an imaginary border inspection. The vehicles all enter the model, proceed to a primary inspection, and then continue to one or more destinations depending on the results of various inspections. Eventually all vehicles will exit the port, end up in an impound lot, or return to their country of origin. The model never needs to consider other events beyond the behavior of each individual vehicle.
We can complicate the model incrementally in a number of ways. The first might be that a privately owned or commercial vehicle needs to park so its occupants can go to yet another process. This is fairly simple because the original vehicle can only wait until that process completes. Another possible complication is that the interactions between different processing stations and the Customs Shipment Database might be included in the model. In this case the model might have to generate multiple entities which must then be coordinated. This logic is shown in the second diagram, below.
The second diagram shows only the commercial operations in the port, along with the flow of tokens through the data side of the process. I’ve tied them together in the second diagram with a tiny bit of faux BPMN symbology. I’ve also added a complication where commercial vehicles may exit the port process but still have to proceed to a bonded warehouse. Only once such a vehicle reaches that destination does its full process terminate, and the physical vehicle and its associated manifest be matched up and cleared from the system.
I’ve actually done this in discrete-event simulations in the past. The SLX language allows the modeler to define multiple subentities called “pucks” that are associated with physical or logical entities. In my case the physical entities were patients in a dental practice (where the activities of the dentists, hygienists, assistants, administrative personnel, and insurance companies were also modeled) while the associated pucks were insurance claims that were processed in the office and forwarded to the insurance companies. Those claims (along with inquiries and other communications) might go through multiple cycles before being resolved. I’m not sure I ever tied the claim processes to the patient processes in any detail, although I could have. I was mainly concerned with recreating the activities of all participants in the office itself.
The interesting thing about the relationship between entities and subentities is that they can all be easily linked inside the software–if the software system is small enough. It’s a simple matter to maintain pointers to the subentities. That way, if something happens to one entity that should terminate all the others (an issue I mentioned yesterday), it should be a simple matter to locate and deal with them. The book I read on Monday and the associated reading I did on the same subjects would indicate that executing business logic as expressed by business notation is extremely difficult and not a straightforward, one-to-one proposition. I’m guessing that has something to do with the scale of systems that implement business logic. If a system is large enough, particularly if it is spread over multiple machines (let alone multiple processors on a single machine), then groups of entities cannot simply be linked using dynamic pointers, as they can be in a desktop simulation. What would have to happen instead is that all of the related entities would have to be tagged with identifying information that could be used to identify them as various data structures were scanned. That can be a time-consuming process. It’s easy to see why such applications can be difficult to scale.
One more difference between simulations and business logic systems is that there is no need to coordinate activities in time in a business system. Things just happen when they happen. You can definitely have coordination issues of the type discussed above, but those have to do with relative time–which event happened first or last–and not absolute time. Driving events like document and transaction arrivals and user actions happen on their own. In a simulation those events may have to be built into the simulation as a driving mechanism (using schedules, Poisson functions, randomly generated events, or combinations thereof).