headers
Paul Andrews | 2 Jun 2003 22:45
Picon
Favicon

SOAP Channel Initialization...

I've got a question about RFC 3288. In section 2.1 - Profile
Initialization - it states:

Alternatively, here is an example in which the boot exchange is
   unsuccessful:

       C: <start number='1' serverName='stockquoteserver.example.com'>
       C:     <profile uri='http://iana.org/beep/soap'>
       C:         <![CDATA[<bootmsg resource='/StockPick' />]]>
       C:     </profile>
       C: </start>

       S: <profile uri='http://iana.org/beep/soap'>
       S:     <![CDATA[<error code='550'>resource not
       S:                                supported</error>]]>
       S: </profile>

   Although the channel was created successfully, it remains in the
   "boot" state.

Does this imply that a subsequent message on the channel of type
<bootmsg> could cause the channel to leave the boot state? If not, what
can actually be done with the channel?
Permalink | Reply | 1 comment |
headers
Marshall Rose | 2 Jun 2003 23:26
Picon
Picon

Re: SOAP Channel Initialization...

> ...
>    Although the channel was created successfully, it remains in the
>    "boot" state.
> 
> Does this imply that a subsequent message on the channel of type
> <bootmsg> could cause the channel to leave the boot state?

yes, exactly.

/mtr
Permalink | Reply | 0 comments |
headers
Jason Rimmer | 6 Jun 2003 07:12
Favicon
Gravatar

[Fwd: [JMX-FORUM] JMXP]

Posted on the JMX-FORUM <at> JAVA.SUN.COM mailing list.

-------- Original Message --------
Subject: 	[JMX-FORUM] JMXP
Date: 	Thu, 5 Jun 2003 17:26:02 -0500
From: 	Ward Harold <wharold <at> US.IBM.COM>
Reply-To: 	Ward Harold <wharold <at> US.IBM.COM>
To: 	JMX-FORUM <at> JAVA.SUN.COM

I've designed a protocol for JMX, called JMXP, using the Blocks
Extensible Exchange Protocol (BEEP) application protocol kernel and am
proposing it to the IETF as a standard, language neutral mechanism for
remote JMX access. The specification can be found at either:

http://www.ietf.org/internet-drafts/draft-harold-jmxp-00.txt

or for a prettier version:

http://www.beepcore.org/beepcore/docs/profile-jmxp.jsp

Note that this work in no way conflicts with the remote API designed by
the JSR 160 Experts Group. JMXP is a protocol and as such could be used
by a JSR 160 provider. My primary intent in designing JMXP was to create
a mechanism via which non-Java programmers - read administrators who may
prefer Perl, TCL, or shell scripts - can access JMX programmatically.

I am of course very interested in feedback on this spec from JMX
community ergo, comments/criticism/questions/corrections from this forum
are especially welcome.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Andrews | 6 Jun 2003 15:30
Picon
Favicon

JMXP

My first thought on the JMXP proposal
(http://www.ietf.org/internet-drafts/draft-harold-jmxp-00.txt) is that
it is a combination presentation and application layer. The presentation
layer is made up of elements like <arguments> and <value>, while the
application layer is made up of elements like <notification-listener
action="remove">.

I am on something of a crusade to press for separation of these two
layers in any standard where I see it. The main reason being that there
is a profilferation of XML presentation layers with every new proposed
XML based protocol. We already have a presentation layer that has very
wide tool support, namely: SOAP.

In order to pre-empt many people's automatic response to the acronym
'SOAP' I will say up front that I am not interested in hearing any
argument based on its supposed verbosity. I strongly believe, and I am
not alone in this, that any mature presentation protocol would present a
similar level of verbosity and that any actual verbosity that SOAP has
does not significantly impact network or application performance. I also
believe that SOAP's (perceived) shortcomings are strongly outweighed by
the community, vendor and tool support that it has.

Naturally, adopting SOAP for the presentation layer would still leave
the application layer protocol undefined and I believe that it is this
layer that any proposed standard should address.

To summarize I would like to see the JMXP proposal split into two:

1. An information model that defines the application protocol.
2. A presentation binding with SOAP being the preferred binding.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dann Martens | 9 Jun 2003 11:05
Favicon

Re: JMXP

I agree with your point of view. I don't think we need another 'custom' 
application specific protocol. Of course, JMXP is an interesting 
initiative in the context of the java JMX technology. But for 
heteregenous systems, SOAP is intended as the RPC (or RMI whatever you 
call it) protocol to rule them all. The (early access) Remote Access API 
for JMX allows for both approaches, but I wouldn't be surprised at all 
that designers have a JAX-RPC based (Sun's java SOAP 1.1 implementation) 
connector in mind for the next JMX Reference Implementation. Perl, TCL, 
or shell scripts will all have SOAP libraries (or binary tools) 
available, if they don't have them available already (I just haven't 
checked).

Let's put our effort at getting the industry to accept SOAP over BEEP 
(as we need HTTP put out to pasture), now that would be a worthy cause !

Kind regards,
 Dann

Paul Andrews wrote:

>My first thought on the JMXP proposal
>(http://www.ietf.org/internet-drafts/draft-harold-jmxp-00.txt) is that
>it is a combination presentation and application layer. The presentation
>layer is made up of elements like <arguments> and <value>, while the
>application layer is made up of elements like <notification-listener
>action="remove">.
>
>I am on something of a crusade to press for separation of these two
>layers in any standard where I see it. The main reason being that there
>is a profilferation of XML presentation layers with every new proposed
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jered Floyd | 30 Jun 2003 16:43
Favicon

SEQs after channel close request?


Here we go again. :-)

This is similar to a complaint I had last year regarding
synchronization for TLS negotation, where I was shouted down for
constructing overly obscure scenarios.  This is less obscure, and
actually a problem I'm running into, but I'm not sure how to best fix.

While adding some functionality to PermaBEEP, we encountered a bug we
hadn't noticed before.  PermaBEEP will not send SEQ frames for a
channel once it has processed a locally-initiated request to close for
that channel.

It doesn't want to generate any further outbound traffic on the
channel after the close request, because as soon as the remote side
accepts, the remote side considers the channel to be closed.  Once
the remote peer has processed the close, if it saw a SEQ for the
channel in response to it's 'ok' response, it would terminate the
connection as per RFC 3081, 3.1.3:

   When a SEQ frame is received, if any of the channel number,
   acknowledgement number, or window size cannot be determined or is
   invalid, then the BEEP session is terminated without generating a
   response, and it is recommended that a diagnostic entry be logged.

(The channel would be closed and thus invalid.)

So, the local peer isn't going to be sending any new MSGs after it's
made a close request, however RFC 3080, 2.3.1.3:
(Continue reading)

Permalink | Reply | 4 comments |
headers
Darren New | 30 Jun 2003 18:30
Picon

Re: SEQs after channel close request?

Jered Floyd wrote:
> I think the latter item there will work but, well, it seems overly
> complicated.  What have other implementors done?

While doing Beepcore-C's core, I noticed this problem. I only send SEQs 
*before* sending outgoing packets. That is, I send the SEQ just before 
sending the RSP or ANS, so it really isn't a problem. As long as the SEQ 
isn't the last packet you send, the other side should always be waiting 
for your response and therefore hasn't processed the close yet.

The other problem you run into is when a response to a close carries 
more data than your window can accept. This is more of a doctor-doctor 
problem. ("Doctor, Doctor, it hurts when I do this!"  "Then don't do that.")

Hope this helps.

--

-- 
Darren New, San Diego CA USA (PST)
Things to be thankful for, #187:
  There is no Chinese tradition of changing from
  shoes to slippers to get off an escalator.
Permalink | Reply | 3 comments |
headers
Marshall Rose | 30 Jun 2003 18:51
Picon
Picon

Re: SEQs after channel close request?

> While doing Beepcore-C's core, I noticed this problem. I only send SEQs 
> *before* sending outgoing packets. That is, I send the SEQ just before 
> sending the RSP or ANS, so it really isn't a problem. As long as the SEQ 
> isn't the last packet you send, the other side should always be waiting 
> for your response and therefore hasn't processed the close yet.

this is the same approach i used in beepcore-tcl: SEQs go first.

when the spec gets updated, i don't have a problem in changing the spec
to ignore SEQs on unknown channels.  it's hard to see any downside in
that.

/mtr
Permalink | Reply | 2 comments |
headers
Jered Floyd | 30 Jun 2003 19:09
Favicon

Re: SEQs after channel close request?


Thanks; I ended up implementing something like this just now.  If
there exist any messages that have not yet been fully replied to,
I will send SEQs, otherwise not.

--Jered

Marshall Rose <mrose <at> dbc.mtview.ca.us> writes:

> > While doing Beepcore-C's core, I noticed this problem. I only send SEQs 
> > *before* sending outgoing packets. That is, I send the SEQ just before 
> > sending the RSP or ANS, so it really isn't a problem. As long as the SEQ 
> > isn't the last packet you send, the other side should always be waiting 
> > for your response and therefore hasn't processed the close yet.
> 
> this is the same approach i used in beepcore-tcl: SEQs go first.
>     
> when the spec gets updated, i don't have a problem in changing the spec
> to ignore SEQs on unknown channels.  it's hard to see any downside in
> that.
>     
> /mtr
Permalink | Reply | 0 comments |
headers
james woodyatt | 30 Jun 2003 20:32

Re: SEQs after channel close request?

On Monday, Jun 30, 2003, at 09:51 US/Pacific, Marshall Rose wrote:
> [ Darren New wrote:]
>> While doing Beepcore-C's core, I noticed this problem. I only send 
>> SEQs
>> *before* sending outgoing packets. That is, I send the SEQ just before
>> sending the RSP or ANS, so it really isn't a problem. As long as the 
>> SEQ
>> isn't the last packet you send, the other side should always be 
>> waiting
>> for your response and therefore hasn't processed the close yet.
>
> this is the same approach i used in beepcore-tcl: SEQs go first.

There is a further complication.  You can't wait until just before 
sending a reply before emitting the SEQ frame.  My implementation will 
send the SEQ frame immediately after extending the window-- which 
happens when the MSG is acknowledged by the application layer, and 
possibly well before the application sends a reply.

After the local peer sends a <close> request and before it receives the 
<ok> reply, if it receives a MSG for which the application at the local 
peer does not have any response other than to extend the channel window 
(to receive more pipelined requests) then the local peer must send a 
SEQ immediately, while a RPY, ERR or ANS (or the transport reset event) 
may not be forthcoming until after the application receives more MSG 
requests.

> when the spec gets updated, i don't have a problem in changing the spec
> to ignore SEQs on unknown channels.  it's hard to see any downside in
> that.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane