NIH | National Cancer Institute | NCI Wiki  

Error rendering macro 'rw-search'

null

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Service discovery and governance allows service developers to specify rich metadata about services. This enables better discovery, and governance of services.

Service discovery and governance help to accomplish the following.

Promote Service Reuse: The use of well defined service metadata promotes better discovery and reuse of services during design and run time. Service metadata includes information about service interactions and dependencies. It also includes a classification scheme for organizing services based on business objectives, domain, and usage. It also links services to all the supporting artifacts in the specification and provides a placeholder for conformance statements. This enables better reuse across the enterprise and eliminates redundancy.

Establish Service policies: Service policies help establish constraints on the service specifications and mandate an approach. Policies can be specified around governance, access control and other design and runtime constraints.

Provide Governance: This includes predefined templates, workflows, and governance policies for governing the service lifecycle as well as an approval and review process for service specifications and the ability to promote services through the stages of the service lifecycle.

Enable Better Discovery: Complex search offers a natural and user-friendly way to find services by progressively refining search results using a variety of criteria including attributes, artifacts, classification, usage scenarios, and dependencies. This includes runtime contract discovery, a powerful query mechanism that allows either the service orchestrator or a program to find the services that best fit the requirements of a given process. This increases both runtime and design time flexibility by enabling selection of services based on computable metadata.

The requirements listed above are derived from the following use cases:

  • caEHR: The caEHR project is developing service specifications and lacks the infrastructure to govern these services. Vendors and external implementations are expected to leverage the caEHR service specifications and there is currently no infrastructure that allows easy discovery and consumption of this information.
  • CBIIT Projects: CBIIT has adopted SOA. Service lifecycle management and governance are industry best practices for all organizations adopting SOA. Better service discovery and reuse improves productivity, avoids redundancy and makes it easier for the CBIIT enterprise architecture governance team to manage NCI's enterprise services portfolio.
  • Life Sciences: Service discovery based on a rich metadata and semantics of the underlying data play a critical role in developing research pipelines. Research pipelines are developed by connecting data and analytical services together to achieve a research objective.
  • Other National Initiatives: All EHR vendors and national initiatives rely on a services paradigm for integration and interoperability. A standardized services metamodel makes it easier for participating organization to discover and reuse services.
  • caGRID 2.0 Platform: The caGRID 2.0 Platform provides a runtime registry for service discovery. This service registry relies on a small subset of information for discovery. The semantic infrastructure provides a mechanism to leverage rich service and artifact metadata to extend this capability.

Functional Profile Group

  • 5.2.5.1 - Administer Services Sept. 6, 2010 Administer Services defines profiles for management of service metadata and service classification schems.
  • 5.2.5.2 - Analyze Services Sept. 6, 2010 Analyze Services defines profiles for service analysis, providing support for determining service interaction dependencies, service reuse, service conformance assessment, heterogeneous data interchange, service collaboration compatability, etc.
    • 5.2.5.2.1 - Analyze Sept. 6, 2010 The use of well defined service metadata promotes better discovery and reuse of services during design.
    • 5.2.5.2.2 - Reason Sept. 6, 2010 This category supports reasoning and using an OWL DL representation of models, and research and clinical data. This addresses a requirement from the BRIDG stakeholder communities. (BRIDG) explicitly called for this capability. This also addresses the CDISC requirement for ontologies
  • 5.2.5.3 - Search and Access Services Sept. 6, 2010 Search and Access Services defines profiles supporting the discovery and visualization of services.
    • 5.2.5.3.1 - Discover Sept. 6, 2010 A key function desired by virtually all stakeholders is the ability to query by example using an item from a model or vocabulary (e.g., data element, property, data type, constraint, relation, concept, etc.) to find equivalent and related elements defined anywhere in the knowledge repository. The response should provide an easily understood description of the degree and nature of the semantic convergence between the example item and responsive items.
    • 5.2.5.3.2 - Find Sept. 6, 2010
    • 5.2.5.3.3 - Runtime Contract Discovery Sept. 6, 2010 A powerful query mechanism that allows either the service orchestrator or a program to find the services that best fit the requirements of a given process. This increases both runtime and design time flexibility by enabling selection of services based on computable metadata.
    • 5.2.5.3.4 - Service Generation Sept. 6, 2010 Service generation is the ability to generate services from user defined service metadata. The semantic infrastructure provides this metadata and the platform leverages this metadata for service generation. The constraints and policies specified in the semantic infrastructure are inherited by the platform and are enforced as runtime policies.
    • 5.2.5.3.5 - Visualize Sept. 6, 2010 Given the complexity of the models in use, and the large number, users are constantly confronted with the problem of trying to gain an understanding of new domains not familiar to them. Visualizations of models and vocabularies are perceived as essential to this task. The requirement is to provide visualizations that are easy to navigate, that identify the contact points between models and between vocabularies and that allow users to seamlessly move from model constructs to data.
  • 5.2.5.4 - Service Governance and workflows Sept. 6, 2010 This includes predefined templates, workflows, and governance policies for governing the service lifecycle as well as an approval and review process for service specifications and the ability to promote services through the stages of the service lifecycle.
    • 5.2.5.4.1 - Governance Processes Sept. 6, 2010 The BIG Health vision brings a lot more stakeholders into the KR. Each of these has their own governance processes in respect to metadata and terminology. At a minimum the KR has to be aware of these processes, and their outcomes, to be able to express the status of metadata definitions and terminology concepts it contains. Some stakeholders expressed the wish to manage their governance processes within the KR.
    • 5.2.5.4.2 - Services Sept. 6, 2010 Users expressed requirements that suggest caBIG services are not sufficiently described to determine if they meets a user’s requirements or are interoperable with other services. These requirements are deemed applicable to future KR services.
  • 5.2.5.5 - Service Policies Sept. 6, 2010 Service policies help establish constraints on the service specifications and mandate an approach. Policies can be specified around governance, access control and other design and runtime constraints.
    • 5.2.5.5.1 - Access Control Policies Sept. 6, 2010 Service policies help establish constraints on the service specifications and mandate an approach. Policies can be specified around access control constraints.
    • 5.2.5.5.2 - Design Constraint Policies Sept. 6, 2010 Service policies help establish constraints on the service specifications and mandate an approach. Policies can be specified around design constraints.
    • 5.2.5.5.3 - Governance Policies Sept. 6, 2010 Service Oriented Architecture is an architectural paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. Consequently, it is important that organizations that plan to engage in service interactions adopt governance policies and procedures sufficient to ensure that there is standardization across both internal and external organizational boundaries to promote the effective creation and use of SOA-based services.
    • 5.2.5.5.4 - Runtime Constraint Policies Sept. 6, 2010 Service policies help establish constraints on the service specifications and mandate an approach. Policies can be specified around runtime constraints.
  • No labels