Introduction to Service-Oriented Architecture

Service Oriented Architecture is an approach to building software. SOA doesn’t dictate an underlying architecture, a hardware platform, an operating system, or a specific programming language. Instead, SOA focuses on interoperability among specialized services. SOA aims to build a whole whose sum is greater than its parts.

If you lack a conceptual model of "i">Service-Oriented Architecture, consider what could
happen if your car breaks down in the middle of a business trip. As
soon as the car is disabled, it could signal for a tow truck,
sending specific GPS coordinates. If car travel was a scheduled
part of your itinerary, the car could also signal your virtual
assistant to generate exceptions, such as canceling a meeting,
rebooking a flight, guaranteeing late check-in, and paging your
spouse. In turn, a cancellation might cascade additional exceptions
to alert each meeting attendee.

A pipe dream? Perhaps not. OnStar is
already provided in a number of new cars, satellite radio is
available in almost every car, and GPS navigation aids cost as
little as $200, integrating maps, traffic alerts, and directories
of local businesses. It’s not a stretch to imagine an
inexpensive device with a full-duplex connection to a worldwide
mesh of information transceivers. The technology is readily
available — the challenge is interconnecting a myriad of
disparate services.

Interconnecting services is the heart of Service-Oriented
Architecture (SOA). SOA aims to build a whole whose sum is greater
than its parts.

There is no single, good definition of Service-Oriented
Architecture. If you scan Wikipedia or
search the Web via Google, you can easily
find over 100 “good” definitions.

Put simply, though, SOA is a philosophy, or an approach to
building software. Specifically, each SOA application is built
expressly to interact “intelligently” with other
applications to swap data and effectuate transactions. SOA does not
dictate an underlying architecture, hardware platform, operating
system, programming language, or interface.

At a minimum, an SOA must have:

*A set of technologies and
tools to allow you to quickly implement and provide services.

*A methodology to implement
services, including a means to advertise your services to maximize
consumers.

*A collection of design
patterns, best practices, and standards to guide the implementation
and publication of your services.

And what exactly is a service? It’s a summons for roadside
assistance, a credit card processor, or a reservations engine. In
general, a service is a valuable, reusable,
and network-addressable application with a
clearly defined interface.

Further, a service is "i">platform-independent — a consumer does not require
the same technology as the provider —and it’s
abstracted, so that any number and kind of
consumers can connect. A service could easily be executed through a
browser front-end, a cell phone, or another software system.

Figure One portrays a service. The method
of invocation and the specifics of the implementation are
abstracted from business logic.

FIGURE ONE:
A service is
independent of invocation and underlying
implementation

class="story_image"> "http://www.linux-mag.com/images/2007-06/soa/figure1.jpg" class=
"story_image">

To connect a consumer to a service, the service’s provider
advertises it widely. This is typically a contract published using
the Web Services Description Language (WSDL)
and cataloged in some directory, typically using "i">Universal Description Discovery and Integration
(UDDI).

Next, the consumer finds (discovers) the service in the
directory, or through another mechanism, often a pre-negotiated
agreement with the provider. Finally, the consumer constructs a
request using WSDL, and awaits a response.

Service — the “S” in SOA — may remind
you of a Web service, but there is an important distinction.

*A Web service connects a
provider and a consumer via a simple remote procedure call. The two
parties connect via HTTP or "i">HTTPS, and exchange information in dialects of
XML.

*A service is agnostic. A
service may accept requests via a Web service, but that is just one
possible “personality” of the service.

Moreover, an SOA is much more than a collection of Web services.
IIOP and CORBA, and
more recently, RMI and "i">EJBs are all valid implementations of a service and
could be a part of your SOA. Figure Two
illustrates that while SOA and Web services overlap, the two
concepts have some unique properties as well.

FIGURE TWO:
There are some commonalities between Web
services and SOA

class="story_image"> "http://www.linux-mag.com/images/2007-06/soa/figure2.jpg" class=
"story_image">

Software Development the SOA Way

Let’s explore a simple scenario to distinguish SOA
software from non-SOA software.

No doubt you’ve waited in line to check-in with an
airline. For convenience and to save money, airlines now offer a
variety of alternatives to standing about, including kiosks, the
Internet, even via cell phone. In fact, some airlines offer air
mile bonuses for avoiding the ticket counter.

The traditional approach to building these alternatives is
daunting. Separate development teams must sift through source to
track down the exact code that implements the check-in process. The
code is commonly copied into another body of source and then
modified to support the new user interface. Duplicating and then
bifurcating the code base is required because the code is
tightly-coupled to the user interface and the information
technology infrastructure. As the number of access mechanisms
increase, the number of copies of the code increases, leaving the
development team to maintain, test, debug and support similar but
not identical variations.

An airline check-in system patterned upon Service Oriented
Architecture provides for a myriad of access techniques without the
need to copy and paste code. With a centralized service — one
body of code — the airline could add self-serve seat
selection and surface that fundamental feature in each portal.

Let’s go a little further and expand the airline’s
SOA and it’s sphere of influence.

When you check-in for your flight, your airline must look-up and
confirm your meal preference. If available, the airline orders the
meal to be delivered. If unavailable, you must choose something
else and an order for your new selection is ordered for
delivery.

Here, the check-in system is expected to interoperate with the
caterer’s system. Interoperability is a fundamental tenet of
SOA. In fact, seat selection need not be an embedded feature of the
check-in service; seat selection could be a service, too.

Services need to follow robust, consistent, and flexible
architecture principles that allow the services to be adapted to
unforeseen changes.

The Benefits of SOA

Adopting SOA can improve both IT and the entire enterprise.

*SOA facilitates rapid
introduction of new business models. If your airline check-in is
implemented as a service, you can quickly introduce new ways to
check-in, such as the Blackberry. Realizing innovations or changes
can also grant you a competitive advantage.

*SOA facilitates mergers and
acquisition. The implementation of SOA allows businesses to
integrate more easily and more cost effectively.

*SOA reduces development time.
It is typically much faster and cost-effective to build and deploy
a service instead of a large monolithic application. Deploying a
new service days or weeks rather than months or years. Of course,
this has a direct implication on cost and perhaps revenue.

*SOA improves business to IT
collaboration and reduces risk. Since a service can be built,
tested, and deployed rapidly, it naturally leads to better
collaboration. Development can more quickly accommodate new
requirements, and the common wisdom that “70% of IT projects
that fail, fail due to bad requirements” no longer holds
true, or is mitigated.

*SOA leads to re-use. A new
service is frequently a collection of existing services. This
reduces the overall development time, simplifies maintenance, and
gives more flexibility.

Implementing an SOA

Implementing a Service Oriented Architecture isn’t easy.
An SOA requires a lot of thought, hard work, and the contribution
and coordination of many skills.

1.Build your
core team.
The first step towards implementing SOA is to
build your core SOA team. This team needs to include people from
all levels of your organization, including a business executive
sponsor (CEO or other business leader), a technical executive
sponsor (CIO), your enterprise architects, project managers
business analysts, the development team, and the infrastructure
team (DBA’s, server administrators, network administrators,
storage administrations, information security, and so on). Of
course, your end-users and customers are very important. Remember,
SOA is not about technology — it’s about the services
you can offer to your customers, partners, and suppliers.

2.Design your
process and methodology.
SOA is all about process. An SOA
implementation is a very complex project, likely spanning many
years, with a lot of sub-projects. You need a methodology as robust
as the RUP process to be successful. However, once you have your
SOA built out and successful, the heavy weight nature of RUP does
not allow you to provide the agility and flexibility that SOA
demands. Thus, you should probably switch to a method akin to
Extreme Programming.

3.Adopt a
maturity model.
Constantly measure the success of your SOA
and show value in the investments made.

SOA projects fail for a number of reasons:

*Lack of
business support.
Business users and executives largely do
not care or really need to care about technology and IT projects.
However, those same folks want want the systems better, faster, and
cheaper. With SOA, “haste” is not the solution. Educate
those users about the SOA approach and how to exploit its
advantages.

*Failure to
investment in technology.
At first glance you might think
SOA is cheaper than traditional software development. Well, yes and
no. You need to spend big up front with SOA and reap the benefits
as you incrementally add new Services. The upfront investment in
infrastructure, technologies, tools, and more, and is critical to
long term success. This is also why the business executive needs to
be bought in- why is IT going to cost more in Years 1 and 2 and
then the cost will go down in Year 3?

*Providing the
wrong service.
Work with your customers to define services
of appropriate granularity.

Onwards

SOA is not a technology and it’s not a tool. It’s an
approach to product development that emphasizes interoperability
between applications. SOA services combine and interact to achieve
large, complex tasks. Better yet, SOA is agile, and more responsive
to changing and evolving business models. Ultimately, that’s
better for customers and better for your company.

Read and read. There’s a wealth of material about SOA.
Future issues of Linux Magazine will drill
into different subject areas in a lot more detail. Enjoy your
journey.

Kunal Mittal serves as the director of technology
for the domestic TV group at Sony Pictures Entertainment, and is
responsible for the technology strategy and application development
for the group. Kunal is very active in several enterprise
initiatives such as the SOA strategy and roadmap and the
implementation of several ITIL processes within Sony Pictures.
Kunal has authored and edited several books and written over 20
articles on J2EE, WebLogic, and SOA. Some of his works include Pro
Apache Beehive (Apress, 2005), BEA WebLogic 8.1 Unleashed (Wrox,
2004), and a three-part series of articles entitled “Build
Your SOA: Maturity and Methodology” (SOAInstitute.com, 2006).
For a full list of Kunal’s publications, visit his web site
at www.kunalmittal.com/html/publications.shtml. Kunal holds a
master’s degree in software engineering and is a licensed
private pilot.

Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62