ietf-openproxy
[Top] [All Lists]

RE: SOAP and OCP

2003-04-22 07:20:27

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.

<Prev in Thread] Current Thread [Next in Thread>