RE: Soap Over Beep Question

I stand by your views Gabe.
I was thinking, as you suggested that message exchange pattern
could be either channel specific, in which case it could
be the property of the "resource" or "feature" negotiated during
the channel initialization; there must be some additional
tag(header) with the message that suggests the message pattern being
used.

I think it would be restrictive to make message patterns
channel specific. And thus would not support it as a solution.

I personally believe that it would be good to have the
message pattern information "outside" the SOAP message. This
would not only help the servers in deciding which BEEP message
type to use for responding to messages, but also help the client
to know beforehand what BEEP message to expect, and thus be
ready for it. Moreover, it would also allow the SOAP Application
developers to think in terms of which message patterns to use,
than to have the code taking care of any possible type of exchange.

I think it would be an important issue in a scenario when one doesn't own
both the
server and the client. All the applications will be using one
of the three possible message patterns, and these message patterns will
have to be "specified"/"known" by both the communicating applications
(server and client)before they can communicate. Thus, it makes sense to
resolve this ambiguity at the protocol level and thereby create a unifying
standard to increase interoperability.

regards,
Rohit Karlupia






-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Gabe Wachob
Sent: Friday, June 28, 2002 10:29 PM
To: Marshall Rose
Cc: [email protected]; [email protected]
Subject: Re: [BEEPwg] Soap Over Beep Question


I think this is a legitimate issue for the SOAP/BEEP RFC.

Message exchange patterns is a hot discussion topic over at the XMLP WG,
and its not clear (at least to me) how the message pattern for a
particular message will be expressed. But no matter what, I would expect
that message patterns for each message type, even on a single BEEP
channel, could be different.

THUS, for a recipient peer to know which message pattern is intended,
there either a) has to be a way to express the desired message pattern at
the "transport" level (e.g. within a BEEP message/channel) or b) within
the message.

Thus, the SOAP/BEEP profile will either have to provide a facility for
communicating the intended message exchange pattern (a per-message
header?) or the recipient node will have to at least partially process the
incoming message to decide which messaging pattern is appropriate (and
whether a NUL or RPY response is appropriate).

Either way, it seems that the SOAP/BEEP RFC is inadequate here because it
assumes the recipient has knowledge of the messaging pattern for a
particular message without giving the recipient any chance to figure it
out.

	-Gabe

On Fri, 28 Jun 2002, Marshall Rose wrote:

> > Since there is nothing in the syntax of SOAP Over Beep messages
> > which suggests how the message is to be replied with (i.e. if
> > this is a one way, 2 way or multi answer response)..the server
> > will only know about the type of message pattern being used only
> > from processing the SOAP message.
>
> this is really a soap-specific issue, not a beep- or soap-over-beep issue.
>
> the answer is the "server" can either have some kind of pre-knowledge over
the kind of messages it gets (i.e., the service it offers only dones one-way
exchanges), or, the first thing the "server" does is parse the envelope and
thereby know what's what.
>
> there, are, of course, some interesting failure modes with either
approach.
>
> /mtr
> _______________________________________________
> BEEPwg mailing list
> [email protected]
> http://lists.beepcore.org/mailman/listinfo/beepwg
>

--
Gabe Wachob                       [email protected]
Personal                       http://www.wachob.com
Founder, WiredObjects    http://www.wiredobjects.com

_______________________________________________
BEEPwg mailing list
[email protected]
http://lists.beepcore.org/mailman/listinfo/beepwg