Thread: [Embedlets-developer] Re: General event mechanism
Status: Alpha
Brought to you by:
tkosan
Menu
▾
▴
embedlets-developer
|
From: Ted K. <tk...@ya...> - 2003-01-13 21:15:46
|
Andrzej,
>Where is the info/discussions on these interfaces? I
wanted to review that
before I post some thoughts to the Embedlet list...
Well, after I realized that people were probably somewhat
busy getting into the new year I posted the 'Embedlet
Challenge' idea so that I could start exploring Embedlets
from the perspective of the wiring tool. I think that the
discussion about the interfaces we are looking for will
probably start right now.
I have been using the Elevator challenge to explore how
various interface ideas play inside of a graphical wiring
tool mockup that I threw together (for now I am just
focusing on the event mechanism). Over the weekend I came
to the conclusion that the SignalSender and SignalReceiver
interfaces would need to be made more general.
I looked through the Embedlet traffic we generated on the
JStamp list and actually I found a post or two from you
that talked about a very general Event mechanism. At that
time I did not have a good feel for why a general event
mechanism was superior to a more tailored Event mechanism
(like what is present in AWT) but after playing with the
wiring tool mockup for the past couple of weeks I think I
understand this better now.
So, here is what the SignalSender/SenderReceiver event idea
evolved into:
public interface EventSender
{
add(type of operation)Receiver(EventReceiver er);
remove(type of operation)Receiver(EventReceiver er);
EventReceiver[] get(type of operation)Receivers(); //get
the receivers for a specific type.
EventReceiver[] getAllReceivers(); //get a list of all
receivers
set(type of operation)Properties //Temporal
properties, etc.
get(type of operation)Properties
}
public interface EventReceiver //All Embedlets implement
this interface.
{
receiveEmbedletEvent(EmbedletEvent ee);
}
For the Elevator Embedlet the following EventReceiver
registration methods might be present:
addFloorReceiver(EmbedletReceiver er); //For receiving
Floor events like 'SetDirectionLights' and
'SetCurrentFloorDisplay'.
addShaftReceiver(EmbedletReciever er); //For receiving
Shaft events like 'MoveElevator'.
The main way that a general event mechanism seems to differ
from a more specific event mechanism like AWT's is that the
type of 'Listener' passed into an AWT addXXXListener method
is Listener type specific while the 'Listener' (Receiver)
in a more general mechanism uses a single type of listener
(in this case org.embedlet.EvenReceiver).
It also appears to me that, in a general event system, the
type of the Event is used to indicate what to do with the
event. For example, if all Embedlet events inherit from
EmbedletEvent then the Elevator Embedlet can send
FloorEvents through the general event mechanism to
controllers that are responsible for running each floor and
ShaftEvents to the controller's that are responsible for
running each elevator shaft, etc.
Different EmbedletEvent types are created to handle all
event needs.
Are these the kind of ideas you were referring to when you
talked about a 'general event mechanism'?
Ted
--- Andrzej Jan Taramina <an...@ch...> wrote:
> Ted:
>
> > So far the 6 interfaces I started with have been
> reduced to
> > the following 2:
> >
> > SignalSender and SignalReceiver
>
> Where is the info/discussions on these interfaces? I
> wanted to review that
> before I post some thoughts to the Embedlet list.....
>
>
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
>
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
|
|
From: Andrzej J. T. <an...@ch...> - 2003-01-26 21:48:27
|
Ted discusses the event mechanism:
> I looked through the Embedlet traffic we generated on the
> JStamp list and actually I found a post or two from you
> that talked about a very general Event mechanism. At that
> time I did not have a good feel for why a general event
> mechanism was superior to a more tailored Event mechanism
> (like what is present in AWT) but after playing with the
> wiring tool mockup for the past couple of weeks I think I
> understand this better now.
> Are these the kind of ideas you were referring to when you
> talked about a 'general event mechanism'?
Not quite.....I don't like the use of a the event type specifier in the Event
Sender interface (see below), and there is probably no need for that.
The bones of the event management should probably be provided by an
Outpost Container service. So if you need to receive events you would
implement the EventConsumer interface and specify in the XML config file that
you want to receive events and of what kind (more on that later). Same thing if
you want to send events...you implement EventProducer and specify in the
XML that you will create events and of what type. Both interfaces will have a
method that allows you to get a reference to the Container's Event Service,
which you actuall do calls on. Something like this (for a listener).
public interface EventConsumer
{
public void receive( EmbedletEvent e );
}
Registration of the EventConsumer should be done transparently by the
Container! The component lifecycle (create/start/stop/destroy for instance)
would guarantee that you would not receive any events till after the start()
method was invoked, ensuring that your component was suitably initialized
first. All part of the Container responsibilities.
In the XML config defining an Embedlet that is an EventConsumer, you would
specify what types of events you wanted to receive.
That's the easy case, and is almost identical to Ted's example, but let's look
how an event sender might actually send a new event:
EmbedletEventService eventService = Outpost.getEventService();
EmbedletEvent event = eventService.getEventInstance();
event.setType( typeSpecifier );
// ...do some stuff with the event you want to send. Set data, etc.
eventService.send( event );
Note that with this approach the EventService could automatically ensure that
the Embedlet is only sending events of the types specified in the config XML (a
very useful cross-check). It also simplifies the Embedlet code, since the
container handles the routing of events to registered listeners....the Embedlet
doesn't care nor does it need to know.
What is a bit tricky is how to specify the Event Type in a globally unique way,
since you don't want a developer to end up with a situation where the event
types were duplicated by two different embedlets/components, for different
purposes.
One way is to use integers as event types, with a single EmbedletEvent class,
which is handy since it's compact and processing them is quite efficient (rather
than string compares), and you can use Select/case constructs in a single
receive() method to distinguish between different events. But the issue there
is how to ensure that different event types don't reuse the same integer
specifier.
One approach that bears investigation is where there is a base class (possibly
abstract) that is an EmbedletEvent. Specific types are created as subclasses
of the base class. The component's XML config file then would specify which
fully qualified Event subclasses it either consumed or produced, along with a
method to be called upon receipt of such an event. For instance, the XML
descriptor for an Embedlet that both sends and receives events might look
like:
<embedlet name=ChaeronGPS" class="com.chaeron.embedlets.GPS" >
<events>
<consumes class="com.chaeron.embedlets.events.NMEASentence"
method="receiveNMEASentence" />
<consumes class="com.chaeron.embedlets.events.GarminPacket"
method="receiveGarminPacket" />
<produces class="com.chaeron.embedlets.events.GPSEvent" />
<events>
</embedlet>
This would allow you to create a generic receiver method (that takes a
EmbedletEvent superclass and then do instanceof() comparisons) or multiple
methods that each receive a single specific event type (class).
Either runtime reflection or construction-time code generation could be used to
provide the glue between the container and the component for the event
handling, depending on the Outpost implementation being used.
What is interesting is that this approach could work for both threaded and co-
operative models of execution. We'ld need to design the Embedlet contract in
such a way that co-operative processing is possible, for those platforms where
threads are not available. The container can optionally use threaded
execution of the components if such is supported. Otherwise, it basically uses
the events to schedule execution across multiple components in a serial
manner. This means that all Embedlet operations should be conducted via
events (eg. writing to a back end server should be done by sending an
appropriate event that will perform the communication). Events could have a
priority value so that there would be some way to prioritize their execution as
well.
> So, here is what the SignalSender/SenderReceiver event idea
> evolved into:
>
>
> public interface EventSender
> {
> add(type of operation)Receiver(EventReceiver er);
> remove(type of operation)Receiver(EventReceiver er);
> EventReceiver[] get(type of operation)Receivers(); //get
> the receivers for a specific type.
> EventReceiver[] getAllReceivers(); //get a list of all
> receivers
>
> set(type of operation)Properties //Temporal
> properties, etc.
> get(type of operation)Properties
> }
>
> public interface EventReceiver //All Embedlets implement
> this interface.
> {
> receiveEmbedletEvent(EmbedletEvent ee);
> }
>
>
> For the Elevator Embedlet the following EventReceiver
> registration methods might be present:
>
> addFloorReceiver(EmbedletReceiver er); //For receiving
> Floor events like 'SetDirectionLights' and
> 'SetCurrentFloorDisplay'.
>
> addShaftReceiver(EmbedletReciever er); //For receiving
> Shaft events like 'MoveElevator'.
>
>
>
> The main way that a general event mechanism seems to differ
> from a more specific event mechanism like AWT's is that the
> type of 'Listener' passed into an AWT addXXXListener method
> is Listener type specific while the 'Listener' (Receiver)
> in a more general mechanism uses a single type of listener
> (in this case org.embedlet.EvenReceiver).
>
>
> It also appears to me that, in a general event system, the
> type of the Event is used to indicate what to do with the
> event. For example, if all Embedlet events inherit from
> EmbedletEvent then the Elevator Embedlet can send
> FloorEvents through the general event mechanism to
> controllers that are responsible for running each floor and
> ShaftEvents to the controller's that are responsible for
> running each elevator shaft, etc.
>
> Different EmbedletEvent types are created to handle all
> event needs.
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
|
|
From: Ted K. <tk...@ya...> - 2003-01-27 09:15:49
|
Andrzej, I read through your event mechanism description and, believe it or not, it is almost identical to the event mechanism that was developed for JavaOS. I think the fact that you independently came up with an event mechanism that is very close to the event mechanism that the pricipal designer of Apple's PCI device driver architecture, Sun and IBM arrived at after years of effort is significant. Here is the summary that is at the end of the Event System chapter in the JavaOS book: "There are several advantages to using an event broker. Consumers can register in one place to receive events from all producers of events of that type. New producers of the event type can be added at any time, and existing consumers of the event type will automatically receive events from the new producer. Event queuing and dispatch code are centralized, and event delivery can be prioritized." As for the event types themselves, we both ended up going with one EmbedletEventListener interface and multiple event types which inherit from a single EmbedletEvent class. The fully qualified names of the event sub-classes seem to be an elegant way to globally uniquely identify event types. Where our current approaches differ is 1) direct event registering vs.using an event broker and 2) having multiple interfaces for registering event listeners on a event producer vs. having one generic event registration interface for all producers. I have read through the JavaOS event chapter multiple times and I have heavily marked it up. There are a number of things I really like about the event broker approach. The two things I am presently unsure of are whether or not an event broker still allows software components to be wired together graphically and whether or not it is too heavyweight an approach for the needs of an embedded system. JavaOS is a full blown operating system that requires a lot of thing to happen dynamically. I am not sure how dynamic a typical embedded system needs to be. I think that some more discussion on this topic and some experimenting would be sufficient to clarify these two issues for me. Is there any chance that I could persuade you to obtain a copy of the JavaOS book (Inside the JavaOS Operating System, Saulpaugh and Mirho, Addison-Wesley, ISBN 0-201-18393-5, available from Amazon) so that we can discuss the merits of an event broker approach using a working and proven example as a starting point? Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-01-27 15:41:33
|
Gregg: > A vaching topic (String based) mechanism can be just as fast, as it can > assign an numeric value to a string based topic on the first use. This > allows the numbers to be different between JVMs, but intra-JVM numbering > is consistent through the use of a factory. True, but an inheritence based approach for Events is simpler/faster and has the added advantage that events could be sent out of the JVM as well. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-01-27 17:57:38
|
Gregg said: > Events are completely separate from topics in my book... Events carry > data, topics tell you why the data is comming... They are in my book too! However, Event Types are equivalent to topics in many situations. I should have been a bit clearer and specified that I was considering types and topics as more or less the same thing for an event management system. > In the embedlet system, we can't make serialization and/or classloading a > requirement. No argument there. Though I would love to have dynamic classloading on aJile chip-based systems (like a JStamp). > Thus, stuff sent between JVMs needs to be repackaged apon > exit and entry to any JVM. That is just a form of serialization (I'm using the term more generically than as the used in the Java object serialization API). You always have to serialize/deserialize data for on-the-wire transport. > This is the fundamental need to meet protocol > neutralization too. Transport has to use a single, trivial to change > representation. XML is one, but is somewhat verbose for very small, low > speed (cheap RF) networks. XML is about the only standardized, neutral way to handling this. It can be verbose....but that can be mitigated pretty easily (use shorter tags), and typically sending an event does not generate very big XML payloads, so in all but the most constrained environments, I don't think it's worth using a proprietary protocol instead of XML. Besides, if the application is architected correctly, then the transport protocol/encoding would/should be de-coupled from the application, in which case if you run into bandwidth issues with XML, then you just replace the transport layer with something more efficient. > Byte arrays are compact, but more difficult to > manage. We, historically, have used byte arrays in our solutions. We use > XML to describe the structure of the data, and have a DOM based parser > that builds an expression tree out of the document which is then executed > for field extraction. Slightly more complex, but infinitely flexible > because we can inject user coded evaluators/extractors to get data out of > any container, byte array, or otherwise... Nice approach! To use something similar for embedlets, it would probably be better to read the XML and then code generate Java that would do the construction/extraction of the binary data, just for performance reasons. This would not be hard to do. But above all else, a plug-n-play approach to transport protocols and packaging is required, since then you can switch things around as you need it (if you need it). Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-01-27 19:27:50
|
Gregg: > In a sense, yes it is serialization :-) But it's not 'native' so I tend > to not call it Serialization... Just terminology differences to try and > not confuse folks, causing them to think I am using Serializable Objects. You call it tomato....I call it tomatoe! ;-) > In many environments, there are so many points to monitor, and the > revenue from those sources is so small, that every opportunity must be > taken to reduce per unit cost. If a unit requires extra bandwidth that > doubles the networking resources required (speed and/or bandwidth), > then certain steps must be taken. XML over the wire is a limiting > factor instead of an enabling factor in many such applications. There > must be a choice... We're in violent agreement I think....you should be able to switch out the protocols and encodings transparently. I just don't think you should do this till you hit a situation where you absolutely have to is all. In general, when building apps, optimization and performance tuning, if done too early, can waste a lot of effort for very little (or no) gain. But the capability to do the tuning/optimization must be there of course. > I am mainly concerned about data gathering issues, not general embedded > Java applications on remote devices that may or may not provide > information to the world... So... Well...that's a valid viewpoint, but I think Embedlets need to be a bit more generic and capable that just data gathering devices. > My grand plan, would let you create a complete XML base spec of data > packaging, poll scheduling, publish timing, extraction etc so that I could > FTP the XML to the outpost device and it would do the right thing. I > could hand the same document to my broker and it would know how to extract > the data, and where to deliver it to... Realistically, for a lot of devices, it would make sense to code generate the application from the XML and then send the app down to the embedded device....just for performance reasons on very limited devices. But the concept is the same nonetheless. In fact, once we write the container, and a generic, configurable "data monitoring" embedlet (or more likely a small collection of embedlets that co- operate in performing the task....a monitoring embedlet, a packet encoding embedlet and a transport adapter embedlet), Outpost should be able to do exactly that, with just the XML config info changing from one implementation to another. > >But above all else, a plug-n-play approach to transport protocols and > >packaging is required, since then you can switch things around as you > >need it (if you need it). > > Yep Yep! Might be best handled by creating protocol-specific transport adapter embedlets that listen to particular events and then send stuff out the back end. I like the thought of the combo of the packaging embedlet coupled with a different one that does the transport. That way the packaging is de-coupled from the transport for maximum flexibility. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |