Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Service Oriented Architecture & Beyond


Published on

An Introduction to SOA, SOA Reference Architecture, SOA Principles, Enterprise Application Integration (EAI), Service Development & Microservices

Published in: Technology
  • Be the first to comment

Service Oriented Architecture & Beyond

  1. 1. Service Oriented Architecture & Beyond Imesh Gunaratne Senior Technical Lead, WSO2
  2. 2. Agenda ▪ An Introduction to SOA ▪ SOA Reference Architecture ▫ Horizontal Layers ▫ Vertical Layers ▪ SOA Principles ▪ Enterprise Application Integration (EAI) ▪ Service Development ▪ Microservices
  3. 3. An Introduction to SOA The concepts and evolution 1
  4. 4. Service Oriented Architecture (SOA) An architectural pattern in computer software design in which application components provide services to other components via a communications protocol, typically over a network.
  5. 5. Evolution of SOA
  6. 6. Evolution of SOA
  7. 7. SOA Reference Architecture A reference architecture for designing enterprise solutions 2
  8. 8. SOA Reference Architecture (RA)
  9. 9. SOA RA Horizontal Layers ▪ Consumer Interfaces ▫ End user applications ▪ Business Processes ▫ Choreographed services representing business use- cases ▪ Services ▫ Business services ▪ Service Components ▫ Components that build services ▪ Operational Systems ▫ Data models, enterprise data repository, technological platforms
  10. 10. SOA RA Vertical Layers ▪ Integration ▫ Platform integration, data integration, service integration, application integration ▪ Quality of Service (QoS) ▫ Security, availability, performance etc. constitute the quality of service parameters ▪ Information ▫ Provides business information ▪ Governance ▫ Governing the entire SOA strategy
  11. 11. SOA Principles Best practices to be followed 3
  12. 12. SOA Principles [1] ▪ Standardized service contract ▫ Services adhere to a communications agreement, as defined collectively by one or more service- description documents. ▪ Service loose coupling ▫ Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other. ▪ Service abstraction: ▫ Beyond descriptions in the service contract, services hide logic from the outside world.
  13. 13. SOA Principles [2] ▪ Service reusability ▫ Logic is divided into services with the intention of promoting reuse. ▪ Service autonomy (govern itself) ▫ Services have control over the logic they encapsulate, from a Design-time and a Run-time perspective. ▪ Service statelessness ▫ Services minimize resource consumption by deferring the management of state information when necessary.
  14. 14. SOA Principles [3] ▪ Service discoverability ▫ Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted. ▪ Service composability ▫ Services are effective composition participants, regardless of the size and complexity of the composition. ▪ Service granularity ▫ A design consideration to provide optimal scope and right granular level of the business functionality in a service operation.
  15. 15. SOA Principles [4] ▪ Service normalization ▫ Services are decomposed or consolidated to a level of normal form to minimize redundancy (performance optimization, access, and aggregation). ▪ Service Location transparency ▫ This refers to the ability of a service consumer to invoke a service regardless of its actual location in the network.
  16. 16. Enterprise Application Integration (EAI) Integration patterns 4
  17. 17. Point to Point Integration Inventory SCM Billing CRM ERP HR
  18. 18. Using an Enterprise Service Bus Inventory SCMBilling CRM ERP HR Enterprise Service Bus (ESB) ▪ Protocol switching ▪ Message transformation ▪ Content/header based routing ▪ Failover handling ▪ Load balancing ▪ Request throttling ▪ Response caching ▪ Security ▪ Logging & monitoring ▪ Enterprise Integration Patterns (EAI)
  19. 19. Integration Pipeline
  20. 20. Sample Integrations
  21. 21. Enterprise Integration Patterns (EAI)
  22. 22. Message Oriented Middleware (MOM) MOM is software or hardware infrastructure supporting the sending and receiving of messages between distributed systems - Wikipedia
  23. 23. Service Development Service types & frameworks 5
  24. 24. Elements of SOA
  25. 25. Service Types ▪ SOAP Web Services ▫ Transport: HTTP/HTTPS ▫ Content type: XML ▫ Service definition: WSDL ▫ Message payload: SOAP Header + SOAP Body ▫ Service method: SOAP Method ▫ Security: WS-Security (BasicAuth, Signature, IDAssertion, LTPA), SAML ▫ Java spec: JAX-WS ▪ RESTful Web Services ▫ Transport: HTTP/HTTPS ▫ Content type: Mostly JSON ▫ Service definition: WADL ▫ Message payload: JSON message ▫ Service method: URI + HTTP Method ▫ Security: OAuth, BasicAuth ▫ Java spec: JAX-RS
  26. 26. Frameworks ▪ SOAP Web Services ▫ Apache Axis (Java, C++) ▫ Apache Axis2 (Java) ▫ Apache CXF (Java) ▫ Java EE: GlassFish, JBoss (Java) ▫ .NET Framework (C#, VB. NET) ▫ Spring Web Services (Java) ▪ RESTful Web Services ▫ Apache CXF (Java) ▫ Jersey (Java) ▫ Java EE: GlassFish, JBoss (Java) ▫ .NET Framework (C#, VB. NET) ▫ Restbed (C, C++)
  27. 27. Microservices Designing an application as a collection of micro services 6
  28. 28. Microservices An approach for developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.
  29. 29. Monoliths Vs Microservices
  30. 30. Deployment Model
  31. 31. Decentralized Data Management
  32. 32. Traditional SOA Vs Microservices [1] Traditional SOA Microservices Messaging Type Synchronous: wait to connect Asynchronous: publish and subscribe Programming Style Imperative model Reactive programming (event/callback driven) Lines of Code per Service Hundreds/Thousands Hundreds or fewer State Stateful Stateless Databases Large RDBMS NoSQL + RDBMS
  33. 33. Traditional SOA Vs Microservices [2] Traditional SOA Microservices Code Type Procedural Functional Means of Evolution Each service evolves and becomes larger Each small service is immutable and can be abandoned or ignored Means of systemic change Modify the monolith Create a new service Means of scaling Optimize the monolith Scale individual services System-level awareness Less aware and event driven More aware and event driven
  34. 34. THANKS! Any questions?