|Home||ROI||Solution||Process||Petition||DNAOS Glossary||Contact [!?]||Links|
The default Infrastructure mode supports string based qualities. For finer grained semantic support, RQs use corresponding available and enabled semantics “plug-ins”.
Existing QoS specifications already lay some of the foundations for both RQ layersB-Negotiationand D-Semantics, as well as for managing NFPs in some more specific domains (e.g. QoS, FT, Risk).
The separation between infrastructure and semantic layer specifications provides flexibility and structure but requires clear definition to ensure that everything that can be generalized is specified at the generalized infrastructure level and that semantic specifications are reserved for semantics issues. There are many, especially as RQs can often be very domain and application specific.
The OMG QoS specifications (UMLTM Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms Specification) offer an interesting basis to build from.
Building on QoS, based on XML, a RQ semantics “plug-in” interface is required to support RQ semantics “plug-ins” that add semantics layer for given RQs.
Specific semantics are used only for the RQs that they are defined, enabled, and validated for. Also requiring specification, RQ semantics bindings are defined and managed through meta-data resources (e.g. attribute types), as well as validated with XML-Schema and Schematron.
At run-time, the semantics “plug-in” for an RQ is typically automatically used, when available and enabled, otherwise, infrastructure level operation is used.
Predefined common semantic RQs (e.g. QoS, ISO, FT) Semantics “plug-ins” require specification.
|sitemap||Copyright 1971-2009 01 COMMUNICATIONS INC. ALL RIGHTS RESERVED. - Powered by DNAOS||contact|