embedlets-developer Mailing List for Outpost Embedlet Container (Page 32)
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: James C. <ca...@vi...> - 2003-02-07 00:43:05
|
This is all part of a paradigm shift from a hardware centric world to a software centric world. The VM concept is all part of the same shift where hardware is the commodity and the software and skillbases of the users has the greatest value. It makes total sense, when hardware was first introduced, there were no software users and knowing the hardware was the only way to solve the problem so hardware got proprietry and arogant and always thought it would be this way. 30+ years later the value is in the millions of users with between 1 and 40 years of software experience equallying hundreds of millions of man years of skillbase and knowledge. These days its pretty rich for a hardware company to put out a new chip costing say 100 man years and expect the market with 100 million man years of momentum to relearn the new hardware. Hence, the VM, making software look like hardware. It also underpins my Language Neutralisation Strategy for muvium. 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: Friday, February 07, 2003 10:25 AM > To: emb...@li... > Subject: [Embedlets-dev] Relevant reading.... > > > Topic tags:[AR][GW][DO][HW][PM] > _______________________________________________ > > Came across an interesting strategy document from Joel Spolsky on > commoditizing your complements today. I thought I had read all > of Joel's older > stuff, but somehow I missed this one. > > It struck me that we are trying to do exactly that with the > Outpost/Embedlet > project. We want to commoditize embedded software development process. > Interesting! His comments about Sun's Java quandry also are > relevant, since > our approach also has the chance of commoditizing the proprietary > hardware > that has been typically used in embedded solutions, as a > side-effect of using > Java as the platform. > > Worth a read: http://www.joelonsoftware.com/articles/StrategyLetterV.html > > > 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: Andrzej J. T. <an...@ch...> - 2003-02-06 23:27:16
|
Came across an interesting strategy document from Joel Spolsky on commoditizing your complements today. I thought I had read all of Joel's older stuff, but somehow I missed this one. It struck me that we are trying to do exactly that with the Outpost/Embedlet project. We want to commoditize embedded software development process. Interesting! His comments about Sun's Java quandry also are relevant, since our approach also has the chance of commoditizing the proprietary hardware that has been typically used in embedded solutions, as a side-effect of using Java as the platform. Worth a read: http://www.joelonsoftware.com/articles/StrategyLetterV.html Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Ted K. <tk...@ya...> - 2003-02-06 22:11:50
|
Andrzej, >I envisioned the Wiring tool as just being responsible >for the specification of how an Outpost application was >wired together (which embedlets, device drivers/JAPLs, >adapters), and would simply generate the XML Config file >declaration that represents this wiring. Then it would >only call the regular(non-graphical) build process upon >request (which might be an ANT build, but that is just >calling a java process like almost any other). My vision for the Wiring Tool is for it to be able to do everything you have laid out here because I agree that they are important to the project. I will call this the Wiring Tool's 'specification' mode. But I also want it to go beyond these capabilities. The Wiring Tool will have a mode where it will host a live Embedlet Container and as Embedlets are dragged from a pallet and dropped into the container they are instantiated and completely functional. I will call this the Wiring Tool's 'live wiring' mode. In live wiring mode, the JAPL pallet will contain a selection of JAPL peripherals on it that can be dropped into the wiring area and then attached to the sides of the Embedlet Container just as you have shown in the Architecture document. These JAPL interfaces can then be implemented by simulated I/O modules (which are wired to the implementation side of the JAPL peripheral) or by physical PnP modules that are attached to the workstation. As the Embedlet based application is wired together, its functionality can be continuously tested by sending live events to the Embedlets using a dialog in the Wiring Tool or by triggering the simulated JAPL I/O module or by triggering the physical I/O module. I also think that perhaps something like JUnit tests could also be generated for both sides of the JAPL interfaces so that the application can be continuously tested from outside the Embedlet container and the I/O modules could be tested from the inside. The ID tags on the I/O modules can also be read or configured at this time so that when the I/O circuit is detached from the workstation and moved over to the target embedded system the application has already had its bindings made with the I/O modules. The application is manipulated until it is running as desired. No compilation occurs during this process and none is needed because all of the Embedlets used in this mode have already been pre-compiled. At this point one has a complete Embedlet object graph that is configured and wired together as desired and all of the configuration file information that can be specified in specification mode already exists in this live object graph. One now has the following choices that can be made: 1) Have all of the configuration files for all of the Embedlets and JAPL peripherals automatically generated from this object graph. This can be done by either a) analyzing the object graph in memory and converting it into the XML configuration file formats or by b) using the Long Term Persistence API to serialize the object graph into an XML file format which can then be used to generate the needed XML files. 2) The object graph represents the application exactly as we want to have it running on the target system so we serialize this object graph, send it to the target system using whatever method method is appropriate and then deserialize it into the target system's Embedlet Container. Of course, each Embedlet's .class file will also need to be sent to the target system but I am hoping that something like a BAR file could accommodate not only .class files and other needed resources, but a serialized object graph if desired too. TINI/TStik already have deserialization capabilities and I have tested this idea on a TINI and it works just fine. As soon as Ajile releases their CDC implementation JStamp/JStik will have deserialization capabilities too. James has said that muivum could also accomodate this technique if needed. The reason that I like the idea of leveraging Ant is that operations that would have been built into the Wiring Tool (and thus dependent on it) could be moved into Ant. For example, the generation of Embedlet configuration files from a serialized object graph could be done in Ant so that this operation can be used by the Wiring Tool and by any other entity that is capable of using Ant. So again, I am committed to giving the Wiring Tool a specification mode that will operate any way you and others think is appropriate for generating Embedlet configuration files but I am going to attempt to give the Wiring Tool a live wiring mode too. Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Nicola K. B. <nic...@ap...> - 2003-02-06 21:04:54
|
Ted Kosan wrote, On 06/02/2003 21.40:
...
> Even though the Embedlet specification's responsibilities would need to stop
> here I could still see us developing a number of Ant targets for deploying BAR
> files into various Embedlet Container hosts including muivums, TStik/TINIs,
> JStamps, etc.
All this discussion on Ant... why don't you all just try it and ditch it
with the speed of light if there is a better alternative or it doesn't work?
I am *very* ignorant about embedded devided, but this is inversally
propostional to my interest in it and in my knowledge of Ant ;-)
I can surely help you with Ant, and will be very happy to do so, because
I want to help in this great project and don't really get it just yet ;-)
--
Nicola Ken Barozzi nic...@ap...
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
|
|
From: Ted K. <tk...@ya...> - 2003-02-06 20:40:16
|
Andrzej said: >Also the design practices/paradigms of Separation of >Concern, Modularity, Layering and Encapsulation apply >to the build/deploy/management process implementations >as much as to the Container design itself. In a nutshell: >"keep 'em all decoupled as much as possible". I have found the build/deploy diagram in the Architecture document to be extremely useful for envisioning how all the pieces we have been talking about fit together. One thing that comes to mind here is that it would be nice if we could abstract the deployment target to just be an Embedlet Container (no matter where is it hosted) and the deployment artifact to be something similar to a WAR file (perhaps BAR (emBedded Application aRchive) ) that would contain all of the resources needed to run the Embedlet based application. Even though the Embedlet specification's responsibilities would need to stop here I could still see us developing a number of Ant targets for deploying BAR files into various Embedlet Container hosts including muivums, TStik/TINIs, JStamps, etc. Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-06 17:44:01
|
Gregg posts an insightful comment (snipped for brevity): > The servlet has the ability to do mass updates to multiple sites so that > mistakes due to missed steps or missed devices are highly unlikely. > Ant is not required because we have automated recognition of new devices, > installation of new configurations, replacement of devices due to failures > etc. Absolutely. Let's get clear on the fact that a build process (from the perspective of compiling and assembling an executable), is a different beastie than a deployment process (which is typically charged with configuration and dissemination of the application), which is again a bit different than a management process (thinking from an Operations/Monitoring perspective). There is some overlap that forms a grey area (configuration, reconfiguration) that any of these processes can subsume, which seems to be causing some of the confusion on this subject. The build process will probably be very nearly identical (with variations for specific platforms possibly, JStamp vs TStik vs. uVM, etc) regardless of the application. The management process will probably be rather unique to each particular application, but by supporting an emerging standard like JMX, existing systems management tools could easily be used to perform this function. The uniqueness here is not found so much in the management tool (use Tivoli, OpenView or even a custom servlet like Greggs, but in all cases JMX provides a base level of commonality on how you technically do the management), as much as unique business procedures (when this alarm is raised, do this.....) which may or may not be automated, depending on the circumstances. The deployment process will probably be very unique to the particular application that was created. As Gregg said, they created a custom deployment solution using a servlet for their application. There probably isn't enough deployment commonality across the whole space of possible applications that Outpost/Embedlets are targeted at to be able to create a single universal "deployer" solution that will meet everyones needs. For example, whether an embedlet/applications needs static versus dynamic configuration capability might alter the thinking of which process should do the configuration, as follows: If the application is using dynamic configuration of the deployed Embedlets (which is proposed to be an optional Outpost service), then the build and deployment processes are quite detatched from each other. You would do one build (per platform), then use the deployment process multiple times to load/config/run the code on many devices (note..the overall deployment process to multiple devices could be automated, basically in a loop that runs through the single device deployment process for each device). The dynamic configuration would be performed using the optional Outpost Management Service...which could be easily implemented as a Browser-visible Servlet that issues (under the covers) the JMX management calls to do the config for each device, similar to Gregg's implementation (or maybe using some other technique). No problem....the architecture handles it nicely, and the build and deploy are nicely separated in responsbility. If we look at more constrained devices or applications that use static configuration (that may not be able or want to support dynamic configuration) , there would probably be a bit more interaction between the build and deploy processes. The build process, which might include generation of the static config, could be used as a "subroutine" of the wider scoped deploy process. For example, the deploy process might grab the config info from a database, then call the build process (which could be just an JVM process which runs Ant) with some parameters specific to the device being deployed/configed, and the build process (Ant) would create a custom static build based on those parms. The deploy process would then grab this output (the statically configured build) and would somehow install it on the device. So even in the static scenario, it's possible to decouple the very application-specific deploy process from the build, by treating the build as a self-contained "subroutine". Ant is very powerful for build processes, especially Java and XML-oriented ones (it comes with a large library of tasks to handle very common Java and XML activities, including XSLT transformations, which might be useful for any static code generation we need). It's yet to be determined whether Ant also provides enough compelling value to a "deployment process" (that will be unique to each user's application and environment) to make it worthy of consideration. My guess is that Ant will not be as useful for that, and that more custom, UI-based deployment solutions will be required for many scenarios. But we don't have to make that determination yet. That being said, there may be some situations where there would be benefit to having the Deployment tool generate a custom Ant build.xml script for each device that needs to be deployed, based on a template script. This might provide for a more flexible custom deployer solution, as compared to one that hard-codes the deployment process in Java (or some other) code. Conceptually, this hybrid approach uses Ant as a rudimentary BPM (Business Process Management) engine with the businesss process (deployment process in this case) being declaritively specified in XML files (templates, etc.). For large Fortune 1000 companies with massive deployment requirements, it might even make sense to use a commercial BPM for this task, rather than investing in the development of a custom solution. More philosophically speaking, regarding the design of business systems, declarative specification of processes is much more flexible and maintainable, at lower cost than procedural (eg. programmed/coded) implementations, for complex processes. Also the design practices/paradigms of Separation of Concern, Modularity, Layering and Encapsulation apply to the build/deploy/management process implementations as much as to the Container design itself. In a nutshell: "keep 'em all decoupled as much as possible". Anyway...some thoughts from snowy Canada. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-06 17:43:56
|
Ted asks > Does anyone have a problem with me setting up a separate list within the > project devoted to development of the wiring tool? Nope...but sign me up for it anyway. I won't have time to do any development of such a tool, but the Embedlet Application XML Config schema will have to be useable by both sides, so I'll probably have some input from that perspective. Also have some "thoughts" already to share regarding wiring metaphors in an event-based system. ;-) Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-06 17:43:52
|
Ted asks: > Why again are we thinking about creating a version of Embedlets that does > not utilize threads? I must have missed the post that talked about this. Some target uControllers may not support threads. I don't believe uVM has them yet and given the size of James' uVM to-do list, it might be a while. It's not something that needs to be in the spec...it's a Container implementation detail is all. Just like with a servlet implementation, the creator of an Embedlet or an assembler (merrily wiring away using a hot graphical tool) should not care nor see whether the container is implemented in a threaded manner or not. However, the spec should provide some guidelines (as the servlet spec does) so that Embedlets are thread-safe regardless. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Gregg G. W. <gr...@sk...> - 2003-02-06 16:53:56
|
>For those who are advocating not going with Ant I would like to see your >solution to the plastics plant scenario listed above. I will also volunteer to >put together a table that compares the various proposed build/deploy solutions >against the above scenario if any more are submitted. This is true today... Okay, we have a customer that has ~200 'wide fanout hub' devices that collect data and control some 460 end devices. The 'wide fanout devices' software is implemented by another company, and is not java based. They send proprietary messages to our 'broker' that we in turn forward to 3 different JDBC accessible databases as well as log to files for the support staff to reference. The broker requires no changes to add new field devices nor 'wide fanout hub' devices. The 'wide fan out' devices have bugs fixed here and there. We have a servlet based web tool that can be accessed from anywhere in the enterprise. It references a directory tree populated with the 'wide fanout hub' manufactures executables, as well as per device configuration files. It also references a configuration database that tells what specific settings apply to each 'wide fanout hub' including its primary, secondary and tertiary broker. From anywhere in the enterprise, you can connect to the associated servlet, with a browser, and (re)configure or reload a 'wide fanout hub' and/or the end devices attached to it, via this servlet. The 'wide fanout hub' is loaded via ftp, and can be reset via ftp as well. In the 3+ years that this system has been installed, we have upgraded the broker software 3 times. The 'wide fanout hub' devices have been through at least 20 software revisions. The enterprise has moved the databases to different servers 3 different times, with a 4th coming soon when we will also move the brokers 2 states away and across networks. Careful organization of the applications, the configuration materials and documentation has made it possible to do all of these things without any loss of service, and with very little work other than that explicitly required to install devices, or recable equipment etc. The servlet has the ability to do mass updates to multiple sites so that mistakes due to missed steps or missed devices are highly unlikely. Ant is not required because we have automated recognition of new devices, installation of new configurations, replacement of devices due to failures etc. Now, I will not say that ant might not be useful for some things. I have gotten along without it by designing tools that would have to be built to run under ant if that was how I chose to deal with automation. We started this before there was an Ant, J2EE, JMS, JMX, J2ME, and even Java-2... However, we have integrated most of these technologies into our systems with little effort, because we have followed the progress of them, and tried to participate in associated mailing lists. GUI tools are important for many management tasks. They help enumerate as well as synchronize steps that need to be performed. Making a task visible is often the most important issue in designing a complicated system... The issues is that obviously the more detailed a particular management task is, the more details need to be covered in any tool that automates things. When you provide an automation tool in a package that is a development platform, its lack of a particular functionality often shapes the way that people with less experience design their applications on that platform. Consider how much really bad HTML was handwritten until there were HTML editors. Also consider the fact that the templates in most HTML editors now confine the styles of web pages that are visible on the web. This is good from the perspective that it makes all of us more comfortable because the sites are similar. However, it also causes people that have special needs, but not the knowledge of HTML, CSS or otherwise, to be confined in their implementation. I don't know that I have a grand idea for how to eliminate this reality though :-) I often just leave out automation tools when I feel like their solution space is so narrow that they confine more than they extend the system involved. And no I am not saying that Ant is confining... :-) ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-06 16:28:59
|
Charles pipes up:
> Sounds like we are very much in sync (see following excerpt).
Pretty close.
> Not to get hung up on the syntax, but I would like to point out that
> passing around the XML serialized object itself as the response has one or
> two advantages:
>
> 1. Multiple attributes can be returned in one request, as opposed to
> multiple requests required for an RPC/SOAP based scheme.
My example was for a single property.....but is easily extended to support
multiple requests/responses. How about this:
<requests target="embedlet"
<request type="light"
id="30212"
operation="getProperty"
property="CB_OUTPUT_1" />
<request type="switch"
operation="getProperties" />
</requests>
and the response could be more like:
<responses target="embedlet">
<response type="light"
<attribute id="30212" property="CB_OUTPUT_1" value="On" />
<response type="switch"
<attribute id="666" property="SW_STATE_1" value="On" />
<attribute id="666" property="SW_STATE_2" value="Off" />
<attribute id="999" property="SW_STATE_1 value="Off" />
<attribute id="1024" property="SW_STATE_3 value="On" />
<response>
</requests>
Single request (over HTTP/SOAP)...single response. But multiple operations
and values. My prior example was to illustrate the difference/benefits between
a more generic syntax and an application specific one, specifically for
Management functions, as is the above example. Now that I think more about
it....it's not so much that it's a generic syntax, it's one that is more specific to a
Management domain than a Persistence one.
The above example is NOT intended to be used for Persistence (serialization),
that should have it's own vocabulary as I'll discuss below.
In fact, if we use SOAP RPC semantics (as I was intending to all along), then it
makes sense to use the SOAP schema for this kind of thing where the
operations are defined by the method called and parameters that are passed
to it and documented in a WSDL definition. If you look at SOAP RPC and a
typical WSDL definition, it does use app-specific element names for the
methods and parameters and return values, very much like your example.
Given that JMX Management invocations are RPC in nature, and so
SOAP/HTTP makes a lot of sense, I was thinking that the best way to
generate this "management vocabulary" would be to take a Web Services
approach. Take your favourite Java->WSDL generator (Apache Axis has one),
and point it at the JMX methods we want to be able to support. Press the
button....and voila....a WSDL definition appears by magic, and exposes an
interface that any Web Services capable application can use to call our
management functions. At the Outpost Container end, we write a very
lightweight Protocol Adapter that translates between the WSDL syntax and our
internal Embedlet Management Service API's (I would suggest that we hand
code this mapping, since it will be more efficient this way, and we can use very
small footprint XML libraries like kXML and kSOAP). Since we will be using
known (and more or less fixed) JMX API's this approach is a very desireable
way of implementing the remote management protocols.
It may or may not make sense to use the SOAP RPC approach to
Persistence. I think we need to design a good Persistence Service API
first.....and then under the covers, if the persisted objects will be sent/retrieved
remotely, it may also make sense to just use the SOAP encoding paradigm
(through an adapter), but still allow lighter weight, non-XML storage on board
the device itself when local storage is called for.
> 2. The object packet is self documenting. The requester needs to know only
> the id of the object and not every attribute. This decouples the
> requester/responder very effectively.
A well designed generic management vocabulary can do the same thing, but
makes it much easier to write a generic service at the container end that can
handle all the grunt work for any/all application domains. For a fairly static
interface definition like JMX, you don't need dynamic/generic parsing that is
implied by self-documenting syntax. SOAP/RPC semantics will do just fine.
3. The ability to 'turn-around' the
> packet with modifications forms the basis for Embedlet update.
This presumes that Persistence and Management should be more tightly
coupled. Something I disagree with.
4. The
> 'object packet' scheme supports persistence in any form (flash, file,
> database etc.) based on the provider, without additional code or XML
> vocabulary.
True enough. However, the issue here is that you have assumed that we
should use a single vocabulary/schema for both Management and
Persistence. These two "services" are orthogonal to each other, thus should
be decoipled and each should probably have it's own underlying
representation. If you are persisting a config (for instance) on the remote
device, then why would you store it in XML format? It would be much easier to
store the config object (post-parsing) itself. By decoupling Management from
Persistence, this could be done more easily.
Decoupling Persistence and Management provides some very compelling
benefits:
1) Each can be specialized and optimized for it's own purposes.
2) Easier to implement them as pluggable/optional services without having to
worry about dependencies.
3) Easier implementation/cleaner of both. For instance, the Management
schema would be structured to make the mapping to JMX API's easier (in fact,
it would be generated by a Java->WSDL Web Services tool). The Persistence
mapping would be structured to make storage/retrieval easier.
4) Each schema would be easier to understand in the context of what the
service is doing, and thus debugging and extension would be easier due to the
decoupling.
5) You wouldn't need serialization capability for Management if your app didn't
need the optional Persistence.
6) It's a best practice to not over-generalize and keep distinct services
decoupled. Sure, you can look at apples and oranges as more generic
fruits....but in this case I think it makes more sense to keep them separate.
> Item 2 leads to a very nice bonus capability where a generic property
> editor without prior knowledge can:
>
> 1. Query the container for its list of Embedlet names/ids
> 2. Select an Embedlet and send a 'getProperties' request. (Note the plural
> form). 3. Display/edit the returned object properties in a name/value
> grid. 4. Modify and update via a 'setProperties' request that returns the
> modified object packet.
All of these can be done (from a Management perspective) with a vocabulary
that is more aligned with the JMX API standard as well. Furthermore, it can be
done with an Enterprise Management tool like Tivoli, Openview or Unicenter.
JMX also provides the capability of receiving remote notifications (simple
matter to translate an embedlet event into a notification), monitoring services
and more, which do not map cleanly into an application specific XML
vocabulary, but that we would need to have present for the optional
Management Service to be able to provide JMX capability easily.
A Persistence schema/vocabulary might be a lot closer to a typical JavaBeans
serialization approach, and might look a lot more like your suggestions. SOAP
RPC syntax does look very much like your approach under the covers, and we
should probably use SOAP it where it makes sense, since standards are
"good things(tm)". ;-)
The problem is trying to do both Persistence and Management in a single
format....I don't think that is wise.
> The responder has control over the properties that are
> exposed/read/written unlike native Java serialization.
Same with the more generic management approach I have outlined.
> The disadvantage of course is that getting the whole object packet is
> likely to be more expensive than a single RPC query, but probably not more
> expensive than 2. If this were an issue the container could filter the
> response down to the requested property.
The exposed API's should provide the level of granularity that makes sense
(regardless of the on-the-wire encoding which is really driven by the API
design in most cases). We could easily provide Management API's that allow
the manipulation/query of individual component properties, and/or more coarse
interfaces like sending/getting of a whole config object in one method. That is
where the "art" of service interface design comes in....figuring out what level of
granularity makes the most sense.
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
|
|
From: Andrzej J. T. <an...@ch...> - 2003-02-06 16:28:46
|
Ted: > One reason is because using Ant or not makes a significant impact on how > the Wiring Tool is designed. If we make the decision to go with Ant then > I can see how the Wiring Tool could heavily leverage Ant's capabilities > for everything from application assembly to packaging and deployment. It > would be much easier to start laying out the architecture of the Wiring > Tool if this decision were made up front. I envisioned the Wiring tool as just being responsible for the specification of how an Outpost application was wired together (which embedlets, device drivers/JAPLs, adapters), and would simply generate the XML Config file declaration that represents this wiring. Then it would only call the regular (non-graphical) build process upon request (which might be an ANT build, but that is just calling a java process like almost any other). The actual code generation (if needed), compiles and packaging would be done by the build process, not the Wiring tool. There is good reason to keep the build process decoupled from the wiring process in this way. As for deployment, that will almost always be application specific, as in your multiple controller/PDA/etc. example. It gets more complicated since some of our target platforms will not easily support dynamic reconfig/redeployment (think about a JStamp....you need a JTag connection to load/burn new code). I think that application-specific deployment will not be something that we should/can tackle early on (if ever) in the Embedlets project. Admittedly, the deployer (put your high-paid consultant hat on, Ted! ;-) ), could probably create automated deployment capabilities using Ant, but they would be custom to each implementation. Brill adds: > I assume the application does not need Ant to work. That is correct....the runtime will not require Ant, just the build/assembly/packaging process. > however I don't think the XML file > format *has* to be the Ant format... in fact I could think of some arguments > against it (also for it but thats another thing) starting with separation of > usage (which I think is a good idea in this case). The intention is that both the Container (Outpost) and Component (embedlet) XML config files will NOT be Ant format. They will be more akin to the Tomcat server.xml and servlet web.xml files. The Ant build.xml file would be a separate file, and would/could use the config files in the various stages of the build as appropriate (eg. for code generation of static application "glue/wiring" logic for very constrainted platforms). What this means is that the build process can be automated with Ant, but all the "ingredients" that specify the final Outpost app could be built with a different tool using the individual container config, component configs, wiring specification, classes, etc. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-06 15:35:42
|
James suggests: > This was the way I very early on proposed uVM devices could interact in > this framework and still make sense. I also think that this is something > that makes sense for the User Interface thing also, why not just use > dynamicall generated HTML as our user interface to anything rather than > try to create some other GUI standard. Exactly so, James. If you have the data in well-structured XML format, then it's an easy matter to transform it into HTML for display in a browser. This is considered an architectural best practice these days. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Ted K. <tk...@ya...> - 2003-02-06 08:09:29
|
I am in the process of putting together a plan for developing the Wiring Tool and part of this plan is going to involve recruiting some people with graphic application development experience to help with its design. Does anyone have a problem with me setting up a separate list within the project devoted to development of the wiring tool? The main reason for doing this is to keep our Wiring Tool 'wussy' traffic off of the main Embedlets developer list. ;-) Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Ted K. <tk...@ya...> - 2003-02-06 07:55:33
|
Why again are we thinking about creating a version of Embedlets that does not utilize threads? I must have missed the post that talked about this. Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Ted K. <tk...@ya...> - 2003-02-06 07:52:25
|
Chris, > Excellent! The TStik would be a natural candidate for both dynamic and > static configuration. Does the class loader have a Classpath outside of the > device or do you load a jar with the available classes? Classloading is done from within the device and they use .tini files instead of .jar files (.tini files contain compressed .class files). Aside from FTP they also support Telnet, reflection, 1-Wire, SPI, I2C CAN and Ethernet. Oh yes, and they cost about $110 when bundled with a socket board. Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Christopher S. <cs...@oo...> - 2003-02-06 07:18:37
|
> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of
> James Caska
> Sent: Wednesday, February 05, 2003 11:02 PM
> To: emb...@li...
> Subject: RE: [Embedlets-dev] Re: [Arch] ANT
>
>
> Topic tags:[Arch][Wiring][Doc][HW][PM]
> _______________________________________________
>
> >A question on the pure dynamic configuration as it relates to muvium: Do
> you
> >have a dynamic instantiator alla forName()?
>
> No I haven't implemented forName() just yet but what I don't have today, I
> 'can have' tommorrow especially if it moves up the priority list.
>
> Implementing a forName() function would be quite straight forward. The
> normal useage of the forName() is something like
> Class.forName("BinaryOr").newInstance(); which complicates the
> implementation with the Class class.
That was the reason for the shortcut.
>
> The alterative would be to override your
> EmbedletClassLoader.forName(String)
> implementation with an assembly implementation that is highly compact and
> optimised for all the classes in the implementation.
>
> Or yes, you could implement it the way you have suggested but for core
> features like this I would think I will be overriding the
> implementations in
> most cases for optimal compactness/performance.
>
> Same thing for planned support of serialisation. As I said.. the list is
> LONG!
>
> James Caska
> http://www.muvium.com
> 'Java Bred for Embedded'
>
>
>
>
>
> > -----Original Message-----
> > From: emb...@li...
> > [mailto:emb...@li...]On Behalf Of
> > Christopher Smith
> > Sent: Thursday, February 06, 2003 5:24 PM
> > To: emb...@li...
> > Subject: RE: [Embedlets-dev] Re: [Arch] ANT
> >
> >
> > Topic tags:[Arch][Wiring][Doc][HW][PM]
> > _______________________________________________
> >
> >
> > > Topic tags:[Arch][Wiring][Doc][HW][PM]
> > > _______________________________________________
> > >
> > > >I do not know what muivum provides but I would be (pleasantly)
> > > surprised if
> > > they have remote-able flash update.
> > >
> > > Updates are over serial Connection UART at the minute with
> TCP/IP remote
> > > update planned shortly. In fact we plan to support dynamic
> updates over
> > > almost anything that can communicate with the uVM device. Also
> > plan remote
> > > in place debugging :-) But the wishlist is pretty long so what
> > > comes when is
> > > trickier!
> > >
> >
> > Very nice! As the muvium is the likely candidate for static
> configuration
> > due to its size contraint this will greatly increase its 'wiring'
> > flexibility.
> >
> > A question on the pure dynamic configuration as it relates to
> > muvium: Do you
> > have a dynamic instantiator alla forName()? This would in effect
> > be the only
> > core requirement for a purely dynamic configuration scheme.
> >
> > If not the following would suffice and it would be interesting
> to see what
> > the footprint would be after your cross compile. (Note name space is
> > speculative and not intended to indicate any preference)
> >
> > /**
> > *
> > * Provides a limited small footprint class loader.
> > * Requires a list of available classes that get instanciated on demand.
> > * Uses the forName(String className) form as in the standard Java class
> > loader.
> > *
> > * @author csmith - OopScope
> > * @date 02/03/2003
> > *
> > */
> >
> > package org.embedlet.persistence;
> >
> > public class EmbedletClassLoader
> > {
> > // Class pool list
> > String[] classes =
> > {"BinaryOr",
> > "BinaryAnd"
> > };
> >
> >
> > /**
> > * Create and instance of the class passed in name
> > *
> > * @param name - the name of the class to instantiate
> > * @return the - instance or null
> > */
> > public Object forName(String name)
> > {
> > int index;
> > boolean found = false;
> > Object object = null;
> > for (index = 0; index<classes.length ; index++)
> > {
> > if (name.equals(classes[index]))
> > {
> > found = true;
> > break;
> > }
> > }
> >
> > if (found)
> > {
> > switch (index)
> > {
> > case 0:
> > // actual code:
> > // object = new BinaryOr();
> >
> > // stub for testing
> > object = new String("BinaryOr");
> > break;
> > case 1:
> > // actual code:
> > //object = new BinaryAnd();
> >
> > // stub for testing
> > object = new String("BinaryAnd");
> > break;
> > }
> > }
> > return object;
> > }
> > }
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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: James C. <ca...@vi...> - 2003-02-06 07:06:32
|
> hang a number of muviums off of it in order to show Outpost-to-Outpost > communications and remote provisioning of the muviums via the > TINI/TStik 'hub'. I think the heirachial connectivity between the layers is extremely important for building full systems from Outpost. I think it will be very attractive to solutions providers to be able to use the java connectivity stack from top to bottom. I am very interested in being able to provide these sort of plug an play capabilities between java enabled devices. James Caska http://www.muvium.com 'Java Bred for Embedded' > -----Original Message----- > From: emb...@li... > [mailto:emb...@li...]On Behalf Of > Christopher Smith > Sent: Thursday, February 06, 2003 6:00 PM > To: emb...@li... > Subject: RE: [Embedlets-dev] Re: [Arch] ANT > > > Topic tags:[Arch][Wiring][Doc][HW][PM] > _______________________________________________ > > > > > Chris stated: > > > > >I do not know what muivum provides but I would be (pleasantly) > > surprised if > > >they have remote-able flash update. > > > > In addition muvium, both TINI and the new Systronix TStik have > > remote update > > capabilities. One can use FTP to upload a new application into a > > TINI/TStik > > and since they are JDK 1.1.8 compliant they also support class > loading and > > object serialization. > > Excellent! The TStik would be a natural candidate for both dynamic and > static configuration. Does the class loader have a Classpath > outside of the > device or do you load a jar with the available classes? > > > > > TINI/TStik are more mature systems than JStamp is and I expect > > that JStamp will > > obtain these capabilities as soon as Ajile finishes their CDC > > implementation. > > > > I personally think that TINI/TStik would make an excellent > > reference platform > > for the Outpost reference implementation and it would also be > > interesting to > > hang a number of muviums off of it in order to show Outpost-to-Outpost > > communications and remote provisioning of the muviums via the > > TINI/TStik 'hub'. > > > > If we decide to go with TINI/TStik as an official reference platform for > > Outpost, I might be able to arrange for each developer on this > > list to get a > > free one. > > > > > > 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: Christopher S. <cs...@oo...> - 2003-02-06 06:59:08
|
> > Chris stated: > > >I do not know what muivum provides but I would be (pleasantly) > surprised if > >they have remote-able flash update. > > In addition muvium, both TINI and the new Systronix TStik have > remote update > capabilities. One can use FTP to upload a new application into a > TINI/TStik > and since they are JDK 1.1.8 compliant they also support class loading and > object serialization. Excellent! The TStik would be a natural candidate for both dynamic and static configuration. Does the class loader have a Classpath outside of the device or do you load a jar with the available classes? > > TINI/TStik are more mature systems than JStamp is and I expect > that JStamp will > obtain these capabilities as soon as Ajile finishes their CDC > implementation. > > I personally think that TINI/TStik would make an excellent > reference platform > for the Outpost reference implementation and it would also be > interesting to > hang a number of muviums off of it in order to show Outpost-to-Outpost > communications and remote provisioning of the muviums via the > TINI/TStik 'hub'. > > If we decide to go with TINI/TStik as an official reference platform for > Outpost, I might be able to arrange for each developer on this > list to get a > free one. > > > 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-06 06:57:39
|
>A question on the pure dynamic configuration as it relates to muvium: Do
you
>have a dynamic instantiator alla forName()?
No I haven't implemented forName() just yet but what I don't have today, I
'can have' tommorrow especially if it moves up the priority list.
Implementing a forName() function would be quite straight forward. The
normal useage of the forName() is something like
Class.forName("BinaryOr").newInstance(); which complicates the
implementation with the Class class.
The alterative would be to override your EmbedletClassLoader.forName(String)
implementation with an assembly implementation that is highly compact and
optimised for all the classes in the implementation.
Or yes, you could implement it the way you have suggested but for core
features like this I would think I will be overriding the implementations in
most cases for optimal compactness/performance.
Same thing for planned support of serialisation. As I said.. the list is
LONG!
James Caska
http://www.muvium.com
'Java Bred for Embedded'
> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of
> Christopher Smith
> Sent: Thursday, February 06, 2003 5:24 PM
> To: emb...@li...
> Subject: RE: [Embedlets-dev] Re: [Arch] ANT
>
>
> Topic tags:[Arch][Wiring][Doc][HW][PM]
> _______________________________________________
>
>
> > Topic tags:[Arch][Wiring][Doc][HW][PM]
> > _______________________________________________
> >
> > >I do not know what muivum provides but I would be (pleasantly)
> > surprised if
> > they have remote-able flash update.
> >
> > Updates are over serial Connection UART at the minute with TCP/IP remote
> > update planned shortly. In fact we plan to support dynamic updates over
> > almost anything that can communicate with the uVM device. Also
> plan remote
> > in place debugging :-) But the wishlist is pretty long so what
> > comes when is
> > trickier!
> >
>
> Very nice! As the muvium is the likely candidate for static configuration
> due to its size contraint this will greatly increase its 'wiring'
> flexibility.
>
> A question on the pure dynamic configuration as it relates to
> muvium: Do you
> have a dynamic instantiator alla forName()? This would in effect
> be the only
> core requirement for a purely dynamic configuration scheme.
>
> If not the following would suffice and it would be interesting to see what
> the footprint would be after your cross compile. (Note name space is
> speculative and not intended to indicate any preference)
>
> /**
> *
> * Provides a limited small footprint class loader.
> * Requires a list of available classes that get instanciated on demand.
> * Uses the forName(String className) form as in the standard Java class
> loader.
> *
> * @author csmith - OopScope
> * @date 02/03/2003
> *
> */
>
> package org.embedlet.persistence;
>
> public class EmbedletClassLoader
> {
> // Class pool list
> String[] classes =
> {"BinaryOr",
> "BinaryAnd"
> };
>
>
> /**
> * Create and instance of the class passed in name
> *
> * @param name - the name of the class to instantiate
> * @return the - instance or null
> */
> public Object forName(String name)
> {
> int index;
> boolean found = false;
> Object object = null;
> for (index = 0; index<classes.length ; index++)
> {
> if (name.equals(classes[index]))
> {
> found = true;
> break;
> }
> }
>
> if (found)
> {
> switch (index)
> {
> case 0:
> // actual code:
> // object = new BinaryOr();
>
> // stub for testing
> object = new String("BinaryOr");
> break;
> case 1:
> // actual code:
> //object = new BinaryAnd();
>
> // stub for testing
> object = new String("BinaryAnd");
> break;
> }
> }
> return object;
> }
> }
> >
>
>
>
>
> -------------------------------------------------------
> 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-06 06:46:40
|
Chris stated: >I do not know what muivum provides but I would be (pleasantly) surprised if >they have remote-able flash update. In addition muvium, both TINI and the new Systronix TStik have remote update capabilities. One can use FTP to upload a new application into a TINI/TStik and since they are JDK 1.1.8 compliant they also support class loading and object serialization. TINI/TStik are more mature systems than JStamp is and I expect that JStamp will obtain these capabilities as soon as Ajile finishes their CDC implementation. I personally think that TINI/TStik would make an excellent reference platform for the Outpost reference implementation and it would also be interesting to hang a number of muviums off of it in order to show Outpost-to-Outpost communications and remote provisioning of the muviums via the TINI/TStik 'hub'. If we decide to go with TINI/TStik as an official reference platform for Outpost, I might be able to arrange for each developer on this list to get a free one. Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Christopher S. <cs...@oo...> - 2003-02-06 06:34:00
|
> Topic tags:[Arch][Wiring][Doc][HW][PM] > _______________________________________________ > > >a decent XML-based > >management vocabulary, exposed as a web service over HTTP would > give us way > >more flexibility, even to the point of providing management across serial > cable > >connections (or wireless equivalents like Bluetooth). The > possbilities are > very > >exciting and would make a very compelling "pitch". > > This was the way I very early on proposed uVM devices could > interact in this > framework and still make sense. I also think that this is something that > makes sense for the User Interface thing also, why not just use dynamicall > generated HTML as our user interface to anything rather than try to create > some other GUI standard. The objective is not to create a GUI standard, rather a data exchange standard based on XML over HTTP. XML is then easily rendered to HTML. This offloads the Embedlet container from having to render HTML which may or may not suite the end users needs. For example it may be desirable to combine the results of many Embedlet containers into one display, almost impossible if the devices are returning their own (different) HTML pages. > > 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: Thursday, February 06, 2003 1:33 AM > > To: emb...@li... > > Subject: [Embedlets-dev] [Arch] JMX Management > > > > > > Topic tags:[Arch][Wiring][Doc][HW][PM] > > _______________________________________________ > > > > Chris said (re GUIs for Control functions): > > > > > am assuming that they have none. The devices that provide the > > UI need to > > > be able to communicate directly and simply with the Embedlets. > > Envision a > > > plant operator walking up to a device with his wireless or > > wired hand-held > > > to make adjustments to the system. > > > > Makes sense. I think it is well beyond our scope to try and > > create a UI library to > > support devices that have display capability, and it would likely > > be best to just adopt > > and implement the MIDP LCDUI API if such was needed on the > > platform itself, but > > that should be a separate project from Embedlets probably. > > > > > Requiring JMX as the sole management > > > interface would, I think, put a very large infrastructure > demand on that > > > simple interaction. > > > > I think you'll be pleasantly surprised. If you compare the JMX > > standard with the > > Embedlets Architecture (as outlined in the discussion document), > > you'll find there is a > > lot of conceptual similarity (deliberate on my part ;-) between > > Embedlets and JMX). > > At a conceptual level there are a lot of parallels between the > > two architectures, with > > the mapping (conceptual, not intended to imply inheritance or > > implementation > > dependency) looking something like: > > > > Outpost/Embedlets JMX > > -------------------------- -------------------- > > Outpost Container MBean Server (and managed resource > > itself) > > Outpost Services JMX Agents/Services > > Embedlet MBean (managed resource/properties) > > Event Manager Service JMX Notifications > > Timer Service JMX Timer Agent/Service > > Monitoring Service JMX Monitoring Agent/Service > > Protocol/Transport Adapter JMX Connector/Adapter > > > > Now if you look at the JMX spec, external management is done through a > > protocol/transport adapter, which exposes the JMX > interfaces/API's at the > > management end. This means we can implement some hooks in the Outpost > > Container and Services, along with a custom Protocol/Transport > > Adapter (probably > > using Web Services, eg. SOAP/XML/HTTP) that exposes the Embedlet > > management functions outside the device. Note that we do NOT > > need to implement > > the actual JMX interfaces in the embedded container! On the > > management side > > (management console, server side JMX-aware management tool like > > Tivoli for > > instance) all we need to do is provide an adapter that can > > translate our Management > > Protocol (XML vocabulary) into the real JMX interfaces, classes > > and methods. This > > can be done because the preliminary architecture I documented > > deliberately maps > > nicely onto JMX concepts as well. > > > > So we get the best of both worlds, optional, but very lightweight > > Management Service > > on the embedded device, with an external JMX-compatible (but > > decoupled) adapter > > and tools (like your Process Control UI remote app) layer that > > translates from the > > Outpost Management protocol to JMX standard APIs (and vice versa). > > > > One of the benefits of this is anyone writing external control or > > management > > applications can use a standard API to do this, namely JMX, which > > is gaining ground > > very rapidly. If there is a standard way of doing something > > there is a lot of value to > > adopting that approach, since it widens the market and gives more > > credibility/acceptance value. Using this approach, the > > glass-house server operations > > boys could actually use Tivoli, OpenView or such to manage the > > distributed > > Embedlets! In fact, this approach would let operations staff > > (which could be the shop > > floor operator, foreman, plant manager, etc.) receive real time > > alerts if things start to > > go amiss...and get those through the corporations normal management > > infrastructure. Wow...now that's a sales/adoption feature big > > time! Management > > is/will be a big issue with thousands of Embedlets flung around a > > corporation and > > integrated to the back ends. > > > > Just like Ted, you can have your cake and eat it too, Chris! <grins> > > > > > It would also lock out other socket/XML capable > > > interfaces such as ActiveX (yes it still lives), .NET, Perl etc. > > > > With the solution that I envision (see above) with the Management > > capability > > exposed as a Web Service (SOAP/XML), it would be trivial to > > integrate into any other > > back end technology that was not JMX enabled, such as the ones > > you mention, yet > > still provide tight integration with JMX-based management > > solutions where desired, > > with minimal performance or footprint penalty. > > > > > I agree > > > that a JMX/Embedlet Adapter would defintely be a huge boost to the > > > acceptablility at the Enterprise management level. > > > > Absolutely! Even if they don't use it right away (or ever) it's > > a very, VERY big selling > > feature. Remote management of Embedlets, to the point of > > enabling integration with > > the large, common back end management systems (eg, Tivoli) would > > be a HUGE > > benefit for Embedlets. I would even say it would be more > > important than many other > > features of Outpost. Manageability is a key issue for corporate > > systems when they > > become integrated together (which is one of our key goals). > > > > > It is my assertion, however that we need and can have a simple dynamic > > > configuration, persistence and management interface without > significant > > > footprint bloat, possibly relieving the requirement for a tool-heavy > > > static build process. > > > > I agree that we need these capabilities, but there are very good > > architectural reasons > > to make them decoupled, independent (of each other) and optional Outpost > > Container services. Take Persistence for instance. It should be > > generic enough to > > store/retrieve any arbitrary data...not just config files. There > > may be good reason for > > an application to use persistance, but it may not need dynamic > > reconfig. Think > > "service-oriented" rather than "interface-oriented" (though it > > can be very convenient > > to have a Persistable interface implemented by objects that are > > candidates for > > storage). > > > > Dynamic config has already been added as an optional service to the 1.2 > > Architecture Discussion Doc. So has Persistence. Management I > > talked about > > earlier. I expect to add more detail to all three of these > > service "definitions" in the > > document (to preserve our thinking) per my comments in this > > email, in the next > > release of the document (1.3). > > > > I think that when more of the details of my (admittedly warped at > > times) thinking > > come to light, you'll see that you'll be able to handle the kind > > of applications you have > > described, without compromising the lightweight design goals of > > an Embedlet server, > > and also be able to leverage more modularity, flexibility and > > standards (eg. JMX). > > > > > A bold statement I know, but I am prepared to back it up with > some coded > > > examples. > > > > I've read some of your stuff already.....will be reviewing the > > JavaDocs in the next day > > or two regarding your implementation of some of these concepts. > > > > Gregg then clarifies: > > > > > The MBean would not necessarily have to be on the device. If we spec > > > a very simple text based admin protocol that provides 'events', > > > 'properties' and 'actions', then we can write a single MBean that can > > > run on the managers device, and talk via a serial network to the > > > device. This would facilitate remote management in places where > > > device have a network to somewhere else.... But a serial port could > > > be used for management of individual devices. > > > > Bingo! Exactly my thinking, Gregg! Larger platforms (maybe > > JStik's or PC's) might > > want to actually implement MBeans on the controller (there are > > some benefits to that > > approach, and it could be implemented as a decorator layer > > without touching the > > core embedlet container code)....but for the most part, a decent > > XML-based > > management vocabulary, exposed as a web service over HTTP would > > give us way > > more flexibility, even to the point of providing management > > across serial cable > > connections (or wireless equivalents like Bluetooth). The > > possbilities are very > > exciting and would make a very compelling "pitch". > > > > Chris then provides an example: > > > > > For example a request: > > > > > > <Request command="getProperties" identity="CB_OUTPUT_1"/> > > > > > > The response: > > > > > > <Light identity="CB_OUTPUT_1" name="Light 30212" value="On" .../> > > > > > > This can easily be handled by one of the small-footprint parsers or a > > > hand-rolled byte level parser. It is in stripped XML form so > > that an upper > > > level transport can simply enclose it into a full envelope or > > transform it > > > to established protocols. Collections, compound objects and > > reference links > > > are possible using this technique as well. > > > > Exactly right. That is what I've been thinking all along, > > however, I think your example > > is too application specific. > > > > The name of the feature/embedlet /device (Lights) would probably > > never be an > > element or attribute. Doing this ties your vocabulary to the > > specific domain > > application (light control in the this example). XML management > > syntax would have > > be more generic than that to provide a universal management > > capability across > > any/all embedlets. For instance, the request to get a property > > from a managed > > object (embedlet) would look more like: > > > > <request target="embedlet" > > type="light" > > id="30212" > > operation="getProperty" > > property="CB_OUTPUT_1" /> > > > > and the response would be more like: > > > > <response target="embedlet" > > type="light" > > id="30212" > > property="CB_OUTPUT_1" > > value="On" /> > > > > Very similar to your example, but extensible to ALL management > > functions, since the > > element tags and attributes are defined by the Embedlet Management XML > > Schema....and only the values are unique to the specific > > embedlet/application. (Don't > > get hyper about the example syntax...it's just an example to get > > the concept across, > > not a "proposal" for how the Management XML Schema should > > actually look. In fact, > > there would be value in using a SOAP-based RPC approach to the > > XML managment > > schema since it maps nicely to the remote RPC-like JMX API's > > cleanly and there are > > a lot of back end tools that let you create/consume such Web > Services RPC > > requests without having to bother with the SOAP/XML "plumbing"). > > > > For example, to control a GPS device the request might look like: > > > > <request target="embedlet" > > type="GPS" > > id="myGPS" > > operation="setProperty" > > property="GPSProtocol" > > value="NMEA"/> > > > > Same syntax, different application altogether! But this allows > > us to implement a > > generic Management Service that all Embedlets can utilize. The > > user wouldn't even > > have to know anything about the underlying XML syntax, since this > > would be > > automatically assembled and then parsed at both ends (JMX API's > > used by the > > remote GUI control app to issue the request through the JMX > > Adapter, then across > > the comm link and the to the Outpost Managment Service API used > > by the Embedlet > > to respond to the request). > > > > I know I'm splitting hairs here...but such genericity has to be > > implicit in the design of > > our protocols and XML vocabularies/schemas for the container to > > be able to provide > > useful, generic, reuseable services, so I thought it worth noting. > > > > > This becomes the foundation for building complex systems out of > > very simple > > > rules, as Andrzej has proposed. > > > > Yuppers! ;-) > > > > BTW....I'm typing this in a coffee shop while waiting to give a > > presentation on Web > > Services (the MGDP project) and ebXML to the Toronto Java Users > > Group in about > > an hour. I'll be mentioning the Outpost/Embedlets initiative at > > the presentation. It > > might engender some more victims....ooops.....I mean interest and > > volunteers. ;-) > > > > > > > > ...Andrzej > > > > Chaeron Corporation > > 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 > > > > > > > > ------------------------------------------------------- > 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: Christopher S. <cs...@oo...> - 2003-02-06 06:23:03
|
> Topic tags:[Arch][Wiring][Doc][HW][PM]
> _______________________________________________
>
> >I do not know what muivum provides but I would be (pleasantly)
> surprised if
> they have remote-able flash update.
>
> Updates are over serial Connection UART at the minute with TCP/IP remote
> update planned shortly. In fact we plan to support dynamic updates over
> almost anything that can communicate with the uVM device. Also plan remote
> in place debugging :-) But the wishlist is pretty long so what
> comes when is
> trickier!
>
Very nice! As the muvium is the likely candidate for static configuration
due to its size contraint this will greatly increase its 'wiring'
flexibility.
A question on the pure dynamic configuration as it relates to muvium: Do you
have a dynamic instantiator alla forName()? This would in effect be the only
core requirement for a purely dynamic configuration scheme.
If not the following would suffice and it would be interesting to see what
the footprint would be after your cross compile. (Note name space is
speculative and not intended to indicate any preference)
/**
*
* Provides a limited small footprint class loader.
* Requires a list of available classes that get instanciated on demand.
* Uses the forName(String className) form as in the standard Java class
loader.
*
* @author csmith - OopScope
* @date 02/03/2003
*
*/
package org.embedlet.persistence;
public class EmbedletClassLoader
{
// Class pool list
String[] classes =
{"BinaryOr",
"BinaryAnd"
};
/**
* Create and instance of the class passed in name
*
* @param name - the name of the class to instantiate
* @return the - instance or null
*/
public Object forName(String name)
{
int index;
boolean found = false;
Object object = null;
for (index = 0; index<classes.length ; index++)
{
if (name.equals(classes[index]))
{
found = true;
break;
}
}
if (found)
{
switch (index)
{
case 0:
// actual code:
// object = new BinaryOr();
// stub for testing
object = new String("BinaryOr");
break;
case 1:
// actual code:
//object = new BinaryAnd();
// stub for testing
object = new String("BinaryAnd");
break;
}
}
return object;
}
}
>
|
|
From: James C. <ca...@vi...> - 2003-02-06 05:23:52
|
>a decent XML-based >management vocabulary, exposed as a web service over HTTP would give us way >more flexibility, even to the point of providing management across serial cable >connections (or wireless equivalents like Bluetooth). The possbilities are very >exciting and would make a very compelling "pitch". This was the way I very early on proposed uVM devices could interact in this framework and still make sense. I also think that this is something that makes sense for the User Interface thing also, why not just use dynamicall generated HTML as our user interface to anything rather than try to create some other GUI standard. 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: Thursday, February 06, 2003 1:33 AM > To: emb...@li... > Subject: [Embedlets-dev] [Arch] JMX Management > > > Topic tags:[Arch][Wiring][Doc][HW][PM] > _______________________________________________ > > Chris said (re GUIs for Control functions): > > > am assuming that they have none. The devices that provide the > UI need to > > be able to communicate directly and simply with the Embedlets. > Envision a > > plant operator walking up to a device with his wireless or > wired hand-held > > to make adjustments to the system. > > Makes sense. I think it is well beyond our scope to try and > create a UI library to > support devices that have display capability, and it would likely > be best to just adopt > and implement the MIDP LCDUI API if such was needed on the > platform itself, but > that should be a separate project from Embedlets probably. > > > Requiring JMX as the sole management > > interface would, I think, put a very large infrastructure demand on that > > simple interaction. > > I think you'll be pleasantly surprised. If you compare the JMX > standard with the > Embedlets Architecture (as outlined in the discussion document), > you'll find there is a > lot of conceptual similarity (deliberate on my part ;-) between > Embedlets and JMX). > At a conceptual level there are a lot of parallels between the > two architectures, with > the mapping (conceptual, not intended to imply inheritance or > implementation > dependency) looking something like: > > Outpost/Embedlets JMX > -------------------------- -------------------- > Outpost Container MBean Server (and managed resource > itself) > Outpost Services JMX Agents/Services > Embedlet MBean (managed resource/properties) > Event Manager Service JMX Notifications > Timer Service JMX Timer Agent/Service > Monitoring Service JMX Monitoring Agent/Service > Protocol/Transport Adapter JMX Connector/Adapter > > Now if you look at the JMX spec, external management is done through a > protocol/transport adapter, which exposes the JMX interfaces/API's at the > management end. This means we can implement some hooks in the Outpost > Container and Services, along with a custom Protocol/Transport > Adapter (probably > using Web Services, eg. SOAP/XML/HTTP) that exposes the Embedlet > management functions outside the device. Note that we do NOT > need to implement > the actual JMX interfaces in the embedded container! On the > management side > (management console, server side JMX-aware management tool like > Tivoli for > instance) all we need to do is provide an adapter that can > translate our Management > Protocol (XML vocabulary) into the real JMX interfaces, classes > and methods. This > can be done because the preliminary architecture I documented > deliberately maps > nicely onto JMX concepts as well. > > So we get the best of both worlds, optional, but very lightweight > Management Service > on the embedded device, with an external JMX-compatible (but > decoupled) adapter > and tools (like your Process Control UI remote app) layer that > translates from the > Outpost Management protocol to JMX standard APIs (and vice versa). > > One of the benefits of this is anyone writing external control or > management > applications can use a standard API to do this, namely JMX, which > is gaining ground > very rapidly. If there is a standard way of doing something > there is a lot of value to > adopting that approach, since it widens the market and gives more > credibility/acceptance value. Using this approach, the > glass-house server operations > boys could actually use Tivoli, OpenView or such to manage the > distributed > Embedlets! In fact, this approach would let operations staff > (which could be the shop > floor operator, foreman, plant manager, etc.) receive real time > alerts if things start to > go amiss...and get those through the corporations normal management > infrastructure. Wow...now that's a sales/adoption feature big > time! Management > is/will be a big issue with thousands of Embedlets flung around a > corporation and > integrated to the back ends. > > Just like Ted, you can have your cake and eat it too, Chris! <grins> > > > It would also lock out other socket/XML capable > > interfaces such as ActiveX (yes it still lives), .NET, Perl etc. > > With the solution that I envision (see above) with the Management > capability > exposed as a Web Service (SOAP/XML), it would be trivial to > integrate into any other > back end technology that was not JMX enabled, such as the ones > you mention, yet > still provide tight integration with JMX-based management > solutions where desired, > with minimal performance or footprint penalty. > > > I agree > > that a JMX/Embedlet Adapter would defintely be a huge boost to the > > acceptablility at the Enterprise management level. > > Absolutely! Even if they don't use it right away (or ever) it's > a very, VERY big selling > feature. Remote management of Embedlets, to the point of > enabling integration with > the large, common back end management systems (eg, Tivoli) would > be a HUGE > benefit for Embedlets. I would even say it would be more > important than many other > features of Outpost. Manageability is a key issue for corporate > systems when they > become integrated together (which is one of our key goals). > > > It is my assertion, however that we need and can have a simple dynamic > > configuration, persistence and management interface without significant > > footprint bloat, possibly relieving the requirement for a tool-heavy > > static build process. > > I agree that we need these capabilities, but there are very good > architectural reasons > to make them decoupled, independent (of each other) and optional Outpost > Container services. Take Persistence for instance. It should be > generic enough to > store/retrieve any arbitrary data...not just config files. There > may be good reason for > an application to use persistance, but it may not need dynamic > reconfig. Think > "service-oriented" rather than "interface-oriented" (though it > can be very convenient > to have a Persistable interface implemented by objects that are > candidates for > storage). > > Dynamic config has already been added as an optional service to the 1.2 > Architecture Discussion Doc. So has Persistence. Management I > talked about > earlier. I expect to add more detail to all three of these > service "definitions" in the > document (to preserve our thinking) per my comments in this > email, in the next > release of the document (1.3). > > I think that when more of the details of my (admittedly warped at > times) thinking > come to light, you'll see that you'll be able to handle the kind > of applications you have > described, without compromising the lightweight design goals of > an Embedlet server, > and also be able to leverage more modularity, flexibility and > standards (eg. JMX). > > > A bold statement I know, but I am prepared to back it up with some coded > > examples. > > I've read some of your stuff already.....will be reviewing the > JavaDocs in the next day > or two regarding your implementation of some of these concepts. > > Gregg then clarifies: > > > The MBean would not necessarily have to be on the device. If we spec > > a very simple text based admin protocol that provides 'events', > > 'properties' and 'actions', then we can write a single MBean that can > > run on the managers device, and talk via a serial network to the > > device. This would facilitate remote management in places where > > device have a network to somewhere else.... But a serial port could > > be used for management of individual devices. > > Bingo! Exactly my thinking, Gregg! Larger platforms (maybe > JStik's or PC's) might > want to actually implement MBeans on the controller (there are > some benefits to that > approach, and it could be implemented as a decorator layer > without touching the > core embedlet container code)....but for the most part, a decent > XML-based > management vocabulary, exposed as a web service over HTTP would > give us way > more flexibility, even to the point of providing management > across serial cable > connections (or wireless equivalents like Bluetooth). The > possbilities are very > exciting and would make a very compelling "pitch". > > Chris then provides an example: > > > For example a request: > > > > <Request command="getProperties" identity="CB_OUTPUT_1"/> > > > > The response: > > > > <Light identity="CB_OUTPUT_1" name="Light 30212" value="On" .../> > > > > This can easily be handled by one of the small-footprint parsers or a > > hand-rolled byte level parser. It is in stripped XML form so > that an upper > > level transport can simply enclose it into a full envelope or > transform it > > to established protocols. Collections, compound objects and > reference links > > are possible using this technique as well. > > Exactly right. That is what I've been thinking all along, > however, I think your example > is too application specific. > > The name of the feature/embedlet /device (Lights) would probably > never be an > element or attribute. Doing this ties your vocabulary to the > specific domain > application (light control in the this example). XML management > syntax would have > be more generic than that to provide a universal management > capability across > any/all embedlets. For instance, the request to get a property > from a managed > object (embedlet) would look more like: > > <request target="embedlet" > type="light" > id="30212" > operation="getProperty" > property="CB_OUTPUT_1" /> > > and the response would be more like: > > <response target="embedlet" > type="light" > id="30212" > property="CB_OUTPUT_1" > value="On" /> > > Very similar to your example, but extensible to ALL management > functions, since the > element tags and attributes are defined by the Embedlet Management XML > Schema....and only the values are unique to the specific > embedlet/application. (Don't > get hyper about the example syntax...it's just an example to get > the concept across, > not a "proposal" for how the Management XML Schema should > actually look. In fact, > there would be value in using a SOAP-based RPC approach to the > XML managment > schema since it maps nicely to the remote RPC-like JMX API's > cleanly and there are > a lot of back end tools that let you create/consume such Web Services RPC > requests without having to bother with the SOAP/XML "plumbing"). > > For example, to control a GPS device the request might look like: > > <request target="embedlet" > type="GPS" > id="myGPS" > operation="setProperty" > property="GPSProtocol" > value="NMEA"/> > > Same syntax, different application altogether! But this allows > us to implement a > generic Management Service that all Embedlets can utilize. The > user wouldn't even > have to know anything about the underlying XML syntax, since this > would be > automatically assembled and then parsed at both ends (JMX API's > used by the > remote GUI control app to issue the request through the JMX > Adapter, then across > the comm link and the to the Outpost Managment Service API used > by the Embedlet > to respond to the request). > > I know I'm splitting hairs here...but such genericity has to be > implicit in the design of > our protocols and XML vocabularies/schemas for the container to > be able to provide > useful, generic, reuseable services, so I thought it worth noting. > > > This becomes the foundation for building complex systems out of > very simple > > rules, as Andrzej has proposed. > > Yuppers! ;-) > > BTW....I'm typing this in a coffee shop while waiting to give a > presentation on Web > Services (the MGDP project) and ebXML to the Toronto Java Users > Group in about > an hour. I'll be mentioning the Outpost/Embedlets initiative at > the presentation. It > might engender some more victims....ooops.....I mean interest and > volunteers. ;-) > > > > ...Andrzej > > Chaeron Corporation > 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: James C. <ca...@vi...> - 2003-02-06 05:21:22
|
>I do not know what muivum provides but I would be (pleasantly) surprised if they have remote-able flash update. Updates are over serial Connection UART at the minute with TCP/IP remote update planned shortly. In fact we plan to support dynamic updates over almost anything that can communicate with the uVM device. Also plan remote in place debugging :-) But the wishlist is pretty long so what comes when is trickier! James Caska http://www.muvium.com 'Java Bred for Embedded' BTW - THe uVMDK is now available for download and device samples are available immianently when I will make a more general announcment. http://www.muvium.com/uVMDK/uVMDK.htm > -----Original Message----- > From: emb...@li... > [mailto:emb...@li...]On Behalf Of > Christopher Smith > Sent: Thursday, February 06, 2003 3:53 PM > To: emb...@li... > Subject: RE: [Embedlets-dev] Re: [Arch] ANT > > > Topic tags:[Arch][Wiring][Doc][HW][PM] > _______________________________________________ > > > > > > Topic tags:[Arch][Wiring][Doc][HW][PM] > > _______________________________________________ > > > > Ted asks: > > >For example, if a change needs to be made > > to the code > > in the muivum devices, does someone walk around to 80 devices > and manually > > upgrade each one? Even if these devices were accessible > through FTP, does > > someone manually FTP the code changes into each device? What if all the > > devices need upgrading or if 3 more injection molding stations > > are added to the > > plant? With Ant, one just types 'ant [params]' in the right > > context and any > > piece or group of pieces in the embedded part of this > > application's build and > > deploy process can be executed. > > In the case of statically configured Embedlets or an Embedlet bug > fix/additions this would require the code base to be updated via whatever > means available. In the Ajile based systems it appears that a Jag physical > connection needs to be made, unless they come up with a flash > bootstrap over > TCP/IP. Other systems may rely on ROM substitution. I do not know what > muivum provides but I would be (pleasantly) surprised if they have > remote-able flash update. I do not think that Ant would be of > assistance in > overcoming these barriers. > > Dynamically configured Embedlets would have the ability to modify > settings, > rewire connections and even instantiate new Embedlets from the available > pool. Ant and other automation tools would be of great assistance in this > case. > > This highlights another advantage of dynamic configuration in > that once the > code base has been QA'ed and stabilized it would not need to be > changed and > all devices of a similar function would share the same code, greatly > increasing reliability and reducing maintenance. > > > > > ------------------------------------------------------- > 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: Christopher S. <cs...@oo...> - 2003-02-06 04:52:22
|
> > Topic tags:[Arch][Wiring][Doc][HW][PM] > _______________________________________________ > Ted asks: >For example, if a change needs to be made > to the code > in the muivum devices, does someone walk around to 80 devices and manually > upgrade each one? Even if these devices were accessible through FTP, does > someone manually FTP the code changes into each device? What if all the > devices need upgrading or if 3 more injection molding stations > are added to the > plant? With Ant, one just types 'ant [params]' in the right > context and any > piece or group of pieces in the embedded part of this > application's build and > deploy process can be executed. In the case of statically configured Embedlets or an Embedlet bug fix/additions this would require the code base to be updated via whatever means available. In the Ajile based systems it appears that a Jag physical connection needs to be made, unless they come up with a flash bootstrap over TCP/IP. Other systems may rely on ROM substitution. I do not know what muivum provides but I would be (pleasantly) surprised if they have remote-able flash update. I do not think that Ant would be of assistance in overcoming these barriers. Dynamically configured Embedlets would have the ability to modify settings, rewire connections and even instantiate new Embedlets from the available pool. Ant and other automation tools would be of great assistance in this case. This highlights another advantage of dynamic configuration in that once the code base has been QA'ed and stabilized it would not need to be changed and all devices of a similar function would share the same code, greatly increasing reliability and reducing maintenance. |
11 messages has been excluded from this view by a project administrator.
