axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject Re: Remote references - future architectural idea
Date Tue, 11 Dec 2001 16:27:31 GMT
hi,

here is how another toolkit is doing - in XSOAP (formerly SoapRMI
source code available at http://www.extreme.indiana.edu/soap/) we represent remote
reference (called Port) as containing three parts:
1. name - this is optional and in XSOAP is only for readability - in component system
    such as XCAT that may be the name of component port
    (as defined in CCA spec http://www.cca-forum.org/specification/spec/)
2. interface that this remote reference is implementing that is identified by QName
    represented as a pair (uri, name) that is used to lookup actual java corresponding
interface
    this PortType QName should be of course defined elsewhere as WSDL PortType
3. endpoint - that is how to contact remote endpoint
        locations - just URL of remote location
        binding - this is placeholder for protocol binding specific information

here is example form our hello sample - that is the port that is bound
to XSOAP registry  (that works similarly to JavaRMI registry but can be also just JNDI):

<port id='id1' xsi:type='ns1:port'
xmlns:ns1='http://www.extreme.indiana.edu/soap/rmi/port/v10/'>
  <name xsi:type='xsd:string'>GUID_1008087077039_1092172062_1</name>
  <portType id='id4' xsi:type='ns2:port-type'
xmlns:ns2='http://www.extreme.indiana.edu/soap/rmi/port/v10/'>
     <uri xsi:type='xsd:string'>urn:soaprmi-v11:temp-java-port-type</uri>
     <name xsi:type='xsd:string'>hello.HelloService</name>
   </portType>
  <endpoint id='id2' xsi:type='ns2:endpoint'
xmlns:ns2='http://www.extreme.indiana.edu/soap/rmi/port/v10/'>
    <location
xsi:type='xsd:string'>http://192.168.1.40:1307/GUID_1008087077039_1092172062_1</location>

    <binding id='id3' xsi:type='ns3:binding'
xmlns:ns3='http://www.extreme.indiana.edu/soap/rmi/port/v10/'>
      <name xsi:type='xsd:string'>GUID_1008087077039_1092172062_1</name>
     </binding>
  </endpoint>
</Port>

for details see:
    http://www.extreme.indiana.edu/soap/rmi/design/ (Remote Reference sections)
    and check source code of XSOAP in particular:
    src/java/soaprmi/soaprpc/soaprmi/server/RemoteRef.java
    src/java/soaprmi/port/soaprmi/port/*.java
    (available also online at:
http://www.extreme.indiana.edu/soap/rmi/download/xsoap_1_2)

our current thinking is that we must be based more on WSDL. the remote reference
above already looks a lot like subset of WSDL so why not to move just one step
ahead and instead of having proprietary remote reference format just use
WSDL _as_ remote reference (simply containing one Port, Binding and PortType)?

maybe we could get one WSDL agreed upon then work on example of remote reference,
express it using different approaches and finally agree about evolutionary direction
how interoperable remote reference should look?

thanks,

alek

Jacek Kopecky wrote:

>  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
>  > >
>  > >
>  > >
>  > >
>  >
>
>   -----------------------------------------------------------------------------------
>                     Name: interrefs.xsd
>    interrefs.xsd    Type: Plain Text (TEXT/PLAIN)
>                 Encoding: BASE64


Mime
View raw message