Capabilities in the architecture

Back in October, I started a discussion about contraints and
capabilities[1] that never resulted in any text in the document.

I believe that it's important for it to be in the document, as it is
for example the rationale for solutions like WS-Policy.

Thinking again about my first proposal and the discussion we had on
the call afterwards, I believe that we can fairly simply address this
problem, by introducing the concept of "capability" in the service
oriented model.

Here is my proposal:

----8<--
==========
Capability
==========

- Definition:

A capability is a feature that is declared as supported by an agent.

- Relationships to other concepts:

A capability is
  a feature

A capability may be referenced in
  an obligation

A capabilitiy may be described in
  a service description

- Description:

Web services provide an extensible, decentralized environment.  The
agents participating into an exchange may therefore implement a wide
variety of features.

In order for a requester agent and a provider agent to make use of a
particular feature, they both need to support it.

There may be variation of a particular extension; for example, there
may be different ways to achieve the reliable delivery of a message.
The requester and provider entities may therefore need to do some
negotiation about the features to be used during the exchange by their
agent. This negotiation may be automatic or manual.

It is therefore necessary for agents to advertize the features they
support. A supported feature is called a capability. One of the agent
could request the mandatory use of capability using an obligation.

-->8----

Comments? Frank, you had problems with my first proposal. How does
this one sound?

Regards,

Hugo

  1. http://www.w3.org/mid/20031016095009.GQ953@w3.org
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/