UNIT I

SOA introduction:
Complexity is a fact of life in information technology (IT). Dealing with the complexity while
building new applications, replacing existing applications, and keeping up with all the
maintenance and enhancement requests represents a major challenge.
If all applications were to use a common programming interface and interoperability protocol,
however, the job of IT would be much simpler, complexity would be reduced, and existing
functionality could be more easily reused. After a common programming interface is
in place, through which any application can be accessed, existing IT infrastructure can be more
easily replaced and modernized.

This is the promise that service-oriented development brings to the IT world, and when deployed
using a service-oriented architecture (SOA), services also become the foundation for more easily
creating a variety of new strategic solutions, including:

 Rapid application integration.

 Automated business processes.
 Multi-channel access to applications, including fixed and mobile devices.

An SOA facilitates the composition of services across disparate pieces of software, whether old
or new; departmental, enterprise-wide, or inter-enterprise; mainframe, mid-tier, PC, or mobile
device, to streamline IT processes and eliminate barriers to IT environment improvements.
The Web Services Description Language (WSDL) has become a standard programming interface
to access any application, and SOAP has become a standard interoperability protocol to connect
any application to any other. These two standards are a great beginning, and they are followed by
many additional Web services specifications that define security, reliability, transactions,
orchestration, and metadata management to meet additional requirements for enterprise features
and qualities of service. Altogether, the Web services standards the best platform on which to
build an SOA—the next-generation IT infrastructure.

SOA Evolution:

Architecture is nothing but lay outing of our applications

Single tier architecture:

In 1960’s and 70’s there is only one architecture. This architecture consists of two parts:
The Main frame and the Dump terminal (thin client). Users can 'access the main frame through
the dump terminal. The dump terminal just receives the information from the user and sends it to
the mainframe which does all the processing needed and send back the information to the dump
terminal. Mainframe server is having entire business logic, data and presentation logic.

Pros: This model is very easy to maintain as everything we need to store in single place i.e.
server

Cons: The major drawback is scalability. More users enter into the system and develop some
functionality and then add this functionality to the application. It is difficult to store these
application logics in single place.

Two tier architecture (client-server architecture):

In 1980’s lot of users uses PCs to access information. A lot of work that main frame was doing
could now off loaded to the PCs. So, PC’s can do business logic, presentation logic and
validation and Mainframe can maintain data and portion of business logic. So, here the main
frame could act as the data server. This model called Client/Server model. The server here is the
Main Frame and the client is the PC.

Pros: The major pros here are scalability is improved. The PCs now can do more tasks, so it’s
easier to add more users and more business logic.

Cons: The most important problem here is the maintenance. Actually it’s the biggest problem in
this level; let’s say we have 5000 users who are running some applications, when it comes the
time to update the application, whether we do bug fix, handling more functionality inside the
application, we've to go to the 5000 PCs and update their application on all of these different
PCs. It’s really hassle to do such process frequently. Another problem we had that all PCs had
different configurations, if you work in a large organization, you might have users running
windows 95, windows 98, windows 98 SE, windows 2000, windows 2000 SP1, windows XP,
windows XP SP1, windows XP SP2, .. etc. Getting all of those PCs to work with whether the
application you are working in could be a real challenge.

Three tier architecture:

In the late of 1990’s and early 2000’s we have 3-tier architecture. We have the main Server that
holds the data base and the most important business logic, and then we have an Application
Server in the middle and the client (usually PCs running a browser). We have a great scale of
scalability as we can add more application servers at this level, we might cluster some of them or
we can have a load balancer to handle all different PCs that going to access information from
server.

Pros: Maintenance which is the biggest problem in Client/Server architecture. Instead of going
to the whole bunch of PCs and updating the application, we just update it in one side, we update
the Application Server. So, when we want to roll out some functionality or bug fix, we just roll
out to the Application Server, the PCs access the application server and get the new application,
the Application Server interacts with the Data Server and do the appropriate business logic. As a
result scalability and maintenance are the most important pros of this model

Cons: The model had high level of complexity. We’re looking to a true distributed system here
and it’s hard to figure out in a lot of cases in these large applications where does the code live.
So, if we have some validation code, does it live in PCs? Is the validation going on the
application server? Is the validation going on the data base level of the server or in the business
logic? Although we have really true scalability and eliminated a lot of the maintenance issues,
but this getting real complex in terms of how we construct our application or in other word how
we are going to architect all of these systems together.
Service Oriented Architecture (SOA):

In the late 2000's we have this concept of SOA.

We've seen how complexity of the distributed applications of the 3-tier model was. We’re going
to isolate each one of those individual pieces in the 3-tier architecture as the below diagram:

Now, we’ve a really complex application like ERP we’ve stuff like Oracle E-Business suites R12
and SAP. These applications have: Account Receivable (AR), Account Payable (AP), General
Ledger (GL), Purchase Order (PO), Inventory Management (IM), Credit Check, .. etc. What if
we can isolate these pieces and called them Web Service. The Web Service is like a black box
that can be accessed to provide a specific functionality within the system. So, here we have a
Web Service for AR, AP, GL, PO, IM and credit check.

Let’s say that we’re going to develop a Web Service for credit check. Credit check actually does
what it sounds like, may put some vendors information in it, how much money we want to give
them credit for and doing some analysis of how they paid their bills, .. etc. We’ve now another
level of flexibility, a flexibility to isolate and understand the functionality of each single Web
Service. We can use this web service across all of our different applications inside
our organization. We can also re-use the code of the Web Service over and over.

The Service-Oriented Enterprise:

Driven by the convergence of key technologies and the universal adoption of Web services, the
service-oriented enterprise promises to significantly improve corporate agility, speed time-to-
market for new products and services, reduce IT costs, and improve operational efficiency.

Several industry trends are converging to drive fundamental IT changes around the concepts and
implementation of service orientation. The key technologies in this convergence are:
1) Business Process Management
2) Service-oriented Architecture
 3) XML
4) Webservices

Extensible Markup Language (XML): A common, independent data format across the
enterprise and beyond that provides:
 Standard data types and structures, independent of any programming language,
development environment, or software system.
 Pervasive technology for defining business documents and exchanging business
information, including standard vocabularies for many industries.
 Ubiquitous software for handling operations on XML, including parsers, queries, and
transformations

Webservices: Services are software components with well-defined interfaces that are
implementation-independent.

 Services are self-contained (perform predetermined tasks) and loosely coupled (for
independence)
 Services can be dynamically discovered
 Composite services can be built from aggregates of other services

Business process management (BPM): Methodologies and technologies for automating

business operations that:
 Explicitly describe business processes so that they are easier to understand, refine, and
optimize.
 Make it easier to quickly modify business processes as business requirements change.
 Automate previously manual business processes and enforce business rules.
 Provide real-time information and analysis on business processes for decision makers.

SOA: Service-oriented architecture (SOA): A methodology for achieving application

interoperability and reuse of IT assets that features:
 A strong architectural focus, including governance, processes, modeling, and tools.
 An ideal level of abstraction for aligning business needs and technical capabilities, and
creating reusable, coarse-grain business functionality.
 A deployment infrastructure on which new applications can quickly and easily be built.

SOA Vs Client Server Architecture:

Application Logic
The Client Server architecture include fat client that does bulk of processing and data-related
logic and database server lying on the server. In the case of SOA options exist regarding where
the application logic can reside and how it is distributed.
Application Processing
The Client Server architecture follow 80/20 where bulk of processing is done by the client and
other database access and connection pooling is done by the server .In case of SOA each service
has a explicit functional boundary and resource requirement.

Technology
Client Server Architecture makes use of 4GL programming languages and for performance
reasons make use of 3GL programming languages. They also use vendor based RDBMS
packages. In case of SOA XML data representation architecture along with SOAP message
framework. It makes use of HTML, CSS, and HTTP etc.

Security
In case of the client server the security is centralized at the server side. But security can also be
realized on the client side.SOA heavily depends on WS-security framework for security.

Administration
In client server architecture the maintenance cost are high and administration problems are also
involved.
SOA is also not that immune to client-side maintenance challenges.

Client server architecture Service Oriented Architecture

Application Places the majority of application The application logic resides
logic logic into client software. completely on the service provider,
sometimes provider can also be
service requester.
Application Bulk of processing(about 80%) is Processing is highly distributed. No
processing on the client side. Processing ratio is fixed processing ratio
80/20 (client/server)
Technology Visual basic and powerbuilder Web
,c++,oracle Sybase at the backend technologies(HTML,CSS,HTTP)
and XML with SOAP messaging
framework

Security Security controlled within client WS-security framework

executable, OS level security can
also be incorporated.
Administration Larger maintenance cost due to Less maintenance cost, if web
distributed application cost service need to be scaled to large
group then it incurs large
maintenance cost
SOA vs Distributed Internet Architecture:
Application Logic:
The majority of the application logic is placed into the server side components.
The distributed Internet Architecture emphasizes on the following principles-
-how application logic should be partitioned.
-where the partitioned units of processing logic should reside.
-how the units of processing logic should interact.

The differences between SOA and Distributed Internet Architecture lie in the principles used to
determine the three primary design considerations.
The significant difference is in how services exchange information. In distributed Internet
architecture the components provide method that once invoked, send and receive parameter data.
Web Services communicate exchanging the SOAP messages.

Application Processing
Components are responsible for the majority of the application processing.
Distributed Internet Architecture promotes use of proprietary communication protocols like
DCOM and CORBA for remote data exchange.

SOA relies on message-based communication. This involves the serialization, transmission and
deserialization of SOAP messages containing XML documents. Processing also involves
conversion of relation data into an XML-compliant structure, the validation of the XML
document prior and subsequent to transmission, and the parsing of the document and extraction
of the data by the recipient

Technology:
Distributed computing consists of components, server side scripts and web technologies like
HTML and HTTP.SOA consists of distributed objects using Xml and web services.

Security
In order to ensure the safe transportation of information and the recognition of user credentials,
while preserving the original security context, traditional distributed internet architectures
incorporate security approaches such as delegation and impersonation.

SOAs heavily rely on the extensions and concepts established by the WS-Security framework.

Administration
Maintaining component-based applications involves keeping track of individual component
instances, tracing local and remote communication problems, monitoring server resource
demands and the standard database administration tasks.
SOAs typically require additional runtime administration involving exception handling with
messaging frameworks. The other maintenance tasks include resource management.

SOA Architecture concepts:

 SOA
 Web Services
 Web Service standards
 Web Services advantages
 Web Service characteristics

A service-oriented architecture is an architectural pattern in computer software design in which

application components provide services to other components via a communication protocol,
typically over a network. The principles of service orientations are independent of any vendor,
product or technology.

Web Services:
A web service is a software module which is designed to perform a certain set of tasks. Ex:
retrieving an online bank statement.

Web services provide a common platform that allows multiple applications built on various
programming languages to have the ability to communicate with each other

 The web services can be searched for over the network and can also be invoked
accordingly.
 When invoked the web service would be able to provide functionality to the client which
invokes that web service.

The main component of a web service is the data which is transferred between the client and the
server, and that is XML. XML (Extensible markup language) is a counterpart to HTML and easy
to understand the intermediate language that is understood by many programming languages. So
when applications talk to each other, they actually talk in XML. This provides a common
platform for application developed in various programming languages to talk to each other. Web
services use something known as SOAP (Simple Object Access Protocol) for sending the XML
data between applications.

Web Services Advantages:

We already understand why web services came about in the first place, which was to provide a
platform which could allow different applications to talk to each other.

But let's look at some other advantages of why it is important to use web services.
 1. Exposing Business Functionality on the network - A web service is a unit of managed
code that provides some sort of functionality to client applications or end users. This
functionality can be invoked over the HTTP protocol which means that it can also be
invoked over the internet. Nowadays all applications are on the internet which makes
the purpose of Web services more useful. That means the web service can be anywhere
on the internet and provide the necessary functionality as required.

2. Interoperability amongst applications - Web services allow various applications to talk

to each other and share data and services among themselves. All types of applications
can talk to each other. So instead of writing specific code which can only be
understood by specific applications, you can now write generic code that can be
understood by all applications

3. A Standardized Protocol which everybody understands - Web services use

standardized industry protocol for the communication. All the four layers (Service
Transport, XML Messaging, Service Description, and Service Discovery layers) uses
well-defined protocols in the web services protocol stack.

4. Reduction in cost of communication - Web services use SOAP over HTTP protocol, so
you can use your existing low-cost internet for implementing web services.

Web service Characteristics:

Web services have the following special behavioral characteristics:

1. They are XML-Based - Web Services uses XML to represent the data at the
representation and data transportation layers. Using XML eliminates any networking,
operating system, or platform sort of dependency since XML is the common language
understood by all.

2. Loosely Coupled – Loosely coupled means that the client and the web service are not
bound to each other, which means that even if the web service changes over time, it
should not change the way the client calls the web service. Adopting a loosely coupled
architecture tends to make software systems more manageable and allows simpler
integration between different systems.

3. Synchronous or Asynchronous functionality- Synchronicity refers to the binding of

the client to the execution of the service. In synchronous operations, the client will
actually wait for the web service to complete an operation. An example of this is
probably a scenario wherein a database read and write operation are being performed.
If data is read from one database and subsequently written to another, then the
operations have to be done in a sequential manner. Asynchronous operations allow a
client to invoke a service and then execute other functions in parallel. This is one of the
common and probably the most preferred techniques for ensuring that other services
are not stopped when a particular operation is being carried out.

4. Ability to support Remote Procedure Calls (RPCs) - Web services enable clients to
invoke procedures, functions, and methods on remote objects using an XML-based
 protocol. Remote procedures expose input and output parameters that a web service
must support.

5. Supports Document Exchange - One of the key benefits of XML is its generic way of
representing not only data but also complex documents. These documents can be as
simple as representing a current address, or they can be as complex as representing an
entire book.

Web Services Standards:

In order for a web service to be fully functional, there are certain components that need to be in
place. These components need to be present irrespective of whatever development language is
used for programming the web service. These components are SOAP, WSDL and UIID.

SOAP (Simple Object Access Protocol)

SOAP is known as a transport-independent messaging protocol. SOAP is based on transferring

XML data as SOAP Messages. Each message has something which is known as an XML
document. Only the structure of the XML document follows a specific pattern, but not the
content. The best part of Web services and SOAP is that its all sent via HTTP, which is the
standard web protocol.

 Each SOAP document needs to have a root element known as the <Envelope> element. The
root element is the first element in an XML document.
 The "envelope" is in turn divided into 2 parts. The first is the header, and the next is the body.
 The header contains the routing data which is basically the information which tells the XML
document to which client it needs to be sent to.
 The body will contain the actual message.

WSDL (Web services description language)

The client invoking the web service should know where the web service actually resides.

Secondly, the client application needs to know what the web service actually does, so that it
can invoke the right web service. This is done with the help of the WSDL, known as the Web
services description language. The WSDL file is again an XML-based file which basically
tells the client application what the web service does. By using the WSDL document, the
client application would be able to understand where the web service is located and how it can
be utilized.

The important aspects to note about the above WSDL declaration are as follows;

<message> - This element is basically used to describe the data that gets exchanged between the

web service and the client application.

Each web service will always have 2 types of messages,

 One is for the input of the web service, and the other is for the output of the web service.
 The input is used to describe the parameters which are accepted by the web service. This is an
important aspect of the client application so that it knows the values to be sent as parameters
to the web service.
 The other type of message is the output message which tells what results are provided by the
web service.

Each message, in turn, will have a <part> element which is used to describe the parameter
used by the input and output message.

Ex: Input message: <message name=”studentrequest”>

<part name=”101” type=”xsd:number”>

</message>

Output message: <message name=”studentresponse”>

<part name=”A+” type=”xsd:string”>

</message>

<portType> - Ports are used in WSDL to define one complete operation which is offered by the
web service. In the previous example, together the input and output message form is known as
one complete operation.

WSDL provides an element called <portType> which is used to define the operations provided
by the Web service.

Ex: <portType name=”student_portType”>

<operation name=”grade_calculation”>

<input message=”studentrequest”/>

<output message=”studentresponse”/>

</operation>

</portType>

<binding> - This element contains the protocol which is used.

Universal Description, Discovery, and Integration (UDDI)

UDDI is a standard for describing, publishing, and discovering the web services that are
provided by a particular service provider. It provides a specification which helps in
hosting the information on web services.

UDDI provides a repository on which WSDL files can be hosted. So the client
application will have complete access to the UDDI, which acts as a database containing
all the WSDL files.

Just as a telephone directory has the name, address and telephone number of a particular
person, the same way the UDDI registry will have the relevant information for the web
service. So that a client application knows, where it can be found.