 |
Page History
| Wiki Markup |
|---|
{scrollbar}
{children}
h3. { |
| Scrollbar |
|---|
| Children Display |
|---|
page-info |
...
Summary
Description of the profile
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.
A workflow capability is deemed required to manage curation workflows and governance workflows.
Governance specializes capabilities architecturally implied by its associated concepts of Artifact , Governance , Management , Metrics , Policy . The implied architectural capabilities are described in the following paragraphs.
An artifact is a managed resource within the Semantic Infrastructure.
An artifact is associated with the following capabilities:
- descriptions to enable the artifact to be visible, where the description includes a unique identifier for the artifact and a sufficient, and preferably a machine processible, representation of the meaning of terms used to describe the artifact, its functions, and its effects;
- one or more discovery mechanisms that enable searching for artifacts that best meet the search criteria specified by the service participant; where the discovery mechanism will have access to the individual artifact descriptions, possibly through some repository mechanism;
- accessible storage of artifacts and artifact descriptions, so service participants can access, examine, and use the artifacts as defined.
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.
SOA governance requires numerous architectural capabilities on the Semantic Infrastructure:
Governance is expressed through policies and assumes multiple use of focused policy modules that can be employed across many common circumstances This is elaborated in the inherited Policy profile.
Governance requires that the participants understand the intent of governance, the structures created to define and implement governance, and the processes to be followed to make governance operational. This is provided by capabilities specialized from the inherited Management Profile.
Governance policies are made operational through rules and regulations. This is provided by the following capabilities, most of which are specializations of the inherited Artifact Profile:
- descriptions to enable the rules and regulations to be visible, where the description includes a unique identifier and a sufficient, and preferably a machine process-able, representation of the meaning of terms used to describe the rules and regulations;
- one or more discovery mechanisms that enable searching for rules and regulations that may apply to situations corresponding to the search criteria specified by the service participant; where the discovery mechanism will have access to the individual descriptions of rules and regulations, possibly through some repository mechanism;
- accessible storage of rules and regulations and their respective descriptions, so service participants can understand and prepare for compliance, as defined.
- SOA services to access automated implementations of the Governance Processes.
Governance implies management to define and enforce rules and regulations.. This is elaborated in the inherited Management profile.
Governance relies on metrics to define and measure compliance. This is elaborated in the inherited Metric profile.
Governance implies management to define and enforce rules and regulations.
Management is provided by the following capabilities:
- an information collection site, such as a Web page or portal, where management information is stored and from which the information is always available for access;
- a mechanism to inform participants of significant management events, such as changes in rules or regulations;
- accessible storage of the specifics of processes followed by management.
Artifact Descriptions include references to metrics which describe the operational characteristics of the subjects being described
Architectural implications of metrics on the Semantic Infrastructure are reflected in the following capabilities:
- access to platform infrastructure monitoring and reporting capabilities
- access to metrics information generated or accessible by related services
- mechanisms to catalog and enable discovery of which metrics are available for a described artifact and information on how these metrics can be accessed;
- mechanisms to catalog and enable discovery of compliance records associated with policies, contracts, and constraints that are based on these metrics.
Artifact Descriptions include references to policies defining conditions of use and optionally contracts representing agreement on policies and other conditions.
Architectural implications of policy on the Semantic Infrastructure are reflected in the following capabilities:
- descriptions to enable the policy modules to be visible, where the description includes a unique identifier for the policy and a sufficient, and preferably a machine processible, representation of the meaning of terms used to describe the policy, its functions, and its effects;
- one or more discovery mechanisms that enable searching for policies that best meet the search criteria specified by the service participant; where the discovery mechanism will have access to the individual policy descriptions, possibly through some repository mechanism;
- accessible storage of policies and policy descriptions, so service participants can access, examine, and use the policies as defined.
Policy capabilities are specialization of Artifact capabilities.
Capabilities
- complianceDiscovery
- discovery
- governanceService
- identity
- managementInformation
- managementNotification
- managementProcesses
- metadata
- metrics
- metricsDiscovery
- monitor
- provenance
- store
- workflowModel
Requirements traceability
...
Requirement
...
Source
...
Capability
...
Provide support for Curation Workflow Activities
...
...
Provide a means to visualize the models that have been loaded into the KR. The UML Model Browser displays the granular details of a model in list format, but there isn't away to visualize and navigate the whole model. The grid portal provides this feature from the metadata, there should be a way to do this when viewing models in the KR. This would enhance a potential new user’s ability to determine if they can use all or part of a model.
...
...
Provide a means to visualize the models that have been loaded into the KR. The UML Model Browser displays the granular details of a model in list format, but there isn't away to visualize and navigate the whole model. The grid portal provides this feature from the metadata, there should be a way to do this when viewing models in the KR. This would enhance a potential new user’s ability to determine if they can use all or part of a model.
...
...
Use business process workflow tool to automate the process of model submissions( and other related data) to the KR.
...
...
Provide workflow component modularization and customization
...
...
Application developers need to be able to easily use the infrastructure to create workflows without having to figure out how to integrate the data or services, the infrastructure should step them through it and just ask for things that are not already available
...
...
Behavioral dynamic models capture the behavior of services. Behavior of services provides an unambiguous definition of the service constraints, capabilities, dependencies and interactions. The metadata and grammar required to realize service behavior is called behavioral semantics. Behavioral semantics provide a mechanism for better service discovery and enforcing the constraints at design and runtime.
...
...
...
monitor from inherited abstract profile Metrics, metrics from inherited abstract profile Metrics, managementInformation from inherited abstract profile Management, managementNotification from inherited abstract profile Management, managementProcesses from inherited abstract profile Management, governanceService from inherited abstract profile Governance, discovery from inherited abstract profile Artifact, identity from inherited abstract profile Artifact, metadata from inherited abstract profile Artifact, store from inherited abstract profile Artifact,
...
...
discovery from inherited abstract profile Artifact, identity from inherited abstract profile Artifact, metadata from inherited abstract profile Artifact, store from inherited abstract profile Artifact, monitor from inherited abstract profile Metrics, metrics from inherited abstract profile Metrics, metricsDiscovery from inherited abstract profile Metrics, complianceDiscovery from inherited abstract profile Metrics,
...
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.
...
...
Service orchestration and choreography allows both application developers and non-developers to discover service "building blocks" that can be composed dynamically to provide business capabilities. Special cases include the orchestration of multiple services for a distributed query, or for a transactional workflow. Service orchestration and choreography will leverage static and behavioral semantics from the Semantic Infrastructure 2.0. The Semantic Infrastructure provides the behavioral semantics required for dynamic composibility of services or generation of distributed queries. This includes runtime contract discovery and negotiation to determine composibility of services based on service capabilities and constraints. Another use case is dynamic retrieval and enforcement of the policies that are in effect for a service interaction in the areas of logging, validations, data transformation, or routing. This information can be used either during the design of the orchestration or during the execution of the defined flow. Link to use case satisfied from caGRID 2.0 Roadmap: Federated query over the TCGA data and other data sets is performed using a service orchestration.
...
...
...
discovery from inherited abstract profile Artifact,
...
Description
Mechanisms to catalog and enable discovery of compliance records associated with policies, contracts, and constraints that are based on these metrics.
Requirements addressed
Overview of possible operations
...
Description
One or more discovery mechanisms that enable searching for artifacts that best meet the search criteria specified by the service participant; where the discovery mechanism will have access to the individual artifact descriptions, possibly through some repository mechanism.
Requirements addressed
Overview of possible operations
...
Description
SOA services to access automated implementations of the Governance Processes.
Requirements addressed
Overview of possible operations
...
Description
Descriptions which include a unique identifier for the artifact.
Requirements addressed
Overview of possible operations
...
Description
An information collection site, such as a Web page or portal, where management information is stored and from which the information is always available for access.
Requirements addressed
Overview of possible operations
...
Description
A mechanism to inform participants of significant management events, such as changes in rules or regulations.
Requirements addressed
Overview of possible operations
...
Description
Accessible storage of the specifics of processes followed by management.
Requirements addressed
Overview of possible operations
...
Description
A representation of the meaning of terms used to describe the artifact, its functions, and its effects.
Requirements addressed
Overview of possible operations
...
Description
Access to metrics information generated or accessible by related services
Requirements addressed
Overview of possible operations
...
Description
Mechanisms to catalog and enable discovery of which metrics are available for a described artifact and information on how these metrics can be accessed.
Requirements addressed
Overview of possible operations
...
Description
Access to platform infrastructure monitoring and reporting capabilities.
Requirements addressed
Overview of possible operations
...
Description
While the Resource identity provides the means to know which subject and subject description are being considered, Provenance as related to the Description class provides information that reflects on the quality or usability of the subject. Provenance specifically identifies the entity (human, defined role, organization, ...) that assumes responsibility for the resource being described and tracks historic information that establishes a context for understanding what the resource provides and how it has changed over time. Responsibilities may be directly assumed by the Stakeholder who owns a Resource or the Owner may designate Responsible Parties for the various aspects of maintaining the resource and provisioning it for use by others. There may be more than one entity identified under Responsible Parties; for example, one entity may be responsible for code maintenance while another is responsible for provisioning of the executable code. The historical aspects may also have multiple entries, such as when and how data was collected and when and how it was subsequently processed, and as with other elements of description, may provide links to other assets maintained by the Resource owner.
Requirements addressed
Overview of possible operations
...
Description
Accessible storage of artifacts and artifact descriptions, so service participants can access, examine, and use the artifacts as defined.
Requirements addressed
Overview of possible operations
...
:title} h4. Summary h5. Description of the profile 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. A workflow capability is deemed required to manage curation workflows and governance workflows. *Governance* specializes capabilities architecturally implied by its associated concepts of Artifact , Governance , Management , Metrics , Policy . The implied architectural capabilities are described in the following paragraphs. An artifact is a managed resource within the Semantic Infrastructure. An artifact is associated with the following capabilities: * descriptions to enable the artifact to be visible, where the description includes a unique identifier for the artifact and a sufficient, and preferably a machine processible, representation of the meaning of terms used to describe the artifact, its functions, and its effects; * one or more discovery mechanisms that enable searching for artifacts that best meet the search criteria specified by the service participant; where the discovery mechanism will have access to the individual artifact descriptions, possibly through some repository mechanism; * accessible storage of artifacts and artifact descriptions, so service participants can access, examine, and use the artifacts as defined. 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. SOA governance requires numerous architectural capabilities on the Semantic Infrastructure: _Governance is expressed through policies and assumes multiple use of focused policy modules that can be employed across many common circumstances_ This is elaborated in the inherited Policy profile. _Governance requires that the participants understand the intent of governance, the structures created to define and implement governance, and the processes to be followed to make governance operational. This is provided by capabilities specialized from the inherited Management Profile._ _Governance policies are made operational through rules and regulations. This is provided by the following capabilities, most of which are specializations of the inherited Artifact Profile:_ * descriptions to enable the rules and regulations to be visible, where the description includes a unique identifier and a sufficient, and preferably a machine process-able, representation of the meaning of terms used to describe the rules and regulations; * one or more discovery mechanisms that enable searching for rules and regulations that may apply to situations corresponding to the search criteria specified by the service participant; where the discovery mechanism will have access to the individual descriptions of rules and regulations, possibly through some repository mechanism; * accessible storage of rules and regulations and their respective descriptions, so service participants can understand and prepare for compliance, as defined. * SOA services to access automated implementations of the Governance Processes. _Governance implies management to define and enforce rules and regulations.._ This is elaborated in the inherited Management profile. _Governance relies on metrics to define and measure compliance._ This is elaborated in the inherited Metric profile. Governance implies management to define and enforce rules and regulations. Management is provided by the following capabilities: * an information collection site, such as a Web page or portal, where management information is stored and from which the information is always available for access; * a mechanism to inform participants of significant management events, such as changes in rules or regulations; * accessible storage of the specifics of processes followed by management. Artifact Descriptions include references to metrics which describe the operational characteristics of the subjects being described Architectural implications of metrics on the Semantic Infrastructure are reflected in the following capabilities: * access to platform infrastructure monitoring and reporting capabilities * access to metrics information generated or accessible by related services * mechanisms to catalog and enable discovery of which metrics are available for a described artifact and information on how these metrics can be accessed; * mechanisms to catalog and enable discovery of compliance records associated with policies, contracts, and constraints that are based on these metrics. Artifact Descriptions include references to policies defining conditions of use and optionally contracts representing agreement on policies and other conditions. Architectural implications of policy on the Semantic Infrastructure are reflected in the following capabilities: * descriptions to enable the policy modules to be visible, where the description includes a unique identifier for the policy and a sufficient, and preferably a machine processible, representation of the meaning of terms used to describe the policy, its functions, and its effects; * one or more discovery mechanisms that enable searching for policies that best meet the search criteria specified by the service participant; where the discovery mechanism will have access to the individual policy descriptions, possibly through some repository mechanism; * accessible storage of policies and policy descriptions, so service participants can access, examine, and use the policies as defined. Policy capabilities are specialization of Artifact capabilities. h5. Capabilities * [complianceDiscovery|#_16_5_1_24a0131_1283702219073_894098_3212] * [discovery|#_16_5_1_24a0131_1283714222600_103266_4106] * [governanceService|#_16_5_1_24a0131_1283718946661_463032_4374] * [identity|#_16_5_1_24a0131_1283714222601_506267_4107] * [managementInformation|#_16_5_1_24a0131_1283719206847_206279_4421] * [managementNotification|#_16_5_1_24a0131_1283719206849_873728_4422] * [managementProcesses|#_16_5_1_24a0131_1283719206851_835373_4423] * [metadata|#_16_5_1_24a0131_1283714222603_853936_4108] * [metrics|#_16_5_1_24a0131_1283702219069_775824_3210] * [metricsDiscovery|#_16_5_1_24a0131_1283702219071_411273_3211] * [monitor|#_16_5_1_24a0131_1283702219067_789210_3209] * [provenance|#_16_5_1_24a0131_1283793030699_512571_7056] * [store|#_16_5_1_24a0131_1283714222609_981432_4109] * [workflowModel|#_16_5_1_24a0131_1283112094907_297211_1904] h4. Requirements traceability ||Requirement||Source||Capability|| |Provide support for Curation Workflow Activities |Gap Analysis::Workflow::{anchor:_16_5_1_24a0131_1283089254843_804603_4467}000 - Provide support for Curation Workflow Activities|{li}[workflowModel|#_16_5_1_24a0131_1283112094907_297211_1904]{li}| |Provide a means to visualize the models that have been loaded into the KR. The UML Model Browser displays the granular details of a model in list format, but there isn't away to visualize and navigate the whole model. The grid portal provides this feature from the metadata, there should be a way to do this when viewing models in the KR. This would enhance a potential new user’s ability to determine if they can use all or part of a model. |Gap Analysis::Workflow::{anchor:_16_5_1_24a0131_1283089255407_169284_4470}015 - Authoring tools should automate the construction of workflows|{li}[workflowModel|#_16_5_1_24a0131_1283112094907_297211_1904]{li}| |Provide a means to visualize the models that have been loaded into the KR. The UML Model Browser displays the granular details of a model in list format, but there isn't away to visualize and navigate the whole model. The grid portal provides this feature from the metadata, there should be a way to do this when viewing models in the KR. This would enhance a potential new user’s ability to determine if they can use all or part of a model. |Gap Analysis::Workflow::{anchor:_16_5_1_24a0131_1283089255935_398923_4473}016 - Semantics describing workflows will be needed|{li}[workflowModel|#_16_5_1_24a0131_1283112094907_297211_1904]{li}| |Use business process workflow tool to automate the process of model submissions( and other related data) to the KR. |Gap Analysis::Workflow::{anchor:_16_5_1_24a0131_1283089256392_93500_4476}041 - Automate model submission process|{li}[workflowModel|#_16_5_1_24a0131_1283112094907_297211_1904]{li}| |Provide workflow component modularization and customization |Gap Analysis::Workflow::{anchor:_16_5_1_24a0131_1283089256991_302329_4479}135.3 - Modularization and Customization|{li}[workflowModel|#_16_5_1_24a0131_1283112094907_297211_1904]{li}| |Application developers need to be able to easily use the infrastructure to create workflows without having to figure out how to integrate the data or services, the infrastructure should step them through it and just ask for things that are not already available |Gap Analysis::Workflow::{anchor:_16_5_1_24a0131_1283089257413_959609_4482}155 - Create workflows|{li}[workflowModel|#_16_5_1_24a0131_1283112094907_297211_1904]{li}| |Behavioral dynamic models capture the behavior of services. Behavior of services provides an unambiguous definition of the service constraints, capabilities, dependencies and interactions. The metadata and grammar required to realize service behavior is called behavioral semantics. Behavioral semantics provide a mechanism for better service discovery and enforcing the constraints at design and runtime. |Semantic Infrastructure Requirements::Artifact Management::{anchor:_16_5_1_24a0131_1283090050000_56698_4488}Behavioral Models|{li}[workflowModel|#_16_5_1_24a0131_1283112094907_297211_1904 |
...
Description
Workflow Model maintenance
Application developers need to be able to easily use the infrastructure to create workflows without having to figure out how to integrate the data or services, the infrastructure should step them through it and just ask for things that are not already available
Authoring tools should automate the construction of workflows.
Provide workflow component modularization and customization
Use business process workflow tool to automate the process of model submissions( and other related data) to the KR.
Provide support for Curation Workflow Activities
Semantics describing workflows will be needed.
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.
Service orchestration and choreography allows both application developers and non-developers to discover service "building blocks" that can be composed dynamically to provide business capabilities. Special cases include the orchestration of multiple services for a distributed query, or for a transactional workflow. Service orchestration and choreography will leverage static and behavioral semantics from the Semantic Infrastructure 2.0.
The Semantic Infrastructure provides the behavioral semantics required for dynamic composibility of services or generation of distributed queries. This includes runtime contract discovery and negotiation to determine composibility of services based on service capabilities and constraints.
Another use case is dynamic retrieval and enforcement of the policies that are in effect for a service interaction in the areas of logging, validations, data transformation, or routing. This information can be used either during the design of the orchestration or during the execution of the defined flow.
Requirements addressed
- 016 - Semantics describing workflows will be needed
- 155 - Create workflows
- 015 - Authoring tools should automate the construction of workflows
- 041 - Automate model submission process
- 000 - Provide support for Curation Workflow Activities
- Service Governance and workflows
- Behavioral Models
- Service Orchestration and Choreography
- 135.3 - Modularization and Customization
Overview of possible operations
...
]{li}|
| |Semantic Profile::OASIS SOA::{anchor:_16_5_1_24a0131_1283763638521_214441_4616}Governance Model|{li}[monitor|#_16_5_1_24a0131_1283702219067_789210_3209] *from inherited abstract profile* Metrics{li}{li}[metrics|#_16_5_1_24a0131_1283702219069_775824_3210] *from inherited abstract profile* Metrics{li}{li}[managementInformation|#_16_5_1_24a0131_1283719206847_206279_4421] *from inherited abstract profile* Management{li}{li}[managementNotification|#_16_5_1_24a0131_1283719206849_873728_4422] *from inherited abstract profile* Management{li}{li}[managementProcesses|#_16_5_1_24a0131_1283719206851_835373_4423] *from inherited abstract profile* Management{li}{li}[governanceService|#_16_5_1_24a0131_1283718946661_463032_4374] *from inherited abstract profile* Governance{li}{li}[discovery|#_16_5_1_24a0131_1283714222600_103266_4106] *from inherited abstract profile* Artifact{li}{li}[identity|#_16_5_1_24a0131_1283714222601_506267_4107] *from inherited abstract profile* Artifact{li}{li}[metadata|#_16_5_1_24a0131_1283714222603_853936_4108] *from inherited abstract profile* Artifact{li}{li}[store|#_16_5_1_24a0131_1283714222609_981432_4109] *from inherited abstract profile* Artifact{li}|
| |Semantic Profile::OASIS SOA::{anchor:_16_5_1_24a0131_1283763560612_868976_4608}Service Description Model|{li}[discovery|#_16_5_1_24a0131_1283714222600_103266_4106] *from inherited abstract profile* Artifact{li}{li}[identity|#_16_5_1_24a0131_1283714222601_506267_4107] *from inherited abstract profile* Artifact{li}{li}[metadata|#_16_5_1_24a0131_1283714222603_853936_4108] *from inherited abstract profile* Artifact{li}{li}[store|#_16_5_1_24a0131_1283714222609_981432_4109] *from inherited abstract profile* Artifact{li}{li}[monitor|#_16_5_1_24a0131_1283702219067_789210_3209] *from inherited abstract profile* Metrics{li}{li}[metrics|#_16_5_1_24a0131_1283702219069_775824_3210] *from inherited abstract profile* Metrics{li}{li}[metricsDiscovery|#_16_5_1_24a0131_1283702219071_411273_3211] *from inherited abstract profile* Metrics{li}{li}[complianceDiscovery|#_16_5_1_24a0131_1283702219073_894098_3212] *from inherited abstract profile* Metrics{li}|
|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. |Semantic Infrastructure Requirements::Service Discovery and Governance::{anchor:_16_5_1_24a0131_1283090103606_857757_4560}Service Governance and workflows|{li}[workflowModel|#_16_5_1_24a0131_1283112094907_297211_1904]{li}|
|Service orchestration and choreography allows both application developers and non-developers to discover service "building blocks" that can be composed dynamically to provide business capabilities. Special cases include the orchestration of multiple services for a distributed query, or for a transactional workflow. Service orchestration and choreography will leverage static and behavioral semantics from the Semantic Infrastructure 2.0. The Semantic Infrastructure provides the behavioral semantics required for dynamic composibility of services or generation of distributed queries. This includes runtime contract discovery and negotiation to determine composibility of services based on service capabilities and constraints. Another use case is dynamic retrieval and enforcement of the policies that are in effect for a service interaction in the areas of logging, validations, data transformation, or routing. This information can be used either during the design of the orchestration or during the execution of the defined flow. Link to use case satisfied from caGRID 2.0 Roadmap: Federated query over the TCGA data and other data sets is performed using a service orchestration. |Semantic Infrastructure Requirements::caGRID 2.0 Platform and Terminology Integration::{anchor:_16_5_1_24a0131_1283090074514_588970_4530}Service Orchestration and Choreography|{li}[workflowModel|#_16_5_1_24a0131_1283112094907_297211_1904]{li}|
| |Semantic Profile::OASIS SOA::{anchor:_16_5_1_24a0131_1283763628053_328597_4610}Service Visibility Model|{li}[discovery|#_16_5_1_24a0131_1283714222600_103266_4106] *from inherited abstract profile* Artifact{li}|
h4. {anchor:_16_5_1_24a0131_1283702219073_894098_3212}complianceDiscovery
h5. Description
Mechanisms to catalog and enable discovery of compliance records associated with policies, contracts, and constraints that are based on these metrics.
h5. Requirements addressed
* [Service Description Model|#_16_5_1_24a0131_1283763560612_868976_4608]
h5. Overview of possible operations
h4. {anchor:_16_5_1_24a0131_1283714222600_103266_4106}discovery
h5. Description
One or more discovery mechanisms that enable searching for artifacts that best meet the search criteria specified by the service participant; where the discovery mechanism will have access to the individual artifact descriptions, possibly through some repository mechanism.
h5. Requirements addressed
* [Service Visibility Model|#_16_5_1_24a0131_1283763628053_328597_4610]
* [Service Description Model|#_16_5_1_24a0131_1283763560612_868976_4608]
* [Governance Model|#_16_5_1_24a0131_1283763638521_214441_4616]
h5. Overview of possible operations
h4. {anchor:_16_5_1_24a0131_1283718946661_463032_4374}governanceService
h5. Description
SOA services to access automated implementations of the Governance Processes.
h5. Requirements addressed
* [Governance Model|#_16_5_1_24a0131_1283763638521_214441_4616]
h5. Overview of possible operations
h4. {anchor:_16_5_1_24a0131_1283714222601_506267_4107}identity
h5. Description
Descriptions which include a unique identifier for the artifact.
h5. Requirements addressed
* [Governance Model|#_16_5_1_24a0131_1283763638521_214441_4616]
* [Service Description Model|#_16_5_1_24a0131_1283763560612_868976_4608]
h5. Overview of possible operations
h4. {anchor:_16_5_1_24a0131_1283719206847_206279_4421}managementInformation
h5. Description
An information collection site, such as a Web page or portal, where management information is stored and from which the information is always available for access.
h5. Requirements addressed
* [Governance Model|#_16_5_1_24a0131_1283763638521_214441_4616]
h5. Overview of possible operations
h4. {anchor:_16_5_1_24a0131_1283719206849_873728_4422}managementNotification
h5. Description
A mechanism to inform participants of significant management events, such as changes in rules or regulations.
h5. Requirements addressed
* [Governance Model|#_16_5_1_24a0131_1283763638521_214441_4616]
h5. Overview of possible operations
h4. {anchor:_16_5_1_24a0131_1283719206851_835373_4423}managementProcesses
h5. Description
Accessible storage of the specifics of processes followed by management.
h5. Requirements addressed
* [Governance Model|#_16_5_1_24a0131_1283763638521_214441_4616]
h5. Overview of possible operations
h4. {anchor:_16_5_1_24a0131_1283714222603_853936_4108}metadata
h5. Description
A representation of the meaning of terms used to describe the artifact, its functions, and its effects.
h5. Requirements addressed
* [Governance Model|#_16_5_1_24a0131_1283763638521_214441_4616]
* [Service Description Model|#_16_5_1_24a0131_1283763560612_868976_4608]
h5. Overview of possible operations
h4. {anchor:_16_5_1_24a0131_1283702219069_775824_3210}metrics
h5. Description
Access to metrics information generated or accessible by related services
h5. Requirements addressed
* [Service Description Model|#_16_5_1_24a0131_1283763560612_868976_4608]
* [Governance Model|#_16_5_1_24a0131_1283763638521_214441_4616]
h5. Overview of possible operations
h4. {anchor:_16_5_1_24a0131_1283702219071_411273_3211}metricsDiscovery
h5. Description
Mechanisms to catalog and enable discovery of which metrics are available for a described artifact and information on how these metrics can be accessed.
h5. Requirements addressed
* [Service Description Model|#_16_5_1_24a0131_1283763560612_868976_4608]
h5. Overview of possible operations
h4. {anchor:_16_5_1_24a0131_1283702219067_789210_3209}monitor
h5. Description
Access to platform infrastructure monitoring and reporting capabilities.
h5. Requirements addressed
* [Service Description Model|#_16_5_1_24a0131_1283763560612_868976_4608]
* [Governance Model|#_16_5_1_24a0131_1283763638521_214441_4616]
h5. Overview of possible operations
h4. {anchor:_16_5_1_24a0131_1283793030699_512571_7056}provenance
h5. Description
While the Resource identity provides the means to know which subject and subject description are being considered, Provenance as related to the Description class provides information that reflects on the quality or usability of the subject. Provenance specifically identifies the entity (human, defined role, organization, ...) that assumes responsibility for the resource being described and tracks historic information that establishes a context for understanding what the resource provides and how it has changed over time. Responsibilities may be directly assumed by the Stakeholder who owns a Resource or the Owner may designate Responsible Parties for the various aspects of maintaining the resource and provisioning it for use by others. There may be more than one entity identified under Responsible Parties; for example, one entity may be responsible for code maintenance while another is responsible for provisioning of the executable code. The historical aspects may also have multiple entries, such as when and how data was collected and when and how it was subsequently processed, and as with other elements of description, may provide links to other assets maintained by the Resource owner.
h5. Requirements addressed
h5. Overview of possible operations
h4. {anchor:_16_5_1_24a0131_1283714222609_981432_4109}store
h5. Description
Accessible storage of artifacts and artifact descriptions, so service participants can access, examine, and use the artifacts as defined.
h5. Requirements addressed
* [Service Description Model|#_16_5_1_24a0131_1283763560612_868976_4608]
* [Governance Model|#_16_5_1_24a0131_1283763638521_214441_4616]
h5. Overview of possible operations
h4. {anchor:_16_5_1_24a0131_1283112094907_297211_1904}workflowModel
h5. Description
Workflow Model maintenance
Application developers need to be able to easily use the infrastructure to create workflows without having to figure out how to integrate the data or services, the infrastructure should step them through it and just ask for things that are not already available
Authoring tools should automate the construction of workflows.
Provide workflow component modularization and customization
Use business process workflow tool to automate the process of model submissions( and other related data) to the KR.
Provide support for Curation Workflow Activities
Semantics describing workflows will be needed.
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.
Service orchestration and choreography allows both application developers and non-developers to discover service "building blocks" that can be composed dynamically to provide business capabilities. Special cases include the orchestration of multiple services for a distributed query, or for a transactional workflow. Service orchestration and choreography will leverage static and behavioral semantics from the Semantic Infrastructure 2.0.
The Semantic Infrastructure provides the behavioral semantics required for dynamic composibility of services or generation of distributed queries. This includes runtime contract discovery and negotiation to determine composibility of services based on service capabilities and constraints.
Another use case is dynamic retrieval and enforcement of the policies that are in effect for a service interaction in the areas of logging, validations, data transformation, or routing. This information can be used either during the design of the orchestration or during the execution of the defined flow.
h5. Requirements addressed
* [016 - Semantics describing workflows will be needed|#_16_5_1_24a0131_1283089255935_398923_4473]
* [155 - Create workflows|#_16_5_1_24a0131_1283089257413_959609_4482]
* [015 - Authoring tools should automate the construction of workflows|#_16_5_1_24a0131_1283089255407_169284_4470]
* [041 - Automate model submission process|#_16_5_1_24a0131_1283089256392_93500_4476]
* [000 - Provide support for Curation Workflow Activities|#_16_5_1_24a0131_1283089254843_804603_4467]
* [Service Governance and workflows|#_16_5_1_24a0131_1283090103606_857757_4560]
* [Behavioral Models|#_16_5_1_24a0131_1283090050000_56698_4488]
* [Service Orchestration and Choreography|#_16_5_1_24a0131_1283090074514_588970_4530]
* [135.3 - Modularization and Customization|#_16_5_1_24a0131_1283089256991_302329_4479]
h5. Overview of possible operations
{scrollbar} |
