The two most common problems dogging SOA projects
By Cameron McKenzie
What are the two most common mistakes that application architects make when designing a service oriented architecture (SOA)? According to Arnon Rotem-Gal-Oz (@arnonrgo), the author of the Manning book SOA Patterns, low level granularity and high level understandings are the most common weak spots in a service oriented design.
"People tend to get the granularity of services wrong. They make them either too big or too small." Building appropriately coarse, but not too large SOA components shouldn't be a mystery, and in that vein, Rotem-Gal-Oz believes we can garner wisdom from an old children's fable. "You need a Goldilocks approach to SOA development where the services you create are not too big and not too small," he says.
The nanoservice anti-pattern
Arnon Rotem-Gal-Oz deals with the smaller half of the granularity issue in his SOA Patterns book during his discussion of the the nanoservice anti-pattern. "The nanoservice is an antipattern where a service is too fine-grained. A nanoservice is a service whose overhead, communications, maintenance and so on, outweighs its utility." Creating nanoservices, which often goes hand in hand with the false assumption that bandwidth is infinite and that data-packet transportation cost are zero, leads to performance issues, fragmented logic and the creation of services whose maintenance overhead outweighs their utility.
And what is the other, perhaps more pervasive issue that software development teams must deal address?
Apparently, it's a fundamental misunderstanding of the basic principles and concepts pertaining to SOA. "An even more important issue is just misunderstanding what SOA is," says Rotem-Gal-Oz. Many organizations make the mistake of believing that if they are developing web services, then they must be SOA compliant, but nothing could be further from the truth.
Exploring SOA patterns and anti-patterns
It is just as easy to create tightly coupled web services as it is to create tightly coupled applications using Servlets, Struts or just plain old Java code. A key part of the SOA approach to development is creating loosely coupled components that makes it possible to "compose services together in a way that creates new business processes," says Rotem-Gal-Oz. But when architects don't truly understand fundamental SOA principles, they end up with systems that are tightly coupled and hard to manage.
In Rotem-Gal-Oz's publication SOA Patterns, three other service anti-patterns are discussed, along with the nanoservice antipattern mentioned earlier, namely the knot antipattern, transactional integration antipattern and the same old way antipattern.
Developing service oriented architectures is always a challenge, even for the most experienced architects and developers. But for every experienced developer out there, there is a aspiring architect who is getting their feet wet in the world of distributed computing. To ensure the distributed systems organizations are architecting are as problem free as possible, Arnon Rotem-Gal-Oz's insight should be taken to heart, as developers work hard to really learn the fundamental principles of SOA design, which includes figuring out the Goldilocks principle of developing components that are exactly the right size.
Have you found using patterns to be helpful or painful when doing application development? Let us know what you think about the industry's love affair with software patterns.
SOA Patterns Arnon
Design Patterns: Elements of Reusable Object-Oriented Software Richard Helm
Head First Design Patterns Eric Freeman
Patterns of Enterprise Application Architecture Martin Fowler
05 Apr 2013