More Related Content


soa ppt v7.ppt

  1. Service Oriented Architecture Dr. V. Prasanna Venkatesan Professor Department of Banking Technology Pondicherry University Pondicherry, India – 605 014 prasanna
  2. Outline Introduction to SOA SOA Concepts SOA Security SOA & Organization Case study: E-Banking Future State of SOA
  3. Introduction to SOA “Information technology and business are becoming inextricably interwoven. I don't think anybody can talk meaningfully about one without the talking about the other.”
  4. Business – The Current Scenario
  5. Business – The Current Scenario Results in
  6. Business – The Current Scenario
  7. Current IT Infrastructure  Lacks agility to keep up with business objectives  Places limitations on Business  Requirements change  Interpretations often inaccurate or limited  Lengthy development cycles inflexible to change  Implementations “cast in concrete”
  8.  Majority of solutions have been created by  identifying the business tasks  defining their business requirements  building the corresponding solution logic  Change in requirements  modify existing solution • Not Efficient • Results in Complex Infrastructures and complicated Enterprise Architectures • Integration becomes a Challenge Current IT Infrastructure
  9.  majority of solutions have been created by  identifying the business tasks  defining their business requirements  building the corresponding solution logic  Change in requirements  modify existing solution  build a new application altogether Current IT Infrastructure • Highly Wasteful • Inflates an Enterprise
  10. The Way out is to…  Go with an enterprise technology solution that promises agility and flexibility  Leverage integration process through composition of services spanning multiple enterprises
  11. The Way out is to… Think about business outcomes as a set of composed services instead of monolithic applications
  12. SOA Concepts “SOA will be a prevailing software engineering practice, ending the 40-year domination of monolithic software architecture.”
  13. The Solution is…ServiceOrientation  SO is a design paradigm that specifies the creation of automation logic in the form of services  Service refers to a discretely defined set of contiguous and autonomous business or technical functionality  SO is applied as a strategic goal in developing a Service- Oriented Architecture (SOA). Services are trees SO is the Forest
  14. The Solution is…ServiceOrientation  Access software via Services that are easy to find and connect to  Provide a standard way of building and accessing Services  Build applications out of Services
  15. Wasn’t there SOA before?  SOA have been around a while  CORBA (Common Object Request Broker Architecture)  DCOM (Microsoft Distributed Component Object Model)
  16. Why is it different?  SOA reflects the reality of ownership boundaries  CORBA, RMI, COM, DCOM, etc. all try to implement transparent distributed systems  Ownership is of the essence in SOA  SOA is task oriented  Components are organized by s/w function  Services are organized by business function  SOA is inspired by human organizations  Component concepts are technology-oriented  Services worked for us, it should work for machines
  17. So… What is SOA ? SOA is a conceptual business architecture where business functionality or application logic is made available to SOA users, or consumers as shared reusable services on an IT network [Source: SOA: A planning and implementation guide for business and technology by Eric A. Marks, Michael Bell]
  18. So… What is SOA ? [Source: IBM ] An SOA is an orchestrated sequence of messaging, transformation, routing and processing events in which XML technologies expose the message content and the components that operate on the messages
  19. SOA- Roles & Functions  Service Consumer : Discover services and metadata from Service Registry  Service Producer : Publish newly developed services and artifacts  Service Registry : Notify clients of changes Organize service metadata with classification and lifecycle support (Broker)
  20. Application Centric Application Application Finance Distribution Manufacturing Supply Narrow Consumers Limited Business Processes Overlapped resources Overlapped providers Business scope Application Integration Architecture Business functionality is duplicated in each application that requires it. EAI ‘leverage’ application silos with the drawback of data and function redundancy. bound to EAI vendor Redundancy
  21. Service Architecture Service Service Service Service Finance Distribution Manufacturing Supply Service virtualizes how that capability is performed, and where and by whom the resources are provided, enabling multiple providers and consumers to participate together in shared business activities. Multiple Service Consumers Multiple Business Processes Multiple Discrete Resources Multiple Service Providers source:TietoEnator AB, Kurts Bilder Business scope SOA structures the business and its systems as a set of capabilities that are offered as Services, organized into a Service Architecture Shared Services Service Centric
  22. Before SOA – After SOA source:IBM
  23. Why SOA? To enable Flexible, Federated Business Processes Enabling a virtual federation of participants to collaborate in an end-to-end business process Enabling alternative implementations Enabling reuse of Services Enabling virtualization of business resources Enabling aggregation from multiple providers Identification Ticket Sales Ticket Collection Inventory Logistics Manufacturing Availability Service Service Service Service Service Service Service Service Service Service Ordering source:TietoEnator AB, Kurts Bilder
  24. Why SOA? To enable Business Process Optimization and the Real Time Enterprise (RTE) Seamless End to End Process Internal Systems SOA Pattern: Standardized Service provided by multiple suppliers Service from Multiple Suppliers SOA Patterns: Single, Multi-Channel Service for consistency BPM Expressed in terms of Services Provided/Consumed Enterprise source:TietoEnator AB, Kurts Bilder Smart Clients Stores POS Mobile 3rd Party Agents Portal Service to Customers
  25. Why SOA? Enable Structural Improvement ERP X Process Z Partner A Process Y Service Standardizing capabilities Information Consistency Policy Consistency e.g. Single Customer Details Service Consolidation/ Selection process Reducing impact of change Encapsulating implementation complexity ERP Z CRM System 2 CRM System 1 Product System Policy Rationalization and Evolution Resource Virtualization e.g. Multiple Sources of Customer Details
  26. SOA Defined  SOA is a software architecture model  in which business functionality are logically grouped and encapsulated into  self contained,  distinct and reusable units called services that  represent a high level business concept  can be distributed over a network  can be reused to create new business applications  contain contract with specification of the purpose, functionality, interfaces (coarse grained), constraints, usage ... of the business functionality Services are autonomous, discrete and reusable units of business functionality exposing its capabilities in a form of contracts. Services can be independently evolved, moved, scaled even in runtime.
  27. What is Service Architecture? • A collection of services • classified into types • arranged into layers • Governed by architectural patterns and policies services type type type source:TietoEnator AB, Kurts Bilder
  28. Big (outer) vs. Little (inner) SOA
  29. SOA is an evolutionary step  for architecture
  30. SOA is an evolutionary step  in reusability and communication
  31. SOA is an evolutionary step Project-ware SOA EAI  in distributed communications source:Sam Gentile
  32. Service Architecture Organized by Layers Reasons for Layering 1. Flexible composition. 2. Reuse. 3. Functional standardization in lower levels 4. Customization in higher layers 5. Separation of Concerns. 6. Policies may vary by Layer Example Layers Presentation & workflow Composed Services Basic Services Underlying API according to:TietoEnator AB, Kurts Bilder
  33. Major service types  Basic Services:  Data-centric and logic-centric services  Encapsulate data behavior and data model and ensures data consistency (only on one backend).  Basic services are stateless services with high degree of reusability.  Represent fundamental SOA maturity level and usually are build on top existing legacy API (underlying services)  Composed Services :  expose harmonized access to inconsistent basic services technology (gateways, adapters, façades, and functionality- adding services).  Encapsulate business specific workflows or orchestrated services.
  34. Service Types Foundation Service Blocks Core APIs G eo M edia Terra Share G / T e c h I/C A DI / . . In Service Other S e r v i c e I n f r a s t r u c t u r e B a s i c S e r v i c e s C o m p o s i t e S e r v i c e s Smart Client P o r t a l SOA Management & Security service mediation, routing, trust enablement. ESB, Service Registry Multi channel applications: Mobile, Smart, Thin, Thick clients, Portals. Business centric services, orchestrated workflows. Intermediate services (gateways, facades ) Data centric and logic centric consistent services. Highly reusable, stateless servers Business Capabilities
  35. SOA Principles  Standardized Service Contracts  Loose Coupling  Abstraction  Reusability  Autonomy  Statelessness  Discoverability  Composability
  36. Standardized Service Contracts  “Services within the same service inventory are in compliance with the same contract design standards."  Services use service contract to  Express their purpose  Express their capabilities  Use formal, standardized service contracts  Focus on the areas of  Functional expression  Data representation  Policy Source: Thomas Erl
  37. Loose Coupling  “Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment."  Create specific types of relationships within and outside of service boundaries with a constant emphasis on reducing (“loosening”) dependencies between  Service contract  Service implementation  Service consumers Source: Thomas Erl
  38. Abstraction  “Service contracts only contain essential information and information about services is limited to what is published in service contracts”  Avoid the proliferation of unnecessary service information, meta- data.  Hide as much of the underlying details of a service as possible.  Enables and preserves the loosely coupled relationships  Plays a significant role in the positioning and design of service compositions Source: Thomas Erl
  39. Reusability  “Services contain and express agnostic logic and can be positioned as reusable enterprise resources."  Reusable services have the following characteristics:  Defined by an agnostic functional context  Logic is highly generic  Has a generic and extensible contract  Can be accessed concurrently Source: Thomas Erl
  40. Autonomy  "Services exercise a high level of control over their underlying runtime execution environment."  Represents the ability of a service to carry out its logic independently of outside influences  To achieve this, services must be more isolated  Primary benefits  Increased reliability  Behavioral predictability Source: Thomas Erl
  41. Statelessness  "Services minimize resource consumption by deferring the management of state information when necessary."  Incorporate state management deferral extensions within a service design  Goals  Increase service scalability  Support design of agnostic logic and improve service reuse Source: Thomas Erl
  42. Discoverability  "Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted."  Service contracts contain appropriate meta data for discovery which also communicates purpose and capabilities to humans  Store meta data in a service registry or profile documents Source: Thomas Erl
  43. Composability  "Services are effective composition participants, regardless of the size and complexity of the composition."  Ensures services are able to participate in multiple compositions to solve multiple larger problems  Related to Reusability principle  Service execution should efficient in that individual processing should be highly tuned  Flexible service contracts to allow different types of data exchange requirements for similar functions Source: Thomas Erl
  44. The Promise of SOA  The Discoverable feature enables  Faster decision cycles  Increase cross-organizational information visibility  Precision information retrieval  Location Transparency  Standards Based and Highly Interoperable capability achieves  Platform and language independent  Leverage existing IT investments: Lower Cost  Heterogeneity
  45. The Promise of SOA  Loosely Coupled and Decentralized nature provides  Plug and play components independent of platform  Enable redundancy for survivability  Emphasis on business logic and less on plumbing  Reduced overall system complexity  System Composability
  46. SOA Security “The computing field is always in need of new clichés.”
  47. Security in SOA  Security is a pressing issue in SOAs  SOA stresses machine-to-machine interaction  IT security is based on human-to-machine interaction.  Authentication and authorization become more challenging in this environment.
  48.  Unsecured SOA  architecture's open nature  hackers with the ability to eavesdrop and reroute it or transform its content for purposes of mischief or fraud  Cannot secure unknown third parties  Vulnerable to overload. Security in SOA (Contd)
  49.  No transaction logging  Cannot keep track of its users or its messages.  No auditable record of usage that can be used to investigate security problems or diagnose security weaknesses. Security in SOA (Contd)
  50. SOA Security Solution SOA security solution that enables  Message monitoring  Federated authentication  Application proxy  Contract management  Certificates, keys, and encryption and  Audit logging Even though it looks like a long list, but the truth is without any one of these in place, all the benefits from SOA will evaporate.
  51. SOA & Organization “Computing is not about computers any more. It is about living. ”
  52. How might SOA transform an organization?  Building New Solutions With Services  Independent Pieces Within Applications  Independent Development and Maintenance  Scale-Out  Slicing Apart Existing Apps  separate the “Big Ball of Mud”  Joining Together Existing Apps  Connectivity  B2B: Business-to-Business  EAI: Enterprise Application Integration  Business Process
  53. SOA Players
  54. SOA – Non applicable scenarios  Stable or homogeneous enterprise IT environment  Organization that does not offer or use software functionality as services to and from external parties  Real time requirements that need synchronous communications
  55. Case Study – E-Banking “Change is such hard work.”
  56. Case study – E-banking  Bank offers various financial services such as  Online banking  Bill payments  Brokerage, etc.,  Financial services are accessible through variety of channels like  Branch offices  ATMs  Call centers  E-mails  Internet  A Service Oriented Computing Model for E-Banking handles the agile scenarios of e-banking system
  57. Achieving Service Abstraction in an e-banking Scenario Bank server Local Data server Data Mart Host Consumer Broker
  58. Case study – E-banking Customer Regulatory bodies Branch Other banks Core financial services Payments services Mutual fund services Bill payment, presentment services Alerts and messaging services Security Services Service Broker Service Manager SA Agent Service Registry Bank Server Knowledge repositories E-Banking Service Layer Business Layer App. Layer Data Layer Service Management Layer
  59. Application layer  Illustrates client applications specific to  Individual customers  Corporate customers  Self-supportive services for branch offices, different section offices, etc.,  Regulatory bodies and  Other banks  Takes advantage of services provided by e-banking system
  60. Business layer  Set of components that constitute the actual e-banking system  E-banking service layer acts as the mediator between client applications and the rest of the system  Service management layer is responsible for generating and coordinating all the messages within the system
  61. E-banking Service Layer  Core financial services  Payments services  Mutual fund services  Bill payment & presentment services  Alerts and messaging services  Security Services
  62. Service Management layer  Service Broker receives service requests and discover the services  Service Manager is responsible for service life cycle management  Service Advisory Agent generate suggestions of composition alternatives
  63. Data layer  Sources of information that support the e- banking system  Service Registry  Data server  Knowledge Repository
  64. Future State of SOA “Deserve your dream.”
  65. Future State of SOA  Combining mature technology with a proven methodology will allow organizations to transit from traditional enterprise automation logic to SOA-based which achieve long-term SOA benefits.  The future state of SOA has the potential of creating a new breed of “agile organization”.
  66. References     Eric A. Marks, Michael Bell, “SOA: A planning and implementation guide for business and technology”, John Wiley & Sons -2006  Tony Chao Shan, “Building a service oriented eBanking platform”, Proceedings of the 2004 IEEE International Conference on Services Computing (SCC’04)