|
About SOA: Why, What, and How by Jeff Zhuk What is
Service-Oriented Architecture (SOA)? SOA is a software architecture style that focuses on services across multiple enterprise applications. Although SOA sounds very technical, the SOA approach is more about bridging business and technology and touching some organizational issues. SOA is not a tool or technology; it’s rather a concept which shifts development focus and overall mentality from applications to services. Why SOA and where
it works best? SOA fits best into big corporate IT structures with multiple applications built-in-silos that often duplicate their main business functions. |
SOA simplifies IT infrastructure and accelerates the process of transforming business idea to its implementation. In the transition to SOA, current applications (that represent today a mix of business and service logics) will become a thin layer that orchestrate services and expose them via portal faces.
integration SOA leads to greater reuse and smaller maintenance by creating robust and scalable services registered and discovered at the enterprise service bus. The services will use data layer to interact with data sources and will be shielded (by stable data layer API) from changes in the data structures.Translate SOA into
savings from maintenance:
SOA simplifies systems and gives less space for errors.
Translate SOA into new
sales:
SOA delivers strategic advantage of quick business changes and more opportunities for sales (this is only true when business is working with IT to capitalize on this advantage.)
How to perform SOA?
SOA requires more “disciplined” approach to SDLC, transition to agile methodology, and architecture presence at each development step from requirements till deployment.
Important factor is early business involvement into the process and persistent communications between subject matter experts, architects, and developers.
SOA is a natural step
in software architecture evolution.
Anyone remembers the days when no operating system (OS) existed?
That was a long time ago. Back then, software programs included hardware support, data drivers, and business logics all together.
Today we call this “spaghetti code”, but at that time it was necessity for programs to run.
Then OS vendors and database vendors took part in the process. Software evolved into layered and component-based architecture and most of programmers today work in the application layer space.
But software architecture evolution doesn’t stop there. What drives the evolution?
Real Problems!
While SOA was an old concept, the current technology paved the way for efficient implementations.
In the SOA world applications are dissolved into orchestrated services and orchestrations (that represent service calls and business rules) are shifted on the top of the software pyramid.
On the slide you can see yellow triangles on the left. They represent old fashioned applications or application layer. This layer is going to split into service and business intelligence layers displayed in the pyramid.
The change in architecture will change development focus from applications to services.
Here is an example
of re-packaging Applications into Orchestrated Services
You can see multiple
applications (we can see only two but it could be more).
Each application has
its own implementation of the LOGIN function
We remove this code from applications and (after analysis) consolidate into a service deployed in the Service Layer. This service will have its own cache and management.
What’s left in the applications? Applications shrink to a thin orchestration layer. One line will call the
Login service scenario when needed and provide necessary parameters.
Here is an example
of the Login scenario that consists of two prompts for name and password and
returns user’s profile.
Another scenario sample
is a composite service that consists of several small services.
This is the Order
scenario that includes Login, GetOrderData and PlaceOrder services.
These scenarios are
written with simple XML that can be easily processed.
The next step is to
replace if/else logic with business rules and operate with close to natural
language expressions while describing business rules and requirements.
This replacement
will give us a real jump in productivity. Here we gain a strategic advantage
enabling quick changes of business rules.
On this picture
multiple business terms, rules, and scenarios are collected into a SOA dictionary
knowledgebase. SOA Dictionary is a collection of related business and technical
terms and documents that represent a navigation map from descriptions of
business functions to their technical implementations as services.
Subject Matter
Experts converse with SOA Dictionary while writing requirements.
Imagine that you
finished a sentence and the machine talks back to you: “you just said this, did
you mean that?”
The machine will map
your language to existing terms and help you to transform requirements into
service orchestrations.
One of the first things in SOA projects is creating an inventory of
business functions and related technology implementations. We often call it a
Business-to-IT “AS-IS” map.
Then we map business functions to services in the TO-BE Business
Process Model (BPM).
The slide below displays a BPM captured with one of SOA tools. In the
model each icon reflects a business function performed by a service. There are
SOA tools that monitor service performance and provide BAM, BEM, and CEM.
Here are the explanations to these abbreviations related to service
monitoring and management.
•
Business Activity Monitoring (BAM) monitors business processes in real time in an effort
to support operational improvements
•
Business Event Management (BEM) monitoring all current processes to provide
meaningful alerts and analytics to users
•
Performance Analysis and Notifications
•
Complex Event Processing (CEM) correlates events
into patterns that may represent a threat, looks for a real reason for
exceptions and invoke an action to prevent serious system failure
SOA delivers Simplicity in IT infrastructure; provides less
space for errors and easier maintenance, and most importantly achieves a great
acceleration in the process of transforming business ideas into their
implementations.
This doesn’t come automatically. SOA requires:
governance of the development process; greater architecture presence in all
steps of the development process; Training sessions, architecture, design, and
code reviews; New Skills, New Processes, … and New Ideas
References:
Integration-Ready
Architecture and Design
Software
Engineering with XML, Java, .NET, Wireless, Speech, and Knowledge Technologies,
Cambridge University Press, Jeff Zhuk, ISBN
0521525837
http://cyc.com – Cycorp,
Inc., a leading
provider of semantic technologies
http://javaschool.com/about/publications.html
- more publications