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]
