|
Service Oriented Architecture - Part 1
bySamudra Gupta
Introduction
In recent times, more and more organizations are implementing IT
systems across different departments. The challenge is to find a
solution that is extendible, flexible and fits well with the
existing legacy systems. Replacing legacy systems to cope with
the new architecture is not only costly but also introduces risk
of malfunctioning. In this context, the traditional software
architectures proves ineffective in providing the right level of
cost effective and extendible Information systems across the
organization boundaries. Service Oriented Architecture (S0A)
provides a relatively cheap and more cost-effective solution
addressing these problems and challenges. Although, it is not a
new concept, with the advent of recent platform-independent
programs and platform-neutral data models, SOA needs some fresh
attention. In this installment, we will examine
the anatomy of a Service Oriented Architecture and develop an
understanding of how to implement SOA in an architectural level.
Why do we need SOA?
One important factor in imbibing a new model of Software
Architecture is the ever-changing business model. Modern day
business constantly needs to adapt to new customer bases. The
ability to quickly adapt to the new customer base and new
business partners is the key to success. Sharing IT systems with
other organizations is a new trend in the business. For example,
businesses like online auctions are opening their systems to third
party organization in an effort to better reach their customer base. In
this context, Service Oriented Architecture offers benefit and
cost-effectiveness to the business. The process of adapting to
the changing business model is not an easy task. There are
many legacy systems, which are difficult to make
available to the new business partners. These legacy systems
might need to change to support the new business functions and
integrate to the newly developed IT systems or integrate to the
IT systems of its partners'. The complexity of the whole thing
is what makes it a constant challenge to organizations.
Imagine a government department has some legacy Sales Tax
management system which interacts with the legacy Trader
Management system. Suddenly, the government needs to incorporate
a new Green House tax. Now the new Green House Tax system will
also interact with the legacy Trader Information system and also
affect the existing Sales Tax for the Traders who are paying
Green House Tax, In essence, because of the introduction of the
new Green House Tax system, both the legacy systems need to be
readjusted to deal with the new type of Traders and Tax
information. This is costly as all the existing legacy systems
will have to be modified and will need to be re-tested.
This sort of complexity scenarios can be resolved by adopting
SOA. Services are defined as a set of well-defined
interfaces, which are generic in nature. Services also define a
schema for the input to be supplied to the Service by its
consumer. The inherent nature of SOA is that Services work with
an extendible Schema and thereby can cope with various different
types of entities that the Service is dealing with. For example,
a Customer Management system works with a XML based data passed
into it and it is capable of processing any type of Customer
without needing to know the difference between a Corporate
Customer and a Household Customer. This aspect of SOA resolves
the above mentioned complexity scenario without having to
change.
Essentially, Services operate as an independent entity. An
Organizational IT system is composed of a collection of
Services. Each of these Services can evolve and change in its
own right.
Another example might be, a bank. Imagine that several areas of
banking applications will deal with the current balance of an
existing customer. More than often, the “get current
balance” functionality is repeated in various application
softwares written within a banking environment. This gives rise
to a redundant programming scenario. The focus should be towards
finding this sort of common, reusable functionality and
implement them as a service, so that all banking applications
can reuse the service as and when necessary.
We have briefly discussed the case for SOA. We have seen
that SOA is mostly driven by the business model of an
organization. The real benefit lies in the reduced cost to fit
into changing and reusable business model. Now let us try to
define what do we mean by a “Service”.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
