First, what is SOA

Service-Oriented Architecture (SOA) is an architectural style that supports service orientation.

Service orientation is a way of thinking in terms of services and service-based development and the
outcomes of services.

A service:

o Is a logical representation of a repeatable business activity that has a specified outcome (e.g.,
check customer credit; provide weather data, consolidate drilling reports)
o Is self-contained
o May be composed of other services
o Is a “black box” to consumers of the service

An architectural style is the combination of distinctive features in which architecture is performed or

The SOA architectural style has the following distinctive features:

o It is based on the design of the services – which mirror real-world business activities – comprising
the enterprise (or inter-enterprise) business processes.
o Service representation utilizes business descriptions to provide context (i.e., business process,
goal, rule, policy, service interface, and service component) and implements services using
service orchestration.
o It places unique requirements on the infrastructure – it is recommended that implementations use
open standards to realize interoperability and location transparency.
o Implementations are environment-specific – they are constrained or enabled by context and must
be described within that context.
o It requires strong governance of service representation and implementation.
o It requires a “Litmus Test", which determines a “good service”.

Another definition, as per the World Wide Web Consortium’s glossary  SOA is "A set of components
which can be invoked, and whose interface descriptions can be published and discovered".

Clear as mud?  We thought so, too.

To understand the concept, let’s think for a moment how the evolution of software development has
progressed over the years. In the beginning were languages like Pascal or C, where the user wrote a text
file of code and used a compiler to make a machine-readable version that could be run on the computer.
Sensible programmers (and the compiler writers, for that matter) placed commonly-used functions in
“libraries” – modules that could be included at will in a developer’s program to save having to write the
same lump of code over and over again.
The problem with the traditional model was that a function could only work with data types that it had
been written for. So it was no good having (say) a function printAsString() that handled decimal values if
you wanted to pass it some wacky user-defined type you’d just invented – you had to add a new function
to the library. So some bright spark came up with the idea of an “object” – a collection of stuff that
included both the data required to represent that object (“properties”) and the functions (“methods”) used
to manipulate that object. This approach removes the vagaries of having to maintain central function
libraries – you just include all the necessary code, and no more, in each object’s methods. Most of us now
work in an object-oriented world – not just with hardcode programming languages like Java but even with
things like PHP and ASP, which are happy to work in an OOP way even if you didn’t know it.

OK, to write an OOP program you work by instantiating (creating) an object and then using its methods
and/or passing it around. Now imagine that instead of that object’s definition being in a code file on the
computer you’re writing/running the program on, it’s on some other machine somewhere. So your
program says things like: “Hey, machine over there – give me an instance of a BOOKING object, and
here’s a CUSTOMER object to relate it to”.

That, in a nutshell, is SOA: a world in which we instantiate and use objects that aren’t necessarily on the
same machine. If you think this sound like a fancy name for a web service, you’re absolutely right – with
the caveat that web services are a component of, not a synonym for, SOA.

Taking it a little further If you’ve ever written a web service (try it, it’s very easy – particularly if you’re
using something like MS Visual Studio, where making a stand-alone function into a web service is as
easy as re-declaring it as a “Web Method”) you’ll realize that in order to call a service at the server end,
the client needs to know where to look. Just as you need to know the URL of a web page in order to view
it, so a SOA “consumer” (the thing doing the calling) needs to know the address (usually a URL too, in
fact – HTTP is commonly used as the intercommunication protocol) of the service it wants to call.
The reason that web services are merely a subset of SOA is that you don’t really want to hard-wire server
addresses into your service calls. Not only might you want to redirect traffic to a different server at some
point, but you may even have the ability to provide some kind of load-balancing and thus allow a single
application to access the same service on multiple servers. We therefore introduce a mechanism whereby
the consumer doesn’t have to care about where to look for the service – it just shouts to the network, or
preferably to some kind of “object broker” on the network that it needs a particular object or service, and
the latter figures out the best place to get the service from.

And a little further still as I’ve hinted, the protocol of choice for SOA is HTTP – the web transport
protocol. It’s simple, well-understood and ubiquitous. Services are described using standards-based
mechanisms such as SOAP (the Simple Object Access Protocol) and WSDL (the Web Service Definition
Language), which simply involves wrapping stuff up in XML documents and flinging them back and forth
over HTTP connections. These mechanisms allow you not only to call services from consumers, but even
to ask a server: “Please tell me what services you can provide me with”.
The problem comes with the fact that the web transport protocol (which is allowed through most firewalls)
has now met business-critical function calls (which you most certainly don’t want to allow blanket access
to). Thus security becomes an issue and you need not just to packet-filter the streams that go through the
firewall, but to dig at application level into the XML of the calls that are flying around in order to decide
whether a given transfer should be permitted or blocked.

In short to conclude, then, the main component of SOA is an object-based service that allows distributed
processing by allowing code on different machines to co-operate and intercommunicate. SOA can exist
with just this component in place. In general, though, it will be complemented by auxiliary functions that
provide facilities such as load balancing, service discovery (figuring out where you can get services),
object brokering/management (optimizing access to services once they’ve been found) and application-
level firewalling in order to maximize scalability whilst maintaining security.

Now, why SOA?

Business processes often run on existing applications and computing environments long after they were
first put in place. Changing the entire IT infrastructure to accommodate new functionalities or building
each application from the ground up each time is too expensive and time-consuming for most enterprises.
SOA architecture is an answer to this problem. It aims at making systems more agile and responsive to
changing business needs. With an SOA focus to enterprise systems, companies can enhance, develop,
maintain and manage applications with great ease while responding to changing business and IT needs
proactively and cost-effectively.

Service Oriented Architecture provides:

 Complete visibility of information across the organization

When you look at SOA projects, what or how to implement them, you should be asking yourself what is
the business group expecting from this, and what are they gaining from this. There has to be some
business value generated and there has to be some business gain or else you are simply implementing
an IT project and any future SOA projects will probably not get off the ground. I can never stress enough
with my clients or friends about reading up on SOA. Make sure to educate your business groups. I had
one client whose business community was supposedly educated on SOA. However when it came time to
pitch in dollars and resources into the project, they refused because "SOA is just an implementation of
web services", from their point of view, and therefore no need for the business community to get involved.
Educating the business group will also help educate them on what they can expect and gain from SOA
projects. This will help you in the long run by allowing you to take the "baby steps" you are going to need
to take to truly implement SOA. This will also help you from the standpoint that the business community
can help you define the business value, versus you trying to figure it out for yourself. You cannot
implement SOA overnight; it will take you several projects to get a solid SOA foundation implemented. In
addition, post implementation, you are going to make changes, both in business and technology, and
those changes need to roll into your SOA implementation, which is another big topic for discussion. 

Therefore, understanding why you choose SOA, and how you became educated in SOA, can help you
determine when your company is ready for SOA. Without a proper education, you and your company will
be ill prepared to support a true SOA endeavor. Moreover, you and/or your company will have the wrong
expectation of what SOA can deliver.

Next big question, why not SOA?

One of the other questions you should ask yourself and your company is, "what if we do not do SOA?"
This question is very important because it underlines what you or your company perceives as benefits
from SOA. If the only reason to do the project is to integrate technologies, or to create a dashboard, you
can implement those things and still not implement SOA. Your answer to this question should have
technical ramifications as well as business value attached to it, like "will not reduce costs of operations by
10%" or "will not improve customer satisfaction by 20%". Applying these types of metrics, business
metrics, allows you to keep the end goal in mind as you delve into the technical aspects of the
implementation. Also with that, the business value is usually greater than the project itself. In other words,
you may be starting an integration project to service enable applications, but your business value is
visibility into customer purchasing habits. This signifies both the real value that SOA brings as well as the
fact that achieving SOA is not immediate. Instead, you do "baby steps", implement an ESB, then create a
Composite Application, and then assign KPI metrics, and so on; each step being a project on to itself, and
with the idea to deliver a specific business value that gets you to your eventual goal. 

As you look at the projects that you classify as SOA, they should be small, focused, and above all deliver
business value at the close of each project. If you are deciding to implement SOA, make sure to
understand what the impact is if you do not implement SOA.

And the last, what did you leverage?

One of the toughest questions clients ask me is "buy or build". My response, "what did you leverage?"
One of the major principles of SOA is leveraging, if you are not leveraging your current infrastructure,
processes, or organizations, then you are not reaping the full value of SOA. Taking what you and your
company has already invested in and expanding its capabilities, enhancing your visibility, or connecting
solid business functions into an heterogeneous Business Service is the power of SOA. This is also critical
when it comes to the education of yourself and your company in SOA; making sure that everyone,
especially the business, understands that leveraging what you have today keeps the costs down and
shortens the time in gaining value. One of the things that clients sometimes miss is leveraging processes
and organizations. All companies have processes, look to see where those processes are the most
developed, and leverage them. Leverage how they were produced or the procedures themselves, this
helps you when looking at creating Business Services (which we will cover in this blog later), and creating
the ability to adapt your infrastructure to your business. Leveraging your organization is also critical in
creating a solid SOA enterprise. Companies tend to have the organizational components for SOA already
in place, but used for a different capacity. One of the other major principles of SOA is governance, making
sure that all parties contribute and monitor, both technically and from the business, on aligning the
business and technology goals for the delivery of business value. You will need structuring organizations
like a Program Management Office (PMO), standardization committees, compliancy departments, or
change management organizations. You can use these types of organizations, no matter what their
current charter is, to govern your SOA implementations and maintain a high value proposition for your
company. 
When you can answer these three questions, "Why SOA?", "Why not SOA?", and "What did you
leverage?" you will have a solid footing on why you are looking at SOA and a beginning on whether or not
SOA is right for you. You are now ready to look into something else, your infrastructure.

Therefore, when it comes to SOA and IT Services, technology is not as important as your ability either to
create visibility or to manage change. These two factors will determine the value you can obtain from
SOA.

Which standards exist for end-to-end security in service-oriented architecture?

To answer this, first let me define what I mean by end-to-end security. Let me use an example where A
passes a message to B which passes a message to C. End-to-end security is security which applies
across the entire chain from A to C. If we looked at SSL for a moment, SSL is a transport-level security
protocol, so it could give you security from A to B, and security from B to C, but not from A to C. That is,
the A to B security is entirely separate from the B to C security.

In terms of end-to-end security standards, there are a number of different parts of the security puzzle to
consider:

Identity (who the caller is) -- There are a number of standards for end-to-end identity (typically referred
to as single-sign-on or identity management). The most common is SAML ("security assertion markup
language"). Many large vendors and customers are adopting SAML. Beyond SAML, there is also
Kerberos (where the Kerberos "tokens" would be transmitted in a WS-Security envelope). The use of
Kerberos becomes important and valuable because Kerberos is the "native" security mechanism of
Windows. So, if you have Windows desktops, you are probably already using Kerberos. Note that identity
can be used actively in order to authorize use of the services in the "chain" or passively to track who is
doing what for auditing purposes.

Privacy -- End-to-end privacy makes it possible for A to send information to C without B being able to
read it (even though B is in the middle of the message flow). The key standards for end-to-end privacy are
XML Encryption together with WS-Security. XML Encryption lets you encrypt part or all of a message
payload, and only those who have the right keys can decrypt it. So, you can choose to encrypt only the
most sensitive information in the message. However, a middleman (such as B) can still act on the parts of
the message which are not encrypted.Integrity. End-to-end integrity ensures that the message is not
tampered with anywhere from A to C. The key standards for end-to-end integrity are XML Signature and
WS-

Security -- As with XML Encryption, you can choose to sign part or all of the message payload. Anyone
who has access to the sender's public key can validate that the message has not been tampered with.

Beyond these three key areas, you may also consider how to have central control over authentication,
authorization, auditing, etc. This is typically the realm of vendor-specific products. There are few
standards in these areas. The one exception being XACML ("XML access control markup language"),
whose adoption as a universal standard is still uncertain.

What's Next After SOA?

What to expect next in the wake of SOA -- Event Driven Architecture, or EDA.

EDA delivers the loose coupling that is only promised -- but not delivered -- by SOA.  "EDA is not a
synchronous command-and-control type of pattern, but just the contrary: an asynchronous publish-and-
subscribe type of pattern. The publisher is completely unaware of the subscriber and vice versa;
components are loosely coupled in the sense that they only share the semantics of the message."

There are roles for both SOA and EDA, Jack van Hoof says. "If you are seeking to support strong
cohesion in the business processes, situations where all process steps are under one control, SOA is the
way to go," he says. "If you are seeking to support independence between business process steps, EDA
is the way to go."

EDA is not just the next evolution for SOA, but an architecture that can effectively work in
conjunction with SOA. So as we move forward, "the most viable, agile architectures will be comprised of
a blend of architecture strategies, including (but not limited to) service-oriented architecture, event-driven
architecture, process-based architecture, federated information, enterprise integration and open source
adoption. How you blend, depends on your business."

Here is an outline of how the interaction between EDA and SOA is occurring: First, "the occurrence of
an event (a notable thing that happens inside or outside your business) can trigger the invocation
of one or many services. Those services may perform simple functions, or entire business processes.
This interaction between events and services is commonly referred to as event-driven SOA."

Next, "a service may generate an event. The event may signify a problem or impending problem, an
opportunity, a threshold, or a deviation. Upon generation, the event is immediately disseminated to all
interested parties (human or automated). The interested parties evaluate the event, and optionally take
action. The event-driven action may include the invocation of a service, the triggering of a business
process, and/or further information publication/syndication. In this interaction, the service is purely one of
many event sources in a broader event-driven architecture. A broader event-driven architecture stretches
beyond event-driven SOA, to include real-time information flow and analysis, and complex event
processing."

SOA in current scenario

As enterprises slowly emerge from the mad rush of cost reduction into a more stable period of cost
management, many of them find themselves in unfamiliar territory. Prior to the economic slowdown, most
firms understood the options they had for IT investment. Many embarked on major package
implementations (e.g., Siebel, PeopleSoft and so on); while others built on the legacy systems they have
trusted for years. Either way, most firms recognized the return promised and made the investment.
Today, the appetite for such large investment is gone.

However, enterprises still need to make forward progress and keep ahead of the competition. SOA (and
typically Web Services as a concrete implementation of those principles) make this possible. The result is
dramatic improvements in collaboration between users, applications and technology components,
generating significant value for any business creating competitive advantage.