SERVICE ORIENTED

ARCHITECTURE
UNIT-1

1
 What is SOA?

SOA is an architecture for building

business applications as a set of loosely
coupled black-box components
orchestrated to deliver a well-defined level
of service by linking together business
processes
Traditional Applications:
Traditional Applications:
The radio

The radio

The
Speakers

The Cassette
Player
 But, what happens if...
• We want a double cassette
• Or a CD player
• Or a digital radio
• ...
We have to change the whole thing
With modular applications
 Speakers
With modular applications Speakers
Speakers

Speakers
Speakers
With modular applications
Amplifier

Double
cassette

DVD
 Do you need a CD player?

DVD
•Double

•cassette
200 CDs
Player

•Amplifier
CD Player and cassette?
Service-oriented architecture
(SOA) is exactly what's needed
It's an approach that helps systems remain
scalable and flexible while growing, and that
also helps bridge the business/IT gap

12
 Architecture Definition in IEEE
1471
⚫ Architecture :
The fundamental organization of a system embodied
in it’s components, their relationships to each other,
and to the environment, and the
principles guiding it’s design and evolution
⚫ Architect :
The person, team, or organization responsible for
designing systems architecture
 Software Architecture
⚫ What is Software Architecture?

⚫ The software architecture of a program or computing

system is a depiction of the system that aids in the
understanding of how the system behave
⚫ Serves as blueprint for both the system and the project
developing
⚫ The primary carrier of system qualities
⚫ An artifact for early analysis
⚫ Set of structures needed to reason about the system
⚫ Documentation of a system
SOA
The approach consists of three
major elements:
• Services, which on the one hand represent
self-contained business functionalities that can
be part of one or more processes, and on the
other hand, can be implemented by any
technology on any platform.
• A specific infrastructure, called the enterprise
service bus (ESB), that allows us to combine
these services in an easy and flexible manner.
• Policies and processes that deal with the fact
that large distributed systems are
heterogeneous, under maintenance, and have
different owners.

16
Fundamental SOA
1. The term "service-oriented" has existed for some time, it
has been used in different contexts and for different
purposes
2. Approach
1. The logic required to solve a large problem can be better
constructed, carried out, and managed if it is decomposed into
a collection of smaller, related pieces.
2. Each of these pieces addresses a concern or a specific part of
the problem.
3. This approach transcends technology and automation
solutions. It is an established and generic theory that can
be used to address a variety of problems.

17
A service oriented analogy

Credit companies are service-oriented in that each provides a

distinct service that can be used by multiple consumers
18
Service Oriented and Composition
The definition of software
services aligns with the
business services that a
bank offers to ensure
smooth business
operations and to help
realize strategic goals
such as providing ATM
and Web access to
banking services in
addition to providing
them in the branch
office.

19
Architecture
•When coupled with "architecture,"
service-orientation takes on a technical
connotation.
•"Service-oriented architecture" is a term that
represents a model in which automation logic is
decomposed into smaller, distinct units of logic.
• Collectively, these units comprise a larger piece of
business automation logic.
• Individually, these units can be distributed. 20
Services oriented
Service-oriented architecture (SOA)

• encourages individual units of logic to exist autonomously yet

not isolated from each other.
• Units of logic are still required to conform to a set of principles
that allow them to evolve independently, while still maintaining
a sufficient amount of commonality and standardization.

•Within SOA, these units of logic are known as

services.

21
How services encapsulate logic

•each service can

encapsulate
• a task performed by an
individual step
• a sub-process comprised
of a set of steps.
•A service can even
encapsulate the entire
process logic.

22
How services relate (I)
•The relationship between services is based on an
understanding that for services to interact, they must
be aware of each other. 🡪 service descriptions.
•A service description establishes
• the name of the service
• the data expected and returned by the service.

23
How services relate (II)
•The manner in which services use service descriptions
results in a relationship classified as loosely coupled.
• Loose coupling describes an approach where integration
interfaces are developed with minimal assumptions between
the sending/receiving parties, thus reducing the risk that a
change in one application/module will force a change in
another application/module. ( wikipedia ottobre 2007 )
•A communications framework capable of preserving
their loosely coupled relationship is therefore
required. [ messaging ].

24
How services communicate
• After a service sends a message, it loses control of what happens to the
message thereafter.
• The messages exist as "independent units of communication."

25
 Why SOA?
Necessity of SOA

♣ Heterogeneous cross-platform
♣ Reusability at the macro (service) level rather
than micro(object) level
♣ Interconnection to - and usage of - existing IT
(legacy) assets
♣ Granularity, modularity, composability,
componentization
♣ Compliance with industry standards
 Benefits of SOA
⚫ New products or processes simply execute
⚫ Flexible systems are not obstacle to changing and rapid
evolution of processes
⚫ Solving complex integration problem of large systems
⚫ Divided of project into smaller components that can be
done independent is simply
⚫ Control of progress in each subproject is calculated
⚫ Integration and connecting to other systems is dominant
approach
 Benefits of SOA
⚫ Systems easily meet the requirements of users
⚫ The problem of data transfer between systems is solved
with integration
⚫ Complexity of systems hidden from users
⚫ Enterprise architects believe that the SOA can help the
business to response faster and more cost-effective to
market conditions changing
⚫ This style of architecture use reusability in macro level
instead micro level
THE EVOLUTION OF
SOA

29
SOA Timeline

30
SOA is an evolutionary step
▪ for architecture
 An SOA Timeline
XML to Web Services to SOA
XML: brief history
• Like HTML, the Extensible Markup Language (XML) was a W3C
creation derived from the popular Standard Generalized Markup
Language (SGML) that has existed since the late 60s.
• This widely used meta language allowed organizations to add
intelligence to document data.
• The language itself was used as the basis for a series of additional
specifications.
• XML Schema Definition Language (XSD) and XSL
Transformation Language (XSLT) were both authored using XML.
(These specifications, in fact, have become key parts of the core XML
technology set)

33
XML
• XML data representation is the foundation layer of SOA
• XML establishes the structure of messages traveling between
services
• XSD schemas preserve the integrity and validity of message data
• XSLT is used to enable communication between disparate data
representations by schema mapping
Web Services:a brief history (I)
• In 2000, the W3C received a submission for the Simple Object

Access Protocol (SOAP) specification.

• This specification was originally designed to unify (and in some cases

replace) proprietary RPC communication. The idea was for parameter data
transmitted between components to be serialized into XML, transported,
and then deserialized back into its native format.

35
 Web Services:a brief history (II)
• This ultimately led to the idea of creating a pure, Web-based,
distributed technology (one that could leverage the concept of
a standardized communications framework to bridge the
enormous disparity that existed between and within
organizations).
• This concept was called Web services.

• The most important part of a Web service is its public interface.

• It is a central piece of information that assigns the service an identity and
enables its invocation

36
 Web Services:a brief history (III)
• One of the first initiatives in support of Web services was the
Web Service Description Language (WSDL).
• The W3C received the first submission of the WSDL language in 2001 and
has since continued revising this specification.

• IBM and Microsoft were each working on a way to

programmatically describe how to connect to a Web Service.
After some discussion, protocol proposals from Microsoft and
IBM merged. In late 2000, a merged specification, Web
Services Description Language (WSDL), was announced.

37
Web Services:a brief history
•Web services required an Internet-friendly and
XML-compliant communications format
•Other alternatives were considered (XML-RPC),
but SOAP was the winning technology
•W3C responded by releasing newer versions of
SOAP that allow RPC-style and document-style
messages
•SOAP became a standalone term as the
acronym no longer matched the purpose
Web Services:a brief history
• Completing the first generation of the Web services standards
family was the UDDI specification.
• Originally developed by UDDI.org, it was submitted to OASIS, which
continued its development in collaboration with UDDI.org.

• This specification allows for the creation of standardized

service description registries both within and outside of
organization boundaries.
• UDDI provides the potential for Web services to be registered
in a central location, from where they can be discovered by
service requestors.
• Unlike WSDL and SOAP, UDDI has not yet attained
industry-wide acceptance, and remains an optional
extension to SOA.
39
Custom Web Services
•Custom services were developed to
accommodate specialized business
requirements
•Existing messaging platforms (Message
Oriented MiddleWare – MOM) incorporated
services to support SOAP
•Some organizations incorporated Web services
for B2B data exchange – replacing EDI
(Electronic Data Interchange)
 SOA History
• Web services could become the basis of a separate
architectural platform that could leverage the benefits of
the Web services technology.

• Thus, service-oriented architecture entered the IT

mainstream.

• At this point an SOA was classified in different ways,

depending on the implementation technology used to
build services.
Early incarnation of SOA:
Architecture modeled around three
basic components

42
Standard Organizations that
contribute to SOA
•W3C
• In the SOA arena, its role has been primarily as a standards body
responsible for specifications that provide core and generic functionality.
•OASIS
• Its overall goal is to support the creation of standards targeted at specific
industries and to foster trade and commerce between eBusiness-enabled
enterprises.
•WS-I
• not produce technology standards.
• Instead, this organization provides profile documents that establish a
proven and tested collection of standards. Compliance to these profiles
guarantees organizations that their environments support a level of
industry-standard interoperability.

43
Comparision of Standards Organizations

44
 What Are Web Services?
• Web Services refers to a collection of standards that cover interoperability.

• These standards define both the protocols that are used to communicate
and the format of the interfaces that are used to specify services and service
contracts.

45
Fundamental Web Services Standards
• There are five fundamental Web Services standards.
• Two of them are general standards that existed beforehand and were used
to realize the Web Services approach:
• XML is used as the general format to describe models, formats, and data types.
• HTTP (including HTTPS) is the low-level protocol used by the Internet.

46
•The other three fundamental standards are specific to
Web Services and were the first standards specified
for them:
• WSDL is used to define service interfaces. In fact, it can
describe two different aspects of a service: its signature
(name and parameters) and its binding and deployment
details (protocol and location).
• SOAP is a standard that defines the Web Services protocol.
While HTTP is the low-level protocol, also used by the
Internet, SOAP is the specific format for exchanging Web
Services data over this protocol.
• UDDI is a standard for managing Web Services (i.e.,
registering and finding services).

47
Primitive SOA
represents a baseline
technology architecture that is
supported by current major
vendor platforms

48
The Service-Oriented Enterprise

49
Extensible Markup Language
(XML)
•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.

50
Web services
•Pervasive, open standards for distributed
computing interface descriptions and document
exchange via messages.
•Independence from the underlying execution
technology and application platforms.
•Extensibility for enterprise qualities of service
such as security, reliability, and transactions.
•Support for composite applications such as
business process flows, multi-channel access,
and rapid integration.
51
Service-oriented architecture
(SOA)
•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.
•A reusable library of services for common
business and IT functions
52
Business process management
(BPM)
•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.
53
 Compare SOA to past
architectures

Comparing SOA to client-server and Distributed

internet architectures
•SOA vs. client-server architecture
•SOA vs. distributed Internet architecture

54
Client Server
Architecture

• The original monolithic mainframe systems that
empowered organizations to get seriously
computerized often are considered the first
inception of client-server architecture.
• These environments, in which bulky mainframe
back- ends served thin clients, are considered an
implementation of the single-tier client-server
architecture

Unit 1

Mainframe systems natively supported both synchronous and
asynchronous communication.

The latter approach was used primarily to allow the server to
continuously receive characters from the terminal in response
to individual key-strokes. Only upon certain conditions would
the server actually respond.

While its legacy still remains, the reign of the mainframe as
the foremost computing platform began to decline when a
two-tier variation of the client-server design emerged in the
late 80s.

Unit 1

This new approach introduced the concept of delegating logic
and processing duties onto individual workstations, resulting
in the birth of the fat client.

The common configuration of this architecture consisted of
multiple fat clients, each with its own connection to a database
on a central server.

Client-side software performed the bulk of the processing,
including all presentation-related and most data access logic.

One or more servers facilitated these clients by hosting
scalable RDBMSs.

Unit 1
Figure: A typical two-tier client-server architecture.

Unit 1
 
Primary characteristics of the two-tier client-server
architecture individually and compare them to the
corresponding parts of SOA.


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.

Unit 1

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 make 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 withUnit
SOAP1
message framework. It makes use
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.

Unit 1
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.

Unit 1
SOA vs Traditional Distributed
Internet Architecture

Distributed architecture consists of many components
but it reduces problem of centralization on server.

It provides a dedicated servers which shares and
manages database connections.

Distributed architecture introduces a new physical tier
web server, which replaced HTTP by RPC protocol to
communicate between remote web and application
server

Unit 1
Distributed Systems
•As businesses grow, they become more and more
complex, and more and more systems and companies
become involved.
•SOA is a paradigm for "organizing and utilizing
distributed capabilities."
•SOA allows entities that need certain distributed
capabilities to locate and make use of those
capabilities. In other words, it facilitates interactions
between service providers and service consumers,
enabling the realization of business functionalities.

65
Different Owners and
Heterogeneity
•SOA includes practices and processes that are
based on the fact that networks of distributed
systems are not controlled by single owners.
• Different teams, different departments, or even
different companies may manage different
systems
•Thus, different platforms, schedules, priorities,
budgets, and so on must be taken into account.
•This concept is key to understanding SOA and
large distributed systems in general.
66
Distributed systems are
heterogeneous

67
Unit 1
 Distributed Object Systems / Protocols

• The distributed object paradigm has been

widely adopted in distributed applications, for
which a large number of mechanisms based on
the paradigm are available. Among the most
well known of such mechanisms are:
~ Java Remote Method Invocation (RMI),
~ the Common Object Request Broker Architecture
(CORBA) systems,
~ the Distributed Component Object Model
(DCOM),
~ mechanisms that support the Simple Object
Access Protocol (SOAP).
 RMI architecture
Web server

Client Browser

HTTP

Applets HTML
HTML pages

Java applets Application server

Object
Implementation

Stub Skeleton

JRMP / IIOP
 CORBA architecture
Web server
Client
Browser
HTTP

Applets HTML
HTML pages

Java applets Application server

Object
Implementation

Client Server
ORB ORB
IIOP
 DCOM architecture
Web server

Client Browser

HTTP

ActiveX HTML
HTML pages

ActiveX Application server

Controls

Object
Implementation

Proxy Stub
DCOM
Application Logic

SOA is similar to distributed internet application
place their application logic lies on server side but
difference lies in principles.

Components are tight coupled and processing
is wasted to locate component at runtime whereas
web services are loosely coupled thus it introduces
opportunity for reuse and extensibility.

Unit 1
Application Processing
Distributed architecture promotes proprietary
protocols like DCOM and CORBA for remote
data exchange.
SOA relies on message based communication,
it involves serialization and deserialization of
SOAP messages containing XML document
payloads

Unit 1
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.

Unit 1
Security

Traditional security architectures includes
approaches like delegation and impersonation,
encryption to HTTP protocol.

SOA rely heavily extension and concepts
provided by WS-Security framework,

SOA emphasize on security logic.

SOAP messages provides header in security
logic can be stored.
Unit 1
 Limitations of Components

♣ Tightly coupled
♣ Cross language/ platform issues
♣ Interoperability issues
♣ Maintenance and management
♣ Security issues
Common Characteristics of SOA

78
 Characteristics of
SOA
The following primary characteristics:
1.Contemporary SOA is at the core of the service- oriented
computing platform.
2.Contemporary SOA increases quality of service.
3.Contemporary SOA is fundamentally autonomous.
4.Contemporary SOA is based on open standards.
5.Contemporary SOA supports vendor diversity.
6.Contemporary SOA fosters intrinsic interoperability.
7.Contemporary SOA promotes discovery.
8.Contemporary SOA promotes federation.
9.Contemporary SOA promotes architectural composability.

Unit 1
10. Contemporary SOA fosters inherent reusability.
11. Contemporary SOA emphasizes extensibility.
12. Contemporary SOA supports a service-oriented business
modeling paradigm.
13. Contemporary SOA implements layers of abstraction.
14. Contemporary SOA promotes loose coupling throughout
the enterprise.
15. Contemporary SOA promotes organizational agility.
16. Contemporary SOA is a building block.
17. Contemporary SOA is an evolution.
18. Contemporary SOA is still maturing.
19. Contemporary SOA is an achievable ideal.

Unit 1
SOA increases quality of service
• Ability for tasks to be carried out in a secure manner, protecting the

contents of a message, as well as access to individual services.

• Reliability so that message delivery or notification of failed delivery

can be guaranteed.

• Overhead imposed by SOAP message and XML content processing

does not inhibit the execution of a task.

81
SOA is based on open standards
• Standard open technologies are used within and

outside of solution boundaries.

82
SOA supports vendor diversity

83
SOA promotes discovery

84
SOA encourages intrinsic
interoperability

85
SOA promotes federation

86
SOA promotes architectural
composability

• Different solutions can be composed of different extensions

and can continue to interoperate as long as they support
the common extensions required.
87
SOA encourages intrinsic
reusability

88
 SOA emphasizes extensibility

• Extensible services can expand functionality with

minimal impact.
89
SOA implements layers of
abstraction

• Application logic created with proprietary technology

can be abstracted through a dedicated service layer.

90
SOA promotes loose coupling
throughout the enterprise

91
SOA promotes organizational agility

92
SOA Is a Paradigm
• SOA is not a concrete architecture: it is
something that leads to a concrete architecture.
• You might call it a style, paradigm, concept,
perspective, philosophy, or representation.
• It is an approach, a way of thinking, a value
system that leads to certain concrete decisions
when designing a concrete software
architecture.
• This aspect of SOA has a very important
consequence: you can't buy SOA.
93
SOA Aims to Improve Flexibility

•A critical factor for business success is keeping

time to market share.
•My job is to deliver on time, on budget, with the
"appropriate" quality metrics.
•To deliver a quality solution right on time, you
need flexibility. But flexibility has a lot to do
with clear organization, roles, processes, and so
on. Therefore,
•SOA has to deal with all these aspects.

94
SOA Reference Model
SOA Reference Model...
• Is not architecture for a single implementation.

• Is a model for developing a range of Service Oriented

Architectures and analysis/comparison thereof.

• Is a framework for understanding significant relationships

among the entities in a SOA environment.

• Is based on a small number of unifying concepts of all SOA’s.

• A Reference Model is the best mechanism to define SOA.

To develop a Reference Model for
SOA
Ask questions:
• What elements are common in all implementations of
SOA?
• What abstract concepts do those elements represent?
• What relationships exist amongst those concepts?
• How do we represent those concepts without
referencing concrete implementations.
• How does this relate to infrastructure concepts?
Principal concepts in the Reference Model

98
99
100
101
SOA Reference Model

102
• This reference model defines the essence of service oriented
architecture, and develop with a vocabulary and a common
understanding of SOA.
• It provides a normative reference that remains relevant for
SOA
• It is an abstract and powerful model, irrespective of the
various and inevitable technology evolutions that will
influence SOA deployment.
• It is the basis for describing references architectures and
patterns for more specific categories of SOA designs.

103
• Concrete architectures arise from a combination of reference
architectures, architectural patterns and additional
requirements, including those imposed by technology
environments.
• Architecture must account for the goals, motivation, and
requirements that define the actual problems being addressed.
• While reference architectures can form the basis of classes of
solutions, concrete architectures will define specific solution
approaches.

104
• Architecture is often developed in the context of a
pre-defined environment, such as the protocols, profiles,
specifications, and standards that are pertinent.
• SOA implementations combine all of these elements, from
generic architectural principles and infrastructure that
define the current needs
• Represent specific implementations that will be built and
used in an operational environment.

105
106
 SOA Anatomy
Logic components of the Web services
framework
Web services contain
one or more
operations.

Figure 8.4 as an
example

10
Unit 1 7
Logic components of the Web
services
framework
Each operation governs
the process of a specific
function the web service
is capable of
performing.

Figure 8.5 gives an

example of an operation
sending and receiving
SOAP messages
10
Unit 1 8
Logic components of the Web
services Framework
Web services form an
activity though
which they can
collectively
automate a task.

Figure 8.6 as an
example

10
Unit 1 9
L ogic components of SOA
•Renamed terms
Fundamental parts of the
framework •Messages

• SOAP messages •Operations

• Web service operations •Services

• Web services •Processes

• Activities
•Activity has been changed because
it uses a different context when
modeling service-oriented business
processes.

11
Unit 1 0
L ogic components of
automation
Messages = units of communication

Operations = units of work

Services = units of processing logic

Processes = units of automation

logic
11
Unit 1 1
L ogic components of
automation
The purpose of these views is to
express the process, services
and operations.
Is also provides a flexible means
of partitioning and modularizing
the logic.
These are the most basic
concepts that underlies
service-orientation.

11
Unit 1 2
Components of an
SOA
Message
A message represents the data required to complete
some or all parts of a unit of work.
Operation
An operation represents the logic required to
process messages in order to complete a unit of
work.

11
01/20/13 Unit 1 3
Components of an
SOA
Service
A service represents a logically grouped set of
operations capable of performing related units of work.
Processes
A process contains the business rules that determine
which service operations are used to complete a unit of
automation.
A process represents a large piece of work that requires
the completion of smaller units of work.

11
01/20/13 Unit 1 4
Components of an
SOA

11
01/20/13 Unit 1 5
How components in an SOA inter-relate
• An operation sends and receives messages to
perform work.

• An operation is therefore mostly defined by the

message it processes.

• A service groups is a collection of related

operations.

• A service is therefore mostly define by the

operations that comprise it. 11
6
Unit 1
How components in an SOA inter-relate
• A process instance can compose service.

• A process instance is not necessarily defined

by its service because it may only require a
subset of the functionality offered by the
services.

• A process instance invokes a unique series of

operations to complete its automation.

• Every process instance is therefore partially

11
defined by the
Unit 1 service operation it uses. 7
How components in an SOA inter-relate

11
Unit 1 8
Common misperceptions about SOA
•An application that uses Web services is
service-oriented
• you need to standardize how Web services are positioned and
designed, according to service-orientation principles.
•SOA is just a marketing term used to re-brand Web
services
• SOA is a legitimate and relatively established technical term.
It represents a distinct architecture based on a set of distinct
principles.
•If you understand Web services you won't have a
problem building SOA
•Once you go SOA, everything becomes interoperable
119
TECHNICAL BENEFITS of SOA
• Efficient development process

• Reduced number of interfaces and development time

• Platform-agnostic applications

• Design time discovery, introspection and usage of services

• Standards-based architectures

• Several enablers - Portals, BPM, BI, ERP

120
BUSINESS BENEFITS of SOA
• Agile business and technology environment

• Reduced business, IT, and maintenance costs

Manageable project size

• Technology autonomy and platform-agnostic systems

• Facilitates automated business process

• Evolutionary approach

121
Limitations of SOA

122
Service orientation : three core
components
1. SERVICES

2. DESCRIPTIONS

3. MESSAGES

123
Architectural component design

124
How services are designed :key aspects
• Loose coupling 🡪 Services maintain a relationship that only requires that
they retain an awareness of each other.

• Service contract 🡪 Services adhere to a communications agreement

• Autonomy 🡪 Services have control over the logic they encapsulate.

• Abstraction 🡪 Services hide logic from the outside world.

• Reusability 🡪 Logic is divided into services with the intention of promoting

reuse.
• Composability 🡪 Collections of services can be coordinated and assembled
to form composite services.
• Discoverability 🡪 Services are designed to be outwardly descriptive so that
they can be found and assessed via available discovery mechanisms.

125
How services are built
•the term "service-oriented" and various abstract SOA
models existed before the arrival of Web services.
•However, no one technology advancement has been
so suitable and successful in manifesting SOA than
Web services.
•All major vendor platforms currently support the
creation of service-oriented solutions, and most do so
with the understanding that the SOA support
provided is based on the use of Web services.

126
 Common principles of
service-orientation
 Services are reusable

 Services share a formal

contract

 Services are loosely coupled

 Services abstract underlying

logic

 Services are composable

 Services are autonomous

 Services are stateless

12
Unit 1 7
 Services are discoverable
VIDEO REFERENCES
• https://www.youtube.com/watch?v=-9zgeS9B2NE

• https://www.youtube.com/watch?v=A3_QlYJRVvk

• https://www.youtube.com/watch?v=_dFJOSR-aFs

128
SOA Delivery Lifecycle
& Case Study
SOA Delivery Lifecycle

1
3
 SOA Delivery Lifecycle
• Service-oriented analysis
– Determine potential scope of of our SOA Service are
– mapped out
– Individual services are model as services candidate

1
3
Service-Oriented Analysis

1
3
 Service Delivery LifeCycle
• Service-oriented design
– Heavily standard-driven phase
– Service design
– Business process definition

1
3
Service-Oriented Design

1
3
Three core specification associate
with Service Design

1
3
 Service Delivery Lifecycle
• Service Development
– Actual construction phase
– Choice of programming language
– .NET or Java EE platform
• Service Testing
– Services are required to undergo rigorous testing
prior to deployment
• Service Deployment
– Configuring distributed components, service
interfaces, and any associated middleware products
onto production servers 2
 Service Delivery LifeCycle
• Service administration
– Standard application management issues
– How to monitor service usage?
– Version control? Message traced?
–

1
3
 Role and Responsible
• SOA Leaders
– Decide whether SOA is right for the organization
– If so, make SOA a business principle
– Drive SOA adoption within the organization
• Business Process Managers
– Train to use BPM tools & know the methodology of
BPM
– Perform BPM
– Drive continuous optimization of business process
1
3
 Role and Responsible
• IT Architects
– Derive the technical infrastructure for SOA
– Make the proper standards are being followed
– Describe technical principles (best practices)
– Establish the Service Oriented Analysis-Design
• SOA Developers
– Design & develop services and business processes
– Most services will wraping up existing software
systems
1
3
 Role and Responsible
• SOA Support Personnel
– Monitor day-to-day operation of developed business
processes
– Suggest enhancements to a business process to the
business managers
• Software Testers
– Test services & business processes
• IT Managers
– IT governance & SOA governance
1
4
SOA Case Studies

1
4
Telco – Case Study

1
4
1. Electronic Wallet

1
4
1. Electronic Wallet

1
4
2. 128 Kb SIM

1
4
2. 128 Kb SIM

1
4
3. Easy Top-up

1
4
Business Requirement

1
4
Legacy Approach

1
4
Legacy Approach

1
5
Technical Challenges

1
5
SOA Approach

1
5
Results

1
5
THANK YOU

154