axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <...@us.ibm.com>
Subject Re: Remote references - future architectural idea
Date Tue, 11 Dec 2001 13:24:18 GMT
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