axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <>
Subject Re: Comments on pluggable provider support
Date Mon, 09 Apr 2001 18:02:26 GMT
Morgan Delagrange wrote:

> In Apache-SOAP, response serialization happens inside
> the Provider.invoke() method.  That design is somewhat
> limiting in my case.
> I'm trying to write an interface to SOAP that uses the
> SOAP services locally on the server _without_ using
> HTTP or serializing/deserializing envelopes.  But I
> can't really do it, because the pluggable providers
> serialize envelopes automatically.  What would be
> better, I think, is if pluggable providers did this
> instead:
>   locate()
>   invoke()
>   serialize()
> That way, one could choose to use a service without
> actually generating a serialized envelope by only
> invoking the first two provider methods.

if you are interested to see some existing SOAP implementation that is doing
it already you may want to check SoapRMI
( and see an example of mixing reference
to local and remote object transparently. when executing methods on local
objects SoapRMI do it directly without overhead of SOAP de/serializtion - an
example of mixing local/remote objects with JNDI is in

how was it designed?

similarly to what you described in locate() there is registry of remote
objects exposed locally - actually multiple registries that are called
dispatchers. when you do lookup to find web service it is using Services
object to convert XML describing remote endpoint into object stub.

if the remote object resides locally instead of returning dynamic SOAP stub
it returns handle to the object itself. this happens in
soaprmi.server.Services.createStartPoint(Port) where it calls
findLocalEndpoint - this method ask all registered dispatchers (each
dispatcher exposes objects implementing web services with some protocol such
as SOAP-RPC/HTTP) to check if they know about particular remote reference
(called here Port) :

  protected Object findLocalEndpoint(Port port) {
    // check dispatchers if there is local implementation
    for (Iterator iter = dispatchers.iterator(); iter.hasNext(); ) {
      Dispatcher dsptr = (Dispatcher);
      Object impl = dsptr.findObject(port);
      if(impl != null) return impl;
    return null;

  public RemoteRef createStartpoint(Port port)
    throws RemoteException
    Object obj = findLocalEndpoint(port);
    if(obj != null && RemoteRef.class.isAssignableFrom(obj.getClass())) {
      RemoteRef ref = (RemoteRef)obj;
      Port stubPort = ref.getSoapRMIPort();
      if(stubPort != null && stubPort.equals(port))
        return ref;
    //no local endpoint found - create stub
     Endpoint epoint = port.getEndpoint();
      for (Iterator iter = invokers.iterator(); iter.hasNext(); ) {
    Invoker invkr = (Invoker);
        RemoteRef ref = invkr.createStartpoint(
        if(ref != null)
          return ref;
    throw new RemoteException("cant get remote refernce to port "+port);

for details).

and here is the beauty of it: when object/stub is returned from lookup the
application does not care how method invocation are executed - it is
transparently either SOAP or very efficient local call.

it is not tested but it should work in servlets as well, see for an example of how to embed dispatcher in servlet


Aleksander Slominski, LH 316, IU,
As I look afar I see neither cherry Nor tinted leaves Just a modest hut
on the coast In the dusk of Autumn nightfall - Fujiwara no Teika(1162-1241)

View raw message