Re: [Embedlets-developer] Re: General event mechanism

[Gregg G. W. <gr...@sk...>]

>> 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.

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.

>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.

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...

>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.

And this is what we have to account for.

>> 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.

An example of what we use in our product today is at: 

	http://www.cytetech.com/~gregg/weg.

Look at this with an XML enabled browser, there are XSL style sheets that will 
hide the gore of the XML...

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...

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...

>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!

-----
gr...@cy...  (Cyte Technologies Inc)