Using SOA to Extend the Client Behavior of a Legacy App
without Changing the Application Code
Over the past few
years, the core tenants of Service Oriented Architectures(SOA) have gotten lost,
as most software engineers have drifted towards thinking of the term SOA as
being a synonym for Web Services. That is not a good thing! At the heart SOA is a set of core concepts
that can be useful or even critical in solving a variety of difficult technical
challenges.
We at CiBA have used
the SOA core concepts as a key component in our Knowledge Master platform which
is used to add guidance to existing applications without the need to touch or
even have access to the source code of the legacy applications. Knowledge Master is a CLIENT SIDE only
application that benefits greatly from an SOA architecture, yet out of the box
it neither includes nor relies upon any remote services.
The following diagram
illustrates the basic architecture of Knowledge Master:
The key concepts of
SOA are pretty apparent in our solution:
1.
Isolation of Process Flow -- Our proprietary Client Side orchestration engine (called Event
Master) sits on the windows PC along
side of the legacy application client.
As the user moves through the Legacy Application, The orchestration engine uses low level
Microsoft Windows facilities to monitor both the screens that are being
presented, and what the user is doing on those screens.
The orchestration engine gathers
information off of the screens (say the clients name and address) as the moves
through the screens. The information
that is gathered from the screens is then stored in a generic memory based data
structure that we call the context.
When the user interaction signals an important event in the business process
(say reaching a point where a bit of guidance should be given to the user, or
an error is detected and needs to be corrected), the orchestration engine calls one or more of the functional
components to respond to the business process event
2.
Isolation of Services—the orchestration engine uses its meta-data to determine the steps that
are needed to respond to a particular business event. It then calls the appropriate functional components, handing each one in
turn the context. Each functional component retrieves the
information it needs from the context, performs its task and if appropriate
updates information in the context,
before handing the updated context
and control back to the orchestration manager.
3.
Loose Coupling – The functional
components are completely unaware of the process flow or of the other functional components. They either get their state from the context, or use information in the context to reconstruct their state. Changing the implementation of a functional component does not affect the
process or the implementation of any of the other functional components.
While Knowledge Master is not a traditional
SOA architecture, it borrows heavily from and benefits greatly from the core
SOA concepts. Benefits include:
1. Flexibility
– The process or the behavior of the services can be altered using meta data
without the need to change the implementation of the functional components
2. Reuse
– The functional components can be configured through meta data and/or
information in the context to handle
a variety of related tasks. The
functional components become reusable and adaptable building blocks.
3. Easier
Implementation and Support – The functional
components perform specific, isolated tasks, so their implementation need
only be concerned with their specific task.
This makes design, implementation and support easier and more efficient.
4. Scalability
of Engineering Resources – Since work units are well isolated from each other,
it is much easier to parcel up the tasks and responsibilities
5. Extensibility
– Since the functional components all
take their state from the context, any Microsoft .NET application that can accept
a context as its only parameter can
be called from the orchestration manager.
This means that the list of possible functional components is endless. There are a few minutes worth of programming
overhead needed to pull information from the context and reconstruct state and
optionally a few more minutes to put results back into the context. But these are simple tasks that any .NET
programmer can handle. Pretty much
anything that .NET can do or call, can be wrapped up and added to the platform.
I could go on for quite some time, but I
think this is sufficient to drive home the point. Don’t confuse SOA with Web Services. The key SOA principles are very powerful and
handy tools that should be present in the hands and heads of all Software
Architects and Software Engineers.
