On Wed, 14 Sep 2005, Brian Lindahl wrote:
I need to generically intercept CORBA requests, queue them up until a
connection can be made to the real server (intermittent connections) and
then send the requests. The clients retrieve object references from a
naming service and invoke methods statically. They expect an exception
to be thrown when the connection is down (RequestPending). The objects
on the 'intermittent' server are static implementations.
OK, so you'd like to use this scheme?
C P S
| ----request-----> | |
| <cache|request> |
| <-RequestPending- | |
| | |
| | |
| <connection|succesfull> |
| | ---request---->|
| | <---reply-------|
| <discard|reply> |
| | |
where C is a client, P is an "invocation proxy" and S is a real target and
the connection bettwen C and P is "persistent" while connection between P
and S is "intermittent".
What I don't understand on your scheme is the usage of RequestPending
exception. The problem is: if P throws RP exc, then client receive it as a
request reply and after processing it it basically removes all the
structures kept by ORB for pending requests, hence P is not able to reply
real reply obtained from the server. That's why I added <discard reply> to
the picture above. Is this what do you expect from your system?
When a connection to the 'intermittent' server is finally made, we pop
'Request' objects off the pending queue and call 'invoke' for each of
them, recording any exceptions thrown (there are no return values, or
'out' values for these DII requests - they are ignored if they existed
in the initial 'client' request).
And what do you do with those recorded exceptions then?
Are there any problems with this approach? Is there a better approach?
Did I miss anything?
I'm not sure I 100% understand motivations behind your design. Well, if
the only issue is to make client communicate with server over the
intermitent connections, then I would probably go different way, either:
1) using some kind of proxy which will manage connection to the target
(validate_connection) and send the queued request when possible. Yes,
client's will be blocked till the time P invokes real target and get
appropriate reply
or
2) using AMI in combination with proxy P, the result the same as above,
but clients are not blocked.
both ways support standard CORBA requet/reply scheme, hence client will
receive all the required results of its request
(result/inout/out/exceptions) and there is not a need to make the system
complex by dividing processing of requests to client and replies to proxy
as seems to be the case with your design.
BTW: adding support for (1) to our ObjectWall[1] proxy daemon (our CORBA
firewall implementation) shouldn't be that hard, if you are really
interested in such system.
Cheers,
Karel
[1]: a little bit out-dated flyer:
http://www.objectsecurity.com/flyer/b4.pdf
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
---
Need experienced, fast, reliable technical MICO support?
---> http://www.objectsecurity.com/commsup.html <---
---
_______________________________________________
Mico-devel mailing list
[email protected]
http://www.mico.org/mailman/listinfo/mico-devel
