Your SlideShare is downloading. ×
soa.ppt
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

soa.ppt

10,869
views

Published on


0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
10,869
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1,020
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Net Centric Operations
    • Recent trends in Network-Centric Warfare (NCW) have significant effect:
      • Service-Oriented Architecture (SOA)
        • Network Centric Enterprise Services (NCES), GIG Enterprise Services (GES), JBMC2, FCS, JBI, and Composable FORCEnet
        • Dynamic publication, runtime selection and discovery, dynamic composition
        • Distributed services and agents
      • These systems must be dynamic and keep on changing even at runtime.
    • These architectures are not static but dynamic and evolving
      • in other words, modern DoD systems need to respond to change at runtime and in real time.
    • Key question
      • 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?
  • 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. 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. SOA-based System Architecture
    • The system has three architectures :
      • The Application Architecture . This application architecture will be built on top of an SOA.
      • The Service Architecture . This is the commonly known SOA architecture.
      • The Component Architecture . This is sub-SOA architecture that describes the various elements that support the implementation of services.
    Note -- although we used application architecture here, we apply this to both application and business logic
  • 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. One view of Enterprise Service Orientation Service Orientation of Enterprise Systems
  • 24. One view of Enterprise Service Orientation Service Orientation of Enterprise Systems
  • 25. Components of Logic in Service Orientation
    • Message (units of communication)
    • Operations (units of work)
    • Services (units of processing logic -- collection of units of work)
    • Processes (units of logic -- coordinated aggregation of services)
    Service Orientation of Enterprise Systems How unit communicate
  • 26. Components of Logic in Service Orientation Service Orientation of Enterprise Systems
  • 27. Modeling Service Layers for Business and Application logic Service Orientation of Enterprise Systems
  • 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. Service Orientation of Enterprise Systems Task-centric and Entity-Centric services
  • 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. Service Oriented Architecture Web services is one realization of the SoA
  • 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. 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. Software Engineering for SoA Bottom up approach Create services based on application needs May not fully take advantage of available services
  • 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. 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. Software Engineering for SoA An example
  • 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. 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. 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