[omniORB] IDL semantics of event publication (including event payload)

[Tom O'Reilly]

My question is not omniORB-specific; my apologies if this is not the appropriate forum..
I'm implementing a "vehicle navigation service" that can supply information to clients in two ways:

1. "Synchronous": client obtains navigation service proxy through Naming service, then invokes IDL-defined operation to get position

2. Subscribe-publish: Client subscribes to "new position" events from the navigation service through CosNotification; the navigation service will then supply events - including vehicle coordinates as event "payload" - to CosNotification service, which will distribute to subscribers.


How to best express these two capabilities in IDL? The synchronous operation is obviously straightforward. But how do developer's (client and server programmers) know from the IDL that the service can publish "new position" events as well, and that the event "payload" includes the new position coordinates?

Here is an example of the IDL I am starting with;

module auv {

interface Navigation {

struct Position {
float latitude;
float longitutde;
float altitude;
};

// Synchronous operation to get vehicle position
void getPosition(out Position p);

// Define event name that client can subscribe to
const string NewPositionEvent = "NewPosition";

// How to express the event payload contents here, such that compiler enforces it???

};
};


Thanks,
Tom


--------------------------------------------------
Thomas C. O'Reilly
Monterey Bay Aquarium Research Institute
7700 Sandholdt Road
Moss Landing, California 95039-9644
831-775-1766 (voice)
831-775-1620 (FAX)
***@mbari.org (email)
http://www.mbari.org (World-wide Web)

"The machine does not isolate man from the great mysteries
of nature, but plunges him more deeply into them."

- ANTOINE DE SAINT-EXUPERY
"Wind, Sand, and Stars" (1939)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20070918/3de92079/attachment.htm

[Tuser]

In the COS notification service the IDLs are given. They are part of the
specification. You therefore do not define any IDL, except the layout of
your events.

If I remember correctly, the Notification service works with a structured
event (Value type), and you can therefore specialize the event. You must
also specify which parts of the event that subscribers can filter on. A
subscriber will receive an event, and thereafter have to down cast it to the
correct event type.

Hope this helps.

Post by Tom O'Reilly
My question is not omniORB-specific; my apologies if this is not the appropriate forum..
I'm implementing a "vehicle navigation service" that can supply
1. "Synchronous": client obtains navigation service proxy through Naming
service, then invokes IDL-defined operation to get position
2. Subscribe-publish: Client subscribes to "new position" events from the
navigation service through CosNotification; the navigation service will
then supply events - including vehicle coordinates as event "payload" - to
CosNotification service, which will distribute to subscribers.
How to best express these two capabilities in IDL? The synchronous
operation is obviously straightforward. But how do developer's (client and
server programmers) know from the IDL that the service can publish "new
position" events as well, and that the event "payload" includes the new
position coordinates?
Here is an example of the IDL I am starting with;
module auv {
interface Navigation {
struct Position {
float latitude;
float longitutde;
float altitude;
};
// Synchronous operation to get vehicle position
void getPosition(out Position p);
// Define event name that client can subscribe to
const string NewPositionEvent = "NewPosition";
// How to express the event payload contents here, such that compiler enforces it???
};
};
Thanks,
Tom
--------------------------------------------------
Thomas C. O'Reilly
Monterey Bay Aquarium Research Institute
7700 Sandholdt Road
Moss Landing, California 95039-9644
831-775-1766 (voice)
831-775-1620 (FAX)
http://www.mbari.org (World-wide Web)
"The machine does not isolate man from the great mysteries
of nature, but plunges him more deeply into them."
- ANTOINE DE SAINT-EXUPERY
"Wind, Sand, and Stars" (1939)
_______________________________________________
omniORB-list mailing list
http://www.omniorb-support.com/mailman/listinfo/omniorb-list

[Tom O'Reilly]

Tuser and Renny, you are both correct of course. The event "payload" object is packed into a CORBA::Any by the publisher, and unpacked by the subscriber, and my application successfully does this. But I was hoping that I could use the navigation service IDL to express the publication operation and various payload types in a way that is enforced by my C++ compiler. After all, software developers need to know what is inside the CORBA::Any payload. Documentation is one answer, but documentation can get out-of-date or programmers forget to include it. The IDL itself seems the ultimate documentation, since it is enforced at compile-time.

I am thinking of something like this:

module auv {

interface Navigation {

struct Position {
float latitude;
float longitutde;
float altitude;
};

// Synchronous operation to get vehicle position
void getPosition(out Position p);

// A PositionEvent is published by the navigation service when it computes a new
// vehicle position.
struct PositionEvent {

// Subscribers should filter on this name
const string name = "PositionEvent";

// Position object is the event payload
Position payload;
};

// The servant must implement a method to publish PositionEvents to
// COSNotification. NOTE: clients that want positional information will never
// call this event! Instead they will subscribe to
void publishPayload(in PositionEvent);
};
};

The problem I see with this approach is that potential client developers might be confused to see the publishPayload() operation; this operation should never be called by most clients. Rather, I define publishPayload() so that the service developer will be forced to implement publication of PositionEvents.

Is this a reasonable approach? Does anyone else worry about this kind of situation?

Thanks,
Tom



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20070919/a9389c5b/attachment.htm

[Tuser]

Tom,

Maybe I misunderstand what you try to do. I also clearly prefer compile time
type checking, as it always saves a lot of trouble later. But if you are
using the COS Notification 'as is' (?), then the IDL is given. There is
therefore no choice; you have to accept the limitations.

What we do is to 'wrap' the COS Notification interface. Simply create your
own provider/subscriber APIs with the IDL you have defined. In the APIs you
use the COS Notification service to issue/receive the events, and perform
the type checking and casting.

The API is linked in at the client side. It may seem weird to have an IDL
interface for an API, but remember that OmniOrb provides collocation, i.e.
the calls will be replaced by direct calls. Also means that the API can be
used from other implementation languages (but without collocation, i.e.
performance overhead).

Post by Tom O'Reilly
Tuser and Renny, you are both correct of course. The event "payload"
object is packed into a CORBA::Any by the publisher, and unpacked by the
subscriber, and my application successfully does this. But I was hoping
that I could use the navigation service IDL to express the publication
operation and various payload types in a way that is enforced by my C++
compiler. After all, software developers need to know what is inside the
CORBA::Any payload. Documentation is one answer, but documentation can get
out-of-date or programmers forget to include it. The IDL itself seems the
ultimate documentation, since it is enforced at compile-time.
module auv {
interface Navigation {
struct Position {
float latitude;
float longitutde;
float altitude;
};
// Synchronous operation to get vehicle position
void getPosition(out Position p);
// A PositionEvent is published by the navigation service when it computes a new
// vehicle position.
struct PositionEvent {
// Subscribers should filter on this name
const string name = "PositionEvent";
// Position object is the event payload
Position payload;
};
// The servant must implement a method to publish PositionEvents to
// COSNotification. NOTE: clients that want positional information will never
// call this event! Instead they will subscribe to
void publishPayload(in PositionEvent);
};
};
The problem I see with this approach is that potential client developers
might be confused to see the publishPayload() operation; this operation
should never be called by most clients. Rather, I define publishPayload()
so that the service developer will be forced to implement publication of
PositionEvents.
Is this a reasonable approach? Does anyone else worry about this kind of situation?
Thanks,
Tom
_______________________________________________
omniORB-list mailing list
http://www.omniorb-support.com/mailman/listinfo/omniorb-list