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

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. 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? Ken Laskey 6 April 2005