Pursuing the theme of reverting to a form of procedural thinking to implement SOA, I remember how we used to draw Context Diagrams and Data Flow Diagrams (DFDs) as part of system design in the eighties. Context Diagrams were also called DFD Level 0. We used to draw the system being designed as a single bubble, and show all interactions (dataflows) with external parties (drawn as rectangles) as a set of arrows going back and forth between these external parties and the system.
To draw the Level 1 and Level 2 DFDs, we used to "explode" the single bubble into "modules". The dataflows shown in the Context Diagram would still need to be shown, but this time, (1) the arrows would terminate at one of the smaller bubbles representing a particular module of the system, (2) the external parties themselves would no longer be shown and (3) there would be new arrows showing dataflows between modules of the system and not involving external parties.
I now think the Context Diagram is the modelling tool for SOA. The dataflows going back and forth between the system and external parties that deal with it form the "service contract". We can express this in SOAP or REST terms. That really doesn't matter.
When we begin to "explode" the single bubble representing the system as a whole into smaller "modules", we are entering the world of domain design. This is no longer SOA. In the old days, the inter-module dataflows were also procedural. Today, they're method calls on objects.
I wrote earlier that when a student embarks on the study of Zen, the mountains are nothing more than mountains. Partway through the training, the mountains are no longer mountains. But finally, when the student has mastered Zen, the mountains are once again mountains, but they're somehow not the same as what they were.
Here's the SOA analogy:
Back in the eighties and early nineties, when systems and modules were purely procedural, we used to draw Context Diagrams and consider them to be Level 0 Data Flow Diagrams. Then we used to use the same paradigm to further explode the Level 0 DFD into Level 1 and Level 2 DFDs.
In the mid-to-late nineties, when OO thinking predominated, we stopped using Context Diagrams and DFDs altogether. We started using UML's Class Diagrams and Sequence/Interaction diagrams and began to look down upon procedural thinking.
In the new millennium, with SOA thinking in vogue, we need to start using Context Diagrams once again to define our service contracts, but we must no longer use the same paradigm to "explode" the single system bubble into modules. Leaving the Context Diagram in place, we must dive below that level and independently model the underlying domain using OO thinking. Alternatively, we build the domain model first, and then independently draw a Context Diagram around it, with a single bubble completely encompassing the domain model and terminating dataflows to and from external parties. Either way, we must then reconcile the two layers by creating a layer of "services" that sit within the Context Diagram's bubble and outside the domain model and translate between the external-facing procedural view and the internal-facing OO view. This service layer would be responsible for the specific transformation that I call The Viewpoint Flip.
A diagram would illustrate this better.
So you see, grasshopper, the mountains are once again mountains, are they not? But they're not the same as when you started on this journey. The Buddha-ness pervades all things, but the SOA-ness and Object-ness live in different worlds.
To draw the Level 1 and Level 2 DFDs, we used to "explode" the single bubble into "modules". The dataflows shown in the Context Diagram would still need to be shown, but this time, (1) the arrows would terminate at one of the smaller bubbles representing a particular module of the system, (2) the external parties themselves would no longer be shown and (3) there would be new arrows showing dataflows between modules of the system and not involving external parties.
I now think the Context Diagram is the modelling tool for SOA. The dataflows going back and forth between the system and external parties that deal with it form the "service contract". We can express this in SOAP or REST terms. That really doesn't matter.
When we begin to "explode" the single bubble representing the system as a whole into smaller "modules", we are entering the world of domain design. This is no longer SOA. In the old days, the inter-module dataflows were also procedural. Today, they're method calls on objects.
I wrote earlier that when a student embarks on the study of Zen, the mountains are nothing more than mountains. Partway through the training, the mountains are no longer mountains. But finally, when the student has mastered Zen, the mountains are once again mountains, but they're somehow not the same as what they were.
Here's the SOA analogy:
Back in the eighties and early nineties, when systems and modules were purely procedural, we used to draw Context Diagrams and consider them to be Level 0 Data Flow Diagrams. Then we used to use the same paradigm to further explode the Level 0 DFD into Level 1 and Level 2 DFDs.
In the mid-to-late nineties, when OO thinking predominated, we stopped using Context Diagrams and DFDs altogether. We started using UML's Class Diagrams and Sequence/Interaction diagrams and began to look down upon procedural thinking.
In the new millennium, with SOA thinking in vogue, we need to start using Context Diagrams once again to define our service contracts, but we must no longer use the same paradigm to "explode" the single system bubble into modules. Leaving the Context Diagram in place, we must dive below that level and independently model the underlying domain using OO thinking. Alternatively, we build the domain model first, and then independently draw a Context Diagram around it, with a single bubble completely encompassing the domain model and terminating dataflows to and from external parties. Either way, we must then reconcile the two layers by creating a layer of "services" that sit within the Context Diagram's bubble and outside the domain model and translate between the external-facing procedural view and the internal-facing OO view. This service layer would be responsible for the specific transformation that I call The Viewpoint Flip.
A diagram would illustrate this better.
So you see, grasshopper, the mountains are once again mountains, are they not? But they're not the same as when you started on this journey. The Buddha-ness pervades all things, but the SOA-ness and Object-ness live in different worlds.
4 comments:
Hmmm, i can see how this could be useful. Perhaps used in conjunction with persona mapping. I've found if you focus on the business customer (to be responsible for the "what is to be built"), mapped to functional requirements, while maintaining a clear view of external factors and customer needs, then let the business analyst do the fact-based supplemental groundwork. you can get the technology staff involved early to provide feasibility and balance (what I want versus what can be built on the shcedule/budget).
Read more at http://www.bluedog.net/weblog/termini/
While I'm all for context diagrams, I think that the services in your diagrams are more along the lines of service-layer components.
I would consider a service as being such that it encapsulates entities (from your diagram), and, as such, other services could not interact with those entities without going first through the service "interface" - ie sending it a message. I include in this a "service" calling an entity which calls into another entity used/owned by a different service.
Does that make sense?
Yes - i think I understand. Service orchestration comes into play in the scenario you describe.
I suppose when you consider security or some other 'universal' service, your model is spot on.
Hey i got very good material for DFD on http://dataflowdiagram.blogspot.com
Post a Comment