Monday June 13, 2005 JavaOne Pitcher
<nl_NL>
Vanavond heb ik me ingeschreven als T-shirt tosser. In eerste instantie leek het mij wel aardig om deze entry als titel "I'm a Tosser" mee te geven, maar dat is waarschijnlijk nogal verwarrend voor onze vrienden in de UK.
Hoe dan ook, betekent dat dat ik tijdens JavaOne op dag 2 (zet het in je agenda) in staat ben om een door James Gosling zelf geproduceerd Duke T-shirt in je maag te splitsen. Maar alleen als je zelf goed kunt vangen. En als ik je ken. (Ik ken mensen pas echt goed als ze een biertje voor me hebben gekocht...)
</nl_NL>
( Jun 13 2005, 10:03:50 PM CEST ) Permalink Comments [0]SOA Smells
Ever heard of "Code Smells"? Let me give you an introduction if you haven't. "Bad Smells in Code" was an essay by Kent Beck and Martin Fowler, published as Chapter 3 of "Refactoring: Improving the Design of Existing Code". This is what Wikipedia says about it:
"In the community of computer programming, code smell is a jargon term used among hackers to refer to a symptom that indicates something may be wrong: a suggestion at the possible presence of an anti-pattern."
The thing with "Code Smells" is that they can indicate that there might be a problem in your code, but they can not guarantee that a specific piece of code is wrong. You still need to make a decision based on the trade-offs involved.
More than half a year ago, we were trying to figure out if we could identify a deterministic approach for defining the appropriate service layer definitions. (Like the granularity of a service, and some proper guidelines for dividing the entire problem space up in several domains.)
After a while, we decided that it might be a little to ambitious to come up with a deterministic approach. We did however agree upon a couple of key indicators that would at least give you a hunch on where to put your service boundaries. The indicators were based on analysis based UML deliverables, and included rules like this:
- Search for tightly coupled clusters of types in your Domain Object Model and defines service boundaries at the edges of these clusters;
- Search for commonalities in Use Case steps; (Those commonalities might justify another service layer.)
- Search for commonalities in how typical scenarios affect snapshots of the Domain Object Model; (Commonalities in affected types might also call for another service layer.)
- Make a distinction between your "Business Process" types and "Business Concept" types in your Domain Object Model. "Business Process"-related types do only exist for the lifetime of a certain business activity; "Business Concept"-related types survive a certain business activity.
We labeled it "SOA Smells", since it reminded us of "Code Smells". A bad smell in refactoring does not necessarily mean that you must refactor something. It just means that you need to consider a piece of code for refactoring. Similarly, a "SOA Smell" does not give you the ultimate and ideal service boundary, just like that. Instead but it simply highlights a few potential candidates, before you consider all of the different trade-offs.