Confessions of a Service-Oriented Abuser
Mahesh H. Dodani, IBM Software, U.S.A.
|
 |
COLUMN
PDF Version |
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):
- For a single class, I used the State pattern to implement
the instance variables to facilitate flexibility in changing the
behavior of the
instance based on its state and the Stategy pattern to implement
the methods to facilitate flexibility in the choice of algorithms.
For
the more complex methods, I used the Bridge pattern to ensure that
the interface of the method was decoupled from the actual implementation,
providing even greater flexibility. I used the Adaptor pattern
to implement the interface defined by the class using existing legacy
code.
-
For a grouping of instances of a class, I applied the Chain of Responsibilitiy
pattern to facilitate the flexibility of allowing the handler of the
request to be determined dynamically. Additionally, I used the Composite,
Iterator and Visitor patterns to group the instances into a tree-like
structure and to facilitate uniform access and treatment of the organized
objects. For a hierarchy of classes, I used the Façade pattern
to ensure that the entire set of classes could be accessed through
a single interface which I could separate from the implementation.
To create objects that are part of a family, I used the Abstract
Factory, Builder and Factory Method patterns to facilitate flexibility
in creating
instances. In some cases, I achieved greater flexibility using the
Prototype pattern to clone objects from existing ones rather than
creating them as instances from a class.
- For the clients of objects, I used the Observer pattern
to facilitate flexibility in how the client reacts to changes in
the object. Furthermore,
I used the Proxy pattern to completely decouple the methods provided
by the object from the manner and location from which they need
to be accessed.
As I became more abusive, I requested help from you in resolving
the following issues:
- How do I know when a pattern is really applicable, and
will have the needed impact on the application?
- How do I know that the application of the pattern has made
the application more flexible and reusable?
-
Will the application become “better” after the patterns
are applied? How do I define “better”, and determine that
the application has become “better”.
2 REMISSION FROM ABUSING PATTERNS
The 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:
- AntiPatterns which documents bad practices using the same template
as patterns. It therefore identifies common problems with solutions,
and then show how to refactor the solution to get rid of the problem.
Several of these antipatterns deal with my problem of applying patterns
just for the sake of applying patterns (e.g. BigDesignUpFront, DesignForTheSakeOfDesign,
PolterGeists) and other (not really categorized as antipatterns)
ways of handling “smells” in your design and implementation.
I was able to leverage these antipatterns and their refactored solutions
to bring back some sanity into my design and coding practices, and
slowly wean myself off using patterns for the sake of patterns.
-
Using larger grained assets through a gradual progression
from design patterns to frameworks and finally to architectures. My
first step was to move from design patterns to components, which
allowed me to break away
from the fine-grained confines of objects to the large-grained
world of components, and from the constricted inheritance-based flexibility
to the more powerful world of composition. From components, it
was
easy to transition into architectures, which provided the most
effective antidote to my design pattern abuses. Layered architectures
allowed
me to separate functionality and concerns between layers that have
well defined interfaces (and consequently hidden implementations)
to interact with – typically layers (from the outside in) include
presentation, business logic, persistence, integration and enterprise
applications. Within each layer, I can implement the required functionality
(maybe through components, and the components in turn are implemented
via objects.) The next step was to evolve to component architectures
where the components themselves were considered first class citizens,
and this led to using interacting components as the primary mechanism
to build flexible systems.
- Agile methods facilitate individuals interacting with each
other and in close collaboration with their customer to build
incremental versions of the system and quickly respond to needed
changes. Agile methods forced me to focus on particular parts
of the system, and build flexibility for one piece of functionality
at a time.
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 SERVICES
As 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
- Simple Object Access Protocol (SOAP) is the XML based messaging
specification that defines the message envelope content, the encoding
rules for the
data types, and conventions for defining requests and responses.
SOAP is vendor neutral, and can support any language, programming
model,
and platform. Implementations of SOAP exist in Java, Perl, C/C++,
and C#.
- Web Services Definition Language (WSDL) is the XML based
description of a web service as a group of ports which are in turn
defined by associating
a network address with a reusable binding. Each binding defines
a group of operations (port type) that is associated with a protocol.
Each
operation in turn is defined in terms of messages and types. WSDL
facilitates the abstract definition of web services to be separated
from their
concrete implementations.
- The Universal Description, Discovery and Integration (UDDI)
specifications define a way to publish and discover information about
Web services.
The core component of the UDDI is the UDDI business registration,
an XML file used to describe a business entity and its Web services,
and
which are used to provide white pages (service provider), yellow
pages business categories), and green pages (technical binding information.)
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:
- For every interface and API in my system, I implemented
a web service. I replaced every (remote) call or point-to-point
message with a SOAP message.
- I created these services for every application in my system,
including for the non-business logic functionality that I had developed
to support
the application.
- I created UDDI based service registries to support the
services that I was creating for each application, and used that
to find the services
that I needed.
- I created lots of fine-grained services to handle the interactions
that I needed between the presentation and business logic functionality.
So, for example, I would have individual services to get each of
the attributes needed to populate information about a cutomer.
- I quickly found that I could convince customers who had
spent all their time on putting in complex and expensive middleware
to facilitate integration
to change over to using point-to-point integration using services.
Basically, I would wrapper the two applications that needed to
be integrated as web services, and then invoke them using SOAP messaging.
The fact
that we were using standards convinced them that it would be cheaper
and easier to maintain.
- I relied on web services to reach any part of the system
that I wanted, and basically used that as the unifying structure
across all applications.
I argued that this made the systems simpler and therefore easier
to change, manage and maintain.
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 ABYSS
I 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
|
