Another place for SOAP in OPES is access to
all reference and information points.
While there is a trend to postpone (preferably indefinitely :)
any specs that go beyond the definition of the reference -
still without such specs OPES achitsture is incomplete.
All references with undefined information structure look
more like a "fine print" - one that is not supposed to be read.
If we move some programmatically accessible information to
references without providing access specs - all
implementers are forced to create proprietary access
formats and interoperability becomes a problem.
Should we look at this now?
Oskar
-----Original Message-----
From: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Alex
Rousskov
Sent: Tuesday, April 22, 2003 12:18 AM
To: ietf-openproxy(_at_)imc(_dot_)org
Subject: RE: SOAP and OCP
On Mon, 21 Apr 2003, Abbie Barbir wrote:
On Mon, 21 Apr 2003, Alex Rousskov wrote:
My understanding is that any existing web service can already
participate in an OPES system "as is" as long as the OPES
processor using the service supports SOAP. However, such
participation is outside of OCP scope because OCP is not SOAP; OCP
is a stand-alone protocol that has features not described in SOAP
specs. To support OCP, a web service must be modified.
True, that is what I mean.
In other words, SOAP may be used as an OPES callout protocol (from
architectural point of view). However, the protocol we are working
on (OCP), is not identical to SOAP (but can be implemented on top
of SOAP). Modifications would be required for existing web
services to support OCP.
very true
Is my understanding correct? If it is, we may have a good
compromise available: treat both OCP and SOAP as possible callout
protocols and make sure that OPES framework is not OCP- or
SOAP-specific. OPES implementations will use the most appropriate
protocol for their needs.
I would love that.
Great! Given the above agreement, I would suggest that OCP we work on
right now is _not_ implemented on top of SOAP because:
1a. SOAP does not deal well with opaque data exchange
1b. efficient opaque data exchange is the primary goal of our OCP
2. SOAP strength (current deployment) can still be used whenever
appropriate by OPES processors that support SOAP and either
adapt SOAP-friendly data only or do not care about performance
on binary data
Instead, I would suggest that the WG encourages Abbie to write a "how
to use SOAP as an OPES callout protocol" draft, supplying OPES
implementors with an explicit OCP alternative. All WG documents
(including those documenting tracing and bypass mechanisms) will have
to make sure that no specific callout protocol is assumed in a general
OPES context.
Any objections or further comments?
Thank you,
Alex.