axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacek Kopecky <ja...@systinet.com>
Subject Re: Remote references - future architectural idea
Date Tue, 11 Dec 2001 15:31:08 GMT
 Glen,
 in our remote reference structure we have a few things more than
the wsdl URL:
 1) The service QName - we view the WSDL service as mapping
directly to a Java class, a WSDL portType mapping directly to an
interface, so a class can implement more interfaces as a service
can have more portTypes (via different ports).
 2) [optional] instanceID - if it's needed, feel free to ask
about our instanceID extension
 3) [optional] information on the mapping from WSDL portTypes to
Java interfaces (for zero-configuration best-case scenario in
deploying web services).
 See the attached schema.
 Anyway, our plan is that when interoperability in this field can
be worked on (which seems to be the case now), the schema would
be tweaked to fit everybody, and probably the optional members
would become fully namespace qualified, signifying extensions to
the remote reference structure.
 What do you think? We would be very happy if this effort focused
on interoperability from the start. BTW, I'm the person from the
WASP team who's responsible for remote references (and
instanceID, too), so it's me who's gonna work with you all on
this. 8-)
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Tue, 11 Dec 2001, Glen Daniels wrote:

 > 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