This document is used internally by editors of the WS Architecture
document to ensure that we are using terms consistently throughout our
document. It has no official status.
Any editor noticing a discrepency in the way we are using a term in our
document should (a) add that term to this list, and (b) propose a
standard usage.
[Also: Is this HTML the most convenient format for reading and
modifying this list?]
| Requester
Term |
Provider Term |
Usage |
| requester |
provider |
Ambiguous. Use more
specific terms instead, such as "provider agent" or "requester entity". |
| service requester |
service provider |
ISSUE: We've been inconsistent
in how we've defined/used these terms. In some cases we are
referring to the requester and provider *agents*; in other cases we are
referring to the person or organization. DBooth opinion: I think we should avoid these terms, and use the more specific "provider agent" or "provider entity" terms instead. |
| requester agent | provider agent |
The concrete agent implementing the service/client. See 1.5.1. |
| requester entity | provider entity |
The "person or organization"
that owns the service/client. See 1.5.2.
|
| requester human | provider human |
A person acting on behalf of the requeter/provider entity. See 1.5.2. |
| ? (client?) requester application? |
service | The service is the abstract
thing that offers a set of functionality; the agent is the concrete
thing that implements the service. ISSUE: What term should we use for the thing that is analogous to the "service", but on the provider side? "Client"? "Requester application"? Fortunately we don't need to refer to this concept often, so hopefully we can just work around it somehow. Also, DBooth previously noted a conflict in the way we were defining versus using the term "service", but he and Frank think they worked out a solution. The issue was that "service" had been defined as a set of actions, rather than the (abstract) thing that *performs* a set of actions. This caused a conflict when using the term in statements like: "A service performs X" or "A service does X". |
| (none) |
service description | ISSUE: Is it only the WSDL
description, or might it include additional semantic
descriptions? See 3.4.2.1. 10/8/03: Frank & DBooth discussed this and agree that we need to be consistent with the WG's decision to sanction WSDL, so DBooth is trying to figure out a new term for the additional description that is beyond what WSDL includes. dbooth: ALSO: Figure 1 uses the term "WSD" (Web service Description) because a longer term would be too big to fit in the diagram. However, we should be consistent in the document about which term we use. At the moment, we seem to be using "service description" most of the time, so perhaps we should standardize on that. |
| Term |
Usage |
| node |
ISSUE: SOAP uses the term "node"
a lot. Should we? We use the term "agent" and the more
abstract term "service". |
| semantics |
ISSUE: We are
inconsistent. Does "semantics" refer to the actual semantics
(i.e., meaning) or does it refer to a (written) description of the
semantics? 10/8/03: DBooth and Frank discussed this and are leaning toward using a different term for the description of the semantics. |
| static vs. dynamic discovery |
ISSUE: We are inconsistent about
the meaning of static versus dynamic discovery. Section
#discovery_service implies that the distinction is based on whether it
is a human or a machine doing the discovery. (Human==>Static;
Machine==>Dynamic). Elsewhere I think we say that static discovery is when the WSD is obtained before the requester agent is invoked (i.e., during development). Dynamic discovery is when the WSD is obtained dynamically by the requester agent. dbooth: Is this correct? What if the URL of the WSD is known beforehand, but the requester agent retrieves the WSD dynamically? |