axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <gdani...@macromedia.com>
Subject RE: Proposed change for RPCProvider.java for Beta 1
Date Mon, 25 Mar 2002 17:29:08 GMT

The standard Axis developer hangout is on DALNet (irc.dal.net), channel #ApacheAxis.  If you
have time now, I'd love to talk about this stuff - I should also be on tomorrow morning from
about 9AM eastern US time (which is, I think, 7 hours back from Germany?).

--Glen

> -----Original Message-----
> From: Thomas Börkel [mailto:tb@ap-ag.com]
> Sent: Monday, March 25, 2002 12:19 PM
> To: axis-dev@xml.apache.org
> Subject: RE: Proposed change for RPCProvider.java for Beta 1
> 
> 
> HI!
> 
> 1) We extend RPCProvider and override some methods of it. I 
> have attached 2 code fragments of our server. 
> I think, you're right. If we would get untyped XML, we would 
> have a problem. If we could set the class and method earlier 
> (right before AxisServer.invoke()), so that Axis would ignore 
> the deployed service, then it should work. Otherwise we would 
> have to deploy dynamically every time a class is used for the 
> first time. :-(
> Also, if you clean up RPCProvider: We still need to do our 
> own method invocation, because we have our own method cache, 
> security and error logging.
> 
> 2) I am here for another hour or so. So, if you want to chat 
> now, please tell me which server and channel. Otherwise we 
> could arrange for some time tomorrow (starting from 10:00 AM 
> german time).
> 
> Regards,
> Thomas
> 
> 
> 
> > -----Original Message-----
> > From: Glen Daniels [mailto:gdaniels@macromedia.com]
> > Sent: Montag, 25. März 2002 17:31
> > To: 'axis-dev@xml.apache.org'
> > Subject: RE: Proposed change for RPCProvider.java for Beta 1
> > 
> > 
> > 
> > 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:tb@ap-ag.com]
> > > Sent: Friday, March 08, 2002 10:01 AM
> > > To: axis-dev@xml.apache.org
> > > 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:wwhl@doc.ic.ac.uk]
> > > > Sent: Freitag, 8. März 2002 12:30
> > > > To: axis-dev@xml.apache.org
> > > > 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:wwhl@doc.ic.ac.uk
> > > > web:www.image-union.com
> > > > 
> > > > 
> > > > 
> > > 
> > 
> 

Mime
View raw message