May 27, 2010
ISM 158
Guest Lecture
SOA
Virendra Galotra
What is SOA?
SOA – Service Oriented Architecture is an
Architecture for building applications as a
loosely coupled black box components
orchestrated to deliver a well defined service
level of service by linking together business
process
• In computing a service-oriented
architecture (SOA) is a flexible set of
design principles used during the phases of
systems development and integration
• A deployed SOA-based architecture will
provide a loosely-integrated suite of services
that can be used within multiple business
domains
SOA in Enterprises
• SOA defines how to integrate widely disparate applications for
a world that is Web based and uses multiple implementation
platforms
– Rather than defining an API, SOA defines the interface in terms of
protocols and functionality
– An endpoint is the entry point for such an SOA implementation
• Enterprises use Service-orientation as loose coupling of
services with operating systems, and other technologies that
underlie applications
• The SOA services and their corresponding consumers
communicate with each other by passing data in a welldefined, shared format, or by coordinating an activity between
two or more services
Simple to SOA
Simple Example of S/W Architecture
• An Order processing application
•Customer placing orders thru internet
• Browser
• Web Server
• The Order processing App
• The DB server
• The DB
Internet
Browser
Browser
Web
Web
Server
Server
Order
Process
Processsing
Orders
DB
DB
Server
Server
Data
Base
Simple to SOA
Simple Example of SOA
• An Order processing application
•Customer placing orders thru internet
• Browser
• Web Server
• The Order processing App
• The DB server
• The DB
• Credit Checking
•App at two levels:
• A business Service Level
describes the functions and how
they interact
• An Implementation point of
view
Internet
Browser
Browser
Web
Server
Process
Orders
Credit
Checking
DB
Server
Data
Base
Problems that complicate SOA
Problems and how they are resolved by SOA
• Keep Business Logic
and Plumbing Separate
• You don’t start from
Scratch
• Application Logic
creeps into the Business
layer
• Coordinating the
components can be tricky
Business
Service Layer
Process
Orders
Credit
Checking
(s/w Components with
Specific business
Functions)
Plumbing
Layer
(Components that
support the business
service using actual
Computer resources)
Invoicing
Application
Presentation
layer
Data
Service
(Web Server)
(DB Server)
Problems that complicate SOA
Problems and how they are resolved by SOA
• You don’t start from
Scratch
• Coordinating the
components can be tricky
Business
Service Layer
Process
Orders
Credit
Checking
(s/w Components with
Specific business
Functions)
Plumbing
Layer
Presentation
layer
(Components that
support the business
service using actual
Computer resources)
Adapter
Invoicing
Service
(Web Server)
Data
Service
(DB Server)
SOA Components
• Enterprise Service Bus
• SOA Registry & Repository
• Business process Orch Mgr
• Service Broker
• SOA Service Manager
Each component have a role to
play, both Independently and
with each other
GOAL: Create an environment
where all these components work
Together to improve the flow of
business process.
Resulting in Dependable and guaranteed service levels
SOA Architecture
This concept is based on an
architectural style that defines an
interaction model between three
primary parties:
–
The service provider, who publishes a service
description and provides the implementation
for the service,
– a service consumer, who can either use the
uniform resource identifier (URI) for the
service description directly or can find the
service description in a service registry and
bind and invoke the service.
– The service broker provides and maintains the
service registry, although nowadays public
registries are not in vogue
Service-oriented architecture is an architectural
discipline that centers on the notion that IT
assets are described and exposed as services.
These services can then be composed in a
loosely coupled fashion into higher-level
business processes, which provide business
in the face of IT heterogeneity.
•
Conceptual model of a SOA architectural style
SOA Architecture
Functioning of SOA Service Manager
SOA Service Manager –
Active if any service is active with
in SOA i.e. 24x7
• Service Broker’s message to
Service Mgr
–
•
Service
Broker
1
New business process is threaded
and started
2
Service Mgr consults registry
–
–
–
To get full details
Set up monitoring s/w for necessary
components
Delegates the job to SLA monitoring
3
SOA
Registry
SOA
Service
Manager
4
Infrastructure
Infrastructure
Infrastructure
Infrastructure
Infrastructure
Infrastructure
SLA
Monitoring
Adapte
r
Business
App 1
Adapte
r
Business
App 2
Performance reporting
Adapte
r
Business
App 3
SOA Conductor
SOA Service Manager (SSM)
•
•
•
•
Master conductor
Grand choreographer
Traffic Cop
All around central point of
control responsible for all
under the hood SOA
orchestration
• Interacts with
infrastructure
• Abstracts the SOA
services from the
technology that they run
on
• Takes care of any end-toend service for
performance issues
• Responsible for ensuring
the service levels
– Using the report from
monitoring agents
SOA Concepts
• Service-oriented modeling is a service-oriented
analysis and design (SOAD) process for
modeling, analyzing, designing, and producing a
SOA that aligns with business analysis,
processes, and goals
• High level approach :
– You decide what you intend to build, namely a SOA and
its layers
– Then describe how to build the SOA by discussing the
main activities and techniques that you need to create a
SOA
Service Oriented Modeling
•
The service-oriented modeling and architecture method
Service Oriented Modeling
• Identification
– domain decomposition – Top down
– Existing asset analysis – Bottom Up
– goal-service modeling – middle out technique
• Specification
– The details of the component that implement the services are
specified:
– Data; Rules; Services; Configurable profile; Variations
• Realization
– the software that realizes a given service must be selected or
custom built
– Other options: integration, transformation, subscription and
outsourcing of parts of the functionality using web services
– Other realization decisions - security; management & monitoring
Example: SOA Arch Template for
enterprises
The layers of a SOA
The template for your SOA
architecture document:
•Scope
•Operational systems layer
•Enterprise components layer
• Services layer
•Business process and
composition layer
•Access or presentation layer
•Integration layer
Addl. Elements for SOA
•
•
•
•
•
Adoption and maturity models
Assessments
Strategy and planning activities
Governance
Implementation of best-practices
Mapping the business process
Business Process
(Left to Right)
below
Feasibility Study
Business process
Discovery and
requirement
Capture
Business process
Modeling
Business process
Prototype
Build
SOA Testing
Business Process
Implementation
SOA Governance
SOA Governance
• Governance meta model
SOA Governance
• A sample list of business principles:
– Standardize processes and technologies wherever possible.
– Alignment and responsiveness to negotiated business principles.
• The following could be derived from those IT principles:
– Architectural integrity
– Responsive, flexible, and extendible infrastructure
– Rapid and efficient deployment of applications
• The IT principles can be mapped to the business principles as
follows:
– Architectural integrity (the first IT principle) provides for standardized
processes and technologies (the first business principle) while rapid and
efficient deployment of applications (the third IT principle) promotes
alignment and responsiveness to negotiated business principles (the
second business principle).
SOA Governance
• Some guiding SOA principles that drive the service model
could be:
– Compliance to standards that are industry-specific as well as cross
organizational
– Service identification and categorization
– Service provisioning
– Service monitoring and tracking
– Capability of services to be composed in order to realize different business
services
– The SOA principles also influence the IT principles. While creating the IT
and SOA principles, the members of the governance council should align
them with how IT proposes to support the enterprise's desired operating
model. Above and beyond creating the IT and SOA principles, it is also the
council's responsibility to see to it that they are properly exercised across
the enterprise.
SOA adoption areas
• Clouds pushing
SOA adoption
• We find all four
variants used by
businesses in
practice
• Discussion: why
would IT choose
one option over
another?
Onpremise
Dedicated
Shared
Linking On
Premise
service to
SaaS
Offpremise
SOA Adoption
SOA - Key value propositions
• Enables changing the
business process
• increasing business
agility
• reducing integration
expense
• Overall cost reduction
• Acquisitions
• Without focusing
underlying technology
plumbing
• reduction of business
risk
• increasing asset reuse
Available SOA products
• Oracle Fusion Middle
ware kit
• IBM SOA suites
• JaxView
• HP SOA center
• Microsoft SOA products
• http://www.oracle.com/techn
ology/products/soa/index.ht
ml
• IBM.com/SOA_Solutions
• http://www.managedmethod
s.com/
Case Study: Cigna
Cigna Group Insurance – Disability, Life and Accident Insurance
• Common Challenge of IT and
Business working together
• Cigna wanted to have shift on
how it viewed its customers
• Challenges:
• Solution: SOA
• Think like a business person
helped foster a successful (ITBusiness) partnership
• Shift of focus from corporate
to individual
• Traditionally supported
employers
• Need to Change Infrastructure
/ Architecture to support
employee centric business
view
• to move incrementally away
from legacy to introduce new
services enablement
Case Study: Cigna
To Solve the business problem - Need to bring the thought
process up a level from services and develop a business
focused enterprise level architecture
Approach
• Work with Business directly
• Service built with extensibility
• Message Centric approach
 Mapped 1000 Biz functions into more
than dozen enterprise services
 Met business on a regular basis
 Participated in Business planning and
strategy meetings
 Understood the business issue
 IT emerged as a value add partner
with Business
 Service to meet today’s requirement
and evolve for tomorrow’s needs
 A service design where attributes can
be added without endangering the
backward compatibility, updating the
service interface schema
Case Study: Cigna
To Solve the business problem - Need to bring the thought
process up a level from services and develop a business
focused enterprise level architecture
Approach
• Capability mapping and
modeling approach
– Business Function – several input
one single output e.g. calculate
benefit function (enrollment,
eligibility, medical underwriting,
self service, claims business
capability)
• Process of grouping related
biz functions resulted in the
definition of all Cigna’s Core
enterprise SOA services
 Mapped 1000 Biz functions into
more than dozen enterprise services
 Defining core business capabilities (
each in terms of one or more
business function)
 Mapping the core capabilities to
these business functions and endto-end business processes
 how business function maps to
products & services
 Grouping helped determine
necessary responsibility &
functionality each service needed in
the end state architecture
Case Study: Cigna - Lessons learnt
Taking a business focused enterprise level architecture
approach helped Cigna go successful
• Cigna overall health improvement strategy of helping
individuals by repositioning technical capabilities
• Business understand SOA benefits in business terms – cost
reduction and efficiency
– Work with Business directly
– Contracting dept. e.g. was able to implement new cases faster by
integrating with legacy system for post sales data
• Service built with reusability and extensibility
– Services built for one part were reused in another part of business
• Message Centric approach
Case Study: SOA at Blue Cross
Health Industry - Independent Physician to Hospitals - Siloed info!!
• Status: Although there are
enormous technological
advances, siloed info
• 32 million claims; 6 million
customer inquiries each year
• Challenges:
– Privacy legislation
– More holistic patient care at low
cost
– Emerging needs
• Solution: SOA
– To link business service and data
across departments
– Improve level of cooperation
between providers and payers
• Sharing of medical info is on
demand only per request from
physician offices to clinics to
hospital departments
• Physicians make use of time
sensitive data for patient care
• Patient’s medical information
systems integration with Billing
systems
• Tie in to Drug delivery
• Large Hospitals, companies
are moving to SOA to help
break Silos of medical data for
comprehensive patient service
Case Study: SOA at Blue Cross
Blue cross was looking to solve the business problem –
reduce cost to balance expenses and maintain reasonable
healthcare cost
Approach
• SOA based application
Development for a single
source of truth
– Blue cross and it’s subsidiaries
are largest insurers in
Philadelphia – 3.4 million
members
– Products & Services ( Managed
Care, traditional indemnity,
Medicare and Medicaid)
• Create a Governance model
• Make developers appreciate
and adopt SOA approach





Claims Status: if it is paid
Call Customer Service
Call billing dept at Physician’s office
Go online to check
Different front end but back end
uses the same single service to
respond to the query
 Only one version of the truth
Case Study: SOA at Blue Cross
Blue cross was looking to solve the business problem –
reduce cost to balance expenses and maintain reasonable
healthcare cost
 Where would all the rules codified
Step 1: Governance
• Governing committee is a
multidisciplinary body
– Initial focus was to set a low level
foundation service
– Business experts made the
governance decision
– Infrastructure group was on chair
with no vote
– A policy - service is a service if it
is used more than once
– Enterprise wide responsibility
assigned for service development
and maintenance




by the governance committee?
The governance committee put
together initial document with
processes and life cycle of services
Approved by Senior leadership and
enforced ( exec support is
necessary)
Reusable and standardized service
is cost reduced
Individual IT support function for
each line of business will build each
services and support those services.
e.g. if service is pulling data from a
database provider then that IT dept.
maintain that data
Case Study: SOA at Blue Cross
Blue cross - the business problem – reduce cost to balance
expenses and maintain reasonable healthcare cost
Step 2: Apps Developer take a
leap of faith
• SOA is the way to GO!
– With Governance and Support
plan in place only task was to
convince the developers to follow
SOA approach
• Developers hate losing control
as part of SOA change
• Management’s responsibility
was to show the value add of
change to the developers
 SOA developers focused on SOA
integration at the outset
 Developers need not worry about
integration but needed to know what
data they were requesting from a
service ( and what they will get back
from Service)
 As per change, access from a database
instead from a direct connection, was
thru a service
 Developers saw the value add of the
SOA change in terms of their
productivity by splitting of tasks for front
end and back end of code for requested
services ( discipline enforced)
Case Study: SOA at Blue Cross
Taking a look across the enterprise approach helped Blue
Cross go successful
Next Steps:
• A long term roadmap for the next three years was put
together
• With first phase of SOA completed – automating governance
in the second phase
Automating the manual registry to validate the metrics for value add of
services being consumed
• Implement the master data management and business
process monitoring
– Single source of truth
– Catalog of services to be made available
Case Study: SOA at Blue Cross
Taking a look across the enterprise approach helped Blue
Cross go successful
Here are the lessons learnt:
• Taking an enterprise view with executive support
• Separating Technology from Methodology
– A consistent governance structure across the board and business
• Federated Governance model
– Enterprise view was achieved by inducting various groups from
across the company
Case Study: SOA at Blue Cross
6
SOA – Don’ts
•
Don’t Boil the Ocean
– Choose a well defined and confined project
•
Don’t Confuse SOA with an IT initiative
– SOA is a joint endeavor between business and IT
•
Don’t Go it alone
– Don’t try to reinvent. Beg borrow or steal – get help
– Use the available offerings – templates, models, roadmap, and best practices
•
Don’t Neglect Governance
– SOA governance is not automatic – it is about leadership and thinking about how you are going
to get there.
– You need a coordinated approach that conforms to the corporate GOALS and Obj
•
Don’t Forget Business Process
– Don’t forget to start with BP that you want to automate with SOA initiatives
– Whether leverage existing code to create reusable service or build new service need to put
them into Business process
•
Don’t start from Scratch
– And Don’t forget Security – pay close attention to security implications of exposing Biz Services
•
Don’t apply SOA to everything
– Use defined project and leave and stand alone apps. Keep the services bigger for reuse and
manageability
Where to learn more
•
•
•
•
•
•
•
•
http://www.Google.com
IBM Software group for SOA
http://www.soa.com/products/service_manager/
SOA in practice – The Art of Distributed System Design by Nicolai M.
Josottis; Publisher : O’ Reily
http://www.oracle.com/technology/products/webservices_manager/pdf/w
ebservices_manager_ds_10gr3.pdf
http://www.softwareag.com/us/Images/HowDefineBusinessServiceSoftwareAG-112007-WP-0165-1_tcm89-35243.pdf
http://blog.softwareag.com
Http://www.soatechnologyassessment.com (assessment in 10 minutes)
Questions?
•
NEWS PRESENTATION