Thread: [Embedlets-dev] Re: Event Manager
Status: Alpha
Brought to you by:
tkosan
Menu
▾
▴
embedlets-developer
|
From: Andrzej J. T. <an...@ch...> - 2003-02-22 22:56:29
|
Ted asks:
> If the Embedlet produces SwitchEvents, does this mean that every other
> Embedlet in the application that consumes SwitchEvents will be forced to
> subscribe to this event source?
>
> What if one had 10 JAPL input bits that were being polled by 10 Embedlets
> which all generated SwitchEvents? Would all SwitchEvent consumers in the
> application be forced to subscribe to all of these event sources?
The Embedlet Event Manager service will provide the ability for an event
consumer to specify criteria for the events they want to receive, and
this will include more than just the "type" of the event (since that is
pretty coarse grained).
You'll be able to subscribe to events by:
- event type
- producer (specific sender)
- various other properties (either user or system properties in the
event).
- Any combination of the above.
So a particular event consumer (eg. an embedlet) will be able to receive
only the events it really wants to get and no others.
Might also add the ability for a producer to specify a specific
consumer(s) that are allowed to receive a specific event (might be useful
for security).
Does that answer your concern, Ted?
...Andrzej
Chaeron Corporation
http://www.chaeron.com
|
|
From: Andrzej J. T. <an...@ch...> - 2003-02-24 21:55:05
|
Gregg suggests: > We wanted to do all of these, and Jini LUS users want all of these. But > in the end, it is simpler to limit the criteria. For pub/sub, I'd still > suggest a simple hierachial topic string system, and that you should just > include the appropriate parts in the topics. Predefined topic trees would > be beneficial, but using properties to configure modules to use the > appropriate topic simplifies the whole mess by delaying this issue till > deployment which can allow some modules to be used in ways that were not > originally in the design. > > control.switch.off.1.<producer> > > is an example topic, where everything is specified. In a topic system, at > deployment time, you could match with > > control.switch.*.1.* I like it. It's a nice way to keep things simple, provides some optimization opportunities along the way, and gives the developers a very extensible event typing/matching system that should be more than enough for their needs in the embedded space. Unless anyone has any objections (or better suggestions), I'll structure the Event Manager Service specifications along these lines. The only thing I think I would do differently is to keep the <producers> and/or <consumer> critera out of the topic string, since this would allow for much more efficient filtering on the part of the Event Manager without adding much in the way of complexity for the developer. Conceptually, it also keeps things a touch clearer since who produced (or should be allowed to consume an event) is not really part of the event type (or topic). > I do have a broadcast 'space' that includes single copy delivery in a mesh > environment, and topic based pub/sub, that I am willing to 'donate' to the > cause... Is this a JINI space? ...Andrzej Chaeron Corporation http://www.chaeron.com |
|
From: Ted K. <tk...@ya...> - 2003-02-22 23:41:52
|
Andrzej stated, > The Embedlet Event Manager service will provide the ability for an event > consumer to specify criteria for the events they want to receive, and > this will include more than just the "type" of the event (since that is > pretty coarse grained). > > You'll be able to subscribe to events by: > > - event type > - producer (specific sender) > - various other properties (either user or system properties in the > event). > - Any combination of the above. > > So a particular event consumer (eg. an embedlet) will be able to receive > only the events it really wants to get and no others. > > Might also add the ability for a producer to specify a specific > consumer(s) that are allowed to receive a specific event (might be useful > for security). > > Does that answer your concern, Ted? Yes, the more we discuss the publish/subscribe model the more I am grasping it and now I am looking forward to playing with it too! What is your perspective on JavaOS's Bidirectional Events (section 3.5)? Ted __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
|
From: Nicola K. B. <nic...@ap...> - 2003-02-23 00:19:16
|
Ted Kosan wrote, On 23/02/2003 0.41: > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Andrzej stated, ... > Yes, the more we discuss the publish/subscribe model the more I am grasping it > and now I am looking forward to playing with it too! In the PLC world, the publish/subscribe model is IMHO a killer feature. We have seen that it makes it much easier to do stuff, and can greatly decrease timing problems. It was even mentioned in this JSR: http://www.jcp.org/en/jsr/detail?id=50 [does anyone know what happened to all these automatiuon JSRs?] Here where I work, it seems that Rockwell Automation seems to gain ground with de-facto standards: http://www.ab.com/catalogs/b113/comm/ethernet.html http://www.ab.com/catalogs/b113/comm/cnet.html http://www.ab.com/catalogs/b113/comm/dnet.html Here are other links to some related stuff I bookmarked. http://ethernet.industrial-networking.com/articles/i12protocols.asp http://www.macrolinx.com/document/rel/industry-Ethernet-Control-Solutions.pdf http://www.manukau.ac.nz/departments/e_e/research/2002/kb.pdf -- Nicola Ken Barozzi nic...@ap... - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- |
|
From: Gregg G. W. <gr...@sk...> - 2003-02-25 01:01:48
|
>The only thing I think I would do differently is to keep the <producers> >and/or <consumer> critera out of the topic string, since this would allow >for much more efficient filtering on the part of the Event Manager >without adding much in the way of complexity for the developer. control.switch.*.1.< specifies the limit of processing level in the hierarchy... This allows information to be excluded from the match when it is not important. Thus, the hierarchy of the topic tree goes from least specific to most specific information to aid in providing convienent cutoff points. >Conceptually, it also keeps things a touch clearer since who produced (or >should be allowed to consume an event) is not really part of the event >type (or topic). But, it can be important for debugging event traffic through the system. And since it is a broadcast mesh, you can connect external monitoring to the space to watch what is happening without having to instrument the system internally. >> I do have a broadcast 'space' that includes single copy delivery in a mesh >> environment, and topic based pub/sub, that I am willing to 'donate' to the >> cause... > >Is this a JINI space? No, it is a space modeled after the Object Space voyager space. I used voyager off and on in different pet projects for some time. But, it had certain problems due to its design. So I took the parts of their API that I used most, and wrote a new implementation without those problems, and some optimizations. ----- gr...@cy... (Cyte Technologies Inc) |
Thanks for helping keep SourceForge clean.
X