|
Service Oriented Architecture - Part 2
by Samudra Gupta
Introduction
In part 1 of this article, we analyzed
the need for Service Oriented Architecture (SOA) in today's ever
changing business model. Experience shows that before we decide
on a technology, careful thinking and analysis is required to
arrive at the correct level of granularity and appropriate
Service definitions. Development teams need to be focused on
what we are trying to achieve and adapting any one technology
does not guarantee success in achieving the goal. We outlined a
few general guidelines in the analysis stage of the process and
laid out a path for identifying Services. In part 2, we will
concentrate more on the technical aspects of Service Oriented
Architecture and finally will reach a framework for implementing
Service Oriented Architecture.
The SOA objectives
Technically, the foremost concept to understand is what we are
trying to achieve with SOA. At the very bottom, SOA relies on
basic units of application software, which automates one or more
pre-defined business processes. In a simplistic scenario, the
goal is to make these basic application units accessible to the
client and also for these basic application units to talk to
each other in a technology-neutral manner. In a more complex
scenario, the goal is to sustain these basic application
components and just change the underlying technology for
improved efficiency. For example, one organization might have a
“CustomerManagement” application component. The component offers
some Services and the Insurance Department and the Marketing
Department of the organization make use of the
CustomerManagement. Now for improved efficiency, we must be able
to migrate the CustomerManagement component to EJB without
affecting the client of this component or event, we should be
able to convert this component to a .NET component even though
the client to this component is written using a different
technology, Java per say.
Keeping these issues in mind, implementing SOA demands the
following features:
- Technology Independence: The Consumer of a Service component
is completely independent of the technology of the Provider
component and vice-versa.
- Life-cycle Independence: Each of the Provider and Consumer
Service components should be able to operate in a separate life-
cycle.
- Loose Coupling: The Service Consumer Component must
define its specification independent of the Service Provider
Component. The responsibility of aligning the two specifications
is up to the Assembler component, which bridges the gap between
two worlds.
- Invokable interfaces: The Service interfaces must be
invokable either locally or remotely. At the architecture level,
we don’t really care how the interface is invoked.
- Communication Protocol: A Service must be invokable by
variety of protocol. The choice of protocol must not restrict
the behaviour of the Service. Binding to a specific protocol
must take place at run-time/deployment-time, and not at the
design or development time.
How to arrive at such solution
In the Part 1 of this series, we have defined Services as
software application units that provide a distinct and atomic
business process. Services do operate independent of the
technology involved in the Consumer and the Service provider
itself.
Although it is a new and novel concept to introduce the inter-
operability of application units in a technology neutral way,
the basic building of SOA relies on some of the proven
methodologies such as Component Based Development. The
Components do exist as the basic unit of the application
performing a certain business operation itself or by
collaborating with other components. What is unique to the SOA
is how these components are invoked and also how the components
interact with each other.
In my opinion, having a sound Component based design helps any
organization to newly implement or even migrate towards SOA in a
smooth transition. In the following sections, we will elaborate
on the concepts of Component Based Development and how it can be
used alongside Service Oriented Architecture (SOA). Often we use
the term SOA and Web Service interchangeably, which is not
strictly correct. Web Service is one implementation of SOA
wherein SOA really means a set of technology, which enables us
to develop business functions as Components which can be invoked
and used in a technology independent fashion.
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.
|
