Subject: [BEEPwg] Benchmarks? Performance, conformance...

From: "Bob Wyman" <[email-masked]>
Date: Thu, 27 Jun 2002 11:34:27 -0400

Has anyone developed, or is anyone developing, any useful BEEP
performance and/or conformance benchmarks or testing suites that might
be useful in compariing the performance and/or conformance to
specification of various implementations of BEEP?
 
Whether or not your are developing such things, I would appreciate
pointers to benchmark or validation suites developed for similar
protocols or your comments on how such testing should be most properly
done.
 
        bob wyman

---

From: "Rohit Karlupia" <[email-masked]>
Date: Fri, 28 Jun 2002 12:30:46 +0530

Hi ALL!

I have a question regarding the SOAP Message Patterns.
In the section 4.1 under SOAP Message Patterns, the RFC 3288 says 
that in case of One-way Message exchange...

"....in which the client sends a "MSG" message containing 
an envelope, and the server immediately sends back a "NUL" 
message, before processing the contents of the envelope."

My question is: How does the server knows that the given MSG 
message containing the SOAP envelope is to be replied using 
the NUL message before processing the message? 

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. 

Please enlighten me on this. I may be completely missing something.

Thanks,
Rohit Karlupia

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

---

From: Marshall Rose <[email-masked]>
Date: Fri, 28 Jun 2002 08:42:36 -0700

> 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

---

From: Gabe Wachob <[email-masked]>
Date: Fri, 28 Jun 2002 09:59:04 -0700 (PDT)

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

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

---

From: Marshall Rose <[email-masked]>
Date: Fri, 28 Jun 2002 11:40:48 -0700

> particular message without giving the recipient any chance to figure it

uh, no. it's up to the soap folks to decide how to deal with this. beep, and soap-over-beep, just doesn't care.

i could just as easily s/beep/http/g in the original note and the same issue exists. ditto for s/beep/smtp/g

/mtr

---

From: Gabe Wachob <[email-masked]>
Date: Fri, 28 Jun 2002 11:57:22 -0700 (PDT)

On Fri, 28 Jun 2002, Marshall Rose wrote:

> uh, no. it's up to the soap folks to decide how to deal with this.
> beep, and soap-over-beep, just doesn't care.
>

Uh, no.

The beep/http binding does NOT specify that the recipient must send back a
HTTP 200 response "before processing the contents of the envelope."

Thats the problem. In fact, the HTTP bindings don't speak about one-way
messaging at all (which is too bad). I'm saying that the phrase under
consideration requires the recipient to know the message pattern before it
has any way of knowing it. Its a logical problem. At the very least I
think the language in this RFC is premature as it eliminates the
possibility of SOAP using a header to express the messaging pattern. The
only way I see out of this is using a BEEP header (ie along the lines of a
MIME header) which expresses the messaging pattern. That assumes the SOAP
people go with expressing the MEP at the transport level.

	-Gabe

---

From: Marshall Rose <[email-masked]>
Date: Fri, 28 Jun 2002 13:09:51 -0700

> people go with expressing the MEP at the transport level.

perhaps, but perhaps not.

the fact that similar language doesn't appear in the http binding doesn't mean the problem isn't the same...

m/tr

---

From: "Rohit Karlupia" <[email-masked]>
Date: Sat, 29 Jun 2002 03:49:55 +0530

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-masked]
[mailto:[email-masked]]On Behalf Of Gabe Wachob
Sent: Friday, June 28, 2002 10:29 PM
To: Marshall Rose
Cc: [email-masked]; [email-masked]
Subject: Re: [BEEPwg] Soap Over Beep Question

	-Gabe

On Fri, 28 Jun 2002, Marshall Rose wrote:

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