UCS1017

SERVICE ORIENTED
ARCHITECTURE
INSTITUTE VISION AND MISSION
VISION OF THE INSTITUTE:
To achieve a prominent position among the top technical institutions.

MISSION OF THE INSTIITUTE:

M1: To bestow standard technical education par excellence through
state of the art infrastructure, competent faculty and high ethical
standards.

M2: To nurture research and entrepreneurial skills among students in

cutting edge technologies.

M3: To provide education for developing high-quality professionals

to transform the society.
DEPARTMENT VISION AND MISSION
VISION OF THE DEPARTMENT:
To create eminent professionals of Computer Science and
Engineering by imparting quality education.

MISSION OF THE DEPARTMENT:

M1: To provide technical exposure in the field of Computer
Science and Engineering through state of the art
infrastructure and ethical standards.
M2: To engage the students in research and development
activities in the field of Computer Science and Engineering.
M3: To empower the learners to involve in industrial and
multi-disciplinary projects for addressing the societal needs.
PROGRAM EDUCATIONAL OBJECTIVES (PEOs):
Our graduates shall
PEO1: Analyse, design and create innovative products for addressing
social needs.
PEO2: Equip themselves for employability, higher studies and
research.
PEO3: Nurture the leadership qualities and entrepreneurial skills for
their successful career

PROGRAM SPECIFIC OUTCOMES (PSOs):

Students will be able to
PSO1: Apply the basic and advanced knowledge in developing
software, hardware and firmware solutions addressing real life
problems.
PSO2: Design, develop, test and implement product-based solutions for
their career enhancement.
PROGRAM OUTCOMES:
PO1 Engineering knowledge
PO2 Problem analysis
PO3 Design/development of solutions
PO4 Conduct investigations of complex problems
PO5 Modern tool usage
PO6 The engineer and society
PO7 Environment and sustainability
PO8 Ethics
PO9 Individual and team work
PO10 Communication
PO11 Project management and finance
PO12 Life-long learning
COURSE OUTCOMES:
1. Outline the various SOA and web service
fundamentals.
2. Demonstrate the steps involved in service-oriented
analysis and design.
3. Implement SOA in development life cycle of web
services experiment with the advanced concepts in
SOA such as WS security.
4. Model the various business processes involved in a
given application with the help of BPEL.
5. Understand the functioning of XML and XML
transformations.
UNIT I - SOA AND WEB SERVICE FUNDAMENTALS

Introduction to SOA - Evolution of SOA - Fundamentals of SOA

- Characteristics of SOA -benefits - Anatomy of SOA - service
orientation and object orientation - Web services and Primitive -
service layers - WSDL - Messaging with SOAP - Message
exchange patterns -coordination - Atomic transactions - Case
Study: Web services - SOAP - REST
Service Oriented Architecture (SOA)

A Service-Oriented Architecture or SOA is a design pattern which is

designed to build distributed systems that deliver services to other
applications through the protocol. It is only a concept and not
limited to any programming language or platform.

There are two major roles within Service-oriented Architecture:

1. Service provider: The service provider is the maintainer of the

service and the organization that makes available one or more
services for others to use.
2. Service consumer: The service consumer can locate the service
metadata in the registry and develop the required client
components to bind and use the service.
Characteristics of SOA

The services have the following characteristics:

o They are loosely coupled.

o They support interoperability.
o They are location-transparent
o They are self-contained.
Components of service-oriented architecture

The service-oriented architecture stack can be

categorized into two parts - functional aspects and
quality of service aspects.
Functional aspects
The functional aspect contains:
o Transport - It transports the service requests from the service
consumer to the service provider and service responses from the
service provider to the service consumer.
o Service Communication Protocol - It allows the service provider
and the service consumer to communicate with each other.

o Service Description - It describes the service and data required to

invoke it.
o Service - It is an actual service.
o Business Process - It represents the group of services called in a
particular sequence associated with the particular rules to meet the
business requirements.

o Service Registry - It contains the description of data which is used

by service providers to publish their services
Quality of Service aspects

The quality of service aspects contains:

o Policy - It represents the set of protocols according to which a
service provider make and provide the services to consumers.
o Security - It represents the set of protocols required for
identification and authorization.

o Transaction - It provides the surety of consistent result. This

means, if we use the group of services to complete a business
function, either all must complete or none of the complete.
o Management - It defines the set of attributes used to manage the
services
Advantages of SOA
SOA has the following advantages:
o Easy to integrate - In a service-oriented architecture, the
integration is a service specification that provides
implementation transparency.
o Platform Independence - The services are platform-
independent as they can communicate with other applications
through a common language.
o Loose coupling - It facilitates to implement services without
impacting other applications or services.
o Parallel Development - As SOA follows layer-based
architecture, it provides parallel development.
o Available - The SOA services are easily available to any
requester.
o Reliable - As services are small in size, it is easier to test and
debug them.
 ANATOMY OF SOA

o Service-oriented Architecture (SOA) has emerged from the

previous practices of object orientation and component-based
application development to promote better reusability and
flexibility of business components. This is a new approach
towards building application architecture for an organization.
Successful implementation of SOA requires several infrastructure
components that can support various services, and relationships
between various service providing applications to service the
consuming applications. The paper explains the
infrastructural components of a typical SOA and discusses the key
architectural and design decisions along with various layers of SOA.

o Typically, Information Technology (IT) infrastructure of an organization

is built over a period of time with different applications developed at
different points in time, on different platforms to meet different business
needs. This gives rise to heterogeneity in the organization's IT
infrastructure across operating systems, applications, system software and
application infrastructure. Today, organizations face the challenge of being
agile and respond quickly to the changing business environment; leverage
upon the existing IT investments and application infrastructure to address
newer business needs; support different channels of interaction with
customers, partners and suppliers. This calls for having a well-crafted IT
architecture that can support the present services requirement, and easily
scale up for future needs while optimizing the use of the existing IT
infrastructure.
 o Further, application and technology infrastructure for the
company are highly interdependent. When business processes
change, the applications supporting such processes also need to be
changed and realigned accordingly. Given the shrinking time to
manage change in business processes, one really has to have
solutions that adapt to changes within days instead of
weeks/months, at the same time, at minimum possible cost.
Service-oriented Architecture (SOA) has evolved as a solution to
address the heterogeneity of IT infrastructure by loosely coupling
independent applications and align business processes and
technology infrastructure.

It is quite difficult to think in terms of services. Though services are

implemented with the help of Object oriented languages We should
Object Orientation:

• Assume homogeneous platform and execution

environment
• Share classes, not schemas
• Assume cheap, transparent communication
• Are linked: Object identity and lifetime maintained by
infrastructure
• Typically require deployment of both client and server in
sync
• Are easy to talk about and become a natural path for
customers to follow
• Customers have 20+ years of experience and great intuition
about what “object oriented is”
Service Orientation:

• Assume heterogeneous platform and execution environment

• Share schemas, not classes
• Assume variable cost, explicit communication
• Are autonomous: Security and failure isolation are a must
• Ease “continuous deployment” of client and server separately
• Builds on ideas from component software, distributed objects, and
MOM
• Dominant theme is to manage/reduce sharing between services
What is Web Services?

Web services are the types of internet software that uses standardized
messaging protocol over the distributed environment. It integrates the web-
based application using the REST, SOAP, WSDL, and UDDI over the
network. For example, Java web service can communicate with .Net
application.

Components of Web Services

The web services must be able to fulfill the following conditions:

o The web service must be accessible over the internet. o The web service
is discoverable through a common mechanism like UDDI. o It must be
interoperable over any programming language or Operating System.
How does data exchange between applications?

Suppose, we have an Application A which create a request to access the

web services. The web services offer a list of services. The web service
process the request and sends the response to the Application A. The input
to a web service is called a request, and the output from a web service is
called response. The web services can be called from different platforms .

Request

—T-
Application A Web Services
<-
Response
There are two popular formats for request and response XML and
JSON.

XML Format: XML is the popular form as request and response

in web services. Consider the following XML code:

1. <getDetail>
2. <id>DataStructureCourse</id>
3. </getDetail>

The code shows that user has requested to access the

DataStrutureCourse. The other data exchange format is JSON.
JSON is supported by wide variety of platform.

JSON Format: JSON is a readable format for structuring data. It

is used for transiting data between server and web application.
 1. [
2. "employee":
3. {
4. "id": 00987
5. "name": "Jack",
6. "salary": 20000,
7. }
8. ]

To make a web service platform-independent, we make the request and

response platform-independent.

Now a question arises, how does the Application A know the format of Request
and Response?
The answer to this question is "Service Definition." Every web service offers a
service definition. Service definition specifies the following:

o Request/ Response format: Defines the request format made by

consumer and response format made by web service.
o Request Structure: Defines the structure of the request made by the
application. o Response Structure: Defines the structure of response
returned by the web service. o Endpoint: Defines where the services are
available.
PRIMITIVES :
Service generally includes set of various primitives. A primitive simply means
Operations. A Service is specified by set of primitives that are available and
given to user or other various entities to access the service. All these primitives
simply tell the service to perform some action or to report on action that is taken
by peer entity. Each of the protocol that communicates in layered architecture
also communicates in peer-to-peer manner with some of its remote protocol
entity. Primitives are called calling functions between the layers that are used to
manage communication among the adjacent protocol layers i.e., among the same
communication node. The set of primitives that are available generally depends
upon the nature of the service that is being provided.
Classification of Service Primitives :

Primitive Meaning

It represent entity that wants or request service to perform some

action or do some Request work (requesting for connection to remote
computer).

It represent entity that is to be informed about event (receiver just

have received Indication request of connection).

It represents entity that is responding to event (receiver is simply

sending the Response permission or allowing to connect).

It represent entity that acknowledges the response to earlier request

that has come Confirm back (sender just acknowledge the permission to get
connected to the remote host).
Primitive Meaning

It represent entity that wants or request service to perform some

action or do some Request work (requesting for connection to remote
computer).

It represent entity that is to be informed about event (receiver

just have received Indication request of connection).

It represents entity that is responding to event (receiver is simply

sending the Response permission or allowing to connect).

Confirm It represents the confirmation

In the above diagram, these four primitives work as following :

• Request - This primitive is transferred or sent to Layer N by Layer

(N+1) to just request for service.
• Indication - This primitive is returned by Layer N to Layer (N+1) to
just advise of activation of service that is being requested or of action
that is initiated by the service of Layer N.
• Response - This primitive is simply provided by Layer (N+1) in reply
to indication primitive. It might acknowledge or complete action that is
previously invoked by indication primitive.
• Confirm - This primitive is returned by the Nth layer to the requesting
(N+1)st layer to simply acknowledge or complete action that is
previously invoked by request primitive.
Parameters of Service Primitives : Some of the Service Primitives
need parameters. These are given below :
• Connect.Request - The initiating entity does this
Connect.Request. It just specifies and determines machine that
we want to get connected to, type of service that is being desired,
and maximum size of packet or message that is used on
connection.
• Connect. Indication - The receiver gets this
Connect.Indication. It just specifies caller’s identity service that
we want to use like FTP and Telnet, etc., and maximum size of
packets that are exchanged.
• Connect. Response - It just specifies whether or not it wants to
accept or simply reject connection that is being requested.
• Connect.Confirm - It just finds out or determines what happened
using the entity that is issuing the initial Connect. Request.
WSDL File
WSDL stands for Web Service Description Language. It describes the web services
and exchanges the information in a decentralized or distributed environment. It is
used to create a relationship between the service requester and the service provider. It
is an XML based language to describe the functionality of a SOAP-based web
service.

In this section, we will learn how to deal with WSDL file in SoapUI.

Features of WSDL

There are following features of WSDL:

o It is an XML based language that defines how to interact with an XML based
service in SoapUI.
o It is used to configure nodes in the SOAP domain. o It is used to describes the
functional characteristics of web service.
o It is used to set a defined endpoint in web service with a set of input, output,
and fault messages.
o WSDL is an XML-based language and it is platform-independent. o It is
pronounced as wiz-dull and is written as W-S-D-L.

WSDL Schemas in terms of Soap and XML:

WSDL is an important component for building web applications. It facilitates

various applications that are built on multiple languages to interact with each
other. WSDL is used as the combination of SOAP and XML schemas that
provide communication between the clients and web services over the internet.
To read the WSDL file, the client program must connect to the Web service and
specify the operation required to connect to the Web server.
WSDL Document Elements

o Definitions: It is the basic element of the WSDL document that

contains the definition of one or more services.
o Types: The Type element is used to give information about the
complicated data types used within the WSDL document.
o Message: It contains abstract data that is being used in communication
between client and web server. It also defines the data elements for each
operation. o portType: It contains the collection of abstract operation
supported by one or more endpoints. o Port: It is used to define the
single endpoint as an address for the binding.
 o Services: It is a collection of endpoint networks that specify the port address for
the binding.

o Binding: It specifies how operations are implemented by concrete protocols and

data format features for operation and messaging.

Structure of WSDL Document

The following code snippet shows the structure of WSDL documents.

1. <definitions>
2. <types>
3. Definition of types goes here.
4. </types>
5.
6. <message>
7. Definition of a message goes here.
8. </message>
9.
10. <portType>
11. <operation>
12. Definition of an operation goes here.
13. </operation>
14. </portType>
15.
16. <binding>
17. Definition of a binding goes here.
18. </binding>
19.
20. <service>
21. Definition of service goes here.
22. </service>
23. </definition>
 We can also add other elements such as extension elements and service
elements combined into a single WSDL document with possible
definitions of multiple web services.

The following are the four major transmissions of the WSDL that
support endpoint in the SoapUI tool.
1. One Way
2. Request and Response
3. Solicit response
4. Notification
The structure of a SOAP message

A SOAP message is encoded as an XML document, consisting of an

<Envelope> element, which contains an optional <Header> element, and a
mandatory <Body> element. The <Fault> element, contained in <Body>, is
used for reporting errors.
 The SOAP envelope
<Envelope> is the root element in every SOAP message, and contains two child
elements, an optional <Header> element, and a mandatory <Body> element.
The SOAP header
<Header> is an optional subelement of the SOAP envelope, and is used to pass
application-related information that is to be processed by SOAP nodes along the
message path; see The SOAP header.
The SOAP body
<Body> is a mandatory subelement of the SOAP envelope, which contains
information intended for the ultimate recipient of the message; see
The SOAP body.
The SOAP fault
<Fault> is a subelement of the SOAP body, which is used for reporting errors;
see The SOAP fault.
XML elements in <Header> and <Body> are defined by the applications that
make use of them, although the SOAP specification imposes some
constraints on their structure. The following diagram shows the structure of a
SOAP message.

SOAP envelope
SOAP header
Header block
Header block

SOAP body

Body sutMtlement
Message Exchange Patterns (MEPs)

An overview of the most common Message Exchange Patterns (MEPs) applicable to the
Business Integration and SOA domains.

Overview
Message Exchange Patterns (MEPs) describe how systems may intercommunicate
using unanimously understood mechanisms. Unless otherwise specified, MEPs
describe logical patterns rather than strict physical ones:

• Logical MEPs: they establish how data is exchanged at a conceptual/use-

case level. For example, a One-Way MEP establishes that there is “no
response” after firing a request. However, if the message is delivered using,
say, HTTP, there is effectively some form of response at the HTTP level. It
just happens to be of no “use case” relevance.
• Physical MEPs: they establish how data is physically exchanged by
computer systems. Within the physical layer, the distinction also varies
according to the chosen layer. For example, if we consider the OSI model’s
transport layer, UDP would be a One-way MEP whereas TCP can support the
Request/Response MEP, but it is, in reality, a bidirectional stream.
Overview of Web Services Atomic Transactions

WebLogic Web services enable interoperability with other external transaction

processing systems, such as Websphere, JBoss, Microsoft .NET, and so on, through
the support of the following specifications:

• WS-AtomicTransaction Version (WS-AT) 1.0, 1.1, and 1.2:

http://docs.oasis-open.org/ws-tx/wstx-wsat-1.2-spec-cs-01/wstx-wsat-1.2-spec-cs
-01.html
• WS-Coordination Version 1.0, 1.1, and 1.2:
http://docs.oasis-open.org/ws-tx/wstx-wscoor-1.2-spec-cs-01/wstx-wscoor-1.2-sp
ec-cs-01.html

These specifications define an extensible framework for coordinating distributed

activities among a set of participants. The coordinator, shown in the following figure,
is the central component, managing the transactional state (coordination context) and
enabling Web services and clients to register as participants.
Description of "Figure 6-1 Web Services Atomic Transaction
s Framework"
Table 6-1 Components of Web Services Atomic Transactions

Component Description
Coordinator Manages the transactional state (coordination context) and
enables Web services and clients to register as
participants.
Activation Enables the application to activate a transaction and create
Service a coordination context for an activity. Once created, the
coordination context is passed with the transaction flow.
Registration Enables an application to register as a participant.
Service
Application Supported coordination protocols, such as WS-
Protocol X, Y AtomicTransaction.
The following figure shows two instances of WebLogic Server interacting within the context of
a Web services atomic transaction. For simplicity, two WebLogic Web service applications are
shown.

Figure 6-2 Web Services Atomic Transactions in WebLogic Server Environment

Please note the following:

• Using the local JTA transaction manager, a transaction can be

imported to or exported from the local JTA environment as a
subordinate transaction, all within the context of a Web service
request.
• Creation and management of the coordination context is handled
by the local JTA transaction manager.
• All transaction integrity management and recovery processing is
done by the local JTA transaction manager.

For more information about JTA, see Programming JTA for Oracle
WebLogic Server.
The following describes a sample end-to-end Web services atomic
transaction interaction, illustrated in Figure 6-2:

1. Application A begins a transaction on the current thread of control

using the JTA transaction manager on Server A.
2. Application A calls a Web service method in Application B on Server
B.
3. Server A updates its transaction information and creates a SOAP
header that contains the coordination context, and identifies the
transaction and local coordinator.
4. Server B receives the request for Application B, detects that the
header contains a transaction coordination context and determines
whether it has already registered as a participant in this transaction. If it
has, that transaction is resumed and if not, a new transaction is started.
 Application B executes within the context of the imported
transaction. All transactional resources with which the application
interacts are enlisted with this imported transaction.

5. Server B enlists itself as a participant in the WS-AT transaction

by registering with the registration service indicated in the
transaction coordination context.
6. Server A resumes the transaction.
7. Application A resumes processing and commits the transaction.