[Embedlets-developer] Re: General event mechanism

[Andrzej J. T. <an...@ch...>]

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