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

securitybusinesstechnical

service interface

metadata query

mechanism

data resource

data resource metadata

user

humanmachine

processing resource

processing resource metadata

rules processing engine metadata

identifies contact for

identifies contact for

identifies contact for

contributes to

contributes to

contributes to

provides conditions for

give constraint satisfaction results to

formally describe

describes

describes

describes

describes

provides formalism for

provides formalism for

describes

describes

metadata components

metadata components

invokes processing

extracts data values from

contributes to

type of

invokes services through

submits query to

provides annotation to

queries

queries

queries

queries

queries queries

type of

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 environmentThe 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