[AltRMI] Pass-by-reference redirection

[Paul Hammant <Pa...@yahoo.com>]

*Redirection*

We've identified the need for ServerA to tell ClientA that the refernce 
required should actually be got from ServerB.  As such, it needs to pass 
back a redirection reply that communicates the location of the 
redirected resource.  We think that some JDBC inspired driver string 
would be the right thing:

  "altrmi:transport-type:host-details:service-name:reference-id"

Related to this we could have a factory impl (avoided thus far) that 
would allow the above scheme to be used client side for provision of the 
factory that performs lookup(..)

*HostFactoryProviders*

We should allow some sort of pluggable or chainable provders to the 
factory.  The last thing we want is something that thunks itself in like 
the XML parser in the SAX API.

Thoughts?

- Paul


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [AltRMI] Pass-by-reference redirection

[Paul Hammant <Pa...@yahoo.com>]

Vinay,

>> "altrmi:transport-type:host-details:service-name:reference-id"
>
>
>*Redirection* would also imply a protocol(REQUEST obj
>maybe )
> which allows ServerB to tell ServerA to register a 
>remote object for him .
>
I was thinking of a solution for the immedate need (refer EOB people 
example) :

Server 1 (Bean 1)  Address Factory, Manages Address
Server 2 (Bean 2)  People Factory, Manages People and their addresses

Client 1 (Bean 3) :
   Gets Bean1, makes a person.
   Gets Bean2 makes an address.
   For its person remote ref, on bean1 sets the address to that made above.

In this case the ref the client has a problem in that it is trying to 
pass a remote ref from server 1 to server 2.  Of course the client knows 
nothing of this.  Anyway, to summarise, the two servers have instances 
already, it is just that for one setAddress method in server 2, the 
adress being used is also from a remote reference.  This is the area 
that EJB steps into keys for to solve.  Maybe this goal (to have a 100% 
reference solution) is impossible.

So I don't think the immedaite need is for "ServerA to register a remote 
object for him ", but for "serverA to tell server B that it has a remote 
inst that is being held for it" .....  For the immediate need anyway.

Regards,

- Paul H
 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [AltRMI] Pass-by-reference redirection

[vinaysahil chandran <sa...@yahoo.com>]

> *Redirection*
> 
> We've identified the need for ServerA to tell
> ClientA that the refernce 
> required should actually be got from ServerB.  As
> such, it needs to pass 
> back a redirection reply that communicates the
> location of the 
> redirected resource.  We think that some JDBC
> inspired driver string 
> would be the right thing:
> 
>  
>
"altrmi:transport-type:host-details:service-name:reference-id"
> 

*Redirection* would also imply a protocol(REQUEST obj
maybe )
 which allows ServerB to tell ServerA to register a 
remote object for him .

Flow of REQUESTs:

=====================
i) REMOTE PUBLISH
======================

          publishREQUEST(serviceName,server(b)
details)
SERVER(b)
-------------------------------------------->SERVER(a)


=================
ii) CLIENT 
=================

       openconn.
Client --------> Server(a)
        
       Lookup(serviceName)
       --------> Server(a) 
                             Lookup
                            ----------> Server(b)
                            LookupReply
                            <---------- Server(b)

        RedirectReply
        (altrmi:type:host:serviceName)
       <-------- Server(a)

                Class Request
Client --------------------------------> Server(b)
                Method Request
       --------------------------------> Server(b)
                               



makes sense.

V i n a y.


__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>