Service-Oriented Architecture
The Art of SOA - More Than Optimal Is Ineffective
SOA refers to an architectural solution that creates an environment in which services and service consumers coexist
Jun. 13, 2006 12:00 PM
Services
Services are any functionality
provided by a provider to a consumer following classical definitions.
It's usual practice to realize these services using either software
assets (or code) or business processes. It's also possible for these
services to be leaf-level (atomic services) or composite (or aggregate
or group of leaf-level services).
Some of the important points in this regard are as follows:
- How many services have to be automated?
- How many services are necessarily manual (due either to the
difficulty of automation or the complexity involved in automating them
or due to leaving them manual since they aren't "in focus" or key
services)?
- How many services are expected to be called from outside
(B2B services) and have to be registered on external registries like
UDDI?
- How many services are expected to be called from the intranet and have to be registered in the internal or corporate registry?
- How many services don't have to be reusable or are legacy,
and are meant only for internal consumption. These services can be made
directly invocable without a complete registry lookup optimizing
performance.
- How many services have to be developed using code and how many using business processes?
- What are the service discovery mechanisms? Is it necessary to
support only registry lookup or is it also necessary to support
advertising and use the protocol for service discovery? Use advertising
and acceptance only with external services.
- Use consequential services or time-bound services where
possible. This reduces the load on the registry and improves
performance.
Registry/Repository- Is it necessary to support an internal registry?
- Is it necessary to include interfaces in the external registry?
- What is the structure of the metadata? By identifying the
basic information structure operated together, it's possible to arrive
at a suitable granularity for the metadata. For example, if it's
necessary to operate on the customer as an entity with all the
associated attributes, it's possible to increase performance, but it
would impact granularity.
- A registry typically stores all the information relevant to
the SOA implementation - from basic interface contract definitions to
more sophisticated meta-service templates. The following provide some
decision points in this process:
> The first step is identifying the data that has to be stored in the repository.
> Which interface contracts have to be global and so go into the
global repository and which interface contracts have to be local and go
into the local store?
> Does the interface contract comply with any standards?
> Does the interface contract support advertising and accepting? For
example, if a specific provider provides an "advertising" mechanism for
service discovery, does the interface contract support the scheme? Are
the advertising and accepting mechanisms validated for "clear
requirements" or is it possible to use direct invocation for such
services as well?
Broker
Do we need a broker? How much
metadata has to be stored and accessed from the broker? If there are
only a few services, it may be a good idea to use a homegrown broker or
a simple register-lookup broker. However, if there are lots of
services, it may be necessary to use a standard broker. The
sophistication of the broker depends on the number of services, among
other things.
Integration Media
- What is the integration media? Do we really need a sophisticated
ESB? Can we make do with simple Open Source middleware or can we use
simple homegrown middleware? These are some of the questions that help
in identifying the level of sophistication required in the integration
media.
- What is the level of security to be supported?
Even if we use http over LAN, we can still comply with SOA
principles, it's just a matter of business requirement. SOA doesn't
mandate any specific integration media.
Maturity of an Organization versus SOA
The
maturity of an organization is usually measured in its performance
against a specific set of goals. These goals are business drivers that
help in defining the scope of the organizational focus, which is always
on meeting business goals and includes, among the other things,
increasing profits and reducing risks.
So, to comply with the maturity models existing in the industry, it's
necessary for an organization to meet some or all of the SOA principles
in such a way as to maximize its applicability to the business.
As we can see in Figure 2,
the SOA solution consists of multiple components - an infrastructure
layer, a set of applications, a set of business processes, and best
practices. Though expertise in SOA architecture is the foundation of
the overall solution, the other components, namely the business process
expertise and applications expertise, are absolutely required to arrive
at an end-to-end solution to the problem at hand.
As we can see,
the maturity of an organization is reflected in the effectiveness with
which it meets its goals, and so increases its profits and reduces its
risks. Maturity can't be inferred by activity per se, but it can be
inferred in the way an activity is done. However, it's necessary to
keep in mind that the set of activities needed to meet business goals
are always specific to the organization and specific to every
enterprise. Once an organization has stated its goals, plans, and
activities, maturity is the measure of how well these activities are
done.
In this context, we have to keep in mind that every business has to
align its business goals with its IT capabilities. Even a small teashop
has to do business-IT alignment, and even a huge organization does the
same business-IT alignment. However, a small organization can use
manual processes (that may or may not be documented/standardized) and a
huge corporation can use a lot of automated processes. To decide which
company is more mature, it's necessary to weigh the execution of the
business activities to meet the goals in the context of the size of the
business. A good maturity study may conclude that a small company with
a few employees is better aligned to SOA than a huge corporation with
lots of employees.
One must also keep in mind that every huge corporation is the result of
a sustained existence in business, improving on itself year after year.
A big modern corporation was once a small company. Hence the rules for
SOA maturity should be interpreted in the light of the size of the
organization, the documented business goals or practices, and expected
future plans.
Summary
In today's context, it's good to
understand clearly what SOA can do and what it is. And it's more
important to understand how much SOA is enough for a given
organization. In other words, the optimum application of SOA can result
in enormous savings and return for an organization. Beyond the optimum
point, any SOA application would only bring limited results. We
attempted to throw some light on some of the important factors to be
considered in making this decision.
About Raghu AnantharangacharRaghu Anantharangachar is a solution architect with the Hewlett Packard Global Delivery India Centre, Bangalore. He has over 15 years of experience and has worked on porting, network management, and system integration projects in the past. He has a Bachelor's degree in Computer Science and Engineering from Bangalore University and a Master's degree in Industrial Management from the Indian Institute of Science, Bangalore.