Published on

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Service Oriented Architecture What is Software Architecture? The overall structure of the software and the ways in which that structure provides conceptual integrity for the system A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed. How does this differ from an OO architecture? Note SoA is a framework for designing software systems using a software architecture hat views all components as services
  2. 2. Service Oriented Architecture In OO, we integrate data and methods into a single object There is a strong coupling among objects Communications are prescriptive -- not descriptive Object discovery is not well understood although CORBA attempted this SoA separates (most of the time) data from a service or behavior The coupling among services is very loose (at least, desired) Communications are descriptive (ideally) Service discovery is inherent in SoA
  3. 3. Service Oriented Architecture Consider an analogy (somewhat controversial) CDs and CD players CD’s contain data/music, etc CD players provide service to read or play CD’s If using OO, we may have to embedded CD player service into each CD data + methods encapsulated If using SoA -- we can separate data from the actual service Possibly even allow the service to interpret the data differently Another analogy -- you want “food preparation” service at a restaurant. You want to order food, but not provide a recipe on how to cook Does polymorphism of OO help in this analogy?
  4. 4. Service Oriented Architecture We are talking about the design methodology associated, not an OO programming language In fact we can do OO based architecture using non OO languages Consider other programming/design frameworks Aspect Oriented Agent Oriented Autonomic oriented Likewise we can build SoA using OO language
  5. 5. Service Oriented Architecture What is a service? A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services. Consider the difference between providing data/information vs a service. We can provide a database or we can provide a service for using the data. In general services can extend beyond software
  6. 6. Service Oriented Architecture How do we encapsulate process/business logic in a SoA? Note we translate both business logic and application logic into services
  7. 7. Service Oriented Architecture We first translate business processes into business logic and define services associated with the logic Likewise, we separate the application logic from implementation and define services
  8. 8. Service Oriented Architecture Can’t we do this with OO? Again the difference is in philosophy separate behavior from data loose coupling descriptive communication
  9. 9. Service Oriented Architecture A service can be both a provider and a consumer For example in the restaurant case, the restaurant is a service provider to dining clients but a consumer of services from grocers Is this still any different from OO? Can’t we build SoA systems using Java and C++? The key difference is to make the coupling as loose as possible
  10. 10. Service Oriented Architecture Make the interactions among components as simple as possible In most software systems, this is often difficult real dependencies among behaviors artifact dependencies Two SoA features leading to loose coupling 1. A small set of simple interfaces to all services. Only generic semantics are encoded at the interfaces. Interfaces are universally available to all providers and consumers 2. Descriptive messages constrained by XML (or other) schemas No or minimal system behavior is included in messages. Schema limits the vocabulary and structure of messages Other descriptive message communication models KQML based on “speech directives” May be interesting to see if we can design XML based KQML
  11. 11. Service Oriented Architecture Interfaces and messages Is there a difference? Descriptive messages -- not instructive Structure is limited by extensible schemas (to permit understanding of request for services) Extensibility is important to permit evolution of services (but still compatible -- CDs, DVDs, HDVDs,) Of course service discovery is needed for SoA May need new services that can be used to locate needed services Semantics, ontologies, etc. Interfaces should be generic and application specific semantics described in messages
  12. 12. Service Oriented Architecture Stateful vs Stateless services Stateless -- a service does not maintain any state information consumer must provide all the needed information permits for easy implementations and mass production of services (generic services) Any disadvantages? Cannot provide “sessions” between providers and consumers e.g., cannot provide security certificate once per session Stateful services Needs to share consumer specific context May be part of interface Or exchanged as a sequence of messages Not scalable
  13. 13. Service Oriented Architecture Instead of stateful services, we can consider “manager” services which provide an interface to a stateful service We can define a manager service that establishes the context. After that we can have a manager that does not require state information All manager services are stateless and can process multiple customer requests
  14. 14. Service Oriented Architecture Idempotency of requests -- what is this why do we need this? All these are ideal characteristics of SoA Can we achieve them (at least for developing software systems)? So what does standard interface mean? Power is standard (unless you want to use the toaster in Europe) How about the width of the slots? Can we think of standard interface? Select a button or a number to specify the choice of width and the toaster adjusts the slot approriately Loose coupling with exensible services but fixed interfaces Consider an analogy We want to provide more services from your toaster Do we need to change the interface? Power outlet width of slots to accept a bagel instead of slice of bread or Pizza
  15. 15. Service Oriented Architecture In software we can state that the service requirements can be “described” with XML schema What happens if the service changes May be provide optional XML tags Extensible tags to facilitate interface to new services But do the extended tags change the interface? Of course, as in case of the toaster example, we can get rid of old service and discover (and buy) the new improved service For software services interfaces are the specification of the number of messages or arguments The actual messages describe the type of inputs
  16. 16. Service Oriented Architecture Web services is one realization of the SoA Standard messages are specified by SOAP Messages (at least ideally) are descriptive using XML tags Service discovery facilitated by UDDI So where do we fit quality of service characteristic of a service That is not essential in SoA -- but needed for service discovery Web services (at least ideally) satisfy the loose coupling facilitated using standards provided Standard interfaces are specified using WSDL
  17. 17. Service Oriented Architecture Net Centric Operations and Service oriented Architecture Net centric operations require all “information” available on network tasks, posting, processing and using of information Can we translate operations into services? We can define services to “pull” information, post (new) information to requesters, process information (analyze) All these operations must be made available via (the) network operations must be interoperable must be able to discover operations
  18. 18. Net Centric Operations <ul><li>Recent trends in Network-Centric Warfare (NCW) have significant effect: </li></ul><ul><ul><li>Service-Oriented Architecture (SOA) </li></ul></ul><ul><ul><ul><li>Network Centric Enterprise Services (NCES), GIG Enterprise Services (GES), JBMC2, FCS, JBI, and Composable FORCEnet </li></ul></ul></ul><ul><ul><ul><li>Dynamic publication, runtime selection and discovery, dynamic composition </li></ul></ul></ul><ul><ul><ul><li>Distributed services and agents </li></ul></ul></ul><ul><ul><li>These systems must be dynamic and keep on changing even at runtime. </li></ul></ul><ul><li>These architectures are not static but dynamic and evolving </li></ul><ul><ul><li>in other words, modern DoD systems need to respond to change at runtime and in real time. </li></ul></ul><ul><li>Key question </li></ul><ul><ul><li>Are the existing approaches to architecture powerful enough to handle these dynamic structure and mechanisms, which are key to building systems for Network-Centric Warfare? </li></ul></ul>
  19. 19. Network Centric Enterprise Services(NCES) Core Enterprise Services (CES) Comms Backbone Community-of-Interest (COI) Capabilities Users Messaging ESM Discovery Collaboration Mediation Security/IA App Storage User Asst Levels of Services above core level Support real-time & near-real-time warrior needs and business users C2 Intel Weapon Systems Dynamically Created COIs Logistics Sensors Personnel Finance Etc.
  20. 20. GIG Enterprise Services SOADR Supports real-time & near-real-time warrior needs DoD (Title 10) IC (Title 50) Users Users Business Domains Warfighter Domains Domain/ COI Capabilities IC Org Spaces National Intelligence Domain Transformational Communications (TC) & Computing Infrastructure ICSIS Community Space Technical Infrastructure Domain Levels of Services Above Core Level COI’s Capability Integrator Installations & Environment Human Resources Management Acquisition Strategic Planning & Budget Logistics Accounting & Finance Governance COI’s Capability Integrator Command & Control Battlespace Awareness Force Application Precision Logistics Protection Governance Net-Centric Enterprise Services (NCES) Application User Assistant Storage Messaging IA/Security IA/Security ESM IA/Security ESM IA/Security ESM Discovery IA/Security ESM Collaboration IA/Security ESM Enterprise Service Management (ESM) Mediation IA/Security ESM IA/Security ESM ESM IA/Security
  21. 21. SOA-based System Architecture <ul><li>The system has three architectures : </li></ul><ul><ul><li>The Application Architecture . This application architecture will be built on top of an SOA. </li></ul></ul><ul><ul><li>The Service Architecture . This is the commonly known SOA architecture. </li></ul></ul><ul><ul><li>The Component Architecture . This is sub-SOA architecture that describes the various elements that support the implementation of services. </li></ul></ul>Note -- although we used application architecture here, we apply this to both application and business logic
  22. 22. Service Orientation of Enterprise Systems Business Logic: documented implementation of the business requirement typically structured into processes expressing the requirements, constraints, dependencies and external factors Consider UNT EIS system UNT business logic and processes What EIS application logic allows us to do Application Logic: implementation of business logic organized into various technology solutions business processes through purchased or designed systems within the confines of the IT infrastructure, security constrains, technical capabilities and vendor dependencies
  23. 23. One view of Enterprise Service Orientation Service Orientation of Enterprise Systems
  24. 24. One view of Enterprise Service Orientation Service Orientation of Enterprise Systems
  25. 25. Components of Logic in Service Orientation <ul><li>Message (units of communication) </li></ul><ul><li>Operations (units of work) </li></ul><ul><li>Services (units of processing logic -- collection of units of work) </li></ul><ul><li>Processes (units of logic -- coordinated aggregation of services) </li></ul>Service Orientation of Enterprise Systems How unit communicate
  26. 26. Components of Logic in Service Orientation Service Orientation of Enterprise Systems
  27. 27. Modeling Service Layers for Business and Application logic Service Orientation of Enterprise Systems
  28. 28. Modeling Service Layers for Business and Application logic Application Service Layer: Typically consists of Utility Services policy implementation, QoS, Security Wrapper Services to encapsulate legacy functionalities Business service layer Task centric service -- encapsulates specific task verify invoice Get account info Entity centric -- encapsulates a specific business entity invoicing service Service Orientation of Enterprise Systems
  29. 29. Service Orientation of Enterprise Systems Task-centric and Entity-Centric services
  30. 30. Modeling Service Layers for Business and Application logic Orchestration service layer Applies the idea of process workflows to compose application and business services Abstracts business rules and service execution sequence logic from other services Service Orientation of Enterprise Systems
  31. 31. Service Oriented Architecture Web services is one realization of the SoA
  32. 32. Software Engineering for SoA What are the implications of SoA on SE processes requirements and specifications design implementation and deployment testing and verification maintenance SoA characteristics imply that we want use “macro” or coarse grained operations/activities as services Don’t want to think of a class to support “queues” or “stacks” as a service You may want to consider services to “search” or discover
  33. 33. Software Engineering for SoA SE Processes -- top down vs bottom up Top down approach Analysis first assume business requirements are known Ontology permits us to classify and develop vocabulary for our services We may need to re-align business models to fit the ontologies
  34. 34. Software Engineering for SoA Bottom up approach Create services based on application needs May not fully take advantage of available services
  35. 35. Software Engineering for SoA In between approach Do some top down to get Ontologies and vocabularies defined Then perform analysis to identify or design services
  36. 36. Software Engineering for SoA Service modeling process How do we identify what services are needed? How do we aggregate units of work into service?
  37. 37. Software Engineering for SoA An example
  38. 38. Software Engineering for SoA Some of the processes (or operations) are not suitable for service orientation manual processes legacy logic that cannot be converted Abstract orchestration logic If novice is valid flow if invoice not valid flow Creating candidates for services decide on task oriented or entity oriented services decide on wrapper services and utility services Refine reusability autonomy discoverability statelessness
  39. 39. Software Engineering for SoA Identify candidates for service compositions common scenarios -- like OO patterns improved performance identify missing workflow logic Revise business service operations previous step (service compositions) may necessitate revisit to grouping of business operations/services Analyze application processing requirement Can we achieve the service compositions with available application logic? Create application service candidates dealing with legacy systems
  40. 40. Software Engineering for SoA Do we have adequate methodologies, formalisms and tools for SoA Can we use UML or extended UML for SoA? How do we model, design, test/verify QoS properties? We have an interest in developing some innovative ideas and tools