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
>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.
>
>If SOAP is the preferred binding for the presentation layer, then the
>session layers and below are already well defined, in particular
>bindings are already defined for both BEEP and HTTP.
>
>If there are reasons why SOAP should not be used for presentation layer
>encoding (other than the 'verbosity' argument discussed above), I would
>be very interested in hearing them.
>
>Paul Andrews - Cisco Systems Inc.
>
>_______________________________________________
>BEEPwg mailing list
>[email protected]
>http://lists.beepcore.org/mailman/listinfo/beepwg
>
>  
>