Subject: RE: SOAP and OCP

From: "Abbie Barbir" <[email-masked]>
Date: Mon, 21 Apr 2003 21:10:35 -0400

ALex,
See inline
Abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Monday, April 21, 2003 1:45 PM
> To: [email-masked]
> Subject: RE: SOAP and OCP
> 
> 
> 
> On Mon, 21 Apr 2003, Abbie Barbir wrote:
> 
> > Try w3c (SOAP 1.2)
> > http://www.xml.org 
> http://www.xml.com/pub/a/2003/02/26/binaryxml.html
> > http://www.w3.org/TR/soap12-af/
> 
> OK. So it looks like we have at least two choices when it 
> comes to transmitting opaque data over SOAP. First, we can 
> base64-encode it. The "binaryxml.html" document argues that 
> encoding is the right way to go because it lets us stay 
> within XML boundaries. On the other hand, encoding is 
> expensive (CPU and bandwidth wise). The second option is to 
> use MIME-like "attachments".
> 

Yes, true, this is why I said that there are ways of doing it.
SO Agree.

> The worst part is that there is no "standard" way to transmit 
> opaque data over SOAP yet. Implementations use different 
> approaches and may not be compatible. Please correct me if I am wrong.
> 

Agree

> OCP is about exchanging opaque data and metadata. XML does 
> not support opaque data well. That is why SOAP does not 
> support opaque data well. From this point of view, SOAP is 
> the wrong protocol to base OCP on -- the primary OCP function 
> is not well supported.  Other factors may be more important though.
> 
> > > If OCP is built on top of SOAP, do you expect any
> > > existing web services to be able to act as callout 
> servers "as is", 
> > > without _any_ modifications? Or do you expect modification of 
> > > existing services to support OCP-over-SOAP to be "easier" than 
> > > similar modification to support OCP-over-notSOAP?
> > >
> >
> > Yes, web services uses SOAP and this will allow OPES to be plugged 
> > into that area (as opposed to be a competitor). The short 
> answere to 
> > your question about modifications is Yes. By definition a 
> web services 
> > once discovered and its description is obatianed is immediatly 
> > interoperable. On the otherhand, a schema of OCP can be 
> written that 
> > could be used by the web services server that he will use 
> to become an 
> > OPES Callout server.
> 
> I am not sure I understand the answer. What does it mean to 
> be "immediatly interoperable by definition"? 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.
> 
> Comments?
> 
> Alex.

I would love that.

abbie

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 21 Apr 2003 22:18:05 -0600 (MDT)

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
> > 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
> > 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.

---

From: "Oskar Batuner" <[email-masked]>
Date: Tue, 22 Apr 2003 10:20:23 -0400

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

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Alex Rousskov
> Sent: Tuesday, April 22, 2003 12:18 AM

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 22 Apr 2003 10:01:39 -0600 (MDT)

On Tue, 22 Apr 2003, Oskar Batuner wrote:

> 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.
>
> references without providing access specs - all implementers are
> forced to create proprietary access formats and interoperability
> becomes a problem.

What do you mean by "providing access specs"? Would providing a
protocol name such as "http:" in a URI identifier be sufficient? You
are not talking about specifying how the referenced content is to be
composed or interpreted, are you?

Can you give a couple of specific examples where implementations would
access referenced content and auto-interpret it?

Thanks,

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 22 Apr 2003 19:10:08 -0400

> Any objections or further comments?

Having a document discussing the usage of SOAP as the OPES callout 
protocol is fine (indeed, I believe there was a now expired, 
individual ID about this a while ago). However, I'd like to hit the 
brake on going down the path of specifying multiple OPES callout 
protocols.

Let's focus on getting "an" OCP - with the appropriate transport 
binding(s) and application binding(s) - done. We're chartered to 
specify a callout protocol, and not a suite of possible callout 
protocols. There might be multiple alternatives, and we'll have to 
decide which is the best one.

If there's a real need for having multiple callout protocols, let's 
have a discussion and see whether there's WG consensus to do so. 
Otherwise, I'd suggest we focus on getting a single callout protocol 
done right, and base the companion documents around this protocol.

Leaving too many options seems like a simple way to overcome 
controversy and to make everybody happy, but it might not always be 
the best choice in technical design.

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 22 Apr 2003 17:51:20 -0600 (MDT)

> the best choice in technical design.

I agree; you may have misinterpreted what we are after:

OPES architecture already assumes that adaptation can be done by means
other than OCP. Thus, we are not increasing complexity or adding
anything really new. We are simply making a statement that OPES
framework (tracing, bypass, and such) should not depend on OCP because
OCP is not the only allowed way to do adaptation!

The fact that SOAP may be used as a callout protocol is just a
side-effect of the above statement. We will not focus on SOAP. We will
focus on "our" OCP. "How to use SOAP as an OPES callout protocol"
draft may (should??) end up having a single normative sentence:
	use "as is"

Does this approach work for you?

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 22 Apr 2003 21:04:40 -0400

Alex Rousskov wrote:

> other than OCP. 

Only if this "other than OCP" fully complies with the requirements 
outlined in the WG documents (which might be obvious if "other than 
OCP" is a local procedure call on the OPES processor).

If this "othern than OCP" would have to be modified/extended in oder 
to meet the requirements, or if the usage of "other than OCP" would 
imply additional complexity on the OPES framework, the WG shouldn't 
spend cycles on it.

I believe we're basically in agreement here.

> Thus, we are not increasing complexity or adding

See above.

> Does this approach work for you?

I hope the above provides an answer to that.

If the WG decides that SOAP (or some modification of SOAP) should be 
the OCP, the WG will work on it.

If the WG decides that something different than SOAP should become the 
OCP, the *WG* should not spend any cycles on SOAP (this includes 
possible modifications/extensions to SOAP, as well as requirements 
that might be imposed by SOAP on the OPES framework). Of course, this 
is *not* meant to prevent individual contributors to look at it, the 
WG just won't take this on as work item, and it should not distract 
the WG. And, obviously, if SOAP can be used without any 
modifications/extensions and without having any additional 
requirements on the OPES framework - hey, there's nothing to do and we 
also don't have a problem.

If I understood you correctly, that's very much what you said.

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 22 Apr 2003 23:34:05 -0600 (MDT)

On Tue, 22 Apr 2003, Markus Hofmann wrote:

> Alex Rousskov wrote:
>
> > OPES architecture already assumes that adaptation can be done by
> > means other than OCP.
>
> outlined in the WG documents

Yes, of course, though the OCP requirements draft may not apply in
this case because it defines many requirements that have nothing to do
with OPES framework but simply outline what we think a _good_ OCP
protocol can be. In other words, it is possible to build an
OPES-compliant system using a non-OCP-compliant callout protocol.

>  (which might be obvious if "other than OCP" is a local procedure
> call on the OPES processor).

As I probably mentioned before, the architecture documents do not
(cannot?) distinguish "local" from "remote" without severely limiting
OPES processor definition. The processor "box" is not well defined,
and even "local" adapters have to obey applicable OPES requirements
(if any).

> imply additional complexity on the OPES framework, the WG shouldn't

I agree. All I am saying is that OPES framework requirements such as
tracing and bypassing draft(s) should not have any dependency on a
particular form of the callout/adaptation mechanism. This is the
primary reason to keep those drafts specific to OPES processor (or
even dispatcher, something we would have to argue about later).

> I believe we're basically in agreement here.

Yes, I think so. We can proceed without violating each other
preferences, at least for now :-). We may have to revisit the "local"
versus "remote" and "processor" versus "dispatcher" issues later, when
it is time to define OPES tracing/bypass scope. At that time, I will
argue that, for example, it is impossible to bypass non-OCP adaptation
"inside" the OPES processor as it is currently defined, and I would
argue that the definition or usage of "processor" and "dispatcher"
terms should be revised to allow for such bypass and to erase any
distinction between OCP-based and other adaptors.

Thank you,

Alex.