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: Remote references - future architectural idea
Date Tue, 11 Dec 2001 14:04:57 GMT
The idea is that the XML below is the return value (or an out param) of a
method call.  So the framework turns it into a Call for you and returns that
as a part of the deserialization process.  The more interesting case,
though, is the one where it returns a particular class (either a Stub or a
dynamic proxy).

--Glen

----- Original Message -----
From: "Doug Davis" <dug@us.ibm.com>
To: <axis-dev@xml.apache.org>
Sent: Tuesday, December 11, 2001 8:24 AM
Subject: Re: Remote references - future architectural idea


> I'm confused, who or what gets:
>  <foo xsi:type="axis:reference">
>   <wsdlLocation>http://myhost/axis/services/ref/0001?wsdl</wsdlLocation>
>  </foo>
> Where is this xml placed?  It kind of sounds like you're just defining
> another way of creating a Call object from WSDL which we already
> have.
> -Dug
>
> "Glen Daniels" <gdaniels@macromedia.com> on 12/11/2001 08:16:45 AM
>
> Please respond to axis-dev@xml.apache.org
>
> To:   <axis-dev@xml.apache.org>
> cc:
> Subject:  Remote references - future architectural idea
>
>
>
>
> I'd like to be able to define a schema type "axis:reference", which looks
> something like this:
>
>  <foo xsi:type="axis:reference">
>   <wsdlLocation>http://myhost/axis/services/ref/0001?wsdl</wsdlLocation>
>  </foo>
>
> The idea being that if you get one of these back, the engine handles
giving
> you back an appropriate object on which you can call methods. In the
> default
> case this is simply a Call pre-initialized to the right endpoint (either a
> "raw" transport URL or a WSDL doc).  Alternately, you could also specify a
> subtype of axis:reference:
>
>  <bar xsi:type"myNS:BankAccount">
>   <wsdlLocation>http://myhost/axis/services/ref/0002?wsdl</wsdlLocation>
>  </bar>
>
> This would map to a particular stub class, which would be again
initialized
> with the WSDL/endpoint in the serialization.  Another way to do this
> without
> explicit stubs would be to add a
> <proxyInterface>my.java.Class</proxyInterface> element to the
serialization
> and use the dynamic proxy support.
>
> On the server, you should be able to write your service like this:
>
> public class BankAccountManager {
>   public BankAccount createAccount(String accountNum)
>   {
>      return new BankAccount(accountNum);
>   }
> }
>
> public BankAccount implements AxisReferenceable {
>   ...
> }
>
> AxisReferenceable is assumed to be a marker interface which indicates that
> the object in question is "auto-deployable".  So as we're serializing the
> return value (and any outparams) from createAccount, we notice in the
> framework if any of those values implement AxisReferenceable.  If they do,
> we use a special Serializer which a) registers the service with the engine
> (in a way which probably does NOT permanently deploy the service into the
> server-config.wsdd) at a dynamically created URL, and b) writes a
> serialized
> XML reference as described above.
>
> An extension to this would be to allow the objects to implement
> AxisReferenceMetadata, which would have methods such as getIdleTimeout()
to
> control the lifetime of the objects.  Lifetime could also be handled
either
> completely by the user code (i.e. any references the engine makes to the
> remote-ref class are WeakReferences to avoid holding up GC), completely by
> the engine code (same thing in reverse - to make a remote reference you
> need
> to call some Axis code which returns you a WeakReference), or somewhere in
> between.
>
> Anyway, this is the basic idea.  What do you think?  I'd like to take a
> closer look at what other toolkits are doing in this regard, and perhaps
> try
> to make Axis compatibile with some of them.
>
> --Glen
>
>
>
>


Mime
View raw message