SOA
Virendra Galotra
May 27, 2010ISM 158
Guest Lecture
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 well-defined, shared format, or by coordinating an activity between two or more services
Simple to SOA
• An Order processing application• Customer placing orders thru internet
• Browser• Web Server• The Order processing App• The DB server• The DB
Browser
InternetWebServer
OrderProcesssing
DBServer
Simple Example of S/W Architecture
Browser WebServer
Process Orders
DBServer
Data Base
Simple to SOA
• An Order processing application• Customer placing orders thru internet
• Browser• Web Server• The Order processing App• The DB server• The DB
Browser
InternetWebServer
DBServer
Simple Example of SOA
Browser Process Orders
Credit Checking
• Credit Checking
• App at two levels:• A business Service Level
describes the functions and how they interact
• An Implementation point of view
Data Base
Problems that complicate 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
Presentationlayer
Data Service
Problems and how they are resolved by SOA
Process Orders
Credit Checking
Business Service Layer(s/w Components with Specific business Functions)
PlumbingLayer(Components that support the business service using actual Computer resources)
(DB Server)(Web Server)
Invoicing Application
Problems that complicate SOA
• You don’t start from Scratch
• Coordinating the components can be tricky
Presentationlayer
Data Service
Problems and how they are resolved by SOA
Process Orders
Credit CheckingBusiness
Service Layer(s/w Components with Specific business Functions)
PlumbingLayer(Components that support the business service using actual Computer resources)
(DB Server)(Web Server)
Invoicing Service
Adapter
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
SOA Service Manager –
Active if any service is active with in SOA i.e. 24x7
• Service Broker’s message to Service Mgr – New business process is threaded
and started
• Service Mgr consults registry – To get full details– Set up monitoring s/w for necessary
components– Delegates the job to SLA monitoring
SLA Monitoring
SOA Service Manager
Business App 1
Business App 3
InfrastructureInfrastructureInfrastructure
Adapter
Business App 2
Adapter
Adapter
InfrastructureInfrastructureInfrastructure
SOA Registry
Service Broker
1
2
3
4
Performance reporting
Functioning of SOA Service Manager
SOA Conductor
• 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-to-end service for performance issues
• Responsible for ensuring the service levels– Using the report from
monitoring agents
SOA Service Manager (SSM)
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?
On-premise
Off-premise
Dedicated Linking On Premise service to SaaS
Shared
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/technology/products/soa/index.html
• IBM.com/SOA_Solutions• http://
www.managedmethods.com/
Case Study: Cigna
• 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 (IT-Business) 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
Cigna Group Insurance – Disability, Life and Accident Insurance
Case Study: Cigna
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
To Solve the business problem - Need to bring the thought process up a level from services and develop a business focused enterprise level architecture
Case Study: Cigna
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 end-to-end business processes
how business function maps to products & services
Grouping helped determine necessary responsibility & functionality each service needed in the end state architecture
To Solve the business problem - Need to bring the thought process up a level from services and develop a business focused enterprise level architecture
Case Study: Cigna - Lessons learnt
• 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
Taking a business focused enterprise level architecture approach helped Cigna go successful
Case Study: SOA at Blue Cross
• 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
Health Industry - Independent Physician to Hospitals - Siloed info!!
Case Study: SOA at Blue Cross
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
Blue cross was looking to solve the business problem – reduce cost to balance expenses and maintain reasonable healthcare cost
Case Study: SOA at Blue Cross
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
Where would all the rules codified 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
Blue cross was looking to solve the business problem – reduce cost to balance expenses and maintain reasonable healthcare cost
Case Study: SOA at Blue Cross
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)
Blue cross - the business problem – reduce cost to balance expenses and maintain reasonable healthcare cost
Case Study: SOA at Blue Cross
• 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
Taking a look across the enterprise approach helped Blue Cross go successful
Next Steps:
Case Study: SOA at Blue Cross
• 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
Taking a look across the enterprise approach helped Blue Cross go successful
Here are the lessons learnt:
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/webservices_manager_ds_10gr3.pdf
• http://www.softwareag.com/us/Images/HowDefineBusinessService-SoftwareAG-112007-WP-0165-1_tcm89-35243.pdf
• http://blog.softwareag.com• Http://www.soatechnologyassessment.com (assessment in 10 minutes)
Questions?
•
NEWS PRESENTATION
Top Related