Hi Thomas:
I have a couple of questions relating to the dynamic stuff you're doing with Axis. 1) For Axis to successfully deserialize XML into parameters suitable for passing to a method invocation, we need to know the schema types of the XML elements. We can either get that information from the xsi:type attribute, or via metadata (i.e. introspecting the Java class, deployment info, etc). Do you rely on xsi:type being set for your stuff to work? It seems like the introspection we do (used to be in RPCElement, now in ServiceDesc) wouldn't pick up your "real" class and instead would get metadata for whichever class you specified in the deployment for the service... so how would you know how to deserialize untyped XML otherwise? 2) I'd like to clean up the code in RPCProvider which ends up trying different things to get the RPCElement to correctly resolve into a method call. My idea is to implement "early binding" as much as possible by hooking the mechanism by which we figure out how to deserialize into the method-dispatch. In other words, by the time we've succesfully deserialized a message, we should already be able to unambiguously determine which back-end method we're going to call. I want to do this in a way which still allows patterns like yours, but to understand just how to do that I'd like to talk about your usage patterns. Any chance you might be able to hop onto IRC for a real-time chat sometime today? Thanks, --Glen > -----Original Message----- > From: Thomas Börkel [mailto:[EMAIL PROTECTED]] > Sent: Friday, March 08, 2002 10:01 AM > To: [EMAIL PROTECTED] > Subject: RE: Proposed change for RPCProvider.java for Beta 1 > > > HI! > > I can describe how I did it: > > I have ONE service deployed (I can provide the deployment > wsdd, if you want, I deploy at runtime with a string) with a > dummy class and method and my own transport always tells Axis > to use that one service. Also, the transport sets the real > class name as property in the MessageContext. > > For the service, I have defined my own provider. This > provider ignores the class and object that Axis gives to the > provider in processMessage() and instead reads the class name > from the MessageContext. > > It is required to have your own transport if you want to do > it that way, AFAIK. > > An alternative to my method, would be for the transport to > deploy the services/classes dynamically at the first call to > this class. This way, Axis would get the real class and > object and give it to my provider. This is a change I *may* > make sometime. > > With the proposed change, I can derive from RPCProvider, > override some methods and implement my own method search, > invocation and security with little effort. Before, I derived > from JavaProvider and copied the SOAP request analyze and > SOAP answer compose code from RPCProvider. > > The reason, we needed invocation without deployment is the > fact, that we expose around 200 java classes as web services. > To keep the Java classes always in sync with the deployment > WSDDs during development (the client comes also from us) > would be a real pain. > > Requests for WSDL are satisfied on the fly. > > If you need further information, feel free to ask. > > Regards, > Thomas > > > -----Original Message----- > > From: William Lee [mailto:[EMAIL PROTECTED]] > > Sent: Freitag, 8. März 2002 12:30 > > To: [EMAIL PROTECTED] > > Subject: Re: Proposed change for RPCProvider.java for Beta 1 > > > > > > Changes posted by Thomas Börkel seems to be related to my > proposal on > > implementing the dynamic RPCProvider, is there any more > > information on > > how to perform your "invocation without deployment" in the > > Axis framework? > > > > William Lee > > > > Thomas Börkel wrote: > > > > > HI! > > > > > > I have made a few minor changes (only extract code from > > processMessage() to seperate methods) in RPCProvider.java > > (please find attached) that allow us much more easily to do > > our own invocation without deployment (one service deployed > > for all our classes). > > > > > > These are the changes: > > > - added MessageContext parameter to getMethod() > > > - added method invokeMethod() > > > - added method checkMethodName() > > > > > > It would be EXTREMELY helpful, if you could commit these > > changes into Beta 1. > > > > > > Thanks! > > > > > > Regards, > > > Thomas > > > > > > > > > > > > > > -- > > > > William Lee > > > > Imperial College of Science Technology and Medicine > > Room 354, Department of Computing, > > 180 Queen's Gate > > London SW7 2BZ, U.K. > > > > email:[EMAIL PROTECTED] > > web:www.image-union.com > > > > > > >
