[Embedlets-dev] FW: Embedlets Architecture: Dynamic Configs and Persistence...

[Christopher S. <cs...@oo...>]

Chris:

Thanks for documenting the scenario....this will definitely help the design
thinking as I plow into the details.  Some comments inline below...

> The typical scenario is:
>
> 1. A new system is installed with new similar but significantly different
> hardware, more inputs, valves, etc compared to the last 25 systems. 2.
> There is a flowchart or written specification of the process defining the
> inputs, computations comparisons, logical operations and outputs.
>
> 3. The Embedlets required to implement the spec are pre-installed on the
> target system, available to the Container.
>
> 4. The system is wired using a graphical tool or the XML configuration on
> the Workstation.
>
> 5. The configuration is downloaded as an XML stream to the target.
>
> 6. The Container instantiates the required Embedlets and wires them
> together based on the configuration.

We could do this.....but the XML parsing might be a bit tough on the smaller
platforms.  As such, I added a Dynamic Config/Context Optional Service to
the
architecture document, intended to provide such a capability.

Part of the problem here is that I intend to use the full power of the XML
libraries available on the PC for the build process, in generating the
"control
tables" and maybe even some intialization code from the XML Config data.
That includes XML Parsing (Xerces, SAX, Jakarta Digester) and XSLT
transforms (which might be very useful for generating code/tables from XML-
tagged Java source files).  Obviously, this level of processing will not be
available on even a JStik level controller.   On the controller itself, I
figured to
use the Enhydra kXML, kSOAP libraries since they work well, are open source
and have very small footprints.  Now if I can find a way to use kXML and
implement a very lightweight SAX layer on top of it, this would ease the
implementation of such a dynamic Config service.

Anyhow...it's in the document....so it will definitely be on the list.

> 7. Modifications to individual Embedlet settings (calibration, scale
> factors, limit thresholds, time delays) are adjusted on the running system
> similar to adjusting potentiometers on analog systems.

Many controllers won't have any display capability.  I see JMX
instrumentation
as the best way to handle this situation for the more capable controllers,
and a
custom solution (lightweight HTTP/HTML server on the controller?) for the
smaller devices.

> 8. The finalized configuration and the adjustments are stored in the
> targets flash ROM for immediate recall as well as on the workstation for
> backup and versioning.
>
> 9. Any variations in the system or alternate configuration settings are
> done in real time and likewise saved.
>
> Notice that the code is compiled/linked/installed only once and is used on
> all systems whose requirements are within the constraints of the available
> Embedlets. This reduces the number of binary packages that need to be
> generated, QA'ed and tracked. In my experience this is a very typical
> scenario in facilities management, industrial controls, aerospace and home
> automation.

Yup....a situation that we need to handle nicely for sure.

> Constrained systems might be deployed with workstation generated 'hard
> wired' configuration, but they will still need some query capability and
> quite likely the ability to update one or more Embedlet parameters.

Yup.

> I have found that the instantiation, serialization/deserialization,
> local/remote persistence and property queries/updates can all be handled
> by the same interface and a compact piece of implementation code at the
> Component/Embedlet level. Please review the Persistence package of OPC for
> details.

I will definitely take a close look at the OPC Persistence package for this.
However, I believe that we will probably need to split up some of these
functions into separate "services" to keep the implementation as modular as
possible  and reuse the max amount of code between the Static Config,
Dynamic Config and back end Build/Construction code bases.

> To respond to your suggestion that JMX and JMS be used as management and
> communication protocols: I agree completely. I would not however think
> that this would be a part of our mission statement. If we have defined a
> simple XML payload with Socket based communication, this can be easily
> packaged within a JMS, SOAP... envelope for transport to distributed
> Enterprise systems.

I think the support of JMX as the optional Management Service does need to
be part of the spec.  Primarily since this is the "standard" way that
systems are
being monitored and managed these days (and gaining ground fast).  For
ultra-constrained devices, sure, a developer would have to do a custom
solution since JMX would be just too fat. But if it fits, it's better to
stick with the
standard, since it would make Embedlet adoption much more palatable to the
corporate/enterprise guys.  I would expect that the remote management would
be exposed using a HTTP/SOAP/XML approach, with a corresponding JMX
Adapter used at the other end to support this protocol (one of the side
projects
I have been looking at is generating a Web Services interface to JMX MBeans
automagically).

JMS is another matter...since it uses proprietary transport protocols, I
have no
intention of supporting it....but the Container would be flexible enough
that
someone could write adapters for their favourite JMS implementation if they
wanted to.

> I look forward to your document release and feedback on OPC applicability.

Will get back to you on the OPC stuff as soon as I get a chance to do some
reading....likely won't get there till Wed sometime.


Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com