Skip to main content

The Interaction-Flow-Service-Model Architectural Pattern

Posted by garysweaver on December 5, 2008 at 2:21 PM PST

There is one thing that I've overlooked until today, which is the importance of the division of the controller into application "flow(s)" and application "service(s)". For a good while now, I had been keeping controller code separate from service code (which in turn called the DAOs, that used Spring DAO, that used Hibernate, that interacted with the DB, etc.). However sometimes business logic that should probably be in those services can easily blur into the controller classes, which are sometimes also at least in part, responsible for the flow.

Until you try to replace the part of the app handling the flow, maybe you're fine, as many are! However, there is a big wave headed your way, that you've felt coming for a good while now (and some have been dunked!) which is "flow".

I started a few days ago to take an application I had written and convert it to Spring Web Flow 2. While writing the flows for the application, it stood out to me clearly how many methods were missing from the service layer of my application that I planned to call from the flows, and the additional pain that will come with moving that code from the controller and other related classes (injected instances in the controller and sometimes utility classes).

Are we moving towards what possibly could be called a "Interaction-Flow-Service-Model" (IFSM) architectural pattern? (Which is updating the lingo a little in model-view-controller and separating the "controller" part concept into "flow" and "service"?)

Throwing this out there, and would appreciate any comments.

Related Topics >>

Comments

@johnreynolds - Thanks! I'm flattered that you consider what I've described to be the essence of Business Process Modeling. Note that the flow part of IFSM is about application/solution flow and not necessarily about business process though. From what I've seen in the past, parts of the IFSM "flow" will often be encapsulated in the components representing tasks/decisions/etc. that are connected in the flows in various BPM solutions. In addition, the organization's application/solution can easily get so tied to the BPM solution, that it isn't easy to replace one BPM solution with another, even if the BPM flow itself is defined in a standardized format. While the intent of BPM is to extract and differentiate the business flow, IFSM's intent is to differentiate the (application or) solution's flow entirely from the services layer in such a way to minimize impact from swapping out one flow layer implementation with another. Many developers differentiate the services layer from the rest of the controller. However, that on its own doesn't isolate the flow layer of the application, as I found out, and will lead to issues integrating with frameworks that isolate flow. However, if the developer is focused on isolating flow in their classes (even before using something like Spring Web Flow) in addition to services, not only will they be ready and able to swap out or rearchitect-and-scale the services layer, but they'll be able to do the same with the flow layer.

Gary, It looks like you've independently discovered BPM... or at least the heart of it. The process flow (between actors) is kept distinct from the rest of your application - BPEL is one form of this. Couple that with distinct page flows (between pages shown to a single actor) - Spring's Web Flow does this - and you've got the core of every BPM suite that I know of. -JohnR

A quick analogy of the IFSM to "real life": when you go to the airport from the moment you walk in, there are places that you are sent to and queues/lines you must wait in and be shuffled off into various places to get to service attendants that in turn decide how to interact with the systems that in turn access the data. There is a clear distinction here between what the person sees/feels/hears (interaction), where and how the person is directed to a service (flow), the workers and self-service machines at the airport (the service), and the terminals the workers use to interact with the data about customers, planes, traffic, etc. (the model). I know it isn't a perfect analogy, but it might help.

Yes, it still falls into the same MVC pattern by that argument. However, if the generally accepted pattern were to be "View-Foobar", and Foobar encompassed what we understand to be Controller and Model, then you could make the same argument. Just as the separation of Foobar into Controller and Model has proven benefits, such as clearer design and modularity (so you can swap out the classes you had that used the JDBC API with Hibernate, etc.), the further separation of Controller into Flow and Services will have similar benefits (there will be different tools/libraries you can use for flow, while not having to change the classes you have that do the business logic that in turn control the Model). The issue is not that MVC *can't* describe an application designed with the IFSM model, but rather further differentiating controller makes the design more modular and better able to handle partial changes to take advantage of new technologies.

IMHO it's the same thing. The controller part will still be there, but divided in two or more different parts, but still doing the same job, in the same manner, so hardly it's a new pattern.