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.

 

Next Step: From Business as Usual

IT of the future: Semantic Cloud

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

Next Step: Next Step: From Business as Usual | IT of the future: Semantic Cloud Architecture

http://javaschool.com/about/publications.html - more publications