RE: SOAP and OCP

Oskar,

Agreed.
Although, I am sure that some will argue otherwise.
 We can address this now or may be address later with the SOAP draft.

ABbie


> -----Original Message-----
> From: Oskar Batuner [mailto:batuner(_at_)attbi(_dot_)com] 
> Sent: Tuesday, April 22, 2003 10:20 AM
> To: ietf-openproxy(_at_)imc(_dot_)org
> Subject: RE: SOAP and OCP
>
>
>
> 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.