Your SlideShare is downloading. ×
Introduction to Service Oriented Architecture
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Introduction to Service Oriented Architecture


Published on

Presentation conducted in October of 2007 discussing the fundamentals behind SOA.

Presentation conducted in October of 2007 discussing the fundamentals behind SOA.

Published in: Technology, Business

  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Introduction to SOA Arabinda (Ari) Roy Senior Project Manager DATA Inc. Montvale, NJ [email_address]
  • 2.
    • Session I – The Nuts and Bolts
    • Why SOA?
    • What is SOA anyway?
    • Who should adopt SOA?
    • When to adopt SOA?
    • Challenges
    • Session II – Examples
    • How to build a real world SOA application
    Today's Agenda
  • 3. Why SOA ? Is it compelling enough?
  • 4. Which one would you pick? ERP/ AS-400 CRM / Siebel Oracle Server PO System/ IBM Mainframe E-Commerce / Web sphere on Solaris Scenario 1
  • 5. Which one would you pick? Service Bus Scenario 2 CRM/ Oracle Server ERP/ AS-400 E-Commerce/ WebSphere- Solaris PO System/ IBM Mainframe
  • 6.
    • Which is the ‘better’ implementation?
    • Which is easier to maintain?
    • Which is the more agile solution?
    • To what extent can you use the features?
    What are your objectives? Which case fits your situation?
  • 7. The Evolution of SOA
    • Years ago electronic systems were self-contained monolithic systems
    • Today’s gadgets are pluggable and independent
    • Standardized connections
    The analogy of A/V Components
  • 8. The Evolution of Dist. Computing
    • How it all grew…
    Downsize (Client /Server) Component (CORBA, EJB/RMI, DCOM) Messaging MOM Mainframe/Mid Range Service Orientation
  • 9. Application Service Evolution Class Layer Service Layer Component Layer Structured design Service Oriented Design (Inter-Enterprise Scope) Component Oriented Design (Inter-Application Scope) Object Oriented Design
  • 10. Evolution from an IT prospective
    • Parallels drawn between trends
      • 1970’s – Legacy systems
      • 2000’s – Distributed systems
    • Ideas were always there…
      • 20 years later now with more disparate platforms.. The need is rising
    • Realization possible
      • Ubiquity the of Web
  • 11. Example IBM Mainframe Middleware XML XHTML Campus Users Example of a “Service” that incorporates Mainframe code COBOL Application 1989 & Service for retrieving updating travel Information
  • 12. Benefits of SOA
    • Efficient and effective usage of ‘Business Services’
    • Greater agility
    • Loosely-coupled with reusable assets and services
    • Promotes productivity
      • Reduces time-to-market
    • Drives business processes closer to end users
  • 13. Benefits of SOA
    • Technology agnostic
    • Leverage and integrate existing applications
    • Build, maintain & extend vs. rip and replace
    • Provide standard connections between systems
    • Abstract complexity for developers
  • 14. Benefits of SOA Independence from technology Adequate business infrastructure Agility Reuse Risk mitigation Evolutionary approach Cost savings More efficient development process Feedback at different levels
  • 15. What is SOA?
  • 16. Drawing Parallels…
    • Mumbai, India : Density of 49K-65K people per sq km.
    • What symbolizes Mumbai - Gateway of India, Victoria Terminus or the Dabbawalla?
    • Why the Dabbawalla?
    Studied by CMU, NITIE, Univ. of Pittsburg, CMM, etc. Editorials in the Washington Post, NY Times, Indian news
  • 17. Discover Customized Service Consumers at Different location Collect and Route Pickup and Deliver Standardize
  • 18. Lessons from Dabbawalla
    • Granularity:
      • Contents are prepared individually and tagged
    • Standardization:
      • All containers are identical in size
      • Each has unique markings for routing, traceability and delivery that is understood by all the 4500+ semi-literate co-workers
  • 19.
    • Integration and service assurance:
      • Each of the 4500+ co-workers are not employed, but work independently as franchises!
      • Service is guaranteed. The association is a binding force.
    • Low cost:
      • Service charge ≈ $7 /month /dabba.
    Lessons from Dabbawalla
  • 20.
    • Performance and speed:
      • Pick up from homes.
      • 200,000+ boxes distributed by hand before lunch time.
      • Average of 4 changes of hands and 3 modes of transport (bus, train, bicycle).
      • Each Dabbawalla memorizes up to 35 address.
    Lessons from Dabbawalla
  • 21.
    • High Reliability:
      • Only one mix-up in 6million deliveries.
      • Six sigma certified (reference official website).
    • Built in Redundancy
    • Flexibility and Scalability
      • Ability to serve new locations and add more customers
    Lessons from Dabbawalla
  • 22. Question: Can parallels be drawn between Dabawalla and SOA? Question: What does Dabbawalla and SOA have in common? Lessons from Dabbawalla
  • 23. Definition of SOA
    • Service Oriented Architecture
      • Autonomous loosely coupled coarse grained business services that can be discovered and accessed by other applications
    • Service Oriented Architecture
      • More agile application infrastructure that responds swiftly to shifting business / demands and re-compose services
    Can we define a Service Oriented Architecture? Our version…
  • 24. Definition of SOA
    • Service Oriented Architecture
      • Broad framework on which enterprises build, deploy, re-compose and manage services
      • Accessed through standard protocols
    Can we define a Service Oriented Architecture? Our version…
  • 25. Characteristics of SOA
    • Services are platform independent, self describing interfaces (XML)
    • Messages are formally defined
    • Services can be discovered
    Interoperable Loosely Coupled Reusable Composable
  • 26. Characteristics of SOA
    • Services have quality of service characteristics defined in policies
    • Services can be provided on any platform
    • Can be governed
    Interoperable Loosely Coupled Reusable Composable Scalable
  • 27. Examples of a Service
    • Creating a Purchase Order inside a mainframe application
    • Requesting and reserving a room in a hotel
    • Applying for a loan by filling out a loan request form
    • Search books/music based on keywords
  • 28. Key components of SOA Discovering SOA Analogy: “The 6 blind men and the Elephant” SNAKE ? FAN ? SPEAR ? TREE ? ROPE ? WALL ?
  • 29. Different interpretation of SOA… ESB ? XML ? BPEL ? Web services ? SOAP? RESTful ?
  • 30. Key components of SOA SOA Business Services Enterprise Service Bus Service Repository Contract Implementation Interface Governance Front-End Data Business Logic
  • 31. Key components of SOA
    • Services (common denominator)
    • Service Description
    • Advertising and Discovery
    • Specification of associated data model
    • Service contracts
  • 32. SOA architecture Finds and Retrieves Registers Invokes Service Directory Service Consumer Service Provider
  • 33. The SOA Life Cycle
  • 34. Challenges SOA Alphabet Soup What Would You Choose? Axis JBI
  • 35. Associated Terminology Service Oriented Architecture SOA Service Oriented Development of Applications SODA Service Oriented Business Applications SOBA Web Services WS Service Oriented Enterprise SOE Global Delivery Model GDM Enterprise Service Provider ESP Business Process Management BPM Business Process Outsourcing BPO
  • 36. How does SOA Work?
  • 37. Using a Service Developer Service Repository Service Contract Service Client ( Application front-end or services ) Service Stub Contains Creates Searches in Based on Invokes Uses Fulfills Describes
  • 38. SOA Start-Up checklist
    • Decide what functionality is needed
    • Understand your business
    • Build a SOA Management or ESB
    • Do a ‘reality check’ on underlying application platforms
    • Plan for a registry and repository
    • Assess the hardware requirements
    • Do you need a firewall?
  • 39. SOA Stack- Based on Standards Source : Network Computing Magazine
  • 40. SOA – A Perspective
    • Strategy and Roadmap
    • Organization and Culture
    • IT process governance
    • Provisioning and Sourcing Policies
    • Resource Optimization within IT and Business.
    • Convergence of IT and Business.
    • IT process for SOA
    • Provider/Consumer Supply Chain
    Management Framework Interest Focus SOA Choreography
  • 41. SOA – A Perspective
    • Enterprise Architecture Context
    • Architectural Constructs of SOA
    • Architectural Governance
    • Arch. and Design Policies
    • Federated Service Architecture
    • Service Identification and Specification
    • Lifecycle of Service
    Architectural Framework Interest Focus SOA Choreography
  • 42. SOA – A Perspective
    • Standards
    • Service Technologies
    • Run-Time Governance
    • Operational Policies
    • Run-Time Deployment of Service and Resources
    • Operational Infrastructure
    • Service Management
    Deployment Framework Interest Focus SOA Choreography
  • 43. Enterprise Service BUS
  • 44. Enterprise Service BUS
    • An architectural pattern – not a single product
      • Provides interconnectivity services
      • Interacts based on the QoS requirements
    • Common infrastructure for SOA, events, messages
      • Connects and integrates an enterprise's IT business
      • Bridges heterogeneous platforms, environments and transports
    A closer look
  • 45. Enterprise Service BUS
    • Mediates service requests and responses
      • Performs transformation, routing and other “value-added” services
      • Content based routing, Publish/Subscribe (Event based), Simple XML transformation
      • Enables connection-type transparency
    • Standard Based
      • HTTP/HTTPS with option for WS-Reliable Messaging
      • Open APIs and protocols support the interoperability and substitution of middleware from multiple vendors
      • JMS, JAX-RPC, SOAP
      • WS-Security, WS-Policy, WS-*
    A closer look
  • 46. BPEL
    • BPEL = Business Process Execution Language
    • Describes Service Orchestration
    • Describes Service Interaction
    • Easy to write and change
  • 47.  
  • 48. Structure of BPEL <process> <!– Definition and roles of process participants --> <partnerLinks> ... </partnerLinks> <!- Data/state used within the process --> <variables> ... </variables> <!- Properties that enable conversations --> <correlationSets> ... </correlationSets> <!- Exception handling --> <faultHandlers> ... </faultHandlers> <!- Error recovery – undoing actions --> <compensationHandlers> ... </compensationHandlers> <!- Concurrent events with process itself --> <eventHandlers> ... </eventHandlers> </process> Process Language
  • 49. <switch> <faultHandlers> Determine if Can Fulfill 10:00am Handle Negative Credit Exception Discount Service start end BPEL Flow ? Credit Service Inventory Service Get Discount Send Credit Application Receive Credit Result 03:00pm Send Inventory Request Receive Inventory Result <process> </process> <variable> <partnerLink> <partnerLink> <partnerLink> <receive> <invoke> <invoke> <flow> </flow>
  • 50. Model View Controller Revisited View Query UI Controller Task Engine Business Process Controller Task Request Select Task Service Request Change State Controller Model Changed Model Changed Select View WS WS WS WS Model
  • 51. SOA requirements View ERP PLM CRM UI Controller Task Engine Business Process Controller Service Request WS Query Engine WS WS WS WS WS WS A Complete Separation of the Business Logic and UI
  • 52. Planning for SOA @ myorg
    • Think strategically and plan tactically
    • Evolutionary not revolutionary
    • Focus on approach, not technology
    • “Leave & layer vs. rip & replace” ( Gartner Group)
  • 53. Planning for SOA @ myorg
    • Make it easy for developers to adopt
    • Natural progression of original Object Oriented Architecture and Approach
    • Not going to happen overnight- It takes time: “the true adoption is about two years behind the hype”. ( Gartner Group)
  • 54. Planning for SOA @myorg
    • Process
      • Experiment with Web Services
        • Small Project – High Degree of Success
        • Helpful not Vital
      • Adapt some existing systems to use Services
      • Remove Intersystem dependencies
      • Establish an Internal SOA
      • Expand Internal SOA to include external services.
  • 55. Challenges of SOA
  • 56. Reality Check … Screen Scrape Screen Scrape Screen Scrape Screen Scrape Message Queue Message Queue Message Queue Download File Download File Download File Transaction File Transaction File Transaction File ORB ORB CICS Gateway CICS Gateway APPC APPC RPC RPC Transaction File Sockets Sockets Message Message Application Application Application Application Application Application Application Application Application Application
  • 57. Implementation Challenge (1)
    • Technical Challenges
      • Security challenges - loosely coupled environment
      • Performance - XML brings robustness not speed
      • Optimization
      • Organizing the services – registry & repository
  • 58. Implementation Challenge (2)
    • Organizational and Cultural Challenges
      • Paradigm shift for developers
      • Paradigm shift for IT Managers
      • More organizational discipline
      • Governance
      • Transactional services
  • 59. Who should use SOA?
  • 60.
    • eBay
      • Abstracting enterprise information
      • Helped to mange more than 2 perabytes of data
    • IBM
      • 77 shareable and reusable services in production
      • Reduced application inventories
    • Wachovia Bank
      • Improve business productivity
      • Bring IT closer to business
    • Harley Davidson
      • Break up inflexible system
      • Credit and Loan origination process
    • Hewlett Packard
      • Reuse across services
      • Cutting operational costs
    Where SOA made a difference Top Organizations where SOA made a difference in 2006
  • 61.
    • Ameriprise Financial
      • Reuse of crucial business services
      • Saved millions of dollar of development cost of new products/services
      • H andle 60 million customers and one million partners
      • Handle growing Transactional load
    • Citi Group
      • Governace
      • Enable “separation of powers” among corporate, divisions, departments
    • OnStar
      • Move business rules out of applications
    • DreamWorks
      • Simplify and consolidate key business operations
      • Use SOA to make movies a easier process
    • Volvo
      • Better customer service by linking all dealership in Belgium
    Where SOA made a difference Top Organizations where SOA made a difference in 2006
  • 62. Session II Sample Case Study <SOA> as an Application bridge
  • 63. Technology/Architecture used
    • J2SE 5 (Java 2 platform Std Ed)
    • Java EE 5 (Enterprise Edition)
    • Apache Maven, Ant
    • Glassfish Application Server
    • REST based architecture
    • Java Web Services (JWS) API
  • 64. What is REST?
    • RESTful services are stateless
    • REST services have a uniform interface
    • Built from resources
    • Manipulate resources by exchanging representation of resources
    ( Representational State Transfer )
  • 65. Problem context
    • XYZ company has many EIS systems:
      • Order Management System <OMS> (SAP)
      • Customer Service System <CSS> (Seibel)
      • Point of Sales System
      • …the list goes on
  • 66. Problem Context contd..
    • Customer calls to determine order status
    • <CSS> invokes a RPC /Web services on <OMS>
    • Order information retrieved and passed back to <CSS>
    • Customer waits avg. 20 sec to receive order status
  • 67. Business Impact
    • Falling customer loyalty
    • Customers switching to competitors for better service
    • Higher operational cost
    • Change in one system affecting the other
  • 68. Proposed Solution
    • Use SOA as an application bridge
    • Every time a new order is entered in <OMS>, SOA transfers information to <CSS> and adds to customer history log
    • <CSS> has basic customer order info
    • Go to <OMS> only for more detailed info
    • Reduces response by more than 50%
  • 69. Sample Customer Order SOA using JAVA Web services – Mark D. Hansen
  • 70. XML representation of Order Record source: SOA using java Web services –Mark D. Hansen
  • 71. Customer History record source: SOA using java Web services –Mark D. Hansen
  • 72. XML representation of Customer History record source: SOA using java Web services –Mark D. Hansen
  • 73. Getting EIS record using REST and JWS source: SOA using Java Web Services –Mark D. Hansen
  • 74. Sending EIS record using REST : Push messaging /w JWS source: SOA using Java Web Services –Mark D. Hansen
  • 75. RESTful Services deployed using Provider <Source> source: SOA using Java Web Services –Mark D. Hansen
  • 76. Sales order – Customer History Data mapping
  • 77. XSLT for transformation – SOA style integration
  • 78. RESTful Services deployed on Glassfish: Package structure and assembly: Snapshot-I
  • 79. RESTful Services deployed on Glassfish : Snapshot- II
  • 80. RESTful Services deployed on Glassfish : Snapshot-III
  • 81. Resources:
    • Books:
    • 1. SOA : Using Java Web Services
    • - by Mark D. Hansen
    • 2. Service-Oriented Architecture (Concepts, Technology and Design) - by Thomas Erl
    • Web resources:
  • 82. Q&A
  • 83. Thank you! Visit my company’s website at