embedlets-developer — Outpost Embedlet container developer list

[Embedlets-dev] Re: [Arch] Serialization

[Ted K. <tk...@ya...>]

Andrzej,

>How do you handle hardware intialization at startup?

The same way that serialized objects that have references to non-serializeable
objects like Threads are properly de-serialized, by using custom serialization.
 With custom serialization the developer gets to define whatever code is
necessary to properly reconstitute the object when it is deserialized.  If it
is a JAPL object that is getting deserialized then the hardware is called with
the proper initialization parameters in the custom deserialization code.



> What about other initializations (Container level....like opening 
> communications connections/streams, ensuring that the component 
> lifecycles are properly managed)?  

Again, custom serialization can make sure that all of the things that are not
serializeable during 'freeze' time, like live communications connections and
Threads, can all be reconnected at 'thaw' time.


> Your approach would almost certainly force the Container itself to be 
> serialized, which is going to be problematic, since the object graph will
> likely 
> have references to all sorts of objects like Container Services, Adapters,
> JAPL 
> device drivers (all of which have initialization/lifecycle requirements and
> likely 
> would not be serializable without a lot of extra, unecessary work, if it even
> was 
> possible).

Custom serialization should fix all of these things with or without serializing
the container. 



> Trying to handle the 
> complexity of mixing and matching config/initialization/lifecycle AND 
> serialization state usually makes the serialization approach much less 
> attractive.

With a serialized application, the components, JAPL peripherals, services, etc.
 have already all been put into the 'running' lifecycle state (or other desired
states) and all of their configurations have already been set using an
inspector or perhaps an easier to use customizer.  Most of the complexity has
already been handled by the application assembler in a PnP instant feedback
environment.  So all of the config, initialization and lifecycle state
information is then serialized, transfered to the target device and then
deserialized.  I guess I am just going to have to see all of this stuff fail
like you say it will with my own eyes in order to believe it.

It is just so difficult for me to take on faith that serialization does not
make sense when the new BeanBuilder application:

http://java.sun.com/products/javabeans/beanbuilder/index.html

leverages the new Long Term Persistence API to do all of the things that you
say can't be done.

You must understand that I agree that serialization might not work for our
application, but I would be much more comfortable reaching this conclusion only
after actually trying it and seeing exactly how and why it failed.  At least
this should be good for an article or two. ;-)



> There is still the issue of keeping class files and serialized objects 
> synchronized, which always ends up being a real PITA in a real world 
> implementation.

The Long Term Persistence API, in combination with a serialized object's SUID
class version identifier, fixes this problem.  Here is a section from one of
the early LTP papers that talks about this:

<paper>
http://java.sun.com/products/jfc/tsc/articles/persistence/index.html

A Note on Marshaling vs. Archiving
There are two common approaches to the problem of persisting graphs of objects:

    * Recording all state in an object graph, including non-public state.
    * Recording all state that can be reconstituted using the public APIs of
the objects in the graph.

The simplest scheme taking the first approach requires the inclusion of all the
classes that define the objects -- which is too expensive. The practical
alternative, which is to refrain from serializing the byte codes that define
the classes themselves, is workable between identical implementations of the
same libraries. The serialization framework in 1.1 implements this and is
therefore the method of choice for sending faithful copies of an object graph
between two similarly configured VMs.

The second approach cannot produce as faithful a copy of the original objects
as the first but can store the state of the graph in such a way that any
API-compatible implementation of the classes involved will be sufficient to
reconstitute it. Since APIs are so much more stable than their private
implementations, this single step virtually solves the versioning issues for
most practical purposes. As importantly, from an applet perspective, the
behavior of the constructors residing on the client machine can be leveraged,
often dramatically reducing the size of the files that need to be transferred.

Luckily, although the serialization APIs in JDK 1.1 provided direct support for
only the first task, they used a series of interfaces to ensure that support
for the second operation could easily be accommodated by the same framework. We
use this framework to implement the ObjectOutput and ObjectInput interfaces and
house a complimentary scheme which is designed to solve the long term
persistence problem for user interfaces of JavaBeans. 

</paper>



> Please name one accepted/widely deployed Container (eg. Tomcat, Jetty, 
> JBoss, Weblogic, Websphere, Avalon, etc...) implementation that uses 
> serialization for it's component "packaging/deployment" strategy? 

Embedlets have some attributes that are much closer to JavaBeans than any of
these other technologies have so I do not know how one can use them to show
that serialization for packaging and deployment purposes is a defective
technique.  First off Servlets are not a component technology so I do not think
that they can be used for comparison here.  As for EJBs and Avalon components,
point me to where I can see object graphs of 10 to 100 EJBs or Avalon
components wired together in a JavaBeans-like configuration and I will
certainly take a look at it.




> Actually...there is one implementation that relied on such a serialized
> object 
> graph approach to saving/packaging an application, and that was Smalltalk.  
> (I'll let you research the massive 
> amount of literature and links that deal with this problem in the Smalltalk
> world 
> if you are interested).

I will definitely research SmallTalk further because I was not aware that they
tried such a strategy.


Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Embedlets-dev] [docs] Forrest XML document format

[Ted K. <tk...@ya...>]

Andrzej,

I have started to build an experimental version of the Embedlets main web site
using Forrest and the more I dig into Forrest the more I like it.

How difficult and/or wise do you think it would be to convert the Architecture
discussion document over to Forrest's documentation DTD format?


Here is a link to information on Forrest's current document DTDs:

http://xml.apache.org/forrest/dtd-docs.html


And here is a link to an example of what a document encoded in the
document-v1.1 format looks like after it has been transformed and rendered:

http://xml.apache.org/forrest/document-v11.html


One advantage to using this format is that all of the contents of the document
are searchable from the web while still being available in .pdf format too.


Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Embedlets-dev] RE:[Arch]New version 1.3 of the Architecture Discussion Document posted in CVS...

[Ted K. <tk...@ya...>]

James stated:

>So, in summary we take the XML Embedlet Configuration (
>Or wiring model) and autogenerate the code to build the 
>embedlet application this is 'included' in the build and 
>called by the container to construct the application, ie
>Instantiate the Embedlet tree from the XML into a 
>initialisation code. Ie Create a verbose code version of 
>serialisation? - pseudo Serialisation.

One thing that I have been wrestling with since I started experimenting with
the Elevator challenge was which of the following scenarios made more sense:

A) The Embedlet Container for any given device would be pre-installed on that
device and then the Embedlet application would be deployed into it as a
separate operation.

B) The workstation that was being used to build the application would start
with a default minimal functionality Embedlet Container, have JAPL peripherals
and Container Services plugged into it as needed, have the Embedlet application
assembled and installed into the container, have the system as a whole Unit
tested and then have the complete system (Embedlet container and all) packaged
into the target system's proprietary deployment format and then sent to the
target device.

For a TINI, the deployment file is called a .tini file and it contains an
application's compressed .class files.  The way that a .tini file is deployed
to a TINI is through FTP and one way to execute the application is through
telnet.


So, is the Embedlet Container pre-installed on the target device or does it get
installed with the application?  Are there compelling reasons to allow for both
scenarios?


Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Embedlets-dev] Re: [Arch]embedlets & security

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

>> Encryption for many network connected devices is typically left to the
>> network transport devices instead of the small field devices since it
>> would typically double the cost to support it on each device.
>> 
>> But, some environments might need it at the devices, and be willing to pay.
>
>As TINIs with integrated networking might be deployed wherever a network
>connection is available or even connected to a GPRS modem at a remote
>location I feel we should make security integral part of our design. 
>Please note, I'm talking about security, not encryption.

Security starts with the ability for both ends to accept each other for who 
they are, respectively.  This does not necessarily require encryption.  A 
simple form of security is encrypted tunnels between two specific network 
entities. This is one way to let the authentication at each entity control who 
has access to the controlling operations of that entity.  This can keep one 
entity from forcing its view of authentication onto another.  If you want to 
use key'd authentication as a standard mechanism for remote access, that would 
be a valuable service to have available.  However, I think that it would be 
best to make it an optional layer, rather than a required, base service.

One of our customers uses private IP networks out from their top level 
brokers, and uses VPNs into the brokers for access.  Logins on the brokers 
control access to the private network.  From the brokers, you can telnet/ftp 
to the field equipment and manage it.  If someone changes responsibilities, 
their account is removed from the brokers and they loose access to the field 
devices, without 1000 devices having to be told about a security change...

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

Re: [Embedlets-dev] Re: Security

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

>I think using vlans to secure the connection between embedlets and
>enterprise systems is overly optimistic. Embedlet hardware with
>temperature probing devices might be used in a plant, but in office
>buildings as well and I don't think network groups are going to be fond of
>creating vlans with lots of devices spread acros buildings.

The point is that as soon as you have to send the data across a building or 
through a network, you really do need to know a lot more about the data's 
successful transference, as well as being able to guarentee that it does 
follow your corporate requirements for data security.

This is not about lazy programmers. The code exists, processors exist, network 
equipment exists.  You have to decide at what level the cost to the end 
devices is so overwhelming that it is more cost effective to do it at the 
point of network traversal rather then between end applications, which may not 
know about each others capabilities regarding secure data transmission.  More 
importantly, when a keyset is compromized, soneone is going to need to fix the 
problem, and asking them to telnet to 1000 field devices to update keys is not 
going to go over well, when there are only 10 routers involved in the network. 
 Data communication concentrators are your friend...

Scalability is paramount here.  The 10 device applications have been done.  
The 100 device applications have been done.  The 500 device applications are 
being worked on using existing technologies.  The 10000 device applications 
are in the future.  Think about how you'll make it possible for a couple of 
people to watch over, manage, configure and repair 10,000 devices...

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

Re: [Embedlets-dev] [Arch] Re: Persistence vs. Management

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

>> If you apply your 'inversion of control' pattern the Embedlet should not
>> see a difference. The container would determine the services that are
>> available and determine whether the Embedlet could be persisted and what
>> persistent service is required. 
>
>Inversion of control means the container controls the Embedlet.  It does not 
>imply that all services are automagically provided to an embedlet by the 
>container, with no work required on the part of the embedlet.  It just means 
the
>embedlet will be called when/if the Container decides it should be...not the 
>other way around.  It has very little to do with which Container services are 
>exposed and how they are accessed by an embedlet.

In our container, we have the following initial interface:

public interface Startable {
	public void startObject(SystemContext ctx);
	public void stopObject();
	public String getSystemName();
	public void setSystemName(String name);
	public UIFactory getStatusUI();
}

This is the minimal context needed to live in the container.  SystemContext 
provides access to lookup other objects that can provide other services, or 
which this object may interact with.  From here we have:

public class StartableObject implements Startable {
	protected String name;
	protected SystemContext context;
	protected boolean debug;
	/** set to true when threads should stop */
	protected boolean stopping; 
	public void startObject( SystemContext ctx ) {
		this.context = ctx;
		stopping = false;
		// Provide the thread for Runnables
		if( this implements Runnable ) {
			new Thread( this, 
				getSystemKey()+"-Thread" ).start();
		}
	}
	public void setDebugging( boolean how ) {
		debug = how;
	}
	public boolean isDebugging() {
		return debug;
	}
	public void stopObject() {
		context = null;
		stopping = true;
	}
	public void setSystemName( String val ) {
		name = val;
	}
	public String getSystemName() {
		return name;
	}
	public void debug( String msg ) {
		if(debug) ctx.debug( getSystemName(), msg );
	}
	public void reportException( Throwable ex ) {
		ctx.reportException( getSystemName(), ex );
	}
}

SystemContext includes a method, waitSync(Object obj) that is to be called by 
all threads in the system, started by objects from inside of startObject().  
It does not return until all objects' startObject() has completed.  Since we 
use properties for persistence, Properties are set first, before startObject() 
is called, to provide the initial parameters, including the name of the 
object, which is stored in the property 'systemName, which the setters/getters 
provide access to.

From here in the class hierarchy, there are more convenience classes such as 
SocketServerStartableObject that has an interface and port property and will 
bind the port and manage it, calling a method apon accepting a connection.  
There's another that just subscribes to the pub/sub space with a specified 
top-level topic for modules that just do local processing of pub/sub traffic.  
Others exist as well that are event more focused on particular types of 
applications.  Providing these base classes with all the convenience methods 
simplifies the developers tasks, as well as allows base functionality to 
evolve with less impact on the actual classes.

The outpost container could either have a persistence object installed that 
could be looked up by the objects, or the 'Base' interface would need to have 
two methods such as the setProperties() and getProperties() that I mentioned 
earlier.  I think that it is vital to have properties in the base API.  At a 
minimum, a 'debug' setting should be available, per embedlet, to control its 
behaviour during testing/debugging.  Andrzej, I really do think that the 
properties based adminitration of the object is exactly the right base 
functionality to provide for all objects.  Adding a more complex management 
paradigm for complex object manipulation would be done in a new base class 
that facilitated that mechanism.

The availablity of the associated classes at compile time would make it clear 
that the functionality was supported.  I really hate configurability just for 
the sake of configurabilty.  Persistance of properties can be optional, but it 
should be possible for them to be configured per object, and I think having 
layered contexts for properties is overkill.  If an embedlet application is so 
large that contexts make since, then it will be a highly specialize 
application, where a specialized configuration tool that would manage this 
layering would not be out of the question.

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

RE: [Embedlets-dev] New version 1.3 of the Architecture Discussion Document posted in CVS...

[James C. <ca...@vi...>]

Andrzej,

Can you clear up a few points for me. I have been reading your changes to
your doc, good work BTW, about the Build Process.

So, in summary we take the XML Embedlet Configuration (Or wiring model) and
autogenerate the code to build the embedlet application this is 'included'
in the build and called by the container to construct the application, ie
Instantiate the Embedlet tree from the XML into a initialisation code.
Ie Create a verbose code version of serialisation? - pseudo Serialisation.

So now I see your advatages
- platforms that don't support serialisation can still deploy the Embedlet
applications.
- Versioning is not a problem

However, Now that I work through it I DEFINETELY! think these should be
interchangeable with platforms that do support serialisation because the
hardcoded serialisation could be a very substantial chunk of code actually.
If this can be done 'off device' where the Serialisation API transforms the
XML Embedlet application into a binary on behalf of the target device then
this is definetely more lightweight for the device as it doesn't need all
this config code. The config code will most certainly take up more FLASH
than to store the serialisation stream for example.

What I would like here is to 'unify' these two concepts because they are the
same thing,

- Pseudo Serialisation ie Build Process Bytecode that implementation
serialisation ie Traverses and builds the Embedlet object heirachy directly
in code
- Serialisation API which 'understands' the target and generates the object
heirachy directly

The end result of both these processes is the internal binary representation
of the Embedlet application generated from the XML schematic representation
which may have been generated from the Wiring Application.

Lets see if we can use them interchangeably pending device capabilities, in
fact lets see if we can't use one to make it easy to create the other.

What might it look like... during the build process

1) We start with the XML Embedlet description of the application
2) The build process generates a configuration ByteCode script, our pseudo
serialisation script
3) Create a Virtual Container ie Our PC Container, and execute the pseudo
serialisation script to instantiate the object heirachy in our PC Container
4) The correctness of the Embdlet configuration is verified by the virtual
container

Now this is where the process diverges.

EITHER the Target has no serialisation API

5) The pseudo serialisation code is inserted into the Container startup
constructor

OR the Platform has a serialisation API

** The developer (Vendor) of the Serialisation API then uses introspection
or system serialisation (on the full blown VM) to generate a serialised
version of the PC Virtual Container contents compatible with their target
platform.
5) The serialised version of the bytecode startup constructor is inserted
into the Container startup constructor

6) The static image is built and targeted for the appropriate platform.


In this way we get the best of both worlds and the also if we provide a
standard reference implementation for the way the Serialisation API
interacts with Container to serialise the application then it will help
other VM vendors with their efforts.

Note: This does not have to be FULL! serialisation - it can be a subset ie
The container only needs to be able to deserialise.

In this way
1) We keep the XML Embedlet Description
2) We keep the build process to autogenerate the configuration code
3) We keep the ability to support non serialise support VM's
4) We add the ability to support serialise enabled VM's
5) We add the ability to strip the configuration code out of the VM making
it more lightweight
6) We add the ability to upload new configurations dynamically into the
container (if they only use the same classes)

Combine this with the XML persistance PropertyBag from my last post, and it
starts looking quite nice :-)

James Caska
http://www.muvium.com
'Java Bred for Embedded'







> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of
> Andrzej Jan Taramina
> Sent: Monday, February 10, 2003 11:42 AM
> To: emb...@li...
> Subject: [Embedlets-dev] New version 1.3 of the Architecture Discussion
> Document posted in CVS...
>
>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> This new version of the Outpost/Embedlets Architecture Discussion
> Document, v1.3, was just posted to the CVS documents dir and includes the
> following new stuff:
>
> - Added optional Security Service
> - Added Appendix A: Build vs. Deployment vs. Management Processes
> - Added Appendix B: Outpost Management Service and JMX
>
> I'll probably add some of our thoughts/decisions on Serialization
> for the next go
> round.
>
> Gonna try and do up some preliminary interfaces/base classes this
> week (if
> time allows) so we can start discussing the actual Embedlet
> Standard and the
> directions of the first implementation of a compatible Container.
>
> Enjoy!
>
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>
>

Re: [Embedlets-dev] Re: [Arch]embedlets & security

[Brill P. <bri...@ro...>]

> As TINIs with integrated networking might be deployed wherever a network
> connection is available or even connected to a GPRS modem at a remote
> location I feel we should make security integral part of our design. 
> Please note, I'm talking about security, not encryption.

You don't see security and encrypting walking hand in hand?

- Brill Pappin

Re: [Embedlets-dev] Re: iButtons

[Brill P. <bri...@ro...>]

Indeed, I think that's what they were supposed to be fore (I remember that
JavaOne, though I didn't get to go)!
however I don't know how often a system like Outpost is going to have to
know an individual... however that same technology could be used to identify
the "black box" or "node" is you like, and provide the public and secret
keys for encrypting.

- Brill

----- Original Message -----
From: "Andrzej Jan Taramina" <an...@ch...>
To: <emb...@li...>
Sent: Sunday, February 09, 2003 5:13 PM
Subject: [Embedlets-dev] Re: iButtons


> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> Brill says:
>
> > You can't order java ibutton samples though, so I don't know where to
pick
> > them up to play around a little...
>
> I actually have one....in a Java Ring from a JavaOne conference way back.
Be
> a great user identification/authentication device.
>
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>

Re: [Embedlets-dev] [Arch] Re: Persistence vs. Management

[Brill P. <bri...@ro...>]

> The fallacy here (in my mind) is thinking that Embedlets should be
persisted.  I
> don't think there are some issues with that.  If you look at a servlet
(probably
> the closest analogy to what I think an Embedlet should look like), you
might
> persist the context (Container, application or Embedlet contexts in
particular),
> but not the Embedlet itself.

So you saying the embedlet should be a simple endpoint, only called when the
container thinks it has something to contribute...

I think I'd agree with that.

> The reason for this has to do with making threading more easily
implemented
> and managed by the container.  So with servlets, you don't use instance

I'd narrow that down a little I think... for the most part an Embedlet would
be talking to/gathering data from a single device, so maybe the embedlet
should be a singleton... also helps reduce load on the embedded environment
by not trying to do to much at once. Of course, that assumes the embedlet
endpoint can do what it needs to do quickly and lets go of the resources its
might be holding to do that task.

For instance, on the physical level in Cork, only one device can be talking
over I2C at any one time, so the underlying code allows the bus to be
"locked" for any other requests, it also takes the addresses of the
available devices into account because you can't have more than one with the
same address (in certain circumstances you can, but in that case it would be
the same device as far as the software was concerned).

Anyway, I don't think its really required that the embedlets behave that
way, as the container can do the work of requesting data as needed...
however the embedlet should take into account that the container can only do
things one at a time (for the most part). Anyway, quick, low traffic
requests are important here.

The other option of course is to dump the data elsewhere (into a DB maybe)
and allow the embedlet to redirect requests, or be used only for outgoing
transmission (and not service requests on its own).

- Brill

RE: [Embedlets-dev] Re: iButtons

[James C. <ca...@vi...>]

>(Also different bugs of course)

I thought these things were 'certified' which is why they are so expensive
;-)

JC

> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of Jac
> Kersing
> Sent: Monday, February 10, 2003 9:47 AM
> To: emb...@li...
> Subject: Re: [Embedlets-dev] Re: iButtons
>
>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> On Sun, 9 Feb 2003, Andrzej Jan Taramina wrote:
>
> > I actually have one....in a Java Ring from a JavaOne conference way
> > back. Be a great user identification/authentication device.
>
> Ouch, that's the oldest (and most buggy) version of the firmware
> available. Newer ones are more capable and have fewer bugs in the
> firmware. (Also different bugs of course)
> And note, the application needs to be translated using the
> correct version
> of the firmware, there is no such thing as 'write once, deploy on
> all Java
> iButtons'.
>
> Regards,
>
> Jac
>
> --
>  Jac Kersing            Technical Consultant   The-Box Development
>  j.k...@th...                         http://www.the-box.com
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>
>

RE: [Embedlets-dev] Re: More on "serialization"...

[James C. <ca...@vi...>]

Andrzej

>you still need the class files as well.

There is no way around this on pretty much any embedded platform
irrespective of the persistance strategy. The new class files are going to
have to be uploaded by ftp(TINI/TStick) or UART/WebServices(uVM) or
JTAG(JStamp). I don't see a transportable version of classes for any of
these platforms so yes, we can only be talking about instances.

>and all you would be
>loading onto the device was pure, executable bytecodes with no embedded
>XML whatsoever (for those platforms where XML parsing and dynamic config
>on the device itself would be problematic).

I am not sure what you mean, loading pure executable bytecodes, is not
possible on any of the embedded platforms. They all have some transform over
the bytecodes first. uVM compiles it, TINI transforms to .tini , and JStamp
obviscates it. You will need to spell out your vision on this a little more
concisely.


> footprint).  It also mirrors the uVM approach....all the "heavy
> lifting" of creating
> and packaging the app to it's smallest possible runtime footprint
> (with all
> extraneous stuff pared away) can be done by the Build process
> (except when
> dynamic config i

Of course I like the approach of doing the work on the 'Build Side' This is
a good thing and I also really love XML in fact I am not sure this is an
EITHER/OR box to tick. I have a feeling these are side by side techniques
for Embedlets.

As for versioning, each platform is going to have their own unique
serialisation format anyhow. THe idea of versioning for an embedded platform
is substantially reduced becuase of this fact, ie you are not likely to want
to upload a serialisation object for a TINI and try to run in uVM and vica
versa. What you are going to see is some sort of API layer that transforms
into the appropriate format before it is uploaded. Any versioning issues
will have to be handled by the vendor at this point of serialisation. My bet
is TINI does this already. There is nothing to stop this API from processing
the XML to generate the platform specific serialisation for the container.

But yet, I agree that this is just a snapshot - it doesn't handle
lifecycle's it is more the 'start conditions' which is why I think these
ideas work together. Serialisation for 'instantiation', Management for long
term persistance of only the minimal peices of data, the delta, that
actually need long term persisting.

Ie to start over at any point in time,

1) Container Instantiates serialisation tree
2) Container PropertyBag overlays 'delta' Management for long term
persistable data

In this way
1) The XML can still fully describe the persistance
2) The versioning is handled by the vendor specific 'Serialisation API'
which transforms the XML into the serialisation heirachy which is done at
build/link/application upload time
3) The long term persistance can be managed by delta Dynamic property
get/set into a containers property bag
4) If you want a complete snapshot for external representation you toXML()
the containers propertybag and combine it with the original XML that was
used to generate the serialisation tree back at the server side which can
then be reserialised if need be and uploaded as new 'start condition'

Hence the container has the following minimal capabilities.

instantiateEmbedletSerialisation(InputStream)
PropertyBag.getProperty()
PropertyBag.setProperty()
PropertyBag.toXML()

And all embedlets access the PropertyBag to store their delta state
conditions.

> My vote stays at -666 for Serialization as a packaging approach. ;-)

My vote is
-1 for Serialization as a exclusive packaging approach
+1 for a Hybrid Serialisation packaging approach


James Caska
http://www.muvium.com
'Java Bred for Embedded'




> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of
> Andrzej Jan Taramina
> Sent: Monday, February 10, 2003 6:37 AM
> To: emb...@li...
> Subject: [Embedlets-dev] Re: More on "serialization"...
>
>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> James:
>
> > One really nice possibility I really like for muvium at least
> is the idea
> > of being able to store the serialised form into FLASH of perhaps a
> > multitude of different 'precofigured' Embedlet applications and
> > instantiate the appropriate embedlet application from Flash in
> serialised
> > form upon demand. Can think of some cool idea's for this, like swapping
> > out entire embedlet applications for say Specialised Error Handling, or
> > different wiring configurations for different onboard applications, or
> > even PipeLining Stages of processing, who knows?
>
> There are some issues with this....you can't do this with just
> the serialized
> objects (stored somewhere)....those are just instances....you
> still need the
> class files as well.  But that requires that all potentially used
> classes be loaded
> right up front (big footpring overhead) or that they can be
> dynamically retrieved
> from storage (eg. Flash) but then you need dynamic classloading.  And you
> get all the baggage/issues of using serialization as an
> application/component
> packaging approach (per my other email on the subject).
>
> > I know this is all persistance stuff but enabling the embedlet container
> > to just suck up applications off a serial stream might prove useful in
> > lots of different ways without having to support layers of XML parsing
> > etc.
>
> The functional concepts very valid and would be a great
> capability, no question
> there.  And the Arch discussion document addresses these requirements
> through the use of the Lifecycle Service in conjunction with the optional
> Management, Persistence and Dynamic Classloading/Config services.
>
> In fact, there could be no XML whatsoever involved in the loading of an
> app.....since the Build process could/would do the parsing on the
> workstation
> side first and code generate pre-populated instances, tables,
> control structures
> that were needed to run a particular app/component, and all you would be
> loading onto the device was pure, executable bytecodes with no embedded
> XML whatsoever (for those platforms where XML parsing and dynamic config
> on the device itself would be problematic).
>
> Funny thing....this would be "lighter weight" (at the Container
> end, at the the
> expense of a Build process is a bit more complex) than even a
> serialization/deserialization process (faster load/initialization
> time, no need for
> serialization/deserialization code on the platform, no need to
> store both the
> serialized and deserialized forms in memory simultaneously so
> lower memory
> footprint).  It also mirrors the uVM approach....all the "heavy
> lifting" of creating
> and packaging the app to it's smallest possible runtime footprint
> (with all
> extraneous stuff pared away) can be done by the Build process
> (except when
> dynamic config is a key requirement,in which case you consciously
> choose to
> accept the overhead of doing some of the dynamic stuff in the Container).
>
> I 100% agree that we need Persistence, Management, Dynamic Config
> optional services (let's not forget...this stuff has to be
> optional/modular, so the
> developer/deployer only selects the services they need for their
> particular
> application and platform constraints and we can target the widest
> possible
> range of platforms/applications). I just don't think
> serialization is the best way
> to implement these features/services.
>
> My vote stays at -666 for Serialization as a packaging approach. ;-)
>
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>
>

[Embedlets-dev] New version 1.3 of the Architecture Discussion Document posted in CVS...

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

This new version of the Outpost/Embedlets Architecture Discussion 
Document, v1.3, was just posted to the CVS documents dir and includes the 
following new stuff:

- Added optional Security Service
- Added Appendix A: Build vs. Deployment vs. Management Processes
- Added Appendix B: Outpost Management Service and JMX

I'll probably add some of our thoughts/decisions on Serialization for the next go 
round.

Gonna try and do up some preliminary interfaces/base classes this week (if 
time allows) so we can start discussing the actual Embedlet Standard and the 
directions of the first implementation of a compatible Container.

Enjoy!

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

[Embedlets-dev] Re: Security

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

Jac states:

>  think using vlans to secure the connection between embedlets and
> enterprise systems is overly optimistic. Embedlet hardware with
> temperature probing devices might be used in a plant, but in office
> buildings as well and I don't think network groups are going to be fond of
> creating vlans with lots of devices spread acros buildings. 

That makes sense...

> Doing things
> this way would shift the burden from developers to those dealing with
> production systems and networks. Being one of the people having to deal
> with problems created by 'lazy' developers for most of my working day I
> can say my collegues and I are not very fond of them... 

Point taken.

> Security should be part of our solution, not something someone else has to
> provide, IMHO.

You've convinced me....I'll add an optional Security Service to the Architecture 
Document with a note that this might just be Authentication and not encryption 
based (due to the constraints of the platforms).  I would expect that it would be 
primarily used in a userid/pswd mode (HTTP Basic Auth?) for external 
Management functions.  The reason for making it optional is that it might not 
be needed if there are security functions provided by the network (eg. the shop 
floor LAN is isolated and protected from general access).

How is that as the beginning of a solution, Jac?

> Webservices are the perfect example of failing security. In the early days
> they promised to be the perfect solution for integration of services over
> the Internet, now they're only being used in closed networks.

That's due to more than just a lack of basic security, since Web Services 
typically are being implemented over HTTP, and you can easily use HTTP 
Basic Authentication, SSL (and more) ot protect access to such services.  As 
soon as you try to do transactional things with web services, you need long 
running transactions, encryption of payloads only (rather than the whole 
transmission with something like SSL), digital signatures (for identification) and 
common B2B requirements like non-repudiation, long running transaction 
support and the like.

I think that saying that Web Services are only implemented inside the firewall 
due to a lack of "security" is a bit misleading, since there are very easy ways 
to secure web services in most cases.  That has nothing to do with Embedlets 
necessarily....just setting the record straight is all.


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

Re: [Embedlets-dev] Re: [Arch]embedlets & security

[Jac K. <j.k...@th...>]

On Sun, 9 Feb 2003, Gregg G. Wonderly wrote:

> Encryption for many network connected devices is typically left to the
> network transport devices instead of the small field devices since it
> would typically double the cost to support it on each device.
> 
> But, some environments might need it at the devices, and be willing to pay.

As TINIs with integrated networking might be deployed wherever a network
connection is available or even connected to a GPRS modem at a remote
location I feel we should make security integral part of our design. 
Please note, I'm talking about security, not encryption.

Regards,

Jac

-- 
 Jac Kersing            Technical Consultant   The-Box Development
 j.k...@th...                         http://www.the-box.com 

Re: [Embedlets-dev] Re: iButtons

[Jac K. <j.k...@th...>]

On Sun, 9 Feb 2003, Andrzej Jan Taramina wrote:

> I actually have one....in a Java Ring from a JavaOne conference way
> back. Be a great user identification/authentication device.

Ouch, that's the oldest (and most buggy) version of the firmware 
available. Newer ones are more capable and have fewer bugs in the 
firmware. (Also different bugs of course)
And note, the application needs to be translated using the correct version 
of the firmware, there is no such thing as 'write once, deploy on all Java 
iButtons'.

Regards,

Jac

-- 
 Jac Kersing            Technical Consultant   The-Box Development
 j.k...@th...                         http://www.the-box.com 

Re: [Embedlets-dev] Re: Security

[Jac K. <j.k...@th...>]

Hmm,

I think using vlans to secure the connection between embedlets and
enterprise systems is overly optimistic. Embedlet hardware with
temperature probing devices might be used in a plant, but in office
buildings as well and I don't think network groups are going to be fond of
creating vlans with lots of devices spread acros buildings. Doing things
this way would shift the burden from developers to those dealing with 
production systems and networks.
Being one of the people having to deal with problems created by 'lazy'
developers for most of my working day I can say my collegues and I are not
very fond of them... 

Security should be part of our solution, not something someone else has to
provide, IMHO.

Webservices are the perfect example of failing security. In the early days
they promised to be the perfect solution for integration of services over
the Internet, now they're only being used in closed networks.

Regards,

Jac

On Sun, 9 Feb 2003, Andrzej Jan Taramina wrote:

> Date: Sun, 09 Feb 2003 13:58:13 -0500
> From: Andrzej Jan Taramina <an...@ch...>
> Reply-To: emb...@li...
> To: emb...@li...
> Subject: [Embedlets-dev] Re: Security
> 
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
> 
> Jac states:
> 
> > While reading some of the messages on this list I started wondering if
> > we're taking security into consideration while designing and are going to
> > implement it from the start. One of the issues with webservices is (was?)
> > the lack of standardized authentication/security, resulting in a delayed
> > acceptance of webservices if one may believe the trade press.
> 
> My thinking was that security would initially (in an enterprise deployment 
> scenario) be provided by the surrounding infrastructure (network and such).  
> Embedlets would be running on a factory/warehouse floor on a physically 
> controlled subne or VLAN, with properly secured gateways to the back end 
> Enterprise Systems, access/security/authentication would be managed outside 
> of the Embedlet container, so we could assume (at least initially) that we don't 
> have to do much in that area (maybe just some rudimentary password 
> protection for external access to Management Services and the like).  If there 
> is a connection between a plant network and head office, it would be secured 
> (either a dedicated link or VPN tunnel across the public net), but I don't think 
> we'll see devices exposed on the public internet for production deployments.
> 
> Doing the typical security things on a tiny processor (authentication, 
> authorization, encryption/decryption of data streams) will be nigh impossible 
> on some of the smaller platforms.
> 
> Web Services are being implemented in production as we speak....but 
> primarily behind the corporate firewalls.  I see embedded systems as following 
> that pattern.
> 
> That being said, our modular approach to services and the like would allow us 
> to plug in more security features later on without much trouble, since it will be 
> an issue that will be raised in the corporate environment.
> 
> 
> 
> 
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
> 

-- 
 Jac Kersing            Technical Consultant   The-Box Development
 j.k...@th...                         http://www.the-box.com 

Re: [Embedlets-dev] Re: [Arch]embedlets & security

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

>I have also done some work looking into wrapping up a simple
>javax.encryption cipher with DES and the TINI cipher (by wrapping existing
>PIC implementation code...)
>
>We should be able to do something along these lines with some of these
>simpler algorithms if it turns out to be critical. Or we can just add it to
>the stream later down the track.  I doubt I can do SSL though...

Encryption for many network connected devices is typically left to the network 
transport devices instead of the small field devices since it would typically 
double the cost to support it on each device.

But, some environments might need it at the devices, and be willing to pay.

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

[Embedlets-dev] Re: iButtons

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

Brill says:

> You can't order java ibutton samples though, so I don't know where to pick
> them up to play around a little...

I actually have one....in a Java Ring from a JavaOne conference way back. Be 
a great user identification/authentication device.

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

[Embedlets-dev] [Arch] Re: Persistence vs. Management

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

Chris:

Good discussion!  Some very good points are being hashed out (and Chris is 
keeping me both honest and forcing me to document my design 
thoughts...both very valuable).

> If you apply your 'inversion of control' pattern the Embedlet should not
> see a difference. The container would determine the services that are
> available and determine whether the Embedlet could be persisted and what
> persistent service is required. 

Inversion of control means the container controls the Embedlet.  It does not 
imply that all services are automagically provided to an embedlet by the 
container, with no work required on the part of the embedlet.  It just means the 
embedlet will be called when/if the Container decides it should be...not the 
other way around.  It has very little to do with which Container services are 
exposed and how they are accessed by an embedlet.

The fallacy here (in my mind) is thinking that Embedlets should be persisted.  I 
don't think there are some issues with that.  If you look at a servlet (probably 
the closest analogy to what I think an Embedlet should look like), you might 
persist the context (Container, application or Embedlet contexts in particular), 
but not the Embedlet itself.

The reason for this has to do with making threading more easily implemented 
and managed by the container.  So with servlets, you don't use instance 
variables 'cause then you get into thread synchronization issues. Instead, you 
put stuff like that in one of the suitably scoped Context objects, and thus would 
have to persist only the Context (or a Config object, which typically would be 
used by the Container to set things up).  The Context object can synchronize 
thread access transparent to the Embedlet (if threading is supported). I figure 
this approach works well, and makes threading easier, so it would make sense 
for us to adopt at least a simple variant of it for Embedlets.

But that does imply that you can persist the Context objects...and of course, 
these would use a dynamic property/value approach (just like with Servlets), 
so on that score we're probably in violent agreement.  That being said, I do 
think there is good reason to have a more generic Persistence interface so 
that almost any arbitrary object could be made persistable, regardless of 
whether it was a JavaBean-style object or not (which sounds suspiciously like 
object serialization....note:  I have no problem with serialization as a something 
that is used for Persistence of objects....just not for app/embedlet packaging 
issues).

> Otherwise the simplest Embedlet would have
> to 'know' how to interact with all of the expected (and unexpected
> services) in order to operate in all containers from constrained to
> powerful.

A simple Embedlet that only depends on Core Services(eg. guaranteed to be 
available services) will be able to run in ANY Outpost-compatible container. 
The developer/deployer has nothing special to do here.

 So much for the simple case....let's look at more complicated ones:

If an Embedlet depends on an optional service (let's say Persistence for the 
purposes of this discussion), then the embedlet.xml config file (in the 
myEmbedlet.bar file) would specify that this particular embedlet can only run in 
a Container that provides the optional Persistence Service (note: how that 
service is provided, in Flash, across a network, etc, should be totally 
transparent).  At build time this dependency would be checked versus the 
outpost.xml config file (which configs the container itself) to ensure that all 
required service dependencies are met...otherwise an error message would be 
generated during the build and it would stop till the developer fixed the problem 
(either by selecting an Embedlet without the dependency or reconfig the 
container to provide that required service).  All the developer/deployer needs 
to do is to set up the config correctly so that all dependencies are resolved 
(but these will be checked during the build).

The snippet of XML in the embedlet.xml file, for the above, might look like:

<services>
	<service name="Persistence" required="true" /> 
<services>

I don't see this as a big issue.....we need the flexibility of optional services due 
to the constrained nature of the embedded platforms (even on more capable 
devices, say a TStik, a large app with lots of JAPL drivers, multiple embedlets 
and requirements for lots of dynamic memory, might benefit from having 
unused Services removed from the container, to free up space).

Now there is the last case.....a "smart" Embedlet that can change it's 
behaviour based on whether a service is available or not, but strictly speaking 
it's not dependent on the service to run (eg. it can run without, but also can do 
more things if it has it).  There will be a way to do this in the Container.  The 
Embedlet could either check ahead of time if the service is available (using a 
Container discovery method wrapped in an if-then-else) or wrap the service 
invocation in a try/catch block (as I did in my example).   The developer of the 
embedlet would note (in the embedlets.xml config file) that the embedlet can 
use Persistence if it's available, but is not dependent on it. 

The snippet of XML in the embedlet.xml file, for the above, might look like:

<services>
	<service name="Persistence" required="false" />
<services>


Yes...this final example will require a bit of extra code in the Embedlet....but 
that is not necessarily a bad thing, since it gives you a more flexible Embedlet 
capability.  The Container can't do everything automatically.....that would take 
too much overhead or it might just not be possible to determine what to do 
when (if/when do I persist a Context? or when do I write log messages?  
Which methods are exposed to external Management?  These have to be 
specified somewhere....and sometimes in actual code).  The code would be 
very simple as well (per my example...it was only a few lines to take advantage 
of Persistence (if it was available).  It's not like this will bloat the Embedlet 
code very much.

This approach makes easy things easy, and hard things still doable!  One of 
my key design philosophies.  Plus it allows us to target the smallest of 
contstrained platforms as well, with the minimal footprint (this will be a crucial 
requirement if we are to have any hope of supporting uVM on PIC 
processors).  I am very reluctant to make anything more than the Core 
Services mandatory....since then the minimum footprint grows quickly.

Yes....it's a compromise.  We gain more Container modularity (with smaller 
footprint) and thus wider range of supportable platforms, at the cost of slightly 
more effort to write complex/dynamic Embedlets.  I think that is wise at this 
stage...though in the future we might need to rethink that as we gain some 
experience in real deployments.

Keep in mind that other "application" services might also be added to the mix 
(not just the container provided Core and Optional Services), and these 
services could be implemented as an Embedlet themselves.  My approach to 
dependency control would also handle the integration of user-written Services 
as well!  Very elegant since you wouldn't have to learn anything new to create 
re-useable Services (versus Embedlets).  

> This means that an Embedlet provider would have to offer multiple versions
> of Embedlets (simple/static, exposed/dynamic, persistent, managed ...??).

Not necessarily (bear with me here)....with my design concepts above, all 
Embedlets would extend org.embedlets.Embedlet only.  And they could 
specify their dependencies in the embedlet.xml file (if they had any).  You 
could also write very complex/dynamic Embedlets that can change their 
behaviour based on what services are available (should you need/wish to do 
so) that could still run on any Outpost-compliant container out there.

Now, to make it easier for developers to create complex/dynamic embedlets 
that adapt to the "environment" (eg. what services are available) they are 
running in, I would propose that we create some Embedlet superclasses rather 
than bloat the container with this dynamic functionality.

So we could provide an org.embedlets.DynamicEmbedlet base class (which in 
turn extends org.embedlets.Embedlet) which would provide abstract and 
reuseable methods that would allow the embedlet to be simple/static or 
exposed/dynamic  simpler container implementation as well.

> If the Embedlet interface is simple and sets & gets its properties via
> name/value pairs (alla Properties) it can accomodate the expected
> interactions with the same interface. So that a simple embedlet would be
> able to run in a complex enviroment and be dynamically loaded, persisted
> and managed. 

Of course we'll use a property/value based approach at some level.  That is 
not in disagreement.  So dynamic reconfiguration will be provided through the 
Lifecycle Service or Maintenance service (depending on whether you have to 
stop/reinit/start or can just change a value on the fly), without any specific 
code required on the part of the Embedlet developer.

For Persistence...that is a service that is intended to be more generic than just 
for persisting current context/config for an Embedlet (there may be many other 
needs for persistence besides just for storing configs and then dynamically 
picking one). To create an Embedlet that will dynamically config itself from a 
persisted config is a more specific (eg. subclass) of a "normal" Embedlet.  
There are a couple of ways to create such a capability while keeping the load 
on the Embedlet developer to a minimum. 

One way to do this is to provide a standard base class (with our Embedlets 
distribution), that incorporates the ability to reconfig from a persisted config.  
Say org.embedlets.PersistentConfigEmbedlet.  Then all a developer would 
have to do would be to extend this more functional class if they needed this 
kind of features.

Or, you could write a new "service" (a fancy Embedlet or even a new 
"Optional" container service) that provided those capabilities by "acting" on 
other Embedlets.  We can easily design the Container and Core services to 
provide "hooks" or "interception points" where such a new service could 
interpose itself (say in the Lifecycle Service....you could install a handler that 
would go and find the config from the persistence service and pass it to the 
Embedlet in the init() or start() methods....transparently to both the container 
and embedlet).

Note that all of these approaches do not compromise the container modularity.  
And you can provide the "service" transparently to the Embedlet code if you 
want to, with such a service being reusable for any/all embedlets.

All I am trying to avoid is having the Core list of service grow to support more 
esoteric services (like dynamic config from a persistent repository) that will not 
be required by all applications and implementations.  Just trying to keep the 
core container as simple and small as possible....but allow for plugins to 
address these other needs.

Management is something that would be layered transparently on top of an 
Embedlet (and the Container and it's services), so it can be pluggable.  What 
is exposed would be specified declaratively in the XML Config files....NOT in 
code (though we might consider exposing the Management service through 
API calls as well for those that are writing plugin services).

> In an enviroment that does not require these (it is hard to
> imagine not needing at least one) the overhead is small.

The overhead is not small for tiny constrained devices like PICs with 4K RAM!

Persistence and dynamic config will not be required by all implementations, for 
the simple fact that some platforms may/will not support it.

As for Management, it might be done through hardwired switches and thus it 
might be easier for the embedlet to just use JAPL instead of having it exposed 
through the Management Service!  Not all embedded controllers will have 
external access...what if they are standalone?  That isn't our target, but we 
should still allow people to write Embedlets for isolated contollers too.

Ted's elevator example is a good one.  It doesn't need dynamic config or 
persistence (elevator configs don't change much after construction! <grins>).  
Management might be valuable, but is definitely not mandatory for this 
example...in fact, Otis might choose to make remote monitoring/management 
of the Elevator system an "optional" (ie. paid) feature.  And since the 
Management service would be totally transparent to the Embedlet code, it 
wouldn't matter to the developer anyway.  Same Embedlet code 
base...different deployment configuration is all.

> Keep in mind, contrary to your statements below, the interface does not
> specify that XML or any media is used just that properties are exposed as
> name/value pairs. 

I agree....I am not proposing that we use something strange instead of 
property name/values pairs.

> This is the commonality that should be defined at the
> Embedlet interface or a separate 'PropertyExposer' interface 

For management, you don't such an interface.  Which methods (be they 
property getter/setters or any arbitrary method an Embedlet implements) 
would be tagged as "Manageable" in the outpost.xml config file....and the 
"hooks" to let the Management Service invoke those methods would be 
created during the build/deploy cycle. Not in hardcoded embedlet code.

I think some of the confusion stems from the fact that the Management Service 
is intended to be totally transparent to an Embedlet....whereas other services 
(eg. Persistence) may not be.

> (I named it
> > Persistent originally which may have caused some of the confusion). 

Goes to show you the value of naming things for what they do. <grins>

> The
> differences between persistence, management and configuration should be
> controlled by the container and its services.

Not sure what you mean by this.  But I do think that these "simple" and 
"optional" services should not be coupled.  If you need a more complex hybrid 
service that does one or more of these, then create one on top of the simple, 
pluggable building blocks.

So if you want/need the ability to do externally managed, dynamic config 
where the config info comes from a persistent store.....write a service that 
does just that on top of the basic services (as I had discussed above, ad 
nauseum).

I don't believe it should be a core service!  Or even an Optional one (that is, 
initially, though it might become an Optional service that is shipped with the 
container eventually if we see that the use is ubiquitous).

KISS principle.  For now, let's stick to getting the basic building blocks 
(services) spec'ed and out the door...cause building more complex ones out of 
those is easy.  If you start with more complex services then it's typically harder 
to go in the other direction and decouple them into their simpler functional 
components later.

> To address your concern about JMX support, I am familiar with the spec
> (probably not in the detail you are) and the one area that would not be
> handled by a PropertyExposer at the Embedlet level would be a notifier.
> This would be handled by a generic notifier Embedlet that gets 'wired' to
> the output of any Embedlet's event and relays the notification to the JMX
> service.

Ignoring the fact that we don't need a PropertyExposer interface, there may be 
better ways to let the user specify this rather than having them wire a Notifier 
Embedlet...but that is neither here nor there.  At some level the "glue" code 
would be generated based on the XML Config file (outpost.xml)...what visual 
metaphor the wiring tool chooses to use to represent this graphically (as an 
Embedlet, or a property on a Event connection) is up to the Graphical tool 
implementation.


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

Re: [Embedlets-dev] Re: [Arch]embedlets & security

[Jac K. <j.k...@th...>]

On Sun, 9 Feb 2003, Brill Pappin wrote:

> You can't order java ibutton samples though, so I don't know where to
> pick them up to play around a little...

They're being sold at the store listed on www.ibutton.com at $53.21 a 
piece.

Regards,

Jac

-- 
 Jac Kersing            Technical Consultant   The-Box Development
 j.k...@th...                         http://www.the-box.com 

[Embedlets-dev] off topic

[Brill P. <bri...@ro...>]

This is a bit off topic;

I've been thinking about this a little on the JAPL front, and how "neat" it
would be if you could connect several processors together  and have them
share their resources (peripherals) with one another.

This is not exactly serialization, but rather a "device pool" so that
processors would let the pool know what they had, and allow the alternate
system to execute operations on its devices.
In oder to do this, a peripherals properties and "actions" would have to be
transmitted (serialized) to the other processors. and since its done in a
fairly generaic format, you onely need to hold one "remote" object.

Anyway its a glimmer in the brain at the moment... something I'm playing
with in my head, but I think it might work, and doesn't need to go into the
Embedlet spec.

- Brill

Re: [Embedlets-dev] Re: More on "serialization"...

[Nicola K. B. <nic...@ap...>]

Andrzej Jan Taramina wrote, On 09/02/2003 20.37:
...
> My vote stays at -666 for Serialization as a packaging approach. ;-)

Also, was not serialization between JDKs not necessarily 100% 
compatible, at least in the "real JDK world"?

I wouldn't like to fix myself to a serialization that is not defined by 
me. And I doubt many programmers are using default serialization for 
majpr tasks at all.

Just 2c

-- 
Nicola Ken Barozzi                   nic...@ap...
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Re: [Embedlets-dev] Re: [Arch]embedlets & security

[Brill P. <bri...@ro...>]

> > Ahh... found a solution that might work...
> > http://wireless.java.sun.com/midp/ttips/dataencryp/
>
> Bouncy Castle Crypto adds kilobytes to an app. Not good for low-end
> devices. (It's a challange to keep MIDlets from growing too much using it)

Yah, I noticed its fairly large, even the J2ME version which is the "light"
version.
I going to try picking it apart and see how much we can save... frankly, I'm
not a security expert, and I'd rather use a lib from a group that has been
doing it for a while, than try and make my own DES stream work properly.

- Brill Pappin

Re: [Embedlets-dev] Re: [Arch]embedlets & security

[Brill P. <bri...@ro...>]

> > Can the iButton encrypt a stream in/out of the device? I'm not sure how
> > they work... are they just keys (in which case we would still need to
> > write an implementation, but its a step in the right direction)?
>
> The buttons should be used for key exchange, not stream encoding/decoding
> as every byte has to travel the 9600 bps 1-wire twice...

That wouldn't be to bad for speed... the running outpost would only need to
read the ibutton once, and store its key in ram.

- Brill