embedlets-developer Mailing List for Outpost Embedlet Container (Page 29)
Status: Alpha
Brought to you by:
tkosan
Menu
▾
▴
embedlets-developer — Outpost Embedlet container developer list
You can subscribe to this list here.
| 2003 |
Jan
(135) |
Feb
(402) |
Mar
(162) |
Apr
(22) |
May
(13) |
Jun
(67) |
Jul
(59) |
Aug
(27) |
Sep
(1) |
Oct
(28) |
Nov
(81) |
Dec
(16) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(2) |
Feb
(21) |
Mar
(6) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(13) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Brill P. <bri...@ro...> - 2003-02-09 19:59:06
|
> > If we go with TINI/TStik as a reference platform (which is the way I am > > also leaning for a number of reasons) then we can use the iButton holder > > clip that is present on most TINI/TStik socket boards to hold a JavaCard > > compliant iButton that could handle our digital signing and verification > > needs. > > That will significantly slow responces. The Java Buttons are far from fast > and the data exchange over 1-wire is not too speedy as well. However, it > is a valid option (and would allow me to use my Java buttons for something > usefull :-) > > It does add significant cost to the product, Java iButtons are not cheap.. I think worth it though... I was thinking about this last night, and though want can't use iButtons for on-the-fly security, they could be used for unique key generation etc... which would also have a high "cool-factor"... each production device would have one, and it would also help uniquely identify the Outpost "nodes" when multiple nodes where connected together. You can't order java ibutton samples though, so I don't know where to pick them up to play around a little... - Brill |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-09 19:39:34
|
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 |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-09 19:39:28
|
Ted said:
> Well, you know, I thought it was an elegant approach. A serialized object
> graph only contains each object's state information (just instance
> variable settings are included, no code is sent with serialization). What
> can be simpler than having a target system read what the state of each
> object's instance variables are and then reconstituting it based on this
> information?
How do you handle hardware intialization at startup? What about other
initializations (Container level....like opening communications
connections/streams, ensuring that the component lifecycles are properly
managed)?
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). If it's just a bunch of very simple components that get serialized, it
can work(as with GUI components where JavaBeans evolved from), but in a
container-based system, this becomes nigh impossible. Trying to handle the
complexity of mixing and matching config/initialization/lifecycle AND
serialization state usually makes the serialization approach much less
attractive.
> The new XML based Long Term Persistence API has completely
> fixed this problem and now Sun strongly recommends using the LTP API for
> saving object graphs of any kind for any purpose for any length of time.
That only makes sense for object graphs that are inherently static in nature,
and that have temporal dependencies (eg. initialization, lifecycle, etc.).
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.
> Perhaps James and I are missing something here but since the Long Term
> Persistence API has fixed the versioning problem I do not see the downside
> of using object serialization as a lightweight method for getting an
> application into an Embedlet Container?
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? There are
none that I am aware of (at least not successful ones). Sure, some of these
containers use serialization as a short term persistence strategy (typically for
caching/paging activities, which can be a good use for this technique), but
every one uses an XML config approach to the packaging/config runtime
config/startup process due to the issues I have mentioned earlier.
Actually...there is one implementation that relied on such a serialized object
graph approach to saving/packaging an application, and that was Smalltalk.
Most Smalltalk implementations saved a complete "image" of the application
(effectively the same thing as serialization under the covers). This approach
was fraught with issues in the real world (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). It failed as a practical application packaging technology.
It was tried. It did not work (or at least it caused many serious problems that
caused the approach to go out of favour). It's against all current Container
design best practices.
My vote: serialization as a component packaging technology for Embedlets:
-666 (forget this wimpy +1/0/-1 stuff <grins>).
The devil is in the details....and he's gonna getcha if you go down this road. ;-)
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
|
|
From: Andrzej J. T. <an...@ch...> - 2003-02-09 19:00:59
|
Brill suggests: > Now the question as I see it, is how much do we try and make the two > dependant from one another... if they are, we will loose flexibility and > the ability for developers to use the japl without Outpost, however if > they are not we will expand the size of our code to some degree (or so I > would assume). I think they should be decoupled as much as is humanly possible. Tight coupling in that area would be disastrous from a flexibility and maintenance perspective. A developer should be able to use Outpost/Embedlets with or without JAPL. Similarily, JAPL should not depend on Embedlets. The one is a container architecture, the other is a hardware abstraction layer. They need to be distinct. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-09 19:00:52
|
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 |
|
From: James C. <ca...@vi...> - 2003-02-09 14:31:44
|
>It does add significant cost to the product, Java iButtons are not cheap.. Maybe I should put a muvium device into an iButton container and sell them for $10 :-) > -----Original Message----- > From: emb...@li... > [mailto:emb...@li...]On Behalf Of Jac > Kersing > Sent: Monday, February 10, 2003 1:20 AM > To: emb...@li... > Subject: Re: [Embedlets-dev] Re: [Arch]embedlets & security > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > On Sat, 8 Feb 2003, Ted Kosan wrote: > > > If we go with TINI/TStik as a reference platform (which is the way I am > > also leaning for a number of reasons) then we can use the iButton holder > > clip that is present on most TINI/TStik socket boards to hold a JavaCard > > compliant iButton that could handle our digital signing and verification > > needs. > > That will significantly slow responces. The Java Buttons are far from fast > and the data exchange over 1-wire is not too speedy as well. However, it > is a valid option (and would allow me to use my Java buttons for something > usefull :-) > > It does add significant cost to the product, Java iButtons are not cheap.. > > 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 > > |
|
From: Jac K. <j.k...@th...> - 2003-02-09 14:15:09
|
On Sun, 9 Feb 2003, Brill Pappin wrote: > 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) Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com |
|
From: Jac K. <j.k...@th...> - 2003-02-09 14:13:19
|
On Sun, 9 Feb 2003, Brill Pappin wrote: > 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... Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com |
|
From: Jac K. <j.k...@th...> - 2003-02-09 14:11:29
|
On Sat, 8 Feb 2003, Ted Kosan wrote: > If we go with TINI/TStik as a reference platform (which is the way I am > also leaning for a number of reasons) then we can use the iButton holder > clip that is present on most TINI/TStik socket boards to hold a JavaCard > compliant iButton that could handle our digital signing and verification > needs. That will significantly slow responces. The Java Buttons are far from fast and the data exchange over 1-wire is not too speedy as well. However, it is a valid option (and would allow me to use my Java buttons for something usefull :-) It does add significant cost to the product, Java iButtons are not cheap.. Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com |
|
From: Jac K. <j.k...@th...> - 2003-02-09 14:06:08
|
On Sun, 9 Feb 2003, Brill Pappin wrote: > The system is really to be run on internal networks, but that won't make > the security conscious happy... You try to keep the security officers happy when the internal network has 30,000+ users. That's the size of one of the internal networks I'm using 4 days a week. BTW, are we targetting J2ME phone connectivity to our embedlets? If so the network won't be internal as GPRS providers in europe assign public IP space for mobile phones. > as for how sensitive the data actually is... I'm not sure... For security officers all data is sensitive until proven otherwise. > Anyway, I think we can get away with not implementing it for our > prototypes, but I think its something that *is* a serious issue that we > need to address. We'd better make provisions right from the start. The prototypes might contain null-security-providers, but it shows we've at least addressed the issue. (And allows for easy extension of the prototypes for 'real' use) Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com |
|
From: Brill P. <bri...@ro...> - 2003-02-09 09:55:31
|
> > That doesn't help us with SSL however, which your going to need to you > > provide HTTP access directly from the device. > > Well, does one really need to encrypt the communications to and from an > embedded device? I would think that measurement data along with command and > control messages do not represent sensitive information that needs to be > encrypted. I can definitely see the need to digitally sign outgoing data posts > and to verify the digital signatures on incoming commands in certain > situations, though. The crypto iButtons should be able to handle these chores > I think. Regardless of my opinion... that's one of the first things that's going to be asked by systems people when you try to sell it to them. The system is really to be run on internal networks, but that won't make the security conscious happy... as for how sensitive the data actually is... I'm not sure... if I had to come up with an example on the spot, you could for instance find out how many of a product a company was producing, or if there where having trouble with their machinery... both of which could be used against the company... how? be inventive... ;) for instance, if you where another company trying to close a deal with them, you might find that information valuable. Anyway, I think we can get away with not implementing it for our prototypes, but I think its something that *is* a serious issue that we need to address. - Brill Pappin |
|
From: James C. <ca...@vi...> - 2003-02-09 09:15:39
|
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? 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. James Caska http://www.muvium.com 'Java Bred for Embedded' > -----Original Message----- > From: emb...@li... > [mailto:emb...@li...]On Behalf Of Ted > Kosan > Sent: Sunday, February 09, 2003 6:38 PM > To: emb...@li... > Subject: [Embedlets-dev] [Arch] Persistence vs. Management > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > James stated: > > > Ted's original vision was to have the Embedlet container be > able to accept a > > serialised stream representing the instantiated application embedlet > > heirachy all in one go. I quite like it, the container only > needs to be able > > deserialise, the task of serialisation is done by the > management tool and > > all you need is some communications link to 'upload' the > serialised embedlet > > application. It is certainly quite an elegant approach. > > Well, you know, I thought it was an elegant approach. A serialized object > graph only contains each object's state information (just > instance variable > settings are included, no code is sent with serialization). What can be > simpler than having a target system read what the state of each object's > instance variables are and then reconstituting it based on this > information? > > The TINI/TStik already supports this now through ObjectInputStream and > JStamp/JStik will be supporting it soon. > > As for the serialized object graph versioning problem that Gregg > pointed out, > this is the well documented weakness of trying to use the > original *binary* > version of object serialization for long term persistence needs > (and hense all > the warnings in the API docs about not using it for long term > storage). The > new XML based Long Term Persistence API has completely fixed this > problem and > now Sun strongly recommends using the LTP API for saving object > graphs of any > kind for any purpose for any length of time. In my opinion they > have made this > API bullet-proof and I strongly suggest that skeptics have a > closer look at it > before rejecting this idea. > > For the purposes of getting a serialized object graph into an Embedlet > Container an object graph would only need to be converted into the binary > serialization format for the short span of time it takes to > transfer it to an > Embedlet Container. > > Perhaps James and I are missing something here but since the Long Term > Persistence API has fixed the versioning problem I do not see the > downside of > using object serialization as a lightweight method for getting an > application > into an Embedlet Container? > > > Ted > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.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 > > |
|
From: Ted K. <tk...@ya...> - 2003-02-09 07:38:08
|
James stated: > Ted's original vision was to have the Embedlet container be able to accept a > serialised stream representing the instantiated application embedlet > heirachy all in one go. I quite like it, the container only needs to be able > deserialise, the task of serialisation is done by the management tool and > all you need is some communications link to 'upload' the serialised embedlet > application. It is certainly quite an elegant approach. Well, you know, I thought it was an elegant approach. A serialized object graph only contains each object's state information (just instance variable settings are included, no code is sent with serialization). What can be simpler than having a target system read what the state of each object's instance variables are and then reconstituting it based on this information? The TINI/TStik already supports this now through ObjectInputStream and JStamp/JStik will be supporting it soon. As for the serialized object graph versioning problem that Gregg pointed out, this is the well documented weakness of trying to use the original *binary* version of object serialization for long term persistence needs (and hense all the warnings in the API docs about not using it for long term storage). The new XML based Long Term Persistence API has completely fixed this problem and now Sun strongly recommends using the LTP API for saving object graphs of any kind for any purpose for any length of time. In my opinion they have made this API bullet-proof and I strongly suggest that skeptics have a closer look at it before rejecting this idea. For the purposes of getting a serialized object graph into an Embedlet Container an object graph would only need to be converted into the binary serialization format for the short span of time it takes to transfer it to an Embedlet Container. Perhaps James and I are missing something here but since the Long Term Persistence API has fixed the versioning problem I do not see the downside of using object serialization as a lightweight method for getting an application into an Embedlet Container? Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Ted K. <tk...@ya...> - 2003-02-09 07:03:45
|
Brill, > 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)? They are good for signing information and verifyng signagures but they are too slow for encrypting and decrypting data streams. See: http://lists.dalsemi.com/maillists/java-powered-ibutton/2002-November/002775.html > That doesn't help us with SSL however, which your going to need to you > provide HTTP access directly from the device. Well, does one really need to encrypt the communications to and from an embedded device? I would think that measurement data along with command and control messages do not represent sensitive information that needs to be encrypted. I can definitely see the need to digitally sign outgoing data posts and to verify the digital signatures on incoming commands in certain situations, though. The crypto iButtons should be able to handle these chores I think. Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: James C. <ca...@vi...> - 2003-02-09 06:19:09
|
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... James > -----Original Message----- > From: emb...@li... > [mailto:emb...@li...]On Behalf Of > Brill Pappin > Sent: Sunday, February 09, 2003 5:08 PM > To: emb...@li... > Subject: Re: [Embedlets-dev] Re: [Arch]embedlets & security > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > 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)? > > I used to have a fairly simple DES encryption class around I wrote a long > time ago (ported from the common C implementations around)... is > was fairly > simple, and should run on something like a aj-80 or a Tini... not the best > solution, but with a little modification I could encrypt a stream with it. > > That doesn't help us with SSL however, which your going to need to you > provide HTTP access directly from the device. > > Anyway, I'll see what I can come up with on the DES front. > > - Brill Pappin > Rogue Robotics > www.roguerobotics.com > > > ----- Original Message ----- > From: "Ted Kosan" <tk...@ya...> > To: <emb...@li...> > Sent: Saturday, February 08, 2003 9:48 PM > Subject: [Embedlets-dev] Re: [Arch]embedlets & security > > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > > _______________________________________________ > > > > Brill stated: > > > > > I think this is an important aspect... and I was recently thinking of > > > implementing some sort of security for Cork... > > > > > > Keep in mind that we're not just talking about password access, but > > > encryption as well, as clear-text passwords are fairly > limited in their > > > ability to protect anything running over the network. > > > > > > I think for our reference impl. we should definitely include it in our > > > design, but we may not be able to implement it for the first run (I > envision > > > it will take some work) but we should include some sort of security > manager > > > so checks can be performed, even if they always succeed. > > > > If we go with TINI/TStik as a reference platform (which is the way I am > also > > leaning for a number of reasons) then we can use the iButton holder clip > that > > is present on most TINI/TStik socket boards to hold a JavaCard compliant > > iButton that could handle our digital signing and verification needs. > > > > Of course, this will not help with Jac's 'random manipulation of I/O > modules in > > live wiring mode' scenario so we will need to do some more thinking on > this > > problem too. > > > > > > Ted > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > > http://mailplus.yahoo.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 > > > > > > ------------------------------------------------------- > 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 > > |
|
From: Brill P. <bri...@ro...> - 2003-02-09 06:11:01
|
Ahh... found a solution that might work... http://wireless.java.sun.com/midp/ttips/dataencryp/ - Brill Pappin Rogue Robotics www.roguerobotics.com ----- Original Message ----- From: "Ted Kosan" <tk...@ya...> To: <emb...@li...> Sent: Saturday, February 08, 2003 9:48 PM Subject: [Embedlets-dev] Re: [Arch]embedlets & security > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Brill stated: > > > I think this is an important aspect... and I was recently thinking of > > implementing some sort of security for Cork... > > > > Keep in mind that we're not just talking about password access, but > > encryption as well, as clear-text passwords are fairly limited in their > > ability to protect anything running over the network. > > > > I think for our reference impl. we should definitely include it in our > > design, but we may not be able to implement it for the first run (I envision > > it will take some work) but we should include some sort of security manager > > so checks can be performed, even if they always succeed. > > If we go with TINI/TStik as a reference platform (which is the way I am also > leaning for a number of reasons) then we can use the iButton holder clip that > is present on most TINI/TStik socket boards to hold a JavaCard compliant > iButton that could handle our digital signing and verification needs. > > Of course, this will not help with Jac's 'random manipulation of I/O modules in > live wiring mode' scenario so we will need to do some more thinking on this > problem too. > > > Ted > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.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 > |
|
From: Brill P. <bri...@ro...> - 2003-02-09 06:07:35
|
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)? I used to have a fairly simple DES encryption class around I wrote a long time ago (ported from the common C implementations around)... is was fairly simple, and should run on something like a aj-80 or a Tini... not the best solution, but with a little modification I could encrypt a stream with it. That doesn't help us with SSL however, which your going to need to you provide HTTP access directly from the device. Anyway, I'll see what I can come up with on the DES front. - Brill Pappin Rogue Robotics www.roguerobotics.com ----- Original Message ----- From: "Ted Kosan" <tk...@ya...> To: <emb...@li...> Sent: Saturday, February 08, 2003 9:48 PM Subject: [Embedlets-dev] Re: [Arch]embedlets & security > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Brill stated: > > > I think this is an important aspect... and I was recently thinking of > > implementing some sort of security for Cork... > > > > Keep in mind that we're not just talking about password access, but > > encryption as well, as clear-text passwords are fairly limited in their > > ability to protect anything running over the network. > > > > I think for our reference impl. we should definitely include it in our > > design, but we may not be able to implement it for the first run (I envision > > it will take some work) but we should include some sort of security manager > > so checks can be performed, even if they always succeed. > > If we go with TINI/TStik as a reference platform (which is the way I am also > leaning for a number of reasons) then we can use the iButton holder clip that > is present on most TINI/TStik socket boards to hold a JavaCard compliant > iButton that could handle our digital signing and verification needs. > > Of course, this will not help with Jac's 'random manipulation of I/O modules in > live wiring mode' scenario so we will need to do some more thinking on this > problem too. > > > Ted > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.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 > |
|
From: James C. <ca...@vi...> - 2003-02-09 05:54:00
|
>Most PICs running uVM won't have enough RAM to hold the parsing stack. If well designed ie XML JAXP style and the XML dictionary is lean enough to handle 'on the fly' then I could probably handle XML. Its a bit like the way I handle TCP/IP - I do the whole thing on the fly - in fact most of the packet has been sent even before it is completely received. >To get the Embedlet to dynamically reconfigure itself, you would use a Managment tool (possibly JMX-based) that would let you remotely invoke the reconfig() method call with a string that denotes what saved config should be used when restarting the Embedlet. Ted's original vision was to have the Embedlet container be able to accept a serialised stream representing the instantiated application embedlet heirachy all in one go. I quite like it, the container only needs to be able deserialise, the task of serialisation is done by the management tool and all you need is some communications link to 'upload' the serialised embedlet application. It is certainly quite an elegant 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: Sunday, February 09, 2003 5:57 AM > To: emb...@li... > Subject: [Embedlets-dev] [Arch] Persistence vs. Management > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Chris responds. > > > I think that it could be simplified to two distinct requests > 'getProperty' > > singular and 'getProperties' plural. > > > > This make request parsing single level. > > > > I am not sure why the response attributes need their own ids as they are > > encapsulated within the response and associated with the object > id?? This > > would make for simple XML encoding of multiple attributes in the > > name=value form. > > Doesn't really matter....it was just a quick example off the top > of my head....not a proposal for an > on-the-wire encoding. As I had mentioned, I think using a > SOAP/RPC encoding that is based on > WSDL and standard Web Services encodings will be the initial way > to go (though with pluggable > adapters for communications protocols and transports, it should > be fairly easy to change to some > other encoding if there is need/desire to do so). > > > They are not actually orthagonal to each other, but rather very much > > parallel. They are both variations on property set/get > functionality. From > > the Embedlet's point of view there is no difference between a > persistence > > property assignment and a Management property assignment. > > Actually I think there is a lot of difference, despite the rather > superficial similarties. > > Of course, Property setting/getting looks similar....that's a > pretty basic requirement. And a > SOAP/RCP based XML encoding (based on Web Services standards and > code generators like > Apache Axis) would look virtually identical. > > But keep in mind that Persistence should not be tied to a > particular encoding format (like XML). > The interface should be generic enough to support pluggable > storage/retrieval handlers for any > object. XML would typically be most useful if the storage was > going to be streamed over a network > connection. Internal storage (flash) should probably be in some > other native object format (for > efficiency of processing and memory utilization). > > > Both require an Object to Property(ies) interface. > > Some forms of persistence (saving an actual object instance to > Flash) many not require this. > > > Both require an XML vocabulary that maps objects (or parts of > objects) to > > XML. > > Not always. We're trying to avoid as much internal use and > parsing of XML as possible since the > overheads can get way too high for constrained devices. Most > PICs running uVM won't have > enough RAM to hold the parsing stack. > > > In the case of Management the media is XML over TCP/IP (HTTP). > In the case > > of persistence the media is varied and will require separate services to > > provide the 'EmbedletProperties' implementation. The interfaces ensure > > that: > > Have you read the JMX spec? It provides for much more than just > property getter/setters. It > supports arbitrary method invocation, notifications (events), > timers, monitors and such. > Persistence does not need all of those features, which is why I > say they should be distinct services > with their own API designs. If there is some overlap and we can > make the API's look similar for > that overlap (or even identical) then that would be useful from a > user learning curve perspective, > but it's not strictly necessary. > > > The Embedlet does'nt care where its properties are sent to or > come from. > > No it doesn't and shouldn't. That is basic interface > encapsulation, and you're preaching to the > converted! ;-) > > However, things like dynamic reconfig need to be handled through > the lifecycle process....some > values in a config will not be changeable without re-initializing > the Embedlet. > > > The 'EmbedletProperties' implementation does'nt care which > Embedlet it is > > populating. > > But the EmbedletProperties approach does not address the other > Management features (arbitrary > method invocation, notifications (events), timers, monitors and > such). It also does not address the > need for a more generic persistence service, which can save > objects other than Embedlets. In > fact, in most cases, I think that applications will not have a > need to save an Embedlet in persistent > storage, but rather some object that the Embedlet may use. For > instance, a Config Object (or > multiple versions from your scenario on dynamic reconfig) could > be Persistable, even if the > Embedlet that uses it is not. Persistence can be implemented > through a JavaBeans properties- > based approach, but that is not the only way to do it (and may > turn out not to be the best way in all > circumstances...eg. storage to flash). > > > That is the hallmark of a good de-coupled design. > > Persistence deals with the storage and retrieval of data > (probably objects that implement a > Persistable interface). Management primarily deals with > configuration and monitoring of > "Manageable" objects (which could be Embedlets, JAPL device > drivers, Communications Adapters, > the Container itself and the Services the container provides). > > They are radically different in their purpose and usage, and thus > I believe should be independent of > each other (for the most part). > > Granted that in some circumstances (specifically the dynamic > config scenario you outlined) the > Management Service may need to be used to reconfig a running > Embedlet using a stored config. > Here's a potential scenario: > > You need to the reconfig the Embedlet where the new config that > is one that is typically put > together using the Wiring tool, that is, part of the normal > Container initialization config info that is > passed to an Embedlet during the startup phase of the lifecycle. > In this scenario the Embedlet > might externally expose a reconfig method (through the Management > Service) something like this > (only an example): > > boolean reconfig( String pconfigID ) { > > try { > PersistenceService ps = Service( > EMBEDLET_PERSISTENCE_SERVICE ); > LifecycleService ls = getService( > EMBEDLET_LIFECYCLE_SERVICE ); > EmbedletConfig newConfig = ps.retrieve( > configID, ConfigObject.class() ); > > ls.reInitialize( this, newConfig ); > } > catch( EmbedletServiceNotImplementedException e ) { > // Oh Shit...no Optional Persistence Service (note: > Lifecycle is a Core/Mandatory Ser vice) > } > } > > To get the Embedlet to dynamically reconfigure itself, you would > use a Managment tool (possibly > JMX-based) that would let you remotely invoke the reconfig() > method call with a string that denotes > what saved config should be used when restarting the Embedlet. > Not all Embedlets will need this > capability, and those that don't would simply not implement nor > expose such a method. The value > of this approach is that it keeps Management, Persistence and > Lifecycle services distinct from > each other, and allows for a lot of flexibility in how to handle > the reconfig issue. Note how the > neither the Embedlet nor the Managment service knows where or how > the new config is stored...it > might actually end up being downloaded over a network connection > by the Persistence Service. > > If all you need to do is to change a specific value in the > Embedlet and it doesn't need to go through > the lifecycle re-initialization process, then you could just use > the JMX Management facilities to > change a property that was externally exposed. Persistence > doesn't even come into it, since > nothing needed storing or retrieval. Lifecycle is not involved > since you don't need to re-initialize and > restart the Embedlet. > > Hopefully this helps to illustrate where my warped mind is heading.... > > > > > > > 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 > > |
|
From: Ted K. <tk...@ya...> - 2003-02-09 02:48:44
|
Brill stated: > I think this is an important aspect... and I was recently thinking of > implementing some sort of security for Cork... > > Keep in mind that we're not just talking about password access, but > encryption as well, as clear-text passwords are fairly limited in their > ability to protect anything running over the network. > > I think for our reference impl. we should definitely include it in our > design, but we may not be able to implement it for the first run (I envision > it will take some work) but we should include some sort of security manager > so checks can be performed, even if they always succeed. If we go with TINI/TStik as a reference platform (which is the way I am also leaning for a number of reasons) then we can use the iButton holder clip that is present on most TINI/TStik socket boards to hold a JavaCard compliant iButton that could handle our digital signing and verification needs. Of course, this will not help with Jac's 'random manipulation of I/O modules in live wiring mode' scenario so we will need to do some more thinking on this problem too. Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Brill P. <bri...@ro...> - 2003-02-08 23:20:30
|
I think this is an important aspect... and I was recently thinking of implementing some sort of security for Cork... Keep in mind that we're not just talking about password access, but encryption as well, as clear-text passwords are fairly limited in their ability to protect anything running over the network. I think for our reference impl. we should definitely include it in our design, but we may not be able to implement it for the first run (I envision it will take some work) but we should include some sort of security manager so checks can be performed, even if they always succeed. - Brill Pappin > Gentlepeople, > > 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. > > As we're designing software that can be use to control all kinds of > equipment I would feel better if Joe Average Hacker would not be able to > override the controls... (hmmm, just imagine some ignorant user starting > the 'life wire' mode of Teds wiring tool and starting to switch random > devices on and off) > > 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 > |
|
From: Gregg G. W. <gr...@sk...> - 2003-02-08 23:13:47
|
>> They are not actually orthagonal to each other, but rather very much >> parallel. They are both variations on property set/get functionality. From >> the Embedlet's point of view there is no difference between a persistence >> property assignment and a Management property assignment. > >Actually I think there is a lot of difference, despite the rather superficial similarties. > >Of course, Property setting/getting looks similar....that's a pretty basic requirement. And a >SOAP/RCP based XML encoding (based on Web Services standards and code generators like >Apache Axis) would look virtually identical. > >But keep in mind that Persistence should not be tied to a particular encoding format (like XML). >The interface should be generic enough to support pluggable storage/retrieval handlers for any >object. In our container, we originally used Java serialization for persistance. But soon found out that it was difficult to make sure that SerialVersionUIDs were managed correctly. We had create a properties based management system, and that worked well (via introspection, so adding a new property was just the business of adding a setter and getter). When we started hating serialization, it was trivial to just write and read properties via the Properties.load() and Properties.save() methods, and we have never looked back. Now, we also include in our container definition the ability of a module to include a GUI. So, there is a method that returns a factory for getting the GUI. This factory falls in line with the Jini ServiceUI, and this allows our status monitoring and management app to swallow the containers management objects and provide them inside of its GUI too. So, if you just have our broker, you can use its management tool. But, if you have the monitoring app, you can use it for management, and the broker is not the wiser... Property set/get based management is a fine starting point. Adding a GUI factory mechanism via the JMX client interface or remoting specs would be the next step... ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Christopher S. <cs...@oo...> - 2003-02-08 22:31:35
|
>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> Chris responds.
>
> > I think that it could be simplified to two distinct requests
> 'getProperty'
> > singular and 'getProperties' plural.
> >
> > This make request parsing single level.
> >
> > I am not sure why the response attributes need their own ids as they are
> > encapsulated within the response and associated with the object
> id?? This
> > would make for simple XML encoding of multiple attributes in the
> > name=value form.
>
> Doesn't really matter....it was just a quick example off the top
> of my head....not a proposal for an
> on-the-wire encoding. As I had mentioned, I think using a
> SOAP/RPC encoding that is based on
> WSDL and standard Web Services encodings will be the initial way
> to go (though with pluggable
> adapters for communications protocols and transports, it should
> be fairly easy to change to some
> other encoding if there is need/desire to do so).
>
> > They are not actually orthagonal to each other, but rather very much
> > parallel. They are both variations on property set/get
> functionality. From
> > the Embedlet's point of view there is no difference between a
> persistence
> > property assignment and a Management property assignment.
>
> Actually I think there is a lot of difference, despite the rather
> superficial similarties.
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. 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.
This means that an Embedlet provider would have to offer multiple versions
of Embedlets (simple/static, exposed/dynamic, persistent, managed ...??).
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. In an enviroment that does not require these (it is hard to imagine
not needing at least one) the overhead is small.
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. This is the commonality that should be defined at the
Embedlet interface or a separate 'PropertyExposer' interface (I named it
Persistent originally which may have caused some of the confusion). The
differences between persistence, management and configuration should be
controlled by the container and its services.
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.
>
> Of course, Property setting/getting looks similar....that's a
> pretty basic requirement. And a
> SOAP/RCP based XML encoding (based on Web Services standards and
> code generators like
> Apache Axis) would look virtually identical.
>
> But keep in mind that Persistence should not be tied to a
> particular encoding format (like XML).
> The interface should be generic enough to support pluggable
> storage/retrieval handlers for any
> object. XML would typically be most useful if the storage was
> going to be streamed over a network
> connection. Internal storage (flash) should probably be in some
> other native object format (for
> efficiency of processing and memory utilization).
>
> > Both require an Object to Property(ies) interface.
>
> Some forms of persistence (saving an actual object instance to
> Flash) many not require this.
>
> > Both require an XML vocabulary that maps objects (or parts of
> objects) to
> > XML.
>
> Not always. We're trying to avoid as much internal use and
> parsing of XML as possible since the
> overheads can get way too high for constrained devices. Most
> PICs running uVM won't have
> enough RAM to hold the parsing stack.
>
> > In the case of Management the media is XML over TCP/IP (HTTP).
> In the case
> > of persistence the media is varied and will require separate services to
> > provide the 'EmbedletProperties' implementation. The interfaces ensure
> > that:
>
> Have you read the JMX spec? It provides for much more than just
> property getter/setters. It
> supports arbitrary method invocation, notifications (events),
> timers, monitors and such.
> Persistence does not need all of those features, which is why I
> say they should be distinct services
> with their own API designs. If there is some overlap and we can
> make the API's look similar for
> that overlap (or even identical) then that would be useful from a
> user learning curve perspective,
> but it's not strictly necessary.
>
> > The Embedlet does'nt care where its properties are sent to or
> come from.
>
> No it doesn't and shouldn't. That is basic interface
> encapsulation, and you're preaching to the
> converted! ;-)
>
> However, things like dynamic reconfig need to be handled through
> the lifecycle process....some
> values in a config will not be changeable without re-initializing
> the Embedlet.
>
> > The 'EmbedletProperties' implementation does'nt care which
> Embedlet it is
> > populating.
>
> But the EmbedletProperties approach does not address the other
> Management features (arbitrary
> method invocation, notifications (events), timers, monitors and
> such). It also does not address the
> need for a more generic persistence service, which can save
> objects other than Embedlets. In
> fact, in most cases, I think that applications will not have a
> need to save an Embedlet in persistent
> storage, but rather some object that the Embedlet may use. For
> instance, a Config Object (or
> multiple versions from your scenario on dynamic reconfig) could
> be Persistable, even if the
> Embedlet that uses it is not. Persistence can be implemented
> through a JavaBeans properties-
> based approach, but that is not the only way to do it (and may
> turn out not to be the best way in all
> circumstances...eg. storage to flash).
>
> > That is the hallmark of a good de-coupled design.
>
> Persistence deals with the storage and retrieval of data
> (probably objects that implement a
> Persistable interface). Management primarily deals with
> configuration and monitoring of
> "Manageable" objects (which could be Embedlets, JAPL device
> drivers, Communications Adapters,
> the Container itself and the Services the container provides).
>
> They are radically different in their purpose and usage, and thus
> I believe should be independent of
> each other (for the most part).
>
> Granted that in some circumstances (specifically the dynamic
> config scenario you outlined) the
> Management Service may need to be used to reconfig a running
> Embedlet using a stored config.
> Here's a potential scenario:
>
> You need to the reconfig the Embedlet where the new config that
> is one that is typically put
> together using the Wiring tool, that is, part of the normal
> Container initialization config info that is
> passed to an Embedlet during the startup phase of the lifecycle.
> In this scenario the Embedlet
> might externally expose a reconfig method (through the Management
> Service) something like this
> (only an example):
>
> boolean reconfig( String pconfigID ) {
>
> try {
> PersistenceService ps = getService(
> EMBEDLET_PERSISTENCE_SERVICE );
> LifecycleService ls = getService(
> EMBEDLET_LIFECYCLE_SERVICE );
> EmbedletConfig newConfig = ps.retrieve(
> configID, ConfigObject.class() );
>
> ls.reInitialize( this, newConfig );
> }
> catch( EmbedletServiceNotImplementedException e ) {
> // Oh Shit...no Optional Persistence Service (note:
> Lifecycle is a Core/Mandatory Service)
> }
> }
>
> To get the Embedlet to dynamically reconfigure itself, you would
> use a Managment tool (possibly
> JMX-based) that would let you remotely invoke the reconfig()
> method call with a string that denotes
> what saved config should be used when restarting the Embedlet.
> Not all Embedlets will need this
> capability, and those that don't would simply not implement nor
> expose such a method. The value
> of this approach is that it keeps Management, Persistence and
> Lifecycle services distinct from
> each other, and allows for a lot of flexibility in how to handle
> the reconfig issue. Note how the
> neither the Embedlet nor the Managment service knows where or how
> the new config is stored...it
> might actually end up being downloaded over a network connection
> by the Persistence Service.
>
> If all you need to do is to change a specific value in the
> Embedlet and it doesn't need to go through
> the lifecycle re-initialization process, then you could just use
> the JMX Management facilities to
> change a property that was externally exposed. Persistence
> doesn't even come into it, since
> nothing needed storing or retrieval. Lifecycle is not involved
> since you don't need to re-initialize and
> restart the Embedlet.
>
> Hopefully this helps to illustrate where my warped mind is heading....
>
>
>
>
>
>
> 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
>
|
|
From: Jac K. <j.k...@th...> - 2003-02-08 21:52:20
|
Gentlepeople, 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. As we're designing software that can be use to control all kinds of equipment I would feel better if Joe Average Hacker would not be able to override the controls... (hmmm, just imagine some ignorant user starting the 'life wire' mode of Teds wiring tool and starting to switch random devices on and off) Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com |
|
From: Christopher S. <cs...@oo...> - 2003-02-08 21:41:13
|
I was guessing so go with Enterprise ARchive > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > I've heard 3 different names for EAR so far, I thought is was "Enterprise > ARchive" the same way WAR is "Web ARchive", and JAR is "Java ARchive". > > Well, its documented somewhere if anyone cares enough ;) > > > Already used in the Sun J2EE reference server. Enterprise Application > > Resources (I think). > > - Brill Pappin > > > > ------------------------------------------------------- > 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 > |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-08 19:00:08
|
Ted: > Again, my main concern here was for making > sure the Embedlets architecture at least kept an eye towards attempting to > accommodate the optional live-wiring-mode/serialized-object-graph > technique as it was being developed. Yup.....I'm definitely keeping this in mind so that we'll be able to create a container that will support live wiring and execution. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
11 messages has been excluded from this view by a project administrator.
Thanks for helping keep SourceForge clean.
X