[omniORB] CORBA Design Questions

[Meding, Olaf]

We are investigating using CORBA / omniORB / omniORBpy for an
application that controls hardware. The client will send commands to
the server / hardware (that part is easy).

Here are the two parts I like some high level design advice on to get me
started.

*** First, how do I implement the server sending unsolicited status
information back to the client?

*** Secondly (and more importantly), how do I implement the client
sending an abort type command to the server? The important part is that
the abort command needs to be send immediately (even if another command
or a response to a command potentially sending large amounts of data is
in progress).

There will be a single server but there can be multiple clients.

I have worked with CORBA and omniORB a few years ago, so I know the
basics. Many thanks for your help to get me started.

Olaf

[Wernke zur Borg]

Hi Olaf,

Post by Meding, Olaf
We are investigating using CORBA / omniORB / omniORBpy for an
application that controls hardware. The client will send commands to
the server / hardware (that part is easy).
Here are the two parts I like some high level design advice
on to get me
started.
*** First, how do I implement the server sending unsolicited status
information back to the client?

There are multiple options; I can suggest a solution that has been
working fine for me. You define a listener (callback) interface in your
IDL. This interface is implemented by the client and used by the server.
With the first server call the client passes the IOR of a listener
object to the server, then the server can asynchronously call back the
client.

Post by Meding, Olaf
*** Secondly (and more importantly), how do I implement the client
sending an abort type command to the server? The important
part is that
the abort command needs to be send immediately (even if
another command
or a response to a command potentially sending large amounts
of data is
in progress).

Your server will by default be multithreaded, therefore, a call of a
(possibly oneway) abort() method will be executed by the server while
other operations may be in progress. Interrupting these ongoing
operations will be an implementation task for your application. Also
your client must be ready to call abort() while other operations are
blocking, therefore your client will have to be multithreaded as well.

Post by Meding, Olaf
There will be a single server but there can be multiple clients.

Solutions depends on how tightly server and client are coupled. If the
server must get aware of client "disconnections" the concept of a
session oriented protocol will be of benefit. Just in short: A session
can be opened and closed by the client. The server can abort a session
with a callback on the SessionListener interface. Optionally, a
heartbeat protocol ensures to both sides that the other side is still
alive.

I do not know if this concept fits your needs; other people may have
other ideas for you. You can mail me if you are interested in more
details.

Regards, Wernke