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 6 Next »

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

Capabilities supporting service discovery and governance may be summarized as:

  • Formalization of Governance Policy Models, with definition and enforcement of rules and regulations, compliance monitoring, and adaptive policies across operational environments. Governance capabilities include 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
  • Service descriptions for using, re-using, deploying, managing, discovering, validating, testing, versioning, configuring, migrating, analyzing, binding, measuring, assembling, organizing, and controlling services.
  • Policy models supporting creation, deletion, edit, maintenance, discovery of policy modules. Polcies help establish constraints on the service specifications.

Service discovery and governance also helps to accomplish the following.

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.

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.1.1 - Service Classification Schemes Sept. 6, 2010 A classification scheme for organizing services based on business objectives, domain, and usage
    • 5.2.5.1.2 - Service Metadata Sept. 6, 2010 A service description defines or references the information needed to use, deploy, manage and otherwise control a service. This includes not only the information and behavior models associated with a service to define the service interface but also includes information needed to decide whether the service is appropriate for the current needs of the service consumer. Thus, the service description will also include information such as service reachability, service functionality, and the policies and contracts associated with a service.
    • 5.2.5.1.3 - Transaction Management Sept. 6, 2010 An important class of joint service action is the business transaction, or contract exchange. Many interactions between participants in the SOA ecosystem are based around business transactions. A business transaction is a joint action engaged in by two or more participants in which the ownership of one of more resources is exchanged.
  • 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