On Mon, 24 Feb 2003, Abbie Barbir wrote:
I would like us to start looking into sporting services (Web
Services). The example, may require (for broader
business/deployment) that an OPES processor may need to support
SOAP.
I really would like us to start looking into that. So far the
Pre-draft discussion developes a protocol that could be easily
implemented as a SOAP one.
we just need few elements, such an an HTTP element (encpasulates
HTTP partial or full), a Responce-Required element etc... Basically,
one class of elements can incoporate all of the features of the
pre-draft.
However, we can add elements that allow for
1. Partial/full controlled access to a profile (user)
2. Partial/full access to policy
3. content-trace-route element (this one is optional)
It is great that the predraft protocol can be implemented on top of
SOAP. That means our options regarding OPES transport are still wide
open; all transport protocols mentioned on this list can be
supported: BEEP, HTTP, and SOAP.
At some point, we need to decide whether to standardize a single
transport protocol binding (e.g., SOAP) OR allow multiple bindings
(e.g., HTTP or SOAP) with one "OPES binding" spec (RFC?) per supported
transport protocol. The one-binding approach is simpler but the
N-binding approach is more flexible.
We should look into not requiring close coupling between the Callout
Server service provider and the OPES provider in terms that they are
bound to a spcific OCP protocol that can only be used to sell or
provide a service.
IF we look at SOAP, we can in thoery allow for any web service
service's provider to become a Calllout Server. (with the proper
OPES framework in mind, of course)
IETF in general and OPES WG in particular cannot dictate what a
service provider can sell. Clearly, there will be competing protocols
and approaches on the market, and OPES would have to fight its way to
the world dominance.
We have to work in OPES context: a service provider either supports
OPES or it does not. We cannot accommodate service providers that do
not use OPES (e.g., those that use raw SOAP with non-OPES extensions).
We can only try to make OPES attractive enough so that more service
providers support it.
It would be great if current service providers can switch to (or add
support for) OPES without much effort. If you can convincingly
demonstrate that having SOAP binding will make transition to OPES
simple, it would significantly increase chances that SOAP becomes an
OPES binding. To make this case, we have to finish implementing the
core of the protocol, I guess. Before that happens, it is difficult to
discuss transitions from existing approaches since there is nothing to
transition to!
Finally, based on e-mails on this list, I expect some resistance to
SOAP because SOAP is not an IETF standard. I do not know what the
official IETF (IAB?) position is regarding developing IETF standards
that rely on IETF-level but non-IETF standards. Are there historical
precedents (e.g., standard-track RFCs) of IETF specs based on SOAP? If
there is a political problem with SOAP, supporting multiple optional
bindings (including SOAP) may help to avoid a deadly clash with IETF
policies.
Thank you,
Alex.