June 29, 2007 [SERVICE ORIENTED ARCHITECTURE]

Service Oriented Architecture

Sunil Chakravarthy Binkam

Introduction
SOA stands for Service Oriented Architecture. The developers of SOA defines it as
“a style of multitier computing that helps organizations share logic and data among

ITON Technologies pvt ltd. 1

 June 29, 2007 [SERVICE ORIENTED ARCHITECTURE]

multiple applications and usage modes”. So from the very definition we can
understand that SOA is distributed, and collaborates various applications which
were developed in various languages to make a service. With java platform
independence came into existence and with SOA language independence came
into existence. In SOA we will talk about and talk through services which are the
basic building blocks of SOA.

What is a Service?

The central concept of the Reference Model is that of service, which the Reference
Model defines as follows: A mechanism to enable access to one or more capabilities,
where the access is provided using a prescribed interface and is exercised
consistent with constraints and policies as specified by the service description.

The following are the principal concepts that the Reference Model defines around
services. Visibility, Interaction, and Real World Effect address the dynamic aspects
of services (interactions with services), while the remaining concepts address static
aspects:

• Service Description: The information needed in order to use, or consider using, a

service. The purpose of description is to facilitate interaction and visibility,
particularly when the participants are in different ownership domains, between
participants in service interactions.

• Visibility: The capacity for those with needs and those with capabilities to be able
to interact with each other. This is typically done by providing descriptions for such
aspects as functions and technical requirements, related constraints and policies,
and mechanisms for access or response.

• Interaction: Refers to the interaction between service providers and consumers.

Typically mediated by the exchange of messages, an interaction proceeds through a
series of information exchanges and invoked actions. The result of an interaction is
a real world effect.

• Real World Effect: The actual result of using a service. This may be the return of
information or the change in the state of entities (known or unknown) that are
involved in the interaction.

• Execution Context: The set of technical and business elements that form a path
between those with needs and those with capabilities and that permit service
providers and consumers to interact. All interactions are grounded in a particular
execution context, which permits service providers and consumers to interact and
provides a decision point for any policies and contracts that may be in force.

• Contract & Policy: A policy represents some constraint or condition on the use,
deployment or description of an owned entity as defined by any participant, while a

ITON Technologies pvt ltd. 2

 June 29, 2007 [SERVICE ORIENTED ARCHITECTURE]

contract represents an agreement by two or more parties. The Reference Model is

focused primarily on the concept of policies and contracts as they apply to services.

A service contract needs to have the following components:

Header

• Name - Name of the service. Should indicate in general terms what it does,
but not be the only definition
• Version - The version of this service contract
• Owner - The person/team in charge of the service
• RACI
 Responsible - The role is the person/team responsible for the
deliverables of this contract/service. All versions of the contract
 Accountable - Ultimate Decision Maker in terms of this contract/service
 Consulted - Who must be consulted before action is taken on this
contract/service. This is 2-way communication. These people have an
impact on the decision and/or the execution of that decision.
 Informed - Who must be informed that a decision or action is being
taken. This is a 1-way communication. These people are impacted by
the decision or execution of that decision, but have no control over the
action.
• Type - This is the type of the service to help distinguish the layer in which it
resides. Different implementations will have different service types. Examples
of service types include:
 Presentation
 Process
 Business
 Data
 Integration
 Functional
• Functional Requirement (From Requirements Document) - Indicates the
functionality in specific bulleted items what exactly this service accomplishes.
The language should be such that it allows test cases to prove the
functionality is accomplished.

• Service Operations - Methods, actions etc. Must be defined in terms of what

part of the Functionality it provides.

• Invocation - Indicates the invocation means of the service. This includes the
URL, interface, etc. There may be multiple Invocation paths for the same
service. We may have the same functionality for an internal and external
clients each with a different invocation means and interface. Examples:
ITON Technologies pvt ltd. 3
 June 29, 2007 [SERVICE ORIENTED ARCHITECTURE]

 SOAP
 REST
 Events Triggers
 Non-Functional
• Security Constraints - Defines who can execute this service in terms of roles
or individual partners, etc. and which invocation mechanism they can invoke.

• Quality of Service - Determines the allowable failure rate

• Transactional - Is this capable of acting as part of a larger transaction and if

so, how do we control that?

• Service Level Agreement - Determines the amount of latency the service is

allowed to have to perform its actions

• Semantics - Dictates or defines the meaning of terms used in the description

and interfaces of the service

• Process - Describes the process, if any, of the contracted service.

WebServices:
Web services are a technology that is well suited to implementing aservice-oriented
architecture. In essence, Web services are self-describing andmodular applications
that expose business logic as services that can be published, discovered, and
invoked over the Internet. Based on XML standards,Web services can be developed
as loosely coupled application components between the serviceconsumer and
provider using any programming language, any protocol, or any platform.

The technology is based on open technologies such as:

 eXtensible Markup Language (XML)
 Simple Object Access Protocol (SOAP)
 Universal Description, Discovery and Integration (UDDI)
 Web Services Description Language (WSDL)

Using open standards provides broad interoperability among different vendor

solutions. These principles mean that companies can implement Web services
without having any knowledge of the service consumers, and vice versa.

A Web Service interface is described using Web Services Description

Language (WSDL) and accessed using the Simple Object Access Protocol (SOAP),
which is a form of XML document. And if the Web Service is to be registered and
discoverable, this is done via the Universal Description, Discovery, and Integration
(UDDI) interface.

ITON Technologies pvt ltd. 4

 June 29, 2007 [SERVICE ORIENTED ARCHITECTURE]

Features of Web Services:

 Web services are language independent and interoperable.
 Web services are open and standards based.
 Web services can be published, located, and invoked across the Web.
 Web services are dynamic.
 Web services are self-describing. Neither the client nor the server knows or
cares about anything besides the format and content of request and response
messages (loosely coupled application integration). The definition of the
message format travels with the message. No external metadata repositories
or code generation tools are required.
 Web services are modular. Web services are a technology for deploying and
providing access to business functions over the Web; J2EE, CORBA, and other
standards are technologies for implementing these Web services.

ITON Technologies pvt ltd. 5