COMM-7

SOAP as an Example of
Evalualtion from an ACL Standpoint

Compare SOAP with an ACL
(ignore service location, composition, debugging, security, namespace issues)

Description style is different- Few pre-defined symbols, no BNF, difficult to infer

3 parts - "Envelope" has ontology references
"Headers" are optional but may contain things similar to ACL performatives
"Body" is similar to inner language for application

Like ACL, transport-independent -Presumes some sort of message path, but is consistent with HTTP

But not only point-to-point - different parts of the message may be intended for different intermediaries. Workflow-like rather than agent-like.

Errors - Similar support for error messages - seems to be up to SOAP Processor/Agent to send an error or ignore.

"Sender"?- It is not clear that "Sender" is part of header or envelope - how then to determine authority?

no "Sorry" - Does not seem possible to say this at header level - no top-level (non-application) commitment to this concept

The goal is similar to that of ACLs:

"SOAP provides a flexible mechanism for extending a message in a decentralized and modular way without prior knowledge between the communicating parties. "

ACLs have been only partly successful in this goal with pre-defined performatives.

SOAP has no commitment at all to types of agent interactions beyond those specified by the application. I.e., beyond system for UDI specification, interaction performatives are not pre-specified. At a minimum, loses the AOSE ACL advantage.

cjp