7083T - Service Oriented Architecture

Week 2 Topic 01
SOA Fundamental
 System Architecture
Problem

Based on : Prabhat gangwar ppt

 System Architecture
Directions
1960 - 1980 1990 - 2000 2010 - 2050

Organization Focus Process Focus Distributed Functions

Mainframe Centric Client Server Data Centric
Internal Use Partial Connectivity Universal Interoperability
Unique Data EDI File Transfer Real-time Connectivity

Based on : Prabhat gangwar

 System Architecture
Data Interoperability Expands as Response Time Shrinks

Based on : Prabhat gangwar

 Fundamental SOA
A method of design, deployment, and management of both
applications and the software infrastructure where:
All software is organized into business services that are
network accessible and executable.
Service interfaces are based on public standards for
interoperability.
 Fundamental SOA
A distinct approach for separating concerns
Logic for large problems are decomposed into smaller, related
pieces
What distinguishes SOA in separating concerns is the manner
in which it achieves separation
Individual units of logic can be distributed
Why is SO separation different?
Units exist autonomously, but not isolated
Units maintain a degree of commonality and
standardization but can evolve independently
Units of logic are known as services
 Adding to the Definition
SOA is an evolution of past platforms, preserving
successful characteristics of traditional architectures,
and bringing with it distinct principles that foster
service-orientation in support of a service-oriented
enterprise
SOA is ideally standardized throughout an enterprise,
but achieving this state requires a planned transition
and the support of a still evolving technology set
 Misconceptions about SOA
An application that uses Web services is service-oriented
SOA is just a marketing term used to re-brand distributed
computing with Web services
SOA simplifies distributed computing
An application with Web services that uses WS-* extensions is
service-oriented
If you understand Web services you wont have a problem
building SOA
Once you go SOA, everything becomes interoperable
HOW SERVICE WORKS
 Services Encapsulate Business Logic

Services can be composed to produce other services

Business processes drive the design
Services execute in predefined sequences that match business
logic and runtime conditions
 Services Encapsulate Logic
Process

Process Service

Step
Service
Service

Sub Process
Service

Source : Service-Oriented Architecture, Thomas Erl, 2005

 How Services Relate
In order for services to interact, they must be aware of each
other
Awareness is achieved through service descriptions
Description: name, location, data exchange requirements
Services are loosely coupled through service descriptions
 How Services Relate

Service A Service B

Service
Description
for Service B

Source : Service-Oriented Architecture, Thomas Erl, 2005

 How Services Communicate
Services need to cooperate and so they must communicate
One communication framework is messaging
Messages, like services, are autonomous
After a message is sent, the service loses control of what
happens to the message
Messages carry enough intelligence to self-govern their parts
of processing logic
 How Services Communicate

Self-governing Message

Service A Service B

Service
Description
for Service B

Source : Service-Oriented Architecture, Thomas Erl, 2005

 How Services Are Designed
Like Object-orientation, service-orientation is a distince design
approach with a set of design principles
Application of principles results in a standardized service-
oriented processing logic
A solution comprised of units of service-oriented processing
logic is said to be a service-oriented solution
 SOA Design Principles

Loose Coupling Services maintain a relationship that

minimizes dependencies
Service Contract Services adhere to a communications
agreement defined by one or more service descriptions and
related documents
Autonomy Services have control over the logic they
encapsulate
 SOA Design Principles
Abstraction Beyond what is described in the service
contract, services hide logic from the outside world
Reusability Logic is divided into services with the intention
of promoting reuse
Composibility Collections of services can be coordinated
and assembled to form composite services
Statelessness Services minimize retaining information
specific to an activity
Discoverability Services are designed to be outwardly
descriptive so they can be found and accessed via discovery
mechanisms
 How Services Are Built
The arrival of Web service technology has promoted SOA
All major vendor platforms support SOA solutions with the
understanding that SOA support is based on Web services
SOA can be achieved without Web services, but the books
focus uses Web service technology
CONTEMPORARY SOA
 Contemporary SOA
The previously discussed ideas comprise primitive SOA
These ideas represent a baseline technology architecture
supported by all major vendors
All other forms of SOA are based on extending primitive SOA
The basic ideas in SOA are continually expanded upon by
vendors
Current platforms include powerful XML and Web services
support
This includes new Web services specifications
We refer to this extended variation of SOA as Contemporary
SOA
 Contemporary SOA
At the core of the service-oriented platform
The term SOA has come to have several meanings including a new
computing platform as well as an architectural approach
This book includes the notion of SOA as a contemporary service-
oriented platform

Increases quality of service but there is more yet to be done in

this area
Tasks need to be carried out in a secure manner, protecting the
contents of messages
Tasks to need to be carried out reliably so that message delivery or
notification of failed delivery is guaranteed
Performance needs to be enhanced for SOAP and XML processing
Transaction processing enhancement for task failure
 Contemporary SOA
Fundamentally autonomous
Individual services need to be as independent and self-contained as
possible
This is realized through message-level autonomy
Messages are intelligence-heavy and control the way they are
processed by recipients
Application that are comprised of autonomous services can be viewed
a composite, self-reliant services
 Contemporary SOA
Based on open standards, messages travel between
services via a set of protocols that is globally
standardized and accepted
Message format is standardized, too.
SOAP, WSDL, XML, and XML Schema allow messages
to be fully self-contained
For services to communicate, they only need to know
of each others service description. This supports
loose-coupling
This limits the role of proprietary technology
 Contemporary SOA
Supports vendor diversity
The communications framework bridges the heterogeneity within and
between corporations
Any development environment that supports web services can be
used to create a non-proprietary service interface layer
Integration technologies encapsulate legacy logic through service
adapters
 Contemporary SOA

Supports vendor diversity

.NET Solution J2EE Solution

Platform neutral
communication
Source : Service-Oriented Architecture, Thomas Erl, 2005
 Contemporary SOA
Promotes discovery
Universal Description Discovery and Integration (UDDI) provided for service registries
Few early SOA systems used UDDI
Promotes federation
Establish SOA in an enterprise doesnt require replacement of what you have
SOA helps establish unity across non-federated environments
Legacy logic is exposed via a common, open, and standardized communcation network
Promotes architectural composability
Supports the automation of flexible, adaptable business process by composing loosely
coupled services
Web service framework is evolving with the release of numerous WS-* specifications that
can be composed
WS-* specification leverage SOAP messaging
 Architectural Composability

WS-ReliableMessaging WS-ReliableMessaging

WS-Policy WS-Policy

WS-Addressing WS-Addressing

WS-Coordination WS-Coordination

WS-AtomicTransaction WS-AtomicTransaction
WS-BPEL

WS-
ReliableMessaging
WS-Policy
WS-Addressing J2EE Solution
.NET Solution

Source : Service-Oriented Architecture, Thomas Erl, 2005

 Contemporary SOA
Fosters inherent reusability
Service-oriented design principles encourage reuse of software
Services can be composed into larger services which in turn can be
reused
Services are agnostic in regard to business processes and automation
solutions
Emphasizes extensibility
When encapsulating functionality through a service description, you
are encouraged to think beyond a point-to-point solution
With appropriate granularity, the scope of a service can be extended
without breaking an established interface
 Extensibility

Same
service
providing
additional
tasks

Source : Service-Oriented Architecture, Thomas Erl, 2005

 Contemporary SOA
Contemporary SOA represents an open, extensible, federated,
composable architecture that promotes service-orientation
and is comprised of autonomous, QoS-capable, vendor
diverse, interoperable, discoverable, and potentially reusuable
services, implemented as Web services
 Contemporary SOA
Supports a service-oriented business modeling paradigm
Business processes are modeled with services and cut vertically
through business logic
BPM models, entity models and other forms of business intelligence
can be accurately represented through coordinated composition of
business-centric services
 Contemporary SOA
Implements layers of abstraction
SOAs introduce layers of abstraction by positioning services as the
sole access points to a variety of resources and processing logic

Services abstracting
application logic and
technology resources

Application Logic

Source : Service-Oriented Architecture, Thomas Erl, 2005

 Contemporary SOA
Promotes Loose Coupling
Business Logic

Service Layers

Application Logic
Source : Service-Oriented Architecture, Thomas Erl, 2005
 Contemporary SOA
Promotes organizational agility
High dependency between parts of an enterprise means that
changing software is more complicated and expensive
Leveraging service business representation, service abstraction, and
loose coupling promotes agility
Is a building block
Services are composed into larger services
Multiple SOA applications can be pulled into service-oriented
integration technologies to help build a Service-Oriented Enterprise
(SOE)
 Contemporary SOA
Is an evolution
SOA is a distinct architecture from its predecessors
Different from client-server technology in that it is influenced by
concepts in service-orientation and Web services
Promotes reuse, encapsulation, componentization, and distribution of
application logic like previous technologies
Is still maturing
Standards organization and vendors are continuing to develop new
SOA technologies
Is an achievable ideal
Moving an enterprise toward SOA is a difficult and enormous task
Many organizations begin with a single application and then begin
leveraging services into other applications
Changing to SOA requires cultural changes in an organization
 Benefits and Pitfall SOA
BENEFIT
Improved integration and intrinsic interoperability
Inherent reuse
Streamlined architectures and solutions
Leveraging of legacy investment
Establishing standardized XML data representation
Focused investment on communication infrastructure
Best of breed alternatives
Organizational agility
 Pitfalls of adopting SOA
Building service-oriented architectures like traditional
distributed architectures
Proliferation of RPC-style service descriptions (increased
volumes of fine-grained message exchanges)
Inhibiting the adoption of features provide by WS-*
specifications
Improper partitioning of functional boundaries within services
Creation of non-composeable services
Entrenchment of synchronous communications
Creation of non-standardized services
 Pitfalls of adopting SOA
Not standardizing SOA in the enterprise
Not creating a transition plan
Not starting with an XML foundation architecture
Not understanding SOA performance requirements
Not understanding Web services security
Not keeping in touch with product platforms and standards
development
Thank You