Jet Propulsion Laboratory California Institute of Technology National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California 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 1 – 3/19/2018
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California 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 2
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • Instructors Steven Fonseca – Senior Engineer: Advanced Ground Data System Development Group Jet Propulsion Laboratory, California Institute of Technology Jeff Estefan – Principal Engineer: Systems and Software Division Jet Propulsion Laboratory, California Institute of Technology Jeff Singer – Senior Engineer: Ground Command & Tracking Software Group Jet Propulsion Laboratory, California Institute of Technology Costin Radulescu – Senior Engineer: Instrument Product Software Development Group Jet Propulsion Laboratory, California Institute of Technology Dan Crichton – Principal Engineer: Planetary Data System Engineering Node Jet Propulsion Laboratory, California Institute of Technology GSAW 2008: Achieving Operationally Responsive Ground Systems 3
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Agenda Duration Topic Presenter 10 Introduction Steven Fonseca 85 Understanding the Essence of SOA: First Principles Jeff Estefan 20 Break 60 Application Services Architecture Steven Fonseca 35 Infrastructure Services Jeff Singer 90 Lunch 35 Infrastructure Services (continued) Costin Radulescu 60 Introduction to Information Architecture Dan Crichton 20 Break 30 SOA Maturity and Roadmap Steven Fonseca 60 SOA Group Exercise Steven Fonseca GSAW 2008: Achieving Operationally Responsive Ground Systems 4
Jet Propulsion Laboratory California Institute of Technology National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Understanding the Essence of SOA: First Principles Jeff Estefan Division Chief Technologist Systems and Software Division Ground System Architectures Workshop March 31, 2008 5 – 3/19/2018
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • Part I: Separating Hype from Reality – – – • Topics 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 6
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Part I: Separating Hype from Reality GSAW 2008: Achieving Operationally Responsive Ground Systems 7
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California A Service Oriented World Service Oriented Business and Government • We all use services on a daily basis • Organizational entities that provide such services include business and government • Businesses provide services to customers, clients, and partners, for example: – Financial, insurance, healthcare, law enforcement, municipal utilities (e. g. , water, power), etc. – 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 8
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • A Service Oriented World Service 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 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 citizencentered • 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 9
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • A Service Oriented World Service 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 (B 2 B) exchanges GSAW 2008: Achieving Operationally Responsive Ground Systems 10
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California A Service Oriented World Services 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 11
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California A Service Oriented World Capabilities 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 12
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California 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 13
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Where Does SOA Fit In? A Brief History of SOA* • 1991 - Tim Burton started the Network Services Model • 1996 - Roy Schulte and Yefim Natis (Gartner analysts) coined the term "Service-Oriented" Architecture • – “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. " – “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 • 2006 - OASIS SOA Reference Model published as a formal standard – WSDL 1. 0 published – W 3 C Workshop on web services *Courtesy: Ken Laskey, Rob Mikula, Chris Bashioum, The MITRE Corporation GSAW 2008: Achieving Operationally Responsive Ground Systems 14
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California What is SOA? High-Level/Abstract Perspective SOA is first and foremost a paradigm* • • • 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† *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 15
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California What is SOA? Pragmatic Perspective • It’s a paradigm applied to IT architecture • It’s “something you do, not something you buy or build”* • It impacts all areas related to IT – It affects much more than just development – Results in shared, reusable application and infrastructure services – – – 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 16
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • 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 17
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • 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 18
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • 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 19
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • 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 20
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • 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 21
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Part I Q & A GSAW 2008: Achieving Operationally Responsive Ground Systems 22
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Part II: Core Concepts GSAW 2008: Achieving Operationally Responsive Ground Systems 23
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California OASIS Reference Model for SOA Relation to Other SOA Work Provides a vocabulary for understanding the “essence” of SOA GSAW 2008: Achieving Operationally Responsive Ground Systems Focus for today 24
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California OASIS Reference Model for SOA Core 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 25
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Core Concepts Service • 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 26
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Core Concepts Service (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 separation is pertinent in terms of a clear expression of the nature of SOA and the value it provides GSAW 2008: Achieving Operationally Responsive Ground Systems 27
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • Core Concepts Service (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 28
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Core Concepts Service (4) • Service Provider • Service Consumer • Note: The provider of the underlying capability may not be the same entity that provides the service which enables access to that capability – Entities (people and organizations) – who offer (and provide access to) capabilities – Entities with needs – who make use of services – to satisfy their need – 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 29
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Core Concepts Service (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 30
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • Service (6) A service is opaque in that its implementation is typically hidden from the service consumer except for – – • Core Concepts 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 1. Information returned in response to a request for that information [the service consumer does not know how the information is generated] 2. A change to the shared state of defined entities [the service consumer does not know how the state change is effected], or 3. Some combination of (1) and (2) GSAW 2008: Achieving Operationally Responsive Ground Systems 31
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • Core Concepts Dynamics 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 32
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • Core Concepts 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 33
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • Core Concept 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 34
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • Core Concepts 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 35
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • Core Concepts About 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 36
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • Core Concepts 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 37
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Core Concepts Service 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 38
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Core Concepts Service 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 39
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • Core Concepts Service 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 40
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • Core Concepts 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 41
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Core Concepts Contract & 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 42
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Core Concepts Contract & 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 (Qo. S) – Beyond such infrastructure-oriented policies, participants MAY also express business-oriented policies • Hours of business • Return policies GSAW 2008: Achieving Operationally Responsive Ground Systems 43
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Core Concepts Contract & 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 44
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Core Concepts Contract & 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 overarching 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 inband process GSAW 2008: Achieving Operationally Responsive Ground Systems 45
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • Core Concepts 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 46
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Core Concepts Execution 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 47
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • An Illustrative SOA Example Electric 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 48
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • An Illustrative SOA Example Electric 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 49
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California An Illustrative SOA Example Electric 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 50
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California An Illustrative SOA Example Electric Generation and Use (4) An additional service policy scenario: • Additional service policy: In certain situations (for example, excessive demand), a utility may limit supply or institute rolling blackouts • Consumer's implied policy: might lodge a formal complaint if this occurred frequently GSAW 2008: Achieving Operationally Responsive Ground Systems 51
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Part II Q & A GSAW 2008: Achieving Operationally Responsive Ground Systems 52
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Resources • Eric Newcomer and Greg Lomow, Understanding SOA and Web Services, Addison-Wesley Professional, 2004 • Anne Thomas Manes, “Service Oriented Architecture, ” Burton Group, Briefing to FFRDC EA and CIO Meetings, Jan. 24 -25, 2006 • OASIS Reference Model for Service Oriented Architecture 1. 0, Organization for the Advancement of Structured Information Standards (OASIS), Oct. 12, 2006 – http: //www. oasis-open. org/specs/index. php#soa-rmv 1. 0 GSAW 2008: Achieving Operationally Responsive Ground Systems 53
Jet Propulsion Laboratory California Institute of Technology National Aeronautics and Space Administration Application Services Architecture Jet Propulsion Laboratory California Institute of Technology Pasadena, California Steven Fonseca Chief Software Architect Deep Space Information Services Architecture Ground System Architectures Workshop March 31, 2008 54 – 3/19/2018
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • Topics Introduction – SOA as an Architectural Style – Doing SOA: Disciplined Design and Implementation – Context of the Application Services Architecture SOA Application Reference Architecture – Application Services Architecture Layers – Service Categorization – Service Portfolio Plan SOA Business Iteration Model – Business discovery – Strategy and Planning – Implementation Achieving Modifiability Example References GSAW 2008: Achieving Operationally Responsive Ground Systems 55
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California SOA as an Architectural Style Business Goals System Qualities Extensibility Modifiability Interoperability Reusability Design Choices Controlled Implementation GSAW 2008: Achieving Operationally Responsive Ground Systems Enterprise Architecture as Strategy, Ross et al. 56
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • Doing SOA: Disciplined Design and Implementation Software architecture is about the governance of subsequent design and implementation to ensure the satisfaction of stakeholder demanded system qualities The SOA approach advocates rich prescription of constraints A reference architecture establishes the hooks that are needed to associate policies with design and implementation artifacts It is only through disciplined adherence to the reference architecture and associated specifications that quality attributes are achieved Architecture and implementation teams must work closely together – To ensure the reference architecture is a good fit – To ensure the design and implementation adhere to the architecture SOA best practices must be habitually used to reap their full benefit SOA best practices frequently go against engineering culture statusquos GSAW 2008: Achieving Operationally Responsive Ground Systems 57
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California SOA Reference Architectures • Everware-CBDI • • IBM Solution Stack View SOA Practitioners Guide GSAW 2008: Achieving Operationally Responsive Ground Systems • The application services reference architecture is one of several views of a complete SOA reference architecture Many SOA reference architectures exist in the literature but most are not defined in detail There is considerable variability in the way that SOA reference architectures are decomposed The application services reference architecture is a conceptual model whose instantiation is a service portfolio plan 58
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California SOA Infrastructure Versus Application Service Layers Presentation Layer Choreography Service Layer GDS Business Service Layer Functional Service Layer Application Layer GSAW 2008: Achieving Operationally Responsive Ground Systems 59
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • SOA Infrastructure Layers Basic Services – – – Messaging Metadata registry Service hosting platform Workflow engine Cross-Cutting Services – Governance – Security – Logging Infrastructure Service Architecture – Largely dependent on SOA strategy and COTS products – Design should be consistently applied and isolate proprietary dependencies – Must consider centralized versus distributed, integrated versus federated – Ease of COTS integration must be planned / architected Basic SOA Infrastructure Functionality GSAW 2008: Achieving Operationally Responsive Ground Systems 60
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California SOA Application Architecture Layers • Literature abounds with SOA application architecture layering approaches • Deep Space Information Services Architecture (DISA) Application Services Layers Each layer organizes a set of services or standard application code by function type Layers can depend on lower layers (n-1, n-2, etc. ) Dependencies between elements within a layer should be governed by policy Upward dependencies can be appropriate but should be governed by implementation policy 3 layers are allocated to services Your reference architecture could define layers within layers • • • GSAW 2008: Achieving Operationally Responsive Ground Systems Standard benefits of the layering architectural style apply 61
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Application Layer • • • Characteristics – Typically composed of legacy applications and COTS products – Normally there is an enterprise architecture activity to consolidate legacy applications Benefits – SOA initiatives typically reuse vast amounts of existing functionality Example Policies – Communication between applications within the application layer shall occur over the message bus – Applications shall not become a part of the service portfolio plan without having first been reviewed by the enterprise architecture team for consolidation opportunities GSAW 2008: Achieving Operationally Responsive Ground Systems 62
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Functional Service Layer • • • Characteristics – Include two classes of service: 1) those that offer highly reusable and general purpose capabilities, 2) adapter services that expose basic capabilities within a specific business domain – Service granularity varies considerably – Statelessness is desirable but not required – Expose legacy and COTS capabilities as services Benefits – Isolation from 3 rd party dependencies – Many opportunities for reuse across domains Example Policies – functional services shall not share cyclic dependencies with one another – The interfaces of functional services shall hide the legacy application data model by using terms defined in the SOA information architecture – Functional services shall not be exposed to external partners GSAW 2008: Achieving Operationally Responsive Ground Systems 63
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California GDS Business Service Layer • Characteristics – Align with the core GDS capabilities offered by the business – Cleanly encapsulate business logic, ideally independent of • • The user interface Specific business processes – Tend to be more coarse-grain than functional services but not necessarily – Generally include two classes of service* • • those that are based on tasks those that are based on business entities. – Typically aggregate functional services • Benefits • Example Policies – Explicit business layer helps ensure technology alignment with the business – Provide reusable layer of business-centric services that can be orchestrated via declarative process execution – Hide functional service interfaces – Business services shall directly align with capabilities or entities defined by the business model – Candidate services shall be assessed for enterprise-wide reuse, as defined by process X – Business services shall developed in-house *Service-Oriented Architecture, Concepts, Technology, and Design by Thomas Erl GSAW 2008: Achieving Operationally Responsive Ground Systems 64
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Process Service Layer • • • Characteristics – Contain software that controls the order of execution flow – Designed for a specific business process – Composes business and functional services – Requires that a workflow engine be a part of the SOA infrastructure services suite – Maintains execution state Benefits – Provide the ability to separate process execution from business logic execution – promoting greater system flexibility (agility) – Driven by declarative process descriptions and execution implementation are standards and COTS-based Example Policies – All process services shall be certified fault tolerant GSAW 2008: Achieving Operationally Responsive Ground Systems 65
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Presentation Layer • • • Characteristics – Primarily contains user interface software, may contain some session-related data – Cleanly separates visualization code from its data, business logic, and process execution – Decomposes user interfaces into reusable components that can be composed in a variety of contexts Benefits – Improves system flexibility and maintainability – Moderates the proliferation of user interface technologies – Reduces user interface development costs through reuse and reduced system complexity Example Policies – Presentation components shall support minimal composition at the level of sharing screen real estate – Presentation components shall adhere to the WSRP specification for exposing remote operations GSAW 2008: Achieving Operationally Responsive Ground Systems 66
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Service Categorization • • • Sequencing Planning • • By layer – Functional, business, process By domain – i. e. planning, sequencing By function – i. e. adapter, coordinator, controller By quality of service – i. e. high throughput By maturity – i. e. Experimental, proposed, stable Utility Proposed Wrapper • GSAW 2008: Achieving Operationally Responsive Ground Systems Any other classification that facilitates policy association 67
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Service Portfolio Plan • • • The service portfolio plan documents the Transition or TO-BE application service architecture Use conceptual, implementation, and deployment views to capture the application service architecture Plan Contents* – – – Architecture background Policies Scope & domain overview Default quality requirements Service architecture and descriptions Development schedule * Practical Service Specification and Design Part 1: Planning the Services, John Dodd GSAW 2008: Achieving Operationally Responsive Ground Systems 68
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Methodical, Iterative, and Incremental Service Orientating * Adapted from Service-Oriented Architecture, A Planning and Implementation Guide for Business and Technology, Marks & Bell GSAW 2008: Achieving Operationally Responsive Ground Systems 69
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Business Discovery A methodical approach to ensuring that business needs drive technology initiatives in a manner that is coordinated, efficient, and that serves the best interests of the enterprise Vision Statement … enables principal investigators to directly, immediately, flexibly, and seamlessly interact with their instruments and their data from wherever they are located… Business Context The DSN and AMMOS are funded by different NASA organizations (SOMD and SMD) whose allocations are not synchronized Business Goals Enable flexible deployment of GDS capabilities to meet mission needs. Technical Imperatives Provide remote access to AMMOS capabilities. Architecture Quality Attributes Adaptability Important Functions Accountability GSAW 2008: Achieving Operationally Responsive Ground Systems Quality Attribute Scenarios* • Quality Attribute: Adaptability • Stimulus: Customer request for display of additional telemetry parameter that is part of an already rendered telemetry group • Artifact: AMMOS • Environment: nominal operations, system running • Response: Telemetry parameter is rendered with the group • Response Measure: 10 seconds * Software Architecture in Practice, Len Bass et al. 70
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • SOA Strategy and Planning: Service Selection Factors Business needs Existing legacy capabilities Existing services Level of granularity Architecture appropriateness – quality attributes to satisfy Reuse opportunity Implementation readiness Quick proof of value Cost GSAW 2008: Achieving Operationally Responsive Ground Systems 71
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California SOA Implementation: Example Transition Approaches SOA Transition Scenarios for the IBM z/OS Platform GSAW 2008: Achieving Operationally Responsive Ground Systems 72
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California SOA Implementation: Infrastructure Technologies and Standards • • • There are many SOA standards, a good portion of which are immature Focus on SOAP, WSDL, WS-I Basic Profile, UDDI, WS-Security, WS-BPEL, PBMN, WSRP to start Methodically assess standards for maturity and vendor support using a “technology” architectural view – (i. e. Do. DAF SV-9, TV-2) GSAW 2008: Achieving Operationally Responsive Ground Systems • • SOA COTS product classes – – – Enterprise Service Bus Workflow SOA Management Registry Service Platform Messaging COTS capability bundling across vendors is highly variable Many vendors are in the business Generally, avoid vendor lock-in through standards-based isolation Manage architectural mismatch between your system and its COTS products via methodical integrated evaluation COTS Products are not silver bullets – COTS-Based Systems Top 10 list – COTS-Based Systems – Twelve Lessons Learned about Maintenance 73
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Example: Achieving Modifiability Message Bus Service Registry Layered Architecture Controlled Evolution • Software elements can be readily added and removed • Method invocation replaced with message passing • Message content connects sender and receiver, not ID • Eliminates host-host dependencies • Coupling by service not ID • Coupling is dynamic and can be shortlived • Eliminates dependencies on COTS software • Homogenizes technology idiosyncrasies • Architecture change impact management • Managed non-compliance TO-BE AS-IS GSAW 2008: Achieving Operationally Responsive Ground Systems 74
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Example: Achieving Modifiability Component-Based UI Workflow Engine Information Separation • Decouples interface from business logic • Reusable interface components can be used in several contexts • Declarative process definition drives service aggregation and execution • Processes can be easily re-defined • Explicit and separated declaration of semantics permits re-definition • Unified access to information is more maintainable TO-BE AS-IS GSAW 2008: Achieving Operationally Responsive Ground Systems 75
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • References SOA Practitioners Guide, http: //soablueprint. com/practitioners_guide Service-Oriented Architecture, Concepts, Technology, and Design by Thomas Erl Everware-CBDI, http: //www. cbdiforum. com/ Practical Service Specification and Design Part 1: Planning the Services by John Dodd Service-Oriented Architecture – A Planning and Implementation Guide for Business and Technology by Michael Bell and Eric Marks COTS-Based Systems – Twelve Lessons Learned about Maintenance by Donald Reifer et al. COTS-Based Systems Top 10 List by Victor Basili and Barry Boehm Enterprise Architecture as Strategy by Jeanne Ross et al. SMART: The Service-Oriented Migration and Reuse Technique, Grace Lewis et al. (CMU-SEI) GSAW 2008: Achieving Operationally Responsive Ground Systems 76
Jet Propulsion Laboratory California Institute of Technology National Aeronautics and Space Administration Infrastructure Services Jet Propulsion Laboratory California Institute of Technology Pasadena, California Jeff Singer Lead Development Engineer Messaging Services Products & Telecommand Common Software Ground System Architectures Workshop March 31, 2008 77 – 3/19/2018
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • Topics Introduction – Definition, Benefits – Our Goal - Message Bus Scaling Usage Anti-Patterns Governance and Mediation Administration and Monitoring References Conclusion GSAW 2008: Achieving Operationally Responsive Ground Systems 78
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • Definition – • Definition - Benefits common communication infrastructure, provides a cross-platform, cross-language universal adapter between applications, coordinates and manages sending and receiving of messages over defined channels [1] Benefits – Asynchronous : no need to wait for delivery/receipt – Decoupled: consumers/producers do not need to know where communication partners are or what they do – Reliable : service responsible for delivery – Disconnected Operation: messages can be queued and delivered at a later time – Simplifies Remote Communication: standard interface, abstraction of underlying transport protocols/mechanisms/serialization/etc. GSAW 2008: Achieving Operationally Responsive Ground Systems 79
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Goal - Message Bus • Definition – A combination of a canonical data model, common command set and a messaging infrastructure to allow different systems to communicate through a shared set of interfaces. [1] GSAW 2008: Achieving Operationally Responsive Ground Systems 80
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Scaling Emergency Control Center Station 1 General Use GDS Ops Mission Ops Headquarters Station 2 GSAW 2008: Achieving Operationally Responsive Ground Systems Station 3 81
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • Usage Anti-Patterns Channel proliferation If you publish it they will come Everything is a message All durable all the time All communication carried out via the message service Request For/Reply With Everything GSAW 2008: Achieving Operationally Responsive Ground Systems 82
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • Governance And Mediation Naming Conventions Data Models Resource Availability And Location Message Format Service Level Agreements – Service Performing As Agreed – Clients Performing As Agreed Security Requirements GSAW 2008: Achieving Operationally Responsive Ground Systems 83
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • Administration And Monitoring Deployment Management Vendor Relations/Product Knowledge Implementation/Management of Service For New Clients Implementation of Corrective Action For Misbehaving Clients Service Data Point/Metrics Visibility Automated Service Health Monitoring Traffic Monitoring GSAW 2008: Achieving Operationally Responsive Ground Systems 84
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • Conclusion Message Service is usually a key low level infrastructure component of Service Oriented Architectures Anticipate and plan for future expansion and increased usage of the Message Service Be directly involved in the architecture and design phases of services, components, applications, etc. intending to utilize the Message Service Have well defined, active Governance and Mediation in place GSAW 2008: Achieving Operationally Responsive Ground Systems 85
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California References [1] Hohpe, Gregor & Woolf, Bobby Enterprise Integration Patterns. Boston: Addison. Wesley, 2004. [2] Java Messaging Service 1. 1 Specification, https: //sdlc 3 d. sun. com/ECom. Action. Servlet; jsessionid=1049 A 828 DAD 7 B 6 F 145456873418 B 91 DC [3] OMG Data Distribution Service Portal, http: //portals. omg. org/dds [4] eb. XML Portal, http: //www. ebxml. org [5] Microsoft Message Queueing, http: //www. microsoft. com/windowsserver 2003/tehnologies/msmq/default. msp x GSAW 2008: Achieving Operationally Responsive Ground Systems 86
Jet Propulsion Laboratory California Institute of Technology National Aeronautics and Space Administration Infrastructure Services (continued) Jet Propulsion Laboratory California Institute of Technology Pasadena, California Costin Radulescu Senior Member Technical Staff Registry Standards and Technology Infusion Ground System Architectures Workshop March 31, 2008 87 – 3/19/2018
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • Overview Role of the Registry Key Features Need for Governance Standards-based Registry/Repository Choosing a Registry Summary GSAW 2008: Achieving Operationally Responsive Ground Systems 88
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • What is a SOA Registry? Largely, SOA promises IT organizations two things: – Increased Efficiency – Increased Agility. Loose coupling enable rapid service evolution. Increased reuse of existing components to build new ones. The Registry is that piece of SOA infrastructure which manages, shares and tracks information about services and related artifacts. GSAW 2008: Achieving Operationally Responsive Ground Systems 89
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • Functions of the Registry Describe, deploy and discover services through rich metadata management. Classification and association. Rich query capability. Ensure data consistency within an organization. GSAW 2008: Achieving Operationally Responsive Ground Systems 90
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • Business Value Promotes reuse at the macro level (service) Simplify connection to - and usage of - existing IT assets (legacy) Improves flexibility, interoperability and consistency – Reduces maintenance by reducing overall system integration complexity. – Quickly re-aligns to customer needs since the system is a set of flexible and interoperable software elements. – Better standardizes system construction with reusable services built once. GSAW 2008: Achieving Operationally Responsive Ground Systems 91
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • Key Features of the Registry Standards – Provides standards-based way to manage information assets Classification and Affiliation – Manages user-define relationships between content and metadata. Validation – Policy enforcement throughout an asset’s lifecycle. Cataloging and rich query – Flexible mechanism for content discovery Notification – Facilitates Event-based delivery of information to appropriate personnel or system (part of eb. XML and UDDI_V 3). Federation – Enables integration of information assets across organizational boundaries. GSAW 2008: Achieving Operationally Responsive Ground Systems 92
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • Governance: 1. 2. 3. • Organizational Policies and Governance Policies by which an organization functions Process through which we ensure compliance to the organizational polices. Ensure consistency and predictability in applying organizational policies across the SOA deployment Registry provides a single point of control within SOA that provides governance of service components and related assets. GSAW 2008: Achieving Operationally Responsive Ground Systems 93
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • Integrated SOA Registry/Repository Registry stores metadata about an artifact along with associated links or pointers to the artifact. – Makes the actual artifact ungovernable by the registry – A common metaphor to describe this: • • • A library that maintains only a card catalog, with no books. The books would be kept in people’s homes. A Registry-Repository solution maintains not only the metadata related to an artifact but also the artifact itself. Validation (automatic) - Key to governance – Policy enforcement throughout an asset’s lifecycle. – Automatically upon publishing or change/update. GSAW 2008: Achieving Operationally Responsive Ground Systems 94
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • Federated architecture The Goal: – Appearance of a single “corporate” registry-repository while allowing individual organizations regional control over their realms (sub-registries) – link and share information Federated Policy Management – eb. XML (OASIS standard) supports federated policy management Federated Identity management: – i. e. using open standards such as Security Assertions Markup Language (SAML) GSAW 2008: Achieving Operationally Responsive Ground Systems 95
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • Which registry is right for me? Most SOA registry deployments fall within the following: – UDDI registry (OASIS standard) with a proprietary repository • Often used in organizations which used SOA for a while and evolve through UDDI’s t. Model extensions – eb. XML Registry-Repository (OASIS standard) • Lately it picked up momentum in the industry, but fairly heavy weight, if not used properly – Combination UDDI/eb. XML • Used by new SOA adaptors which want the wide acceptance of UDDI combined with eb. XML standard features. – Proprietary registry-repository deployments • Buyer be aware: Federated SOA deployments require standards-based approach. GSAW 2008: Achieving Operationally Responsive Ground Systems 96
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • Piloting activities Evaluate COTS Registry implementations of the two SOA Registry Standards available today: (UDDI and eb. XML) – Universal Description Discovery & Integration (UDDI) • Web Services centric • COTS product evaluated: Systinet (by HP) - UDDI compliant + Repository component. – Electronic Business using e. Xtensible Markup Language (eb. XML) • Core component for organizations doing business over the Internet. • COTS product evaluated: Software AG X-registry (aka Infravio/web. Methods X-registry) eb. XML compliant, however, heavily integrated as part of more comprehensive SOA suite offering. GSAW 2008: Achieving Operationally Responsive Ground Systems 97
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • Summary Today’s SOA deployments are increasingly more complex and require a standards based registry-repository infrastructure component. Governance is key to enforcing organizational policies An integrated registry-repository is needed to achieve complete asset governance Federated information management is required to achieve complete enterprise integration. GSAW 2008: Achieving Operationally Responsive Ground Systems 98
Jet Propulsion Laboratory California Institute of Technology National Aeronautics and Space Administration Introduction to Information Architecture Jet Propulsion Laboratory California Institute of Technology Pasadena, California Dan Crichton Program Manager Planetary Data Systems Engineering Office Ground System Architectures Workshop March 31, 2008 99 – 3/19/2018
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • Outline Basic definitions and concepts Core Concepts – Information Modeling – Metadata and Standards – Information-oriented Services CCSDS Reference Architecture for Space Information Management Planetary Data System Example Conclusion GSAW 2008: Achieving Operationally Responsive Ground Systems 100
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Information Architecture • “Information architecture involves the design of organization, labeling, navigation, and search systems to help people find and manage information more successfully. ” [Rosenfeld, Louis. Information Architecture for the World Wide Web. O’Reilly 1998). • “Just as with infrastructure in the larger society, the benefits of an infrastructure for an organization, as well as its healthy evolution, generally depend on content, mechanisms for agreeing on standards, and a range of common services for enriching connectivity for all to use and build on. We are calling this structure information architecture. ” [Lawrence Livermore Labs IA Program http: //www. llnl. gov/projects/ia/library/iareport/intro. html] • “Enterprise information architectures provide a framework for reducing information system complexity and enabling enterprise information sharing. There are significant technology benefits that flow out of of an enterprise information architecture such as reducing data and software redundancy and facilitating the movement to new technology. ” [Cook, Melissa. Building Enterprise Information Architectures. 1996] GSAW 2008: Achieving Operationally Responsive Ground Systems 101
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • Information Architecture Definitions Cont… “Enterprise Information Architecture extends beyond organizational boundaries to external sources and targets to enable rapid business decision making and information sharing. EIA also includes: 1) a catalog of authentic information sources (e. g. company databases, commercial databases, …); 2) classes of relevant business information and their value to the enterprise; 3) information governance processes to support policy development and information management principles/practices that address security access, privacy, confidentiality, information quality, integrity, authenticity, archival cycles, business resumption planning, and ownership; and 4) the roles and organizational structure for managing content and delivery”. [Meta Group: http: //www. metagroup. com] GSAW 2008: Achieving Operationally Responsive Ground Systems 102
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • Metadata • Key Definitions Schema • – – is used generally to designate a set of semantic units along with their attributes, such as name, identifier, definition, or relationship to other semantic units [derived from SCHEMAS] Example: Dublin Core element set Data Element – – • is “structured data” that contains definition or description about other data [derived from SCHEMAS] Examples: “Title”, “Author”, and “Subject” of a book is a unit of data for which the definition, identification, representation and permissible values are specified by means of a set of attributes [ISO/IEC 11179] Examples: “Identifier”, “First Name”, or “TARGET ID”. Information Model – An abstract, but formal representation of entities including their properties and relationships…The main driving force behind the definition of an information model is to provide formalism to the description of a problem domain without constraining how that description is mapped to an actual implementation in software. [derived from Wikipedia] GSAW 2008: Achieving Operationally Responsive Ground Systems 103
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Emerging Trends in Managing Information Centralized Data No explicit, shared information models Distributed Service Architectures Model-Driven Data System Maturity Small # of Projects/Data Volume Large # of Projects/Data Volume Basic Data Capture Data Location Data Product Exchange/ Infrastructure Interoperability - Data Acquisition - Catalog Systems - Metadata - Heterogeneous Servers - Databases - Data sets - Distributed Data sets - Data Interchange - Data Analysis - Data Products - Distributed Services - Data Sharing Tools - Metadata - Distributed Architectures - Homogeneous - Standards-based Frameworks & Computing COTS Middleware GSAW 2008: Achieving Operationally Responsive Ground Systems 104
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Applicability of Shared IA GSAW 2008: Achieving Operationally Responsive Ground Systems 105
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Multi-Discipline Interoperability GSAW 2008: Achieving Operationally Responsive Ground Systems 106
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • Data vs Technology Architecture Separate the data from technology architecture Data architecture provides mechanisms for describing data – Data semantics: Data dictionary, taxonomies, vocabularies, etc – Data models: Provide organization of the semantics – Domain oriented Technology architecture provides – Services and infrastructure to create information systems – Leverage the data architecture – Framework for plugging applications together GSAW 2008: Achieving Operationally Responsive Ground Systems 107
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • Agenda Basic definitions and concepts Core Concepts – – Architectural Concepts Information Modeling Metadata and Standards Information-oriented Services CCSDS Reference Architecture for Space Information Management Planetary Data System Example Conclusion GSAW 2008: Achieving Operationally Responsive Ground Systems 108
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Architecture Distinction • Separate the information architecture and the software architecture • Core services, built on distributed standards, form the basis for serviceoriented architectures – Develop these services to support the exchange of information objects CCSDS Reference Architecture for Space Information Management, Green Book, 2006. GSAW 2008: Achieving Operationally Responsive Ground Systems 109
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • Info Architecture Core* Information Objects – An information object consists of a data object and one or more metadata objects – A data object is a sequence of bits without any representation information. Our focus is on “digital” data objects rather than “physical” data objects – 1. Information Objects A metadata object is representation information used to describe something like a data object • Information Models – A formal representation of objects and their relationships – Allows for specialization of information objects within a domain • Meta Models – A meta-model is simply a model that prescribes another model. Meta models are useful for normalizing the definition of object models * Achieving Operationally Responsive Ground Systems GSAW 2008: CCSDS Reference Architecture for Space 2. Information Models 3. Meta Models Information Management 110
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Example: Domain Information Object Model Conceptual Model Information Object Data Dictionary Defines… Data Elements Implements Data set schema Vocabulary <TITLE> Cassini Saturn Image </TITLE> <Mime. Type> Image/JPEG <Mime. Type> <Resource Location> http: //… </Resource Location> Metadata Object (derived from a common meta model) <TARGET_NAME> Saturn </TARGET_NAME> <SPACECRAFT_NAME> Cassini </SPACECRAFT_NAME> Data Element Model (ISO 11179) Describes… Data Object GSAW 2008: Achieving Operationally Responsive Ground Systems 111
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • Modeling Concepts An Information Object is prescribed by a domain model which is prescribed by a meta model Domain models model relationship and attributes for a particular domain – Implemented with a meta model – Identify objects and attributes within the domain – Are necessary for describing domain information GSAW 2008: Achieving Operationally Responsive Ground Systems 112
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • Meta Models Meta models are useful for normalizing the definition of object models. For example, – All data dictionaries can be described by a common meta model (E. g. DEDSL, ISO 11179) – Software models can be described by a common meta model (i. e. UML) – Software interfaces to applications can use common meta models to enable exchange of objects across domains • Projects and enterprises need to identify and define common meta models for its architecture and standards specifications. GSAW 2008: Achieving Operationally Responsive Ground Systems 113
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • SOA-based Architectural Model Service-Oriented, event-driven Architecture Common Meta Model for Communication (e. g. , common XML-based schema(s)) – Meta model can be instantiated for a domain implementation (e. g. , specific GDS) Core Information Mgmt components – Registry class services – Repository class services Registry Services Message Bus Repository Services -Common Meta Model supports exchange of information objects GSAW 2008: Achieving Operationally Responsive Ground Systems 114
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California REST Model Service. Server Name Registry Name Server Web I/F WSDL XML Request Information Object Registry 1 Node Server Node 1 Profile Server Node Server Profile 1 Profile Server Resource Catalogs XML Request Desktop I/F Query Integration Information Object XML Request Information Object Repository Services Sci/Eng Products Example: Science Data Systems (e. g. , Planetary Data System) GSAW 2008: Achieving Operationally Responsive Ground Systems 115
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • Agenda Basic definitions and concepts Core Concepts – – Architectural Concepts Data and Information Modeling Metadata and Standards Information-oriented Services CCSDS Reference Architecture for Space Information Management Planetary Data System Example Conclusion GSAW 2008: Achieving Operationally Responsive Ground Systems 116
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Data Modeling Theory • Zachman Framework - Perspectives on Data Focus* – a Contextual data model (list) identifies entity classes (representing things of significance to the organization). – a Conceptual data model (semantics) defines the meaning of the things in an organization. This consists relationships (assertions about associations between pairs of entity classes). – a Logical data model (schema) describes the logic representation of the properties without regard to a particular data manipulation technology. This consists of descriptions of the attributes (role a data element plays in relation to the thing (entity) it represents. – a Physical data model (blueprint) describes the physical means by which data are stored. This is concerned with partitions, CPUs, tablespaces, and the like. – a data definition (configuration) This is the actual language coding of the database schema in the chosen development platform – a data instantiation holds the values of properties applied to the data in the schema • At an enterprise-level, we are particularly interested in the contextual and conceptual model. For this presentation, data and information modeling will refer to this level. From Zachman Framework Perspectives on Data Focus * From Wikipedia on data modeling GSAW 2008: Achieving Operationally Responsive Ground Systems 117
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • Data Modeling in context We think of a data model as abstract model that describes how data is represented and used. A planetary scientist working on the NASA PDS has described a data model as “the organization of the metadata and structure of the data”. A Data Model is transformed into an Information Model by adding additional* relationships or “meaning”. PDS Image Class (Object-Oriented) PDS Image Label (ODL) Describes An Image * The boundaries are vague since what may be considered data to one might be information to another. -- The Flexible Image Transport System (FITS) specification is what most would consider to be data model. GSAW 2008: Achieving Operationally Responsive Ground Systems 118
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • What is an Information Model? We think of an Information Model as a type of Data Model. A data model is generally associated with simpler items such as data formats and data structures. An information model* can be thought of as a data model that has a richer set of relationships. These relationships add "meaning" and "change data into information". For example, associating a image description with an image map projection could be considered to be adding meaning. Labeled Image Registered to Image Map Projection * The Planetary Data System (PDS) has what many would consider an Information Model since its data format models are related to other models to add meaning. GSAW 2008: Achieving Operationally Responsive Ground Systems 119
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Why are information models critical? • The information model is the foundation on which an information system is built. • The development and the subsequent management of the Information Model is one of the most significant factor for developing successful enterprise-scale information systems on time, within budget, and that remain viable over time. • Information models need to be part of the development lifecycle, and in fact, should ultimately drive the software GSAW 2008: Achieving Operationally Responsive Ground Systems 120
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Models need to be appropriate for the viewpoint of the system such as: Viewpoint Data Technology Process Architect/Modeler Ontology Model Component Architecture/Diagram Process Flow DBA/Database Developer Entity-Relationship Model Technology Architecture Transaction Management Component Developer Object Data Model UML Class Diagram Web Developer Taxonomy Data Engineer/Curator Data Dictionary, XML Schema Specification GSAW 2008: Achieving Operationally Responsive Ground Systems Information management guides 121
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • Goals in Information Model Development for Complex Science and Engineering Domains Present an information model development and management framework that includes methodologies and tools that address the following across geographical, political, and domain boundaries. 1. 2. 3. 4. 5. Develop information models for diverse and complex domains Maintain the information model independent of system implementation choices. Test the information model and use to drive documentation and implementation efforts. Manage continuous evolutionary changes to the information model. Enable and maintain interoperability between domains. GSAW 2008: Achieving Operationally Responsive Ground Systems 122
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Information Modeling Approaches • Several techniques have been used object, object-relational, hierarchical, etc • The key challenge is capturing an abstract model that can be useful to the domain. How that model is captured, continues to be a challenge – Entity Relationship • Good for database level concepts and expression of a model – Unified Modeling Language • Widely acceptable notation – Ontology Management • Lots of flexibility, but lacks notation GSAW 2008: Achieving Operationally Responsive Ground Systems 123
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • The purpose of an ontology is simply to answer the question, "what is ___? ", as in "what is a Viking Image? ". – – • Ontology Management The ontological answer to “what is a Viking image” is a collection of metadata that formally describes a Viking image sufficiently for some stated purpose. An ontology typically allows for the formal specification of object-oriented concepts such classes and their attributes and relationships. An ontology modeling tool is used to build an ontology and is designed to help a user convert unstructured intuitive knowledge into a formal specification that describes "things". GSAW 2008: Achieving Operationally Responsive Ground Systems 124
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Information Models are Cross-cutting • The information captured in the formal specification needs to address information system requirements that have been levied on the “things” that an information system manages. • Within Space Data Systems* the requirements that dictate what “things” and how completely those “things” are to be modeled can be derived from several viewpoints. – Enterprise • Business Concerns, Organizational perspective – Connectivity • Physical Concerns, Node & Link perspective – Functional • Computational Concerns, Functional composition – Information • Data Concerns, Relationships and transformations – Communications • Protocol Concerns, Communications stack perspective • The Information viewpoint is often the initial focus but all viewpoints can be and probably should be considered. * Reference Architecture for Space Data Systems (RASDS) GSAW 2008: Achieving Operationally Responsive Ground Systems 125
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • Capturing Ontologies Ontology Modeling Tool GUI – Image Class Definition GSAW 2008: Achieving Operationally Responsive Ground Systems 126
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Testing • Ingesting data into the ontology results in a knowledge base. – Ensures that the definition of an ”individual” correctly describes all possible individuals. – Configure simple, full-capability “database” application for design testing. • User Queries • System Queries • Navigation path analysis for optimization. • Semantic technologies can process and reason about the model – “Triple” database engines provide both unfettered and schema guided access to both data and metadata. – Semantic browsers provide both text- and facet-base search and guided navigation through the knowledge base. – Development frameworks are available for configuring custom GUI applications. – Semantic technologies such as “reasoners” provide sophisticated analysis. E. g. consistency checking. GSAW 2008: Achieving Operationally Responsive Ground Systems 127
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Manage Change • Configuration Management of the model – Governance structure • Consider multiple levels within the model (enterprise to sub-system/component); existing models can be used (Dublin Core, etc) • Namespace management can help with the governence process – Schema changes – Version Control – Test data – Change logs • Application compliance – Applications are configured based on the model versions – Decisions of run-time, build-time, design-time need to be considered • Obviously run-time offers quite a bit of flexibility GSAW 2008: Achieving Operationally Responsive Ground Systems 128
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • Agenda Basic definitions and concepts Core Concepts – – Architectural Concepts Information Modeling Metadata and Standards Information-oriented Services CCSDS Reference Architecture for Space Information Management Planetary Data System Example Conclusion GSAW 2008: Achieving Operationally Responsive Ground Systems 129
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • Why Focus on Metadata? Focuses on the Data Architecture Metadata is data about data Provides descriptive information about the data – Classification, identification, etc – Classified as: • • • Data Element (ISO 11179 definition) Data Values (E. g. MISSION_NAME) Identifies the domain and context Metadata is critical to enabling interoperability and building enterprise applications – Data sharing – Building new systems – Turning data into information and knowledge What if I told you I was using username in my application. Which one am I talking about? From where? GSAW 2008: Achieving Operationally Responsive Ground Systems 130
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Metadata Concepts and Approaches • Controlled Vocabularies – Need agreed upon terms that are controlled by a registration authority • Taxonomy – A collection of controlled vocabulary terms built into a hierarchical (or poly-hierarchical) structure with parent-child relationships – NASA Taxonomy – start defining “gold standard” sources for core data classes • Built from a controlled vocabulary – Mission Domains • Earth Science • Space Science • Human Exploration • Data Element – Defines a concept and its set of permissible values (aka Spacecraft Name) – Used to form data dictionaries – Dublin Core is an Internet recommendation of 15 data elements useful for describing any electronic information GSAW 2008: Achieving Operationally Responsive Ground Systems 131
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Metadata Standards • The Dublin Core element set (Meta Level Attributes) • ISO/IEC 11179 (Meta-Meta Level Attributes) – – Is intended to facilitate discovery of electronic resources Has a simple information resource description format Has received wide spread acceptance amongst the electronic information community Is used by Metadata Registry to describe the registered data dictionaries – Is a widely accepted standard that provides the basis for data element definition and classification. – Describes the specification of a registry for managing metadata to ensure that the representation of relevant characteristics is consistent and accurate. – Is designed to foster the exchange of metadata between members of the information technology community. GSAW 2008: Achieving Operationally Responsive Ground Systems 132
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Domain Data Element (11179 -based) GSAW 2008: Achieving Operationally Responsive Ground Systems 133
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • Agenda Basic definitions and concepts Core Concepts – – Architectural Concepts Information Modeling Metadata and Standards Information-oriented Services CCSDS Reference Architecture for Space Information Management Planetary Data System Example GSAW 2008: Achieving Operationally Responsive Ground Systems 134
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • Conceptual Information Management Functions Registry Services – Registry of “objects” within the enterprise • • • Schemas and dictionary definitions including standard domain and local models Service registries Standard values – Enable discovery of information as well as dynamic configuration • Repository Services • Generalized Registry and Repository Services form the basis for constructing distributed, information services – Access and capture information objects – Short term & long term persistent storage of information objects GSAW 2008: Achieving Operationally Responsive Ground Systems 135
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Registry Services Description • Metadata Registry (Sometimes referred to as a CMR) – Data dictionary ingestion and management – Data element relationship management – Schema management (e. g. , XML artifacts, etc) – Namespace Management • Resource Registry – Manages standard values • Service Registry – Manages service entry points CCSDS Registry Decomposition eb. XML Registry Architecture and Standards GSAW 2008: Achieving Operationally Responsive Ground Systems 136
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • Metadata Registry Efforts at other Agencies Environmental Protection Agency: Environmental Data Registry (http: //www. epa. gov/edr) IEEE Intelligent Transportation Systems Data Registry (http: //standards. ieee. org/regauth/its/index. html) U. S. Census Bureau Corporate Metadata Repository Department of Transportation Department of Energy Bureau of Labor Statistics National Cancer Institute Common Data Element (CDE) (http: //cii-server 5. nci. nih. gov: 8080/pls/cde_public/cde_java. show) … Note: Information from various sources including http: //hmrha. hirs. osd. mil/mrc/White. Paper. html GSAW 2008: Achieving Operationally Responsive Ground Systems 137
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • Repository Services Repository services provide for the management of information objects, particularly, within a distributed system – Store information object – Get information object – Transform information object • Within science data systems, for example, these are core functions which allow for the storage, transformation and retrieval of science data sets, products and subset. Transformations add higher order processing on such objects. GSAW 2008: Achieving Operationally Responsive Ground Systems 138
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • Agenda Basic definitions Core Concepts – – Architectural Concepts Information Modeling Metadata and Standards Information-oriented Services CCSDS Reference Architecture for Space Information Management Planetary Data System Example Conclusion GSAW 2008: Achieving Operationally Responsive Ground Systems 139
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • CCSDS Reference Architecture for Space Data Systems End-to-end Information Management a core need within Space Data Systems – Common Data Architecture – Common Set of Information Management Services GSAW 2008: Achieving Operationally Responsive Ground Systems 140
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California CCSDS RASIM Architecture Layers • Information architecture models provide models for domains that capture relationships and attributes • Services are driven by the information models and their attributes – Defined by standard interfaces governed by meta models GSAW 2008: Achieving Operationally Responsive Ground Systems 141
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Data Intensive View of Planetary Data Pipeline Relay Satellite Spacecraft / lander Data Processing & Control Spacecraft and Scientific Instruments Data Archival & Distribution Data Archive Data Processing Data Acquisition and Command Planetary Science Infrastructure Data Access External Science Community Data/Information Distribution Data Analysis and Modeling Mission Operations Instrument /Sensor Operations Planning GSAW 2008: Achieving Operationally Responsive Ground Systems Science Team Data Modeling Science Planning 142
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • Taxonomy of Information Objects based on concept of Application Information Object Various classes of information objects – Primitive Information Object – Those classes of objects which have no explicit descriptive metadata (E. g. Telemetry Packet) – Standard Information Object – Those classes of objects which have explicit descriptive metadata (E. g. Science observation such as an image) – Complex Information Package – information objects that encapsulate one or more information objects GSAW 2008: Achieving Operationally Responsive Ground Systems 143
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Mission Operations Architecture (IA View) Relay Satellite Simple Information Object Spacecraft / lander Spacecraft and Scientific Instruments Primitive Information Object Science Data Archive Primitive Information Object Science Information Package Science Data Processing Telemetry Information Package Science Information Package External Science Community Science Products Information Objects Science Information Package Data Analysis and Modeling Science Information Package Planning Information Object Instrument Planning Information Object Data Acquisition and Command Science Team Mission Operations Instrument /Sensor Operations • Common Meta Models for Describing Space Information Objects • Common Data Dictionary end-to-end GSAW 2008: Achieving Operationally Responsive Ground Systems 144
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Representative Functional Objects Space Information Management Functional Architecture Monitor & Control Mission Planning Data Objects Mission Analysis Directive Generation Query / Results Data Acquisition Directive Management Metadata / Resources Registry Service Domain Data Models Repository Service Information Management Functional Objects Query Service Product Service Local Data Models Common Schema & Dictionaries GSAW 2008: Achieving Operationally Responsive Ground Systems 145
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Critical Components: Registries & Repositories Registries Repositories GSAW 2008: Achieving Operationally Responsive Ground Systems 146
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • Agenda Basic definitions Core Concepts – – Architectural Concepts Information Modeling Metadata and Standards Information-oriented Services CCSDS Reference Architecture for Space Information Management Planetary Data System Example Conclusion GSAW 2008: Achieving Operationally Responsive Ground Systems 147
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Characteristics of space science missions • Often unique, one of a kind missions – Can drive technological changes • Instruments are competed and developed by academic, industry and industrial partners – Highly distributed acquisition and processing across partner organizations – Highly diverse data sets given heterogeneity of the instruments and the targets (i. e. solar system) • Missions are required to archive and distribute data with the NASA Planetary Data System (PDS) – PDS is chartered to ensure that data are archived and available to the scientific community • Work with projects to help design, generate, and validate data products for placement in archive • Develop data standards to ensure interoperability and future usability • Provide expert scientific help to the user community. • Lead peer-review to ensure data quality • Distributed archive managed by the community – PDS is a nationally distributed federation with international partners • Data and services are located with the scientific expertise GSAW 2008: Achieving Operationally Responsive Ground Systems 148
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Organization of PDS GSAW 2008: Achieving Operationally Responsive Ground Systems 149
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Emerging Architecture of the PDS • A common “information architecture” is critical to the function of the PDS • Common distributed information services infrastructure that connects PDS data nodes – The PDS model is the “core” of the PDS – Data standards are enabling interoperability – – End-user transparency from the data PDS-wide search of data holdings Ability to keep data distributed Common software/service architecture • • Initially implemented in 2002 Movement towards full SOA for common and domain-specific services in 2008+ GSAW 2008: Achieving Operationally Responsive Ground Systems 150
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California PDS Data Model: At the “core” of the PDS • Cross-disciplinary model applied to all missions using the PDS – Community developed – Planetary Science Data Dictionary – Planetary Community Model – Standard structural specifications for products, data sets, volumes, etc supported by the model • Increasing awareness by the scientists and within the broader data system community that tools and software should be driven by the model – Scientists buy-in has been critical to supporting the governance of the model – Correlative search across missions and projects – International interoperability GSAW 2008: Achieving Operationally Responsive Ground Systems 151
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California PDS Model vs System • Information models are seldom developed or managed over time with the rigor afforded to software development and management. • The Planetary Data System has had multiple system implementations over the past 20 years – – However, the model has evolved to support those domains The fact that the model is independent of any implementation has been critical to supporting this evolution GSAW 2008: Achieving Operationally Responsive Ground Systems 152
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California 2001 Mars Odyssey: A paradigm change • Pre-Oct 2002, no unified view across distributed operational planetary science data repositories – Science data distributed across the country – Science data distributed on physical media – No common set of services for access • Planetary data archive increasing from 4 TBs in 2001 to 50 TBs in 2007 – Traditional distribution infeasible due to cost and system constraints – Mars Odyssey could not be distributed using traditional method • Current work with the JPL OODT Data Grid Framework has provided the technology for NASA’s planetary data management infrastructure to – Common set of services distributed across the PDS – Support online distribution of science data to planetary scientists (up to 500 MB products) – Enable interoperability between nine institutions – Support real-time access to data products – Provided uniform software interfaces to all Mars Odyssey data allowing scientists and developers to link in their own tools – Operational October 1, 2002 GSAW 2008: Achieving Operationally Responsive Ground Systems 2001 Mars Odyssey 153
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California PDS Discipline and Data Nodes Mars Odyssey THEMIS/ASU Data Node Geosciences/Washington University Rings/SETI Radio Science/Stanford Small Bodies/UMD Planetary Plasma/UCLA Imaging/JPL MROHi. RISE/Uof. A Data Node Imaging/USGS Atmospheres/ NAIF/JPL New Mexico Achieving Operationally Responsive Ground Systems State Engineering/JPL GSAW 2008: NOTE: Lunar data node is next 154
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Product Server Components GSAW 2008: Achieving Operationally Responsive Ground Systems 155
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California International Interoperability • NASA/PDS and ESA/PSA have worked closely together to coordinate archiving activities for current missions (e. g. , Huygens, Mars Express, Venus Express) – This has led to ESA PSA/NASA PDS collaborating on an international strategy for planetary science data archiving to: • Give scientific communities worldwide access and services to data archives built from similar standards • Reduce cost of archiving and distributing science data by collaborating and sharing standards • Ensure reusability of science data across agency/mission/instrument boundaries • Coordinate archiving processes and plans • Improve and increase services offered • In 2006, the International Planetary Data Alliance was established which includes participation from major space agencies around the world GSAW 2008: Achieving Operationally Responsive Ground Systems 156
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • Capture PDS Data Model Upper Level PDS Data Model (PDS Catalog) – Data Sets, Instruments, Missions, etc – Model information extracted from data dictionary – Hardcopy documentation used to complete the model and add descriptive narrative Product Model – Basic data objects as extracted from data dictionary. (Image, Time Series, etc) – Product types as extracted from products in the archive. – Product types vary widely by missions Produce an IPDA Data Model – Data Dictionary of Terms – Standard Data Formats – Model of Objects and their Relationships – Expressed in a formal notation GSAW 2008: Achieving Operationally Responsive Ground Systems Ontology Modeling Tool UML Model 157
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • Agenda Basic definitions Core Concepts – – Architectural Concepts Information Modeling Metadata and Standards Information-oriented Services CCSDS Reference Architecture for Space Information Management Planetary Data System Example Conclusion GSAW 2008: Achieving Operationally Responsive Ground Systems 158
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Conclusion • Define information architecture independent of the technology architecture • Data owners move towards being service providers • Information models need by managed for their discipline – – – – Model-driven to support dynamic change Common semantics Common structures Needs to have an enterprise view Common interfaces described by well known meta models Common discipline information models Requires a solid governance model to manage change – They need to be expressed in forms that are useful to their community of users GSAW 2008: Achieving Operationally Responsive Ground Systems 159
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California References 1. H. Wache, T. Vogele, U. Visser, H. Stuckenschmidt, G. Schuster, H. Neumann and S. Hubner , Ontology. Based Integration of Information — A Survey of Existing Approaches, Proceedings of IJCAI-01 Workshop: Ontologies and Information Sharing, Seattle, WA, 2001, Vol. pp. 108 -117 2. Information Models as a Basis for Ontologies, Ed Barkmeyer, NIST, Ontolog Forum, April, 2007 3. Planetary Science Data Dictionary Document, JPL D-7116, Rev. D. , Jet Propulsion Laboratory, California Institute of Technology, http: //pds. nasa. gov/tools/data_dictionary_lookup. cfm. 4. Planetary Data System, Standards Reference, March 20, 2006, Version 3. 7, JPL D-7669, Part 2, Jet Propulsion Laboratory, California Institute of Technology, http: //pds. nasa. gov/documents/sr/index. html 5. Draft International Planetary Data Alliance (IPDA) Information Model, IPDA Core Requirements Identication Team, June 29, 2007, Under revew, http: //planetarydata. org/projects/archivestandards/documents/data-model/information-model/international-planetary-data-alliance-ipdainformation-model. 6. S. Hughes, D. Crichton, S. Kelly, C. Mattmann, The Semantic Planetary Data System, PV-2005, The Royal Society, Edinburgh, 21 -23 November 2005, http: //www. ukoln. ac. uk/events/pv-2005 -final-papers/. 7. J. S. Hughes, D. Crichton, S. Kelly, C. Mattmann, J. Crichton, T. Tran, Intelligent Resource Discovery Using Ontology-Based Resource Profiles, Data Science Journal, Volume 4, 31 December 2005 171. 8. CCSDS Reference Architecture for Space Information Management, 2006. GSAW 2008: Achieving Operationally Responsive Ground Systems 160
Jet Propulsion Laboratory California Institute of Technology National Aeronautics and Space Administration SOA Maturity and Roadmap Jet Propulsion Laboratory California Institute of Technology Pasadena, California Steven Fonseca Chief Software Architect Deep Space Information Services Architecture Ground System Architectures Workshop March 31, 2008 161 – 3/19/2018
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • • Topics Adoption Approach Roadmap Development Methodology Overview Oracle SOA Maturity Assessment Framework GSAW 2008: Achieving Operationally Responsive Ground Systems 162
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Innovation Adoption Approach growth-oriented approach balanced approach Enterprise SOA Adoption* cost conscious approach * Adapted from Enterprise SOA Roadmap by Hack & Lindemann Productivity • • • There is considerable opportunity to tailor the rollout of a SOA solution Establish a SOA strategy early Sufficient planning is essential to choosing an adoption path that is right for the organization GSAW 2008: Achieving Operationally Responsive Ground Systems 163
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Roadmap Development Methodology Overview* 1. Strategic Determining Factors • • • Identify the business strategy and business requirements Identify the IT strategy and IT requirements Compare the enterprise strategy with enterprise SOA Assess the individual readiness to implement enterprise SOA Create a common understanding of enterprise SOA • • • Acquire an overview of the organization (business and IT) Document the business process and application landscape Document planned and budgeted projects Create a list of suggested service candidates Make an agreement on the relevance of services 2. Transparency to the Business and IT Landscape 3. Enterprise SOA Potentials Analysis 4. Enterprise SOA Design 5. Enterprise SOA Roadmap Definition GSAW 2008: Achieving Operationally Responsive Ground Systems * SAP Enterprise SOA Roadmap Methodology, Hack & Lindemann 164
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Roadmap Development Methodology Overview* 1. Strategic Determining Factors 2. Transparency to the Business and IT Landscape 3. Enterprise SOA Potentials Analysis • • • Enterprise SOA cost/benefit analysis Enterprise SOA potentials analysis Make an agreement on the potentials of services • • • Feasibility check of service candidates Create a schedule and plan the process of implementing the services Create an overview of the enterprise SOA design • • Analyze the restrictions Risk statements Roadmap with milestones Management summary 4. Enterprise SOA Design 5. Enterprise SOA Roadmap Definition GSAW 2008: Achieving Operationally Responsive Ground Systems 165
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • SAP Roadmap Methodology-Based – – – • • • SOA Roadmap Contents No two roadmaps are the same (SAP Consulting) SAP SOA roadmap has a 3 year planning window Work products of methodology phases aggregated into the roadmap document Business and IT strategy and requirements Description of the business (small-scale enterprise architecture modeling) – – Basic organizational information Architecture: application & process SOA maturity assessment Cost benefit analysis Enterprise SOA design Planned and budgeted project descriptions Service portfolio plan with buy-in commitments documented Service development process definition Risk assessment Schedule of major milestones Management summary GSAW 2008: Achieving Operationally Responsive Ground Systems 166
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California SOA Maturity Models • • • SOA maturity models define – A set of maturity levels – A set of practice areas from which maturity is assessed – Practices or characteristics indicative of a certain maturity level SOA Maturity Models provide – A systematic way to describe the AS-IS and TO-BE states of an enterprise SOA initiative – An anecdotally-based means of assessing progress – Practice guidance for a given maturity level Some maturity model selection factors – Do the practice areas emphasize aspects of the SOA initiative that are important to your organization? – Are the maturity definitions sufficiently descriptive for your purposes? – Do the practice areas line-up with how the organization thinks about its SOA initiative? – Can the model be readily reused or tailored? – Are the practice areas and maturity levels sufficiently granular? GSAW 2008: Achieving Operationally Responsive Ground Systems 167
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Oracle SOA Maturity Assessment Standard (5) Industrialized: Focus on business optimization – react and respond. Be a leader in the ecosystem. Enable the virtual enterprise with business insight, and real time information access (3) Enterprise: Focus on driving business improvement, automation, and change (1) Opportunistic: Find lowrisk small-duration projects where SOA will show greatest value to business people (4) Measured: Focus on real-time business and measurement with a view to enabling continuous improvement enterprise-wide (2) Systematic: Systematically apply SOA to existing projects across departments Maturity Practice Areas: Infrastructure, architecture, information & analytics, runtime management, infusion execution, finance & portfolios, people & organizations, governance GSAW 2008: Achieving Operationally Responsive Ground Systems 168
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Maturity levels Focus • • • GSAW 2008: Achieving Operationally Responsive Ground Systems Industrialized – focus on business optimization, react and respond. Be a leader in the ecosystem. Enable the virtual enterprise with business insight and real time information access Measured – focus on real-time business and measurement with a view to enabling continuous improvement enterprise-wide Enterprise – Focus on driving business improvement, automation, and change Systematic – systematically apply SOA to existing projects across departments Opportunistic – find low-risk small-duration projects where SOA will show value to business people 169
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California • • Oracle SOA Maturity Model Practice Areas Infrastructure Architecture Information & Analytics Operations Project Execution Finance & Portfolios People & Organization Governance GSAW 2008: Achieving Operationally Responsive Ground Systems 170
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Oracle SOA Maturity Model Architecture Practice Area Opportunistic (1) Systematic (2) Enterprise (3) 1. 2. 3. 1. 2. 3. 4. 5. 6. 7. Silos of infrastructure, applications across lines of business Informal cross application architecture collectives Clear view of enterprise architecture SOA strategy formulated SOA infrastructure and tooling standards in use across one of more departments Key industry standards identified, e. g. industry XML Initial SOA-based application reference architecture defined Enterprise-wide architectural audit completed SOA roadmap planning initiated Metrics to measure SOA adoption and success identified 4. Infrastructure and applications standardization across lines of business to address efficiency, and reduce fragility 5. Nascent EA group becomes active in driving SOA in development and business communities 6. Service identification, interface definition, service development guidelines defined 7. Candidate list of conceptual foundation services, business services, and data service identified at enterprise level based on existing projects 8. Scoring framework in place to evaluate investments based on adherence to SOA roadmap 9. Enterprise SOA platform strategy 10. Integration & security reference architectures 11. Cookbooks for SOA tools GSAW 2008: Achieving Operationally Responsive Ground Systems Deep understanding of business strategy in IT organization driven by EA 2. Strict enforcement of architectural standards 3. Metrics on process variances, changes, service reuse tracked 4. Application blueprints defined and in use 5. Guidelines for scoring projects for adherence to architectural policies and contribution to enterprise SOA in place 6. Projects scored for adherence to these guidelines 7. Clearly defined reference architecture covering applications, information, technology, security architectures 8. Business policies abstracted out of application code and captured as business rules which are available as services 9. Models for deciding what to repeat (patterns), what to share (service reuse) 10. Best practices coming together and being disseminated 171
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Oracle SOA Maturity Model Architecture Practice Area Measured (4) Industrialized (5) 1. Substantial project acceptance of EA 1. Adherence to architectural standards and formal 2. 3. practices and contribution to enterprise SOA Business processes and their supporting technologies be reused for efficiency and recombined for agility EA a power house for growth and alignment 3. 4. GSAW 2008: Achieving Operationally Responsive Ground Systems exception handling mechanisms in place Enterprise architecture fully transformed into business service delivery vehicle (i. e. a service and event driven enterprise), with SOA embodied across development, security, management, and operations Applications rationalized and migrated to services and composites Critical emphasis on a continuous improvement mindset and a culture of testing, learning, improving using business insight and adaptable processes 172
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Oracle SOA Maturity Model: AS-IS Versus TO-BE Maturity GSAW 2008: Achieving Operationally Responsive Ground Systems 173
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California Assessing the Deep Space Information Services Architecture Maturity BEA http: //www. bea. com/framework. jsp? CNT=index. htm&FP=/content/solutions/soa/ Architecture 1 Infrastructure 2 Operations 1+ Project Execution 1 Information & Analytics 1+ Organization 1+ Governance 1 Oracle http: //www. oracle. com/technologies/soa/center. html GSAW 2008: Achieving Operationally Responsive Ground Systems 174
Скачать презентацию Jet Propulsion Laboratory California Institute of Technology National
5f38520ba01776c074c844076a9deaf5.ppt