Making SOA Leaner and Cleaner to Maximize Profits (Part I of II)
Mohamad Afshar, VP of Product Management, Oracle
David Chappell, Vice President and Chief Technologist for SOA, Oracle
Walking through the IKEA store a few weeks back I noticed a poster highlighting
IKEA's green credentials and the trio: "Reduce, Reuse and Recycle."
I started thinking, as any SOA practitioner should, about the implications of
the green movement and its parallels in how we build SOA solutions. Some of
the reasons that we see customers adopt SOA include: interoperability, ease
of development and maintenance, visibility, and, of course, reuse. At the superficial
level, SOA is somewhat green because it encourages reuse of existing capabilities
as services. What about recycling? And what about reducing waste and inefficiencies?
Reducing the impact on the surrounding environment and systems?
A successful SOA project usually results in driving more traffic to backend
systems that will need to be scaled out, taking more hardware resources not
less. In some sense, a service consumer is naturally akin to a greedy consumer
that hogs resources of backend systems and drives traffic through them grinding
the CRM, finance applications, legacy systems and databases to the edge -- a
re-incarnation of the free-rider problem if you like.
So where does the wastefulness come from in SOA, and what can be done to manage
As with the green movement in general, the solution boils down to being a responsible
consumer. We are all being taught to be more conscious about consumption every
day in the real world. In the case of SOA the things that are being consumed
are backend capabilities that provide services Just because you can call a service
a hundred times doesn't mean you should. Conversely just because a specific
service consumer calls your service a hundred times only for you to return the
same result, it doesn't mean that you should do the same amount of work for
each service call. What is beautiful about the solution that we talk about here
is that it results in reducing the operational risk associated with doing SOA
in addition to taking out the waste!
Reduce: Where do the inefficiencies come from?
If a service consumer is being wasteful, then the obvious question is where?
As you look into the way that applications are built in a SOA environment, you
start to see. We recently looked at a wireless telco's Web portal where customers
can view, print, pay and add additional service to their account. This system
is linked to billing, CRM, provisioning and legacy systems. Although the application
was built using SOA principles, what we noticed was that during the typical
customer interaction, the billing system in particular was called an average
of 3 times. This is a big deal.
Additionally, the Web portal also manages changes to the subscriber's services
not as an EJB, but as state data in an existing database backend. Finally, we
observed that a provisioning process that was kicked off as a result of changes
to services ended up pulling or updating the customer profile information from
the Home Subscriber Service (HSS) multiple times. The Web front end also pulled
the profile information from the HSS at least once.
The HSS is an operational system that has one hand in the IT world and the
other in the network world so accessing it is only for the privileged!
Taking a high level view of the application unearthed the following characteristics
that lead to wasteful consumerism:
1. Multiple Calls to Legacy Systems -- Multiple service requests were
made to the legacy billing system for information that was very unlikely to
change for the duration of the Web interaction. Accessing legacy systems costs
time -- a few seconds per interaction, and money. The latter is not so much
of an issue if you like paying big iron vendors for more mainframe MIPS, otherwise,
it's of concern.
2. Hitting Backend Data Stores with Constantly Updating State Information
-- An existing database was used to store transient state data related to the
Web session. The state could have been managed in the mid-tier, e.g. with EJB,
but the customer was looking for a scale-out solution so they decided to use
the database as a state repository and store transient state data in the transactional
3. Multiple Read -- Write interactions with Services -- Multiple read
and update requests were made to the user profile in the HSS both in the Web
tier and also in the backend provisioning logic which was implemented using
a BPEL orchestration engine.
All these wasteful interactions put undue stress on the backend systems. The
solution to these ills is a mid-tier data caching / grid solution that enables
you to save on service invocations by caching results, allowing you to manage
state in the mid-tier in a scalable way.
What is a mid-tier data grid solution?
A critical part of a grid-enabled SOA environment is a mid-tier grid layer.
This layer provides a JCache-compliant, in-memory, data grid solution for state
data that is being used by services in a distributed service-oriented application.
The mid-tier distributed caching layer balances the in-memory storage of a service
instance to other machines across the grid. This effectively provides a distributed
shared memory pool that can be linearly scaled across a heterogeneous grid of
machines (which can include both high-powered, big-memory boxes, and other lower-cost
In a data grid-enabled, stateful service-oriented environment (one that makes
use of this mid-tier caching layer), all the data objects that an application
or service puts in the grid are automatically available to and accessible by
all other applications and services in the grid, and none of those data objects
will be lost in the event of a server failure. The fact that the application
has access to all data from an API, irrespective of the location of the data,
is called a single systems image. To support this, a group of constantly cooperating
caching servers coordinate updates to shared data objects, as well as their
backups, using cluster-wide concurrency control.
The key to this approach is in ensuring that a primary owner and an additional
backup server always manage each piece of data. This data can be anything from
simple variables to complex objects or even large XML documents. From the perspective
of the developer, the service is simply performing operations against a programmatic
interface to a collection, such as a Java map or a .NET dictionary. At any point
in time, all of the data grid nodes know exactly where the primary and backup
copies of all the data are stored, so the application doesn't have to! This
eliminates the massive overhead of each node having to find out where a piece
of data resides.
As shown in Figure 1, the request to put data into the map is taken over by
the data grid and transported across a highly efficient networking protocol
to the grid node P, which owns the primary instance data. The primary node in
turn copies the updated value to the secondary node B for backup, and then returns
control to the service once the proper acknowledgments are handled.
Figure 1: Primary/backup synchronization of data access across the SOA grid
Conversely, when the instance data needs to be accessed by a service, the data
grid calls the primary node which owns that instance data, and routes the data
back to the service or business object that is requesting it. A range of operations
is supported in this manner, including parallel processing of queries, events,
and transactions. In a more advanced implementation, an entire collection of
data can be put to the grid as a single operation, and the grid can disperse
the contents of the collection across multiple primary and backup nodes in order
One of the questions that you may ask is how do you ensure that the cached
data within the data grid is up to date, especially in cases in which a data
grid front-ends a database or transactional system. While the general discussion
of this issue is beyond the scope of this paper, you can ensure data is fresh
through policy-based cache expiry rules that are defined in the data grid or
use an event-driven mechanism in which changes to data are propagated to the
data grid at the same time as they are pushed through to backend databases.
What's the big deal with data grids? The data grid simultaneously provides
performance, scalability and reliability to in-memory data. So how does that
relate to what we want to deliver in a SOA environment, in relation to reducing
the impact on backend systems, check back next week and find out?
(Check back next week for Part II)
About the Authors
Mohamad Afshar PhD, is Vice President, Product Management within the Oracle Fusion Middleware development organization. His main focus includes vision, strategy, and architecture, with an emphasis on SOA, EDA and next generation. He works closely with customers advising them on their SOA roadmaps and has spearheaded Oracle's SOA Methodology. Previous to Oracle he was a co-founder of Apama, an algorithmic trading platform (sold to Progress). Mohamad is a frequent speaker at industry events and is a contributing author to business-oriented, technical, and academic journals. He holds a PhD in Parallel Database Systems from Cambridge.
Dave Chappell is vice president and chief technologist for SOA at Oracle Corporation, where he is driving the vision for Oracle’s SOA Grid initiative. Chappell is well known worldwide for his writings and public lectures on the subjects of Service Oriented Architecture (SOA), SOA Grid, the enterprise service bus (ESB), message oriented middleware (MOM), enterprise integration, and is a co-author of many advanced Web Services standards.
As author of several books including the O’Reilly Enterprise Service Bus book, Dave has had tremendous impact on redefining the shape and definition of SOA infrastructure. In his over 20 years of experience in the industry, he has built enterprise infrastructure ranging across client-server, web application servers, enterprise messaging systems, and ESB. Chappell and his works have received many industry awards including the "Java™ Technology Achievement Award" from JavaPro magazine for "Outstanding Individual Contribution to the Java Community" and CRN Magazine “Top 10 IT leaders” award for “casting larger-than-life shadow over the industry”.