Service

1. human machine security business technical queries metadata components metadata query mechanism queries data resource metadata submits query to queries type of queries queries describes rules language metadata invokes services through user type of queries rules metadata queries service interface service constraints data resource provides annotation to describes invoked through describes describes extracts data values from formally describe contributes to constraints metadata provides formalism for rules language rules Service contributes to describes provides formalism for give constraint satisfaction results to invokes processing Service metadata provides conditions for processing resource rules processing engine contributes to contributes to what Service is configuration management info describes describes contributes to identifies contact for service creation processing resource metadata who responsible for rules processing engine metadata part of identifies contact for identifies contact for creation / modification info service maintenance type of metadata components service deployment Ken Laskey 6 April 2005

2. Other notes and questions: • In the previous slide, the advertising/discovery aspect emphasizes metadata. To what extent is metadata a necessary/integral part of an SOA? • Mechanisms to produce/maintain/evaluate rules/policy are often alluded to but then conveniently ignored. This capability affects not only access and security but also choices for dynamically composable orchestration and data fusion of information obtained from multiple, independent resources. To what extent are mechanisms to support rules/policy (more generally, decision support) a necessary/integral part of SOA? • A distributed, composable system of independently generated and maintained resources will need mechanisms to support translating between corresponding vocabularies. We can assume the hard work of semantic negotiation (e.g. vocabulary mapping) is done outside the SOA but supporting mechanisms will likely be needed even without dynamic composability. To what extent are mechanisms to support semantic negotiation a necessary/integral part of an SOA? • If mechanisms to support semantic negotiation are part of an SOA, are mechanisms to facilitate capturing vocabulary use (e.g. input for vocabulary mappings) part of an SOA? • An SOA is a bit like a TC (well, a rather unruly one) in that you don’t control any of the resources but you try to control the overall outcome. For a TC, we keep minutes of meetings and maintain configuration control of our results. For an SOA, I see this as a system logging capability against which one could run audits, query for how tasks were performed (what resources, what order, what results), generate metrics. I could also see logs being in some sense “executable” so I can repeat processes. To what extent are mechanisms to support logging a necessary/integral part of an SOA? • Thoughts on capabilities(excerpted from soon to be published discussion of metadata and a net-centric/SOA environment • The Global Information Grid (GIG) Core Enterprise Services (CES) Strategy calls for “robust [GIG] enterprise services (GES) [to] provide visibility and access to data, enabling the end user to execute an intelligent pull of mission-tailored information from anywhere within the network environment.” Moreover, “the CESs provide the basic ability to search the DoD enterprise for desired information and services, and then establish a connection to the desired service/data.” • This vision describes an environment where the interaction between the providers and consumers of resources must be flexible and readily configurable across entities (consumers, providers, and resources) that had no previous knowledge that the others existed. This implies a number of capabilities that go beyond the traditional data and processing paradigm. • Consumers must be able to search for resources without knowing the details, such as specific APIs, of the resource beforehand. This implies that the description of the resource must be expressed in a universally accessible format and, though it will be associated with the resource, the description will be external to the resource so it can be accessed without reading or otherwise invoking the resource itself. • The external description must contain sufficient detail so the consumer can decide if the resource will satisfy the current need. • If the resource is appropriate, the consumer must be able to access the resource content or invoke the resource processing without knowing the APIs or other details of the resource. • If the consumer attempts to access the resource, sufficient information must be available about the consumer so that the provider or an agent acting for the provider can determine if the access is authorized. • The producer and consumer must share a common format for the description and must also agree on how to interpret the description content. This may be accomplished by indicating a common vocabulary or distinct vocabularies for which services exist to mediate a translation. Ken Laskey 6 April 2005