1 MEET PAT TERNA BUSER“One comment I saw in a news group just after patterns started to become more popular was someone claiming that in a particular program they tried to use all 23 GoF patterns. They said they had failed, because they were only able to use 20. They hoped the client would call them again to come back again so maybe they could squeeze in the other 3. Trying to use all the patterns is a bad thing, because you will end up with synthetic designs—speculative designs that have flexibility that no one needs.” – Erich Gamma, http://www.artima.com/lejava/articles/gammadp.html Hello, my name is Pat, and I resemble the person that Erich is talking about in his quote above. I introduced my pattern abusing story to you in 1999 [Dodani, M., "Rules are for Fools, Patterns are for Cool Fools", Journal of Object-Oriented Programming, Vol. 12, No. 6, pp. 21-23, SIGS Publications, October 1999], and asked for help in getting over my abuse. To summarize my abuses, I applied patterns mercilessly to any software development project, and in fact came up with a “pattern” to abuse patterns – which ensured that I could apply almost every pattern (yes, I was disappointed that I could not apply all 23 as well) to the implementation of a single class hierarchy (I assume that you are familiar with the Gang of Four Patterns):
As I became more abusive, I requested help from you in resolving the following issues:
2 REMISSION FROM ABUSING PATTERNSThe outpouring of support and help from the community was overwhelming. I got help that focused on several facets of my abuses – including, unfortunately, how to increase the number of patterns that I could use in my approach above! The key antidotes that I received that helped me overcome my sickness were the following:
Using the above three antidotes, I was able to push myself into remission from abusing patterns. The architectures, frameworks, and components that I was having to deal with in addition to the design patterns made my design and development life complex and engrossing. These higher-level abstractions allowed me to use a model-driven approach to my development, so that by the time I came to implementing the components with objects, I knew which patterns would be applicable to provide the flexibility in the smaller context of implementing the needed interface. The agile methods gave me further focus by facilitating iterative and incremental feature/function driven. 3 RELAPSING INTO ABUSING SERVICESAs you must be aware, a few years ago, the entire technical world was awash with services – here was the ultimate construct for building flexible systems. A Service is a discoverable software resource which has a service description. The service description is available for searching, binding and invocation by a service consumer. The service description implementation is realized through a service provider who delivers quality of service requirements for the service consumer. I got introduced to services through web services. Web Services are self-describing, self-contained, modular applications that have to be described, published, found, bound, invoked and composed. Web services conform to the structure summarized in Figure 1. Fig. 1: The Web Service Structure As shown in the figure, service providers create application functions that are available on disparate implementation platforms as web services and describe them using a standard definition language. These services are published in a service registry. Service requestors who need a particular type of service search the service registry and find the desired service. Once a service is found the requestor and the provider of the service negotiate to access and invoke the service. The other beauty of web services is that they are standards based, implying that the underlying technologies supporting web services need to be platform and implementation neutral, and are therefore specified in XML. The core technologies include
So, this was great – I was able to relapse right back to working with smaller-grained constructs (services), achieve great flexibility, and I had the added bonus of working in a standards-based environment! It was just too good to be true. I took to services, with the same excitement and fervor that I did with objects. Very soon, I realized I had relapsed right back to abusing services. Here is what I was doing in my design and implementation:
Of course, I soon realized that I was back to my old pattern abusing days – taking advantage of my prowess with this new services construct and the hype surrounding it to brow beat any customer into agreeing that I was leaving them with a much more flexible, changeable and cheaper to maintain system. Of course, I used the metric of number of services as the key indicator of these “qualities”, along with the added “open standards” that were now an integral part of the system. Like before, the reality was far from what I was selling. The proliferation of services and registries, the unstructured nature of the system, the number of fine-grained services, and the point-to-point integration quickly led to systems that performed poorly, were difficult to maintain, and were expensive to make changes to. 4 RISING BACK FROM THE ABYSSI quickly realized that I had relapsed so far into the dark side again that it was time for me to go back to my rehabilitation “pattern.” Using the same techniques and approaches that I did to get out of my pattern-abusing nightmare, I was able to fight back from my services abyss. I got involved with Service Oriented Architectures and use those first to organize and structure the services that I would build and use and to define how these services could interact with another through the Enterprise Service Bus. I also determined how to handle qualities of service effectively through the layers of services. I used appropriate methods to help me identify services that are appropriate to the domain that I was involved with, starting first with modeling the business process, and then establishing the services needed to implement the process. I used “smell” tests to determine the appropriate validity and granularity of services. To provide the services, I used components to first pull together relevant functionality and then to make these available as services. I composed components and services to provide larger grained services. Learn from my story, and heed my words – architecture is the salvation for your technical soul. About the author
|
![]() |
![]() |
Mahesh Dodani is a software architect
at IBM. His primary interests are in enabling communities of practitioners
to design and build complex on demand business solutions. He can
be reached at dodani@us.ibm.com. |
Cite this column as follows:Mahesh Dodani: “Confessions of a Service-Oriented Abuser”, in Journal of Object Technology, vol. 4, no. 7, September-October 2005, pp 19-24, http://www.jot.fm/issues/issue_2005_09/column2