I can recall a recent shopping expedition in which I was searching for the perfect bath robe. Being a frequent traveller, I am used to having these “one size fits all” bath robes not fit my frame very well…and definitely wanted to improve the bath robe wearing experience considerably…at least at home.
I quickly realized that “One Size” was not my size. It turns out that I needed XL…now I am a happy camper with a properly fitting bath robe.
(Fairmont San Jose…if you are reading this….c’mon, buy some XL robes already)
Ok…so now you’re wondering “Is this guy for real? Is this all he thinks about? Bath robes?”. I am for real, and I felt that the bath robe story illustrates how I feel about an activity going on over at OASIS to develop a set of patterns & anti-patterns for implementers of Service Oriented Architecture.
A recent “anti-pattern” that has been discussed is about having too many services. The argument is that when we have too many services, it becomes dificult to find and invoke them. It would be better to group related services together and reduce some of the noise.
Now…in some architectures this could be a reasonable anti-pattern. I am sure there are SOAs out there that do not have any mechanism for classifying and managing services so as to help consumers to efficiently make use of a large body of services. On the other hand, I am also sure that there are SOAs out there that use an efficient, local transport which allows for fine grained services to be employed without serious performance penalties, and use a registry system (UDDI, ebXML, ISO 11179, …) to classify and manage their services.
I don’t mean to pick on this particular anti-pattern (In fact, the Blueprints TC has more or less dropped this as an anti-pattern)…I actually mean to attack the parent concept of all this, which is that of a few practitioners of a particular architectural style making broad statements about what is good and bad. This frustrates me to no end since I have spent the last year trying very hard to formalize Service Orientation as a valid software development paradigm. What the software industry needs now is a really good understanding of what Service Oriented Architecture really is, and what it means to their organizations in the long term. Generalizations such as “Don’t create hundreds of services.” or “Create hundreds of services.” are not really useful because those statements only apply in certain circumstances. Practitioners need help understanding when and why they should go coarse or fine grained…and that is the goal of foundational work such as SOA-RM.