Tutorial C: Service Oriented Architecture in the Context of Ground Systems

1. Tutorial C:Service Oriented Architecture in the Context of Ground Systems Steven Fonseca Jeff Estefan Jeff Singer Costin Radulescu Dan Crichton Adans Ko Ground System Architectures Workshop March 31, 2008

2. Learning Objectives • Provide an introduction to Service Oriented Architecture in the context of ground systems • Provide an overview of the application services reference architecture • Discuss Service Oriented Architecture infrastructure services and ground data systems deployment experiences (message bus and registry) • Provide an introduction to information architecture and its application • Review Service Oriented Architecture best practices in maturity assessment and road mapping • Complete a group exercise to reinforce talk concepts (time permitting) GSAW 2008: Achieving Operationally Responsive Ground Systems

3. Instructors • Steven Fonseca • Senior Engineer: Advanced Ground Data System Development GroupJet Propulsion Laboratory, California Institute of Technology • Jeff Estefan • Principal Engineer: Systems and Software DivisionJet Propulsion Laboratory, California Institute of Technology • Jeff Singer • Senior Engineer: Ground Command & Tracking Software GroupJet Propulsion Laboratory, California Institute of Technology • Costin Radulescu • Senior Engineer: Instrument Product Software Development GroupJet Propulsion Laboratory, California Institute of Technology • Dan Crichton • Principal Engineer: Planetary Data System Engineering NodeJet Propulsion Laboratory, California Institute of Technology GSAW 2008: Achieving Operationally Responsive Ground Systems

4. Agenda GSAW 2008: Achieving Operationally Responsive Ground Systems

5. Understanding the Essence of SOA: First Principles Jeff Estefan Division Chief Technologist Systems and Software Division Ground System Architectures Workshop March 31, 2008

6. Topics • Part I: Separating Hype from Reality • A Service-Oriented World • Where Does SOA Fit In? • What SOA Is • Challenges and Impediments • Recommendations • Part II: Core Concepts • OASIS Reference Model for SOA • Service • Dynamics of Services • About Services • An Illustrative SOA Example GSAW 2008: Achieving Operationally Responsive Ground Systems

7. Part I: SeparatingHype from Reality GSAW 2008: Achieving Operationally Responsive Ground Systems

8. A Service Oriented WorldService Oriented Business and Government • We all use services on a daily basis • Financial, insurance, healthcare, law enforcement, municipal utilities (e.g., water, power), etc. • Organizational entities that provide such services include business and government • Businesses provide services to customers, clients, and partners, for example: • Banks provide savings & checking accounts, consumer loans, mortgages, etc. • Insurance agencies provide property & casualty insurance, health insurance, etc. • Retail stores provide in-store shopping, online shopping, catalog shopping, etc. GSAW 2008: Achieving Operationally Responsive Ground Systems

9. A Service Oriented WorldService Oriented Business and Government (2) • Governments (at all levels) provide services to citizens, for example: • Police department provides law enforcement, community education, etc. • Motor vehicle department provides driver testing and licensing, vehicle licensing, vehicle inspections, etc. • Water and power department provides water & power services, water & quality, conservation measures, etc. • “Service orientation” is the organizational principle that drives business and government to be customer-oriented and citizen-centered • Business and government services span organizational boundaries • Service orientation applies equally to services that internal business units, departments, or agencies supply to each other GSAW 2008: Achieving Operationally Responsive Ground Systems

10. A Service Oriented WorldService Delivery • Business and government services are delivered in a variety of ways • Human-mediated delivery – A human agent acting on behalf of the business or government agency is involved in delivering some or all of the service to the customer, client, citizen, or partner • Self-service delivery – The customer, client, citizen, or partner obtains the service on his/her own, typically using an automated system provided by the business or government agency • System-to-system delivery – The service is performed automatically for the customer, client, citizen, or partner by the business or government agency and usually involves automated interactions among two or more computer systems – examples include automated check deposit and business-to-business (B2B) exchanges GSAW 2008: Achieving Operationally Responsive Ground Systems

11. A Service Oriented WorldServices that JPL Provides (An Example) • JPL is an organizational entity (FFRDC) that provides services to the scientific community, the public, and its employees • Interplanetary Network Directorate (IND) Deep Space Network (DSN) and Advanced Multimission Operations System (AMMOS) services • DSN: Command, telemetry, DSN science, & tracking services • AMMOS: Mission planning, sequencing, spacecraft analysis, mission control, instrument operations, data management, navigation & mission design services • Integrated Ground Data Systems Section services • GDS systems engineering • GDS software system engineering • GDS integration & test • GDS operations GSAW 2008: Achieving Operationally Responsive Ground Systems

12. A Service Oriented WorldCapabilities and Needs • In general, entities (people and organizations) create capabilities to solve or support a solution for the problems they face in the course of their business • Natural to think of one person’s needs being met by capabilities offered by someone else • Or in the world of distributed computing, one computer agent’s requirements being met by a computer agent belonging to a different owner • Not necessarily a one-to-one correlation between needs and capabilities • Granularity of needs and capabilities vary from fundamental to complex • Any given need may require the combining of numerous capabilities while any single capability may address more than one need GSAW 2008: Achieving Operationally Responsive Ground Systems

13. Where Does SOA Fit In?General Observations • While service orientation is an organizational principle applied to business and government; Service Oriented Architecture (SOA) is a paradigm applied to IT architecture • The primary goal of SOA-based IT systems is to directly support the services and delivery channels that an organization provides to its customers, clients, citizens, partners, and other organizations • Perceived value: • Powerful framework for matching needs and capabilities and for combining capabilities to address those needs • Flexibility and agility: Being able to compose new services from other services • Better business and IT alignment GSAW 2008: Achieving Operationally Responsive Ground Systems

14. Where Does SOA Fit In?A Brief History of SOA* • 1991 - Tim Burton started the Network Services Model • “Describes a set of services required of networks – notably file, print, management, security, directory, messaging and Web. And it predicts that these services will only scale and proliferate to the degree they are interoperable." • 1996 - Roy Schulte and Yefim Natis (Gartner analysts) coined the term "Service-Oriented" Architecture • “A style of multitier computing that helps organizations share logic and data among multiple applications and usage modes ... essentially, SOA is a software architecture that builds a topology of interfaces, interface implementations and interface calls." • 1998 - Network Applications Consortium position paper: "Business Services Architecture: Integration of software components and common services infrastructure" • "Organizations should plan to move to a multi-tier, service-oriented architecture, in which strategic applications are partitioned between user services, business services, data services, and legacy services... Successful migration to a service-oriented architecture requires a fundamental cultural shift toward recognizing infrastructure and business services as long-term capital assets." • Note: CORBA and DCOM the dominant distributed programming models • 2000/2001 - Web Services show up • WSDL 1.0 published • W3C Workshop on web services • 2006 - OASIS SOA Reference Model published as a formal standard *Courtesy: Ken Laskey, Rob Mikula, Chris Bashioum, The MITRE Corporation GSAW 2008: Achieving Operationally Responsive Ground Systems

15. What is SOA?High-Level/Abstract Perspective • It’s a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains† • It’s about working across boundaries, especially ownership boundaries • Different people or organizations may provide (“own”) the service and its underlying capability than the entities accessing it • It’s a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations† SOA is first and foremost a paradigm* *Paradigm: “A set of assumptions, concepts, values, and practices that constitutes a way of viewing reality for the community that shares them, especially in an intellectual discipline.” (Source: New American Heritage Dictionary) †Source: OASIS Reference Model for Service Oriented Architecture 1.0 GSAW 2008: Achieving Operationally Responsive Ground Systems

16. What is SOA?Pragmatic Perspective • It’s a paradigm applied to IT architecture • It affects much more than just development • Results in shared, reusable application and infrastructure services • It’s “something you do, not something you buy or build”* • It impacts all areas related to IT • Governance Policies & Procedures • Principles & Guidelines • Development Methods & Tools • Management & Maintenance • Enterprise Architecture *Source: Anne Thomas Manes, Burton Group GSAW 2008: Achieving Operationally Responsive Ground Systems

17. What SOA is Not • Web services • Web services is a set of technologies and standards that leverage Web and internet-based standards (e.g., XML, HTTP) • Gaining in popularity as a technology to implement SOA • Other technologies exist (OMG CORBA, MS DCOM, MS .NET, Java EE, Sun Jini™) • Enterprise Architecture (EA) • EA is a strategic planning and IT governance asset used to capture current state (“as-is”) and future state (“to-be”) architectural views (business, information/data, application/services, technology) of an enterprise and to use those assets and the associated transition plan to make IT portfolio planning and investment decisions • EA is the “intellectual component of SOA.” Undertaking SOA without a road map can result in formalizing the old ways of doing things using a new technology and missing the reconfigurability and agility benefits of SOA (Source: Jan Popkin, “Leveraging the Value Proposition of SOA,” Telelogic white paper, Telelogic AB, May 2007) GSAW 2008: Achieving Operationally Responsive Ground Systems

18. Challenges and Impediments*SOA is Hard! • SOA requires a sincere willingness to change • SOA is something you do • Not something you buy • Not something you build • SOA is about culture and politics • Not about technology • Technology makes it easier, but not a panacea • SOA is about collaboration • IT and LOBs must work together • Proper governance is critical • Many SOA initiatives will fail spectacularly *Source: Anne Thomas Manes, Burton Group GSAW 2008: Achieving Operationally Responsive Ground Systems

19. Challenges and Impediments*Fundamental Changes Required • Design ramifications: • Different design focus (service rather than application) • Designing reusable services takes more time • Accounting ramifications: • Who pays for initial service development? • How does a dev team recoup those expenditures? • Control ramifications: • Hard dependencies on services outside your control • Operations ramifications • New applications may impact performance of existing apps *Source: Anne Thomas Manes, Burton Group GSAW 2008: Achieving Operationally Responsive Ground Systems

20. Challenges and Impediments*Why Will SOA Initiatives Fail? • Insufficient education • SOA is fundamentally different • Lack of collaboration across business units • Limited benefits if SOA effort is constrained to a single LOB • Walking without a net • Coordination, guidance, and governance are critical *Source: Anne Thomas Manes, Burton Group GSAW 2008: Achieving Operationally Responsive Ground Systems

21. Recommendations* Develop a SOA Adoption Plan • No vendor can sell you “instant SOA” • SOA is a process, not technology • Plan training and mentoring for staff • Develop corporate guidelines and best practices • Institute governance processes and tools • Establish new incentives that reward good SOA behavior • From senior management on down *Source: Anne Thomas Manes, Burton Group GSAW 2008: Achieving Operationally Responsive Ground Systems

22. Part I Q & A GSAW 2008: Achieving Operationally Responsive Ground Systems

23. Part II: Core Concepts GSAW 2008: Achieving Operationally Responsive Ground Systems

24. OASIS Reference Model for SOARelation to Other SOA Work Provides a vocabulary for understanding the “essence” of SOA Focus for today GSAW 2008: Achieving Operationally Responsive Ground Systems

25. OASIS Reference Model for SOACore Concepts • Service • Dynamics of Services • Visibility • Interaction • Real World Effect • About Services • Service Description • Contract & Policy • Execution Context GSAW 2008: Achieving Operationally Responsive Ground Systems

26. Core ConceptsService • The noun “service” is defined in dictionaries as “the performance of work (a function) by one for another”; however… • As generally understood, the term “service” combines the following • The capability to perform work for another • The specification of the work offered for another • The offer to perform work for another • These concepts emphasize a distinction between a capability – and the ability to bring that capability to bear This is a very important point! GSAW 2008: Achieving Operationally Responsive Ground Systems

27. Core ConceptsService (2) • The service concept emphasizes a distinction between a capability (that represents some functionality created to address a need) – and the point of access where that capability is brought to bear in the context of SOA • It is assumed that needs capabilities exist outside of SOA • In actual use, maintaining this distinction may not be critical(i.e., the service may be talked about in terms of being the capability)but the separationis pertinentin terms of aclear expression of the nature of SOA and the value it provides GSAW 2008: Achieving Operationally Responsive Ground Systems

28. Core ConceptsService (3) • Practically speaking, a [SOA] service is a mechanism to enable access to a set of one or more capabilities, where • The access is provided using a prescribed [service] interface, and • [the access] is exercised consistent with constraints and policies as specified by [referenced in] the service description (a core concept described later) • A service is provided by an entity – the service provider (defined on the next slide) – for use by others, but • The eventual consumers of the service may not be known to the service provider, and • [the eventual consumers] may demonstrate uses of the service beyond the scope originally conceived by the provider GSAW 2008: Achieving Operationally Responsive Ground Systems

29. Core ConceptsService (4) • Service Provider • Entities (people and organizations) • who offer (and provide access to) capabilities • Service Consumer • Entities with needs • who make use of services • to satisfy their need • Note: The provider of the underlying capability may not be the same entity that provides the service which enables access to that capability • Entity with the domain expertise to create, maintain, and evolve a given capability • May not have the expertise to create, maintain, and evolve the mechanism to provide access to the capability GSAW 2008: Achieving Operationally Responsive Ground Systems

30. Core ConceptsService (5) • Access to services in SOA-based systems is provided using a prescribed [service] interface and is exercised consistent with constraints and policies as specified by the service description • There are no constraints on what constitutes the underlying capability or how access is implemented by the service provider [or others] • The service could carry out its described functionality through one or more automated and/or manual processes that themselves could invoke other available services GSAW 2008: Achieving Operationally Responsive Ground Systems

31. Core ConceptsService (6) • A service is opaque in that its implementation is typically hidden from the service consumer except for • The information and behavior models exposed through the service interface, and • The information required by service consumers to determine whether a given service is appropriate for their needs • The consequence of invoking a service is a realization of one or more real world effects • Information returned in response to a request for that information[the service consumer does not know how the information is generated] • A change to the shared state of defined entities [the service consumer does not know how the state change is effected], or • Some combination of (1) and (2) GSAW 2008: Achieving Operationally Responsive Ground Systems

32. Core ConceptsDynamics of Services • Three concepts are core in describing the dynamics of services • Visibility – The capacity for those with needs and those with capabilities to be able to see each other • Interaction – The activity of using a capability • [Real World] Effect – The actual result of using a service (rather than the underlying capability being offered) GSAW 2008: Achieving Operationally Responsive Ground Systems

33. Core ConceptsVisibility • Visibility – Capacity for those with needs and those with capabilities to be able to see each other • i.e., the possibility of matching needs to capabilities • Typically done by providing descriptions for such aspects as • Functions and technical requirements • Related constraints and policies • Mechanisms for access or response • Descriptions need to be in a form in which syntax and semantics are • widely accessible • and understandable • Visibility applies to both capabilities and needs GSAW 2008: Achieving Operationally Responsive Ground Systems

34. Core ConceptInteraction • Interaction – Activity of using a capability • Typically mediated via exchange of messages (as opposed to objects or procedure calls) • Proceeds through a series of information exchanges and invoked actions • “An act” as opposed to “an object” • Results in an effect (next concept) GSAW 2008: Achieving Operationally Responsive Ground Systems

35. Core ConceptsReal World Effect • Real World Effect – The reason for using a capability • The result of an interaction • May be the return of information, or • The change in the state of entities involved in the interaction • Description of which establishes the expectations of those using the capability* • Expected real world effects are important part of decision whether a particular capability meets a need • Distinguish between public actions and private actions • Public actions result in changes to the state that is shared between at least those involved in the current execution context and possibly shared by others • Private actions are inherently unknowable by other parties GSAW 2008: Achieving Operationally Responsive Ground Systems

36. Core ConceptsAbout Services • Three concepts are core in describing the meta-level aspects of services (information about services) • Service Description – The information needed in order to use, or consider using, a service • Contract & Policy – The agreement between two or more parties (contract) and a statement of obligations, constraints or other conditions of use of an owned entity as defined by a participant • Execution Context – Set of technical/business elements that form path between those with needs and capabilities GSAW 2008: Achieving Operationally Responsive Ground Systems

37. Core ConceptsService Description • Service Description – The information needed in order to use, or consider using, a service • Makes available critical information that a consumer needs to decide whether or not to use a service • That the service exists and is reachable • That the service performs a certain function or set of functions • That the service operates under a specified set of constraints and policies • That the service will (to some implicit or explicit extent) comply with policies as prescribed • How to interact with the service in order to achieve the required objectives, where “how-to” information includes • The structure (syntax) and semantics (meaning) of information exchanged between the service and the consumer • The sequences of information exchange that may be expected GSAW 2008: Achieving Operationally Responsive Ground Systems

38. Core ConceptsService Description (2) • Each of these items (5 previous sub-bullets) should be represented in any service description • Details can be included through references (links) to external sources and are not required to be incorporated explicitly • Inclusion by reference enables reuse of standard definitions, such as for functionality or policies • Facilitates dynamics of services • Visibility is promoted through the service description • Which is a collection point for all information related to a service • Contains information necessary to interact with the service (e.g. service inputs and outputs, associated semantics, conditions for using the service) • Conveys real world effects when one interacts with the service GSAW 2008: Achieving Operationally Responsive Ground Systems

39. Core ConceptsService Description (3) • No one “right” description • Elements of description required depend on the context and the needs of the parties using the associated entity • Certain elements are likely to be part of any service description (e.g., the information model) but many elements such as function and policy may vary • Best practice suggests that the service description should be represented using a standard, referenceable format GSAW 2008: Achieving Operationally Responsive Ground Systems

40. Core ConceptsService Description (4) • Important Caveat: There are limits of Service Descriptions • It is simply not possible to specify, completely and unambiguously, the precise semantics of and all related information about a service • Will always be unstated assumptions made by the describer of a service that must be implicitly shared by readers of the description • Applies to machine processable descriptions as well as to human readable descriptions • A search query cannot be so complete as to guarantee a single response • Any query has the potential for zero or more responses • Consumer of the search information must choose among alternatives GSAW 2008: Achieving Operationally Responsive Ground Systems

41. Core ConceptsContract & Policy • Contract & Policy – The agreement between two or more parties (contract), and a statement of obligations, constraints or other conditions of use of an owned entity as defined by a participant (policy) • A policy is the point of view of an individual participant; a contract represents an agreement between two or more participants • Let’s start with the concept of [Service] Policy… • Three aspects of policies • Policy assertion • Policy owner (sometimes referred to as the policy subject) • Policy enforcement GSAW 2008: Achieving Operationally Responsive Ground Systems

42. Core ConceptsContract & Policy (2) • Policy Assertion • Policy assertions are measurable: each may be true or false • Often about the way the service is realized; i.e., they are about the relationship between the service and its execution context • For example, the assertion: “All messages are encrypted” is an assertion regarding the forms of messages: it is true or false depending on whether the traffic is encrypted • Policy Owner • A policy always represents a participant’s point of view • An assertion becomes the policy of a participant when they adopt the assertion as their policy Ex: The service consumer declares that “All messages are encrypted” • That reflects the policy of the service consumer • This asserted to be policy by the service consumer independently of any agreement from the service provider • Linking of an assertion to policy is normally not part of the assertion itself – it is in the use of the assertion by its owner GSAW 2008: Achieving Operationally Responsive Ground Systems

43. Core ConceptsContract & Policy (3) • Policy Enforcement • Service policy enforcement amounts to ensuring that the policy assertion is consistent with the real world • SOA-RM does not deal with enforcement mechanism other than to imply that an architecture will likely have such a mechanism • An unenforceable constraint is not a policy; it would be better described as a wish\ • Policies potentially apply to many aspects of SOA: • Security • Privacy • Manageability • Quality of Service (QoS) • Beyond such infrastructure-oriented policies, participants MAY also express business-oriented policies • Hours of business • Return policies GSAW 2008: Achieving Operationally Responsive Ground Systems

44. Core ConceptsContract & Policy (4) • Policy assertions should be written in a form that is understandable to, and processable by, the parties to whom the policy is directed • The service description is a natural place to contain references to the policies associated with the service • Now, let’s turn to the concept of [Service] Contract… • A service contract is a measurable assertion that governs the requirements and expectations of two or more parties • Note: not necessarily referring to legal contracts • Recall, policy enforcement is usually the responsibility of the policy owner • Contract enforcement may involve resolving disputes between the parties to the contract • Contracts can cover a wide range of aspects of services: • Quality of service agreements • Interface and choreography agreements • Commercial agreements GSAW 2008: Achieving Operationally Responsive Ground Systems

45. Core ConceptsContract & Policy (5) • Contracts may be expressed in a form that permits automated interpretation • Machine processable form to facilitate, for example, automated service composition • May also have to be readable by people, e.g. when describing over-arching agreements between service providers and consumers • A contract may be arrived at by a mechanism that is not directly part of an SOA – an out of band process. Alternatively, a contract may be arrived at during the course of a service interaction – an in-band process GSAW 2008: Achieving Operationally Responsive Ground Systems

46. Core ConceptsExecution Context • Execution Context – Set of technical/business elements that form path between those with needs and capabilities • Is the set of infrastructure elements, process entities, policy assertions and agreements that are identified as part of an instantiated service interaction, and thus forms a path between those with needs and those with capabilities • Permits information to be exchanged, actions to be performed and provides a decision point for any policies and contracts that may be in force • Given visibility, can begin interaction • What protocols are participants prepared to use? • What vocabularies/mediation must participants understand? • What policies/mediation do participants want to be in place? • Etc… GSAW 2008: Achieving Operationally Responsive Ground Systems

47. Core ConceptsExecution Context (2) • Each answer is step in coordinating details to be resolved before service will perform its described functions • Generate its described real world effects • Participants must agree and acknowledge a consistent set of agreements in order to have a successful service interaction • Execution context is the evolving collection of answers, agreements, expectations, appropriate future actions • A way to envision Execution Context • The consumer and provider can be envisioned as separate places on a map and, for a service to actually be invoked, a path must be established between those two places. This path is the execution context. As with a path between places, it can be a temporary connection (e.g. a tenuous footbridge of an ad hoc exchange) or a well-defined coordination (e.g. a super highway) that can be easily reused in the future GSAW 2008: Achieving Operationally Responsive Ground Systems

48. An Illustrative SOA ExampleElectric Generation and Use • The underlying capability: An electric utility has the capacity to generate and distribute electricity • The need: residential consumer needs to power appliances • The service (bringing together capability and need): wiring, processes, procedures of the electric company’s distribution grid • The service functionality: provides the means to supply electricity to support typical usage for a residential consumer’s house • Output of invoking service (real world effect): a consumer accesses electricity generated • Service interface: access via a wall outlet • Service technical assumptions: • Consumer needs to understand • What type of plug to use • What is the voltage of the supply • Possible limits to the load GSAW 2008: Achieving Operationally Responsive Ground Systems

49. An Illustrative SOA ExampleElectric Generation and Use (2) • Service technical assumptions (cont): • Utility presumes consumer will only connect devices that are compatible with the voltage provided and load supported • Consumer in turn assumes that compatible consumer devices can be connected without damage or harm • Service policy: A residential or business user will need to open an account with the utility in order to use the supply • Service policy: the utility will meter usage and expects the consumer to pay for use at the rate prescribed • Service contract: When the consumer and utility agree on polices, the consumer can receive electricity using the service • Service reachability: the consumer can receive electricity using the service as long as the electricity distribution grid and house connection remain intact (e.g. a storm knocking down power lines would disrupt distribution) and the consumer can have payment sent (e.g. a check by mail or electronic funds transfer) to the utility GSAW 2008: Achieving Operationally Responsive Ground Systems

50. An Illustrative SOA ExampleElectric Generation and Use (3) An alternative need scenario: • Alternate need: A visitor to someone's house may use a contracted supply • Alternate service contract: none – no relationship with the utility or any requirement to also satisfy the initial service constraint (i.e. reachability only requires intact electricity distribution) • Alternate service technical assumptions: unchanged • Alternate service interface: expected to be compatible with same service interface GSAW 2008: Achieving Operationally Responsive Ground Systems