It seems that while the first is somewhat a subset of the second, the main RQ negotiation use cases can be summarized as either:
- item:hoping to obtain a certain quality value, a requester evaluates a provider's proposed quality value by comparing it to a target
or threshold value, with appropriatesemantics
- set:selecting providers of given services, from the competition, by comparing and evaluating their various service features, with
Quality Negotiation (e.g. SOA governance, Web Service NFP negotiation) specification considerations include:
- Trust:Below a minimal trust level,matchingis useless, as values are meaningless. Trust is a complex issue that reaches beyond the scope of RQs and is better addressed
elsewhere. Unless otherwise specified, this document assumes adequate trust and entitlement
- Match:Matching, compares two values for an RQ (e.g. a provider RQ value and a minimal desired quality value), returning the difference between
the two, according to applicablesemantics.
- Evaluate:Evaluating RQ sets or groups for a service is better defined along with the RQs' semantics, especially as group member respective
weight is typically domain and RQ specific. Formulas define “de facto” RQ sets, when using other attributes.
While these “de facto” groups typically also require formalization and meta-data considerations, and while they are real “physical”
groups, other, “virtual” sets are also required, especially for evaluation, as for SOA service negotiation.
As RQsemanticsand RQ sets definitions are progressively adequately supported, their specifications should be added to the RQ standards (e.g.
- Process:The RQ negotiation process can be defined directly around the negotiation protocol request and response exchange pairs. There
are many issues to negotiation and to the required trust, protocol, and evaluation. Some may not be ready for specification.
- Protocol:During negotiation, the protocol supports requests either for quality value proposals or for information on context resources,
services, meta-data, and semantics. Correspondingly, responses return value proposals and resource/service information.
The requesters typically initiate negotiation with a request for Quality proposals, on a service or resource. The quality
provider returns available value plans, per RQ.
Requesters evaluate proposals and either send more requests for proposals, or queries to find out more about available services,
or requests to connect to services, in which case providers respond with confirmation and connection support (e.g. login).