See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/280445814

Service Oriented Architecture – A New Paradigm

Article  in  CSI Communications · March 2006

CITATIONS READS

6 643

1 author:

Debasish Jana
TEOCO Software Pvt Ltd
163 PUBLICATIONS   152 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

EAIT 2014 View project

All content following this page was uploaded by Debasish Jana on 26 July 2015.

The user has requested enhancement of the downloaded file.

 Service Oriented Architecture – A New Paradigm
Debasish Jana
Principal Software Engineer
Anshin Software Pvt. Ltd.
Treasurer, CSI Kolkata Chapter

Abstract
Service Oriented Architecture (SOA) is not an entirely new concept, yet it has become a new paradigm of
today’s enterprise applications. Before the Internet and the Web came into existence, communication between
systems was very tightly coupled with the underlying system. Today’s complex software needs to be
interoperable and loosely coupled in order to communicate with each other in a seamless manner. Earlier SOAs
were built using DCOM or Object Request Brokers (ORBs) based on the Common Object Request Broker
Architecture (CORBA) specification. CORBA was capable of providing standards-based interoperability and
connectivity. SOAs provide loose coupling between components so that some components provide services
while some others consume offered services. Web services promise to offer interoperability to cater to the
growing complexity needs of software yet at the same time provide easy to access service interfaces.

1. Introduction
Early programming days had monolithic code running on mainframes. The goal was to have the computing done
using the machine. Earlier, computers were used more as a data processing machine or a number crunching
machine. With the advent of sophisticated technology in hardware as well as advancement of communication
and increased complexity of software, there emerged the need for structured programming and modularity. In
1968, when Edsger E Dijkstra wrote “Go To Statement Considered Harmful”, since then and later the designers
tried to make the programs more modular, structured, compartmentalized. A new era began. But even then, in a
procedural paradigm framework subroutines, functions, global data, maintenance started become nightmarish.
Need of abstractions were felt. Object Orientation tried to bring a new paradigm. Concentrate on what, not how
– is the theme of the OO paradigm. In OO paradigm, a module or a class offering a set of services should expose
a set of public interfaces or contracts and hide out the implementation details. The caller needs to make call to
the exposed interface to avail the service without being bothered how internally the service is catered to.

2. Need of Component-based Software

With growing complexity of software, a need became imperative to maintain not the code only but the
functionality exposed and in use, as well. Individual modules or compartments needed to be reused as
components in order to reduce time, effort in further software developments. Component-based software
development came into existence to build resilient architectures. In principle, software needs to be soft i.e.
flexible enough to cope up with changing requirements or adapting to changing technology.
Compartmentalization or breaking into multiple interrelated components and making things simple can cater to
extendibility quality aspect of a software. Extensibility is the quality factor that makes a software product easy to
adapt to changes of specifications or requirements. Also, by reusing commonality or patterns, the task of
reinventing the same wheel can be avoided. This requires that components of a software system should not be
designed to cope up specific problems in specific contexts, rather they should be designed to provide generic
solutions to a class or pattern of problems in different contexts. This makes such general components to be
adapted and reused many times. All modern engineering disciplines offer high levels of assurance, predictability
and efficiency because new projects are based on a vast, well documented repository of experience, good
practice and sound principles. Reusable software components hold the promise of contributing to software
development eventually attaining the same status as the established engineering disciplines.
Compartmentalization to components also need to cater to integrity so as to protect various components
(programs, data, documents, system software, hardware environment etc.) against unauthorized access and
modification.

3. Changing Nature of Software

The nature of the software that we're building is also changing, from the simple batch systems of the 1970s that
structured techniques are geared towards to the interactive, international, user-friendly, high-transaction, high-
availability online systems that object-oriented and component-based techniques are aimed at. By clearly
articulating the major components and the critical interfaces among them, an architecture lets one reason about
reuse, both internal reuse (the identification of common parts), and external reuse (the incorporation of ready-
made, off-the-shelf components. Architecture can also facilitate reuse on a larger scale: the reuse of the
architecture itself in the context of a product line that addresses different functionality in a common domain.
Extensibility, reusability and maintainability issues got addressed through component-based software
development. But complexity issues could not be catered to by just breaking into components. Today’s software
needs to cater to distributed deployment, application integration, heterogeneous platforms, diverse protocols,
web based access to cater homogeneity in access, so on and so forth. With all these requirements in mind,
software compartmentalization task begun. From monolithic mainframe based systems it was a paradigm shift
when the era of client-server computing emerged. The client, typically a personal computer with graphical user
interface (GUI) connected with a backend server with shared resources or database became tightly coupled. The
client or the front-end used to typically depend on the backend server. But, soon from the single-server within a
LAN based client-server system, a need was felt for distributed system to support wide area network and with
the new intergalactic demand or need of communicating between hugely disperse heterogeneous systems spread
out in different geographical areas. The tight coupling of the client and server is sought to be broken. In a
distributed system, the client does not know the server, the server does not know the client. Multi-tier
architecture evolved. The front end tier is supposed to deal with user interface issues. This tier needs to talk to a
middle tier to take care of requests that would be catered by some backend server, and the reply or response
from the server will reach the client via the middle tier. This middle tier is often called a broker.

4. Loose Coupling and Statelessness

To cater growing need of complexity, we try to minimize the coupling between the components in the system so
as to reduce dependency and increase flexibility. The interacting software components should know other
components minimally. The idea is to discover information when needed. Loose coupling helps to have better
flexibility of relocating a service on a different server, or replaceability i.e. changing the implementation of the
server without changing the communication protocol or interface of communication. Loose coupling also helps
to have better scalability in the sense that services can be added and removed with growing or shrinking
demands. With loose coupling, when a service is required, the server offering the service would be discovered
with its capabilities, policies, location, protocols etc. Having established the connection or binding with the
server, now the client can communicate with the server to avail the service directly. Loose coupling also helps to
achieve fault tolerance. If a server fails, alternate server may become operational by updating the directory
service or registry service.
Statelessness is a very important issue to achieve loose coupling. In a stateless communication system, each
transaction is self-contained, does not depend on history or previous transaction. notion of loose coupling is—a
topic that has been much-discussed and is often mentioned as a critical requirement, sometimes without a clear
understanding of its significance. For complex transactions comprising of a series of smaller transactions
however require stateful nature where the state needs to be preserved. However, if the server fails for some
reason, the transaction ends in a spurious situation. In a multi-step transaction, a stateless service requires that at
end of each step, the service must communicate to the client sufficient and meaningful state information to
continue the transaction. The client must communicate back the state information on next transaction. The
submitted state information must be handled in such a way that it should not depend on earlier processing steps.

5. Earlier Technologies
Lets now investigate the available technologies catering to loosely coupled systems or subsystems to make
earlier service based systems before service oriented architecture came into existence. The earlier service-
oriented architecture was using DCOM or Object Request Brokers (ORBs) based on the Common Object
Request Broker Architecture (CORBA) specification. CORBA was capable to provide standards-based
interoperability and connectivity. Also, Microsoft’s Common Object Model (COM) and Object Link Embedded
(OLE) component infrastructure and object bus were among distributed objects based technology. CORBA
objects used to be active objects that can stay anywhere on a network. That are packaged such that remote
clients can access them via method calls. The language and complier used to create server objects used to be
totally transparent to clients. Clients thus don’t need to know where the distributed object stays or what platform
it runs on. Clients don’t also need to know how the server object is implemented. For example, a server object
could be implemented as a set of C++ classes or it could be implemented with a set of code written in some
other language, the client should not be able to make out the difference. The client needs to know only the
interface that the server object publishes as a contract. The interface or contract serves as a binding rule between
clients and servers. CORBA has been designed to be independent from the Operating System. CORBA runs on
many operating system platforms, ranging from the Win32/UNIX up to the real-time embedded systems and
supports a vast majority of programming languages as well as some scripting languages. Communication
protocols used by CORBA for ORB communications include TCP/IP, IPX/SPX, ATM, etc.
Cross-language, cross-vendor interoperability used to be achieved via the Internet InterORB Protocol, or IIOP.
IIOP is a transport protocol for distributed applications written in either IDL (Interface Definition Language) or
Java RMI (Remote Method Invocation). In CORBA, object orientation is limited only to objects that can be
passed by reference or are predefined in the overall framework. We cannot pass code from machine-to-machine.
Passed and returned types must be those declared in the interface. In CORBA, the parameter or return values are
limited to the capability of representation available in the underlying implementation languages. In Java-RMI,
the interface and the implementation language are described in Java. As such, the code i.e. language-level
objects can be passed from one process to the next, from one machine to other. Argument values or return
values can be actual type, not abstracted type. Otherwise, IIOP stubs and skeletons need to be generated to
remain accessible from other CORBA-compliant languages.

6. Service Oriented Architecture

Service Oriented Architecture (SOA) is the answer to meet the problem of growing complexity. The key
premise is the abstraction layer. Abstraction involves the formulation of representations by focusing on
similarities and differences among a set of things or entities to extract intrinsic essential characteristics (relevant
common features or behaviors). It also avoids extrinsic incidental characteristics (irrelevant distinguishing
features) in order to define a single representation having those characteristics that are relevant to defining every
element in the set.
Service-oriented architecture (SOA) provides a loosely coupled composition of services. A service in SOA
should be an exposed piece of behavioral aspects such that the contract for service (i.e. the exposed interface in
highest level of abstraction) to the service remains platform-independent. Also, the service should be
dynamically discoverable and callable as requests. Dynamic discovery requires a discovery or directory service
available at runtime. A service should be defined to be as an atomic operation encapsulating a particular
business process. As such, the service must be self-contained i.e. service should be stateless. Thus, a service
needs to be communicable, publishable, self-containable, well-definable, and also should be platform
independent, and independent on the state of other services. Service providers and consumers need to
communicate via messages. The service contract must clearly define the behavior of the service and the
platform-independent messages exchangeable. The service invocations should be interoperable such that
heterogeneous platforms can offer and avail services through exchange of platform-independent, interoperable
messages.
In a service-oriented architecture (SOA), there should be a bunch of service providers, service requesters, and
service administrators to facilitate services. A service providers should provide facility for service registration,
dynamic discovery, exception handling with automatic failover, distributed security, platform independent
interoperability, and clustering as well as grid computing. Fig. 1 shows SOA in perspective of service providers,
consumers as well as service registry providing directory services for available services. Service providers
register themselves with Service Registry, Service consumers discover or find provider for required services
from service registry. Then, service consumer binds the service provider to execute the service request by the
provider of services.

Fig. 1. SOA – relationship between service providers, consumers and registry

7. Web Services in SOAs

With heterogeneous platforms offering service, web services technology plays a major role in a SOA. Web
Services are basically distributed middleware technology that uses simple XML based protocol to allow
applications to exchange data across the web. Services are described in terms of the messages accepted and
generated. Web services hide out or abstract the underlying complexity of the service providing system the
service consumer is talking to. Web services are built on top of well-known and platform-independent protocols
such as HTTP, XML, UDDI, WSDL, and SOAP. Dynamic discovery and dynamic invocation is possible in
 UDDI, WSDL, SOAP. Sometimes, Service Oriented Architecture (SOA) is often mystified with web services.
SOA concepts were around long before web services came into existence. Still, the growing popularity of web
services are catering the need of SOA in a heterogeneous distributed environment. SOA attempts for loose
coupling between components by providing a software service that is consumed by another software service.
SOA stresses interoperability. This requirement is fulfilled by hypertext based protocol HTTP. SOA, in
combination with web services can cater to growing need of application integration, cross-platform
interoperability, scalability, availability, dynamic discovery and invocation of services as well as reliability.
With web services, application integration has become convenient with standardized APIs.
References
[1] Fujita Satoru, Dynamic Collaboration of Businesses using Web Services, NEC Journal of Advanced
Technology, Vol. 1, No. 1, Jan, 2004, P. 36-42
[2] Jana D, “Java and Object-Oriented Programming Paradigm”, ISBN 8120327756, Prentice Hall of India,
2005.
[3] Jana D, Chaudhuri A, Datta A and Bhaumik B B, “Privacy Protection of Grid Services in a Collaborative
SOA Environment”, IEEE International Region 10 Conference, Proceedings of the IEEE TENCON 2005,
Melbourne, Australia, Nov. 21-24, 2005.
[4] Web Services Architecture, W3C Working Draft 14 November 2002, from http://www.w3.org/TR/ws-arch/
on 5th March 2002
[5] About the World Wide Web Consortium (W3C), http://www.w3.org/Consortium/, March 2000 (updated in
April 2004)

View publication stats