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
|
