We use the method(Doc) interface as well but switching it to
method(Element[]) isn't a huge hit - just an annoyance. ;-)
I wish more people would speak-up like you did - without feedback
like this its hard for the Axis developers to know which interfaces
are being used. While its easier for the Axis team that it appears
most people just bite the bullet (silently) each time Axis' interfaces
(or functionality) changes the "Hey! You cost me X days of my time
to upgrade" would be even more helpful.
-Dug
[EMAIL PROTECTED] on 09/24/2002 06:01:45 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: Re: Message style services - ATTN ANY java:MSG USERS
I would be interested in the thoughts on supporting a Document
method(Document) interface. This is basically what was there in
MsgProvider as an alternate since I started looking (Beta2). Even though
it was labeled as an old one to be eventually removed, I ended up using it
as the class I wanted to expose happened to have that interface signature.
I contemplated changing to the preferred signature, but when it persisted
from Beta2 to Beta3, I assumed this form of interface would stay.
So maybe there are others that are using it as well. I would be hesitant
to pull it as you go to an initial release.
That said I would not keep it on my account as I have been contemplating
going away from this approach to my web service as performance and
invocation compatibility become more important to me.
When I traced the actual parsing for the message based service, I was
somewhat concerned that I was picking the best way for my service to be
handled. The XML gets parsed once as part of getSOAPEnvelope. Then in
MsgProvider the recorded events will be played back to form a string and
then get reparsed to form a Document (doc=reqBody.getAsDOM
().getOwnerDocument(); This invokes MessageElement.getAsDocument which
does a getAsString(), creates a new StringReader and then does an
XMLUtils.newDocument on the StringReader.)
Right now this is being done for any bodyService, but I think it should
only be done in the case for supporting a document interface method. It's
a fairly expensive operation to not be used in the other paths.
All of this suggested to me that if I'm really concerned about efficiency
or memory size, I should avoid message based services. I was actually
interested in taking a closer look at switching to RPC so I could use the
potentially most efficient approach of streaming deserialization that came
back in Beta3. Still haven't had a chance to pursue that yet though.
The part that concerns me with invocation compatibility is the ability to
use a tool like wsdl2java to create a client invocation. As near as I can
tell the AXIS tool will never support anything other than an RPC
binding--it follows the JAX-RPC specification for SOAP body representation
and forces a message part wrapper even for a document based service. The
client generated this way clearly will not be able to talk to my service.
This troubled me as I would have expected my WSDL to distinguish between
these two approaches--element appearing directly in the body and element
wrapped--and for wsdl2java to generate the appropriate approach or indicate
on an unsupported description that it can't do so.
I hope the feedback is useful, sorry a little bit of it is somewhat off
topic.
William
List: axis-dev
Subject: Re: Message style services - ATTN ANY java:MSG USERS
From: "Rick Rineholt" <[EMAIL PROTECTED]>
Date: 2002-09-24 12:46:44
Why not support for public Element [] bodyAsDOMMethod(Element [] bodies)
also:
signatures:
org.w3c.dom.Document bodyAsDOMMethod(org.w3c.dom.Document
bodyElmementsInDocument) //root element namesp:name match SOAPBody
org.w3c.dom.Element bodyAsDOMMethod(org.w3c.dom.Element
rootElementContainingBodyElements) //ditto
IMO these are closer to handling messages as document oriented.
Rick Rineholt
"The truth is out there... All you need is a better search engine!"
[EMAIL PROTECTED]
