Thread: [Embedlets-dev] Re: JAPL part of specification
Status: Alpha
Brought to you by:
tkosan
Menu
▾
▴
embedlets-developer
|
From: Andrzej J. T. <an...@ch...> - 2003-03-30 15:08:33
|
Brill asks: I thought that JAPL was going to be a separate specification, since it would/might have applicability outside of an Embedlet container? > So... what I need to understand is how Outpost would be setting and getting > attributes of a peripheral? An Embedlet would have a reference to the JAPL device and would use whatever API the JAPL device exposed to set/get any attributes the device had exposed. > > Can you give a bit more information about the idea behind these Type IDs? Embedlet Event Types are just a string, which is tokens separated by periods. Something like my.event.id. or device.id.eventtype. The first token should not be emb or outpost, and don't use *'s in the type (those are used for pattern matching), other than that, no real restrictions. > I started Piccadilly (what I'm calling the Outpost/JAPL combo) by extending > Embedlet... the methods are fairly easy to understand. You should not need to (and I feel shouldn't anyway) extend Embedlet to support JAPL devices. See below. > What I don't understand is how the embeled talks to the JAPL device. > What is looked like, extending Embedlet is that the embedlet receives events > from the system... now I assumed that I would do something different depending > on the event code. Assuming that the JAPL stuff is intended to be independent of the Embedlet container (something we talked about a long time ago), here is the way I think you should consider linking the two: 1) Create your JAPL drivers with an exposed API. The JAPL device should NOT have a reference to any Embedlets, nor be dependent on ANYTHING in the embedlet spec (eg. no imports of org.embedlet or org.outpost packages). 2) Create an Embedlet (application logic that wishes to use a JAPL device) that receives Embedlet Events that will originate from a JAPL device somehow. The Embedlet can have a reference to the JAPL device if it needs it (or it can be passed in as part of the Embedlet Event it receives) so that it can make calls against the exposed API of the JAPL device. 3) Create a "proxy" wrapper for the JAPL driver that extends org.embedlet.EventProducer and which takes JAPL events (interrupts) and then creates/sends an appropriate Embedlet Event. Note that this wrapper does NOT extend Embedlet (it doesn't have to), just EventProducer and that the JAPL driver can have a reference to the wrapper (if needed) for interrupt driver events (in which case the wrapper should implement a callback interface defined as part of the JAPL device API for such callbacks). The JAPL wrapper should NOT have a reference to any Embedlets. All this wrapper does is convert internal JAPL information into an Embedlet Event, acting as a "bridge" between the two worlds. A polling scenario doesn't need the wrapper (an Embedlet would use the Timer Service to poll the JAPL device), so let's look at an interrupt driven JAPL device. Here is what the flow would look like: 1) JAPL device gets an interrupt. 2) JAPL device does a callback into the JAPL "Proxy" Wrapper. 3) The wrapper takes the interrupt data, puts in in an Embedlet Event and sends it (note: it does not know who the consumers are going to be). 4) An Embedlet (registered as a consumer for that particular event type) receives the event and then does something with it (possibly issuing JAPL API calls against the originating device, setting/getting attributes). This approach follows best practices (per my earlier email), and is preferred for the following reasons: 1) Coupling between the Embedlet and JAPL layers is reduced (and kept uni- directional, from Embedlet to JAPL only). 2) The use of a wrapper class means JAPL code can be used without change outside of the Embedlet Container environment (a good thing). Make sense? Do I need to write an example to show you how this is intended to be implemented? Anyone else out there? Gregg? Chris? You guys got any opinions? Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-30 17:15:32
|
Ted says > It does appear that JAPL and its relationship with Embedlets needs to be > discussed more. I am sure that Andrzej will have some more thoughts on this > subject Funny you should say that. ;-) > I would also like to hear what Chris, Gregg and James have to say > about it too. Me too. Where are ya guys? You were hot to trot so I filled the CVS repository and then....silence! Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-30 17:23:42
|
Brill says: > 'm thinking that they shouldn't have *any* relationship besides one being able > to talk to the other. The idea being the separation of the two different APIs > and their respective domains... Exactly my thinking. Which leads to the need for a "mediation" layer, like the JAPL Wrapper class that I have proposed as a "best practice" programming paradigm when using both Embedlets and JAPL together. It allows for clean separation of the two layers. > what I intuitively expect, is that I can instantiate a peripheral in an > embedlet, similar to the way I might for a servlet and use that interface to > get/set attributes of the peripheral, including finding out what JAPL > interface it is talking to/with (Port, Temperature etc). Yup.....Embedlets would instantiate the JAPL stuff in their initialize() or start() lifecycle methods and keep a reference to the JAPL peripheral (if they needed to) so they could get/set attributes of the peripheral as needed. However, the JAPL peripheral would not know anything about Embedlets or even if it is running in a Container or not. Maximum reuse of JAPL code that way. > You should be also to ask the Outpost container "what to you have" and it > should be able to tell you (this is outpost implementation, not embedlet or > JAPL)... It does that already. You can get some Container level info in the current Outpost API (version, etc.). > you could then ask each embedlet what type of interface it was > controlling... however this would be implementation specific to something like > the wiring tool. Anyway, the embedlet would tell your wiring tool that it > controlled a Port... wiring already knows what a port is because you have the > API already on your system, or the properties are coded etc. It would be based on the XML Config files and maybe properties at runtime. I don't want to put much if any dynamic config information into the runtime system since that will be a strain on less capable platforms. Many Embedlet containers will be "pre-compiled" with their components to fit on smaller platforms like TINI or uVM. Don't count on having a runtime dynamic interface for wiring. Not a big deal since the wiring tool is a "build time" activity and would have access to the config information (out of the XML files) in other ways. > Also, the > Port peripheral might be able to generate events or interrupts (not on the > TINI unfortunately, but on other chips maybe) so you might tell the Port to > report any changes... it would create its own peripheral event listener, and > if it thought it should sent the embedlet event, it would then generate it > (i.e. as in temperature moving outside an alarm window, the peripheral would > get an event, but doesn't *have* to send it out to outpost)... It could also > report changes made by other application, so two remote clients get change > events from outpost when one or the other makes a change (with the added > benefit of confirming a change, if its allowed to report and event like that > back to the caller). Exactly my thinking on what the JAPL Wrapper class should do! > IMO - this is the *only* way to do it if you want to maintain the separation > (though I'm open to alternative ideas). Of course, you could also integrate > the JAPL into the embedlet api, but then you loose the JAPL and it *becomes* > the embedlet api... and I'm not willing to do that, although your welcome to > the code ;) I agree. They need to be kept decoupled. > my JAPL to Outpost implementation is "Piccadilly" (some of you > might understand the reference) and that is what I'm trying to do with it. I'm feeling dense....what is the reference to? > I think I'm just missing how the IO in the embedlet world is done... I > haven't had a lot of time lately, but am still plugging away.... IO to peripherals would be through the JAPL API's (and using JAPL Wrappers where needed for async/interrupt driven stuff). Other IO would be done through Container Services (events, logging, persistence, etc.) or through appropriate Adapters that link to the outside world. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Brill P. <bri...@ro...> - 2003-03-31 05:43:12
|
> > 'm thinking that they shouldn't have *any* relationship besides one being able > > to talk to the other. The idea being the separation of the two different APIs > > and their respective domains... > > Exactly my thinking. Which leads to the need for a "mediation" layer, like > the JAPL Wrapper class that I have proposed as a "best practice" programming > paradigm when using both Embedlets and JAPL together. It allows for clean > separation of the two layers. Yes... agreed... this is what piccadilly is sopposed to be... or at least its the first attempt, and will likley find problems in both api's ;) [...] > It would be based on the XML Config files and maybe properties at runtime. I > don't want to put much if any dynamic config information into the runtime > system since that will be a strain on less capable platforms. Many Embedlet > containers will be "pre-compiled" with their components to fit on smaller > platforms like TINI or uVM. Don't count on having a runtime dynamic > interface for wiring. Not a big deal since the wiring tool is a "build time" > activity and would have access to the config information (out of the XML > files) in other ways. Oh, I don't think you need too much in the way of "dynamic" configuration... the way I've been working it, you would have to know what drivers you where going to load... so the outpost contain could report that fairly easily to a client app. once the client knows what the container has, it can control the methods etc of the drivers... however this all implementation dependant, and every one of us could come up with an implementation. In fact, I'd go so far as to say that you don't even really need the JAPL to do this... but japl being what I've been working on, of course I'm going to try and integreate them ;) > > my JAPL to Outpost implementation is "Piccadilly" (some of you > > might understand the reference) and that is what I'm trying to do with it. > > I'm feeling dense....what is the reference to? heh... I though the americans among us wouldn't get it, but the Ausies and Canucks would! It actually a place name for an area of London (eng.). You will find people calling places Piccadilly in a lot of english literature,... also a lot of families with English roots might name places Piccadilly (my onw family does that at our cottage up on Lake Joseph, and N. Ontario). Anyway, it reffers to a place "where things come togher" a cross-roads etc. I thought it apt because I'm trying to bring Outpost and JAPL together ;) > > I think I'm just missing how the IO in the embedlet world is done... I > > haven't had a lot of time lately, but am still plugging away.... > > IO to peripherals would be through the JAPL API's (and using JAPL Wrappers > where needed for async/interrupt driven stuff). Other IO would be done > through Container Services (events, logging, persistence, etc.) or through > appropriate Adapters that link to the outside world. I think my answer to all this is the wrappers... I'll take a look and see what I can come up with... though I might not get to it again until next weekend, and my week days tend to end late. - Brill Pappin |
|
From: James C. <ca...@vi...> - 2003-03-30 16:17:40
|
>I thought that JAPL was going to be a separate specification, since it >would/might have applicability outside of an Embedlet container? With my recommendation, the APT PeripheralFactory upon which everything sits is provided by the Embedlet Container implementation but it can also be provided elsewhere - for example the UVMRunnable provides it already. Which means the JAPL library can be used outside of the Embedlet container also. James Caska www.muvium.com uVM - 'Java Bred for Embedded' -----Original Message----- From: emb...@li... [mailto:emb...@li...] On Behalf Of Andrzej Jan Taramina Sent: Monday, 31 March 2003 1:07 AM To: emb...@li... Subject: [Embedlets-dev] Re: JAPL part of specification Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] _______________________________________________ Brill asks: I thought that JAPL was going to be a separate specification, since it would/might have applicability outside of an Embedlet container? > So... what I need to understand is how Outpost would be setting and > getting attributes of a peripheral? An Embedlet would have a reference to the JAPL device and would use whatever API the JAPL device exposed to set/get any attributes the device had exposed. > > Can you give a bit more information about the idea behind these Type > > IDs? Embedlet Event Types are just a string, which is tokens separated by periods. Something like my.event.id. or device.id.eventtype. The first token should not be emb or outpost, and don't use *'s in the type (those are used for pattern matching), other than that, no real restrictions. > I started Piccadilly (what I'm calling the Outpost/JAPL combo) by > extending Embedlet... the methods are fairly easy to understand. You should not need to (and I feel shouldn't anyway) extend Embedlet to support JAPL devices. See below. > What I don't understand is how the embeled talks to the JAPL device. > What is looked like, extending Embedlet is that the embedlet receives > events from the system... now I assumed that I would do something > different depending on the event code. Assuming that the JAPL stuff is intended to be independent of the Embedlet container (something we talked about a long time ago), here is the way I think you should consider linking the two: 1) Create your JAPL drivers with an exposed API. The JAPL device should NOT have a reference to any Embedlets, nor be dependent on ANYTHING in the embedlet spec (eg. no imports of org.embedlet or org.outpost packages). 2) Create an Embedlet (application logic that wishes to use a JAPL device) that receives Embedlet Events that will originate from a JAPL device somehow. The Embedlet can have a reference to the JAPL device if it needs it (or it can be passed in as part of the Embedlet Event it receives) so that it can make calls against the exposed API of the JAPL device. 3) Create a "proxy" wrapper for the JAPL driver that extends org.embedlet.EventProducer and which takes JAPL events (interrupts) and then creates/sends an appropriate Embedlet Event. Note that this wrapper does NOT extend Embedlet (it doesn't have to), just EventProducer and that the JAPL driver can have a reference to the wrapper (if needed) for interrupt driver events (in which case the wrapper should implement a callback interface defined as part of the JAPL device API for such callbacks). The JAPL wrapper should NOT have a reference to any Embedlets. All this wrapper does is convert internal JAPL information into an Embedlet Event, acting as a "bridge" between the two worlds. A polling scenario doesn't need the wrapper (an Embedlet would use the Timer Service to poll the JAPL device), so let's look at an interrupt driven JAPL device. Here is what the flow would look like: 1) JAPL device gets an interrupt. 2) JAPL device does a callback into the JAPL "Proxy" Wrapper. 3) The wrapper takes the interrupt data, puts in in an Embedlet Event and sends it (note: it does not know who the consumers are going to be). 4) An Embedlet (registered as a consumer for that particular event type) receives the event and then does something with it (possibly issuing JAPL API calls against the originating device, setting/getting attributes). This approach follows best practices (per my earlier email), and is preferred for the following reasons: 1) Coupling between the Embedlet and JAPL layers is reduced (and kept uni- directional, from Embedlet to JAPL only). 2) The use of a wrapper class means JAPL code can be used without change outside of the Embedlet Container environment (a good thing). Make sense? Do I need to write an example to show you how this is intended to be implemented? Anyone else out there? Gregg? Chris? You guys got any opinions? Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com ------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: Brill P. <bri...@ro...> - 2003-03-31 05:10:51
|
> I thought that JAPL was going to be a separate specification, since it > would/might have applicability outside of an Embedlet container? So did I; I still do ;) > > So... what I need to understand is how Outpost would be setting and getting > > attributes of a peripheral? > > An Embedlet would have a reference to the JAPL device and would use whatever > API the JAPL device exposed to set/get any attributes the device had exposed. Thats exactly what I though should happen, but when I went to take a look at the Embedlet to extend it, there didn't seem to be any way for IO to happen. [...] > > What I don't understand is how the embeled talks to the JAPL device. > > What is looked like, extending Embedlet is that the embedlet receives events > > from the system... now I assumed that I would do something different depending > > on the event code. > > Assuming that the JAPL stuff is intended to be independent of the Embedlet > container (something we talked about a long time ago), here is the way I > think you should consider linking the two: > > 1) Create your JAPL drivers with an exposed API. The JAPL device should NOT > have a reference to any Embedlets, nor be dependent on ANYTHING in the > embedlet spec (eg. no imports of org.embedlet or org.outpost packages). Ok, good so far... done. [...] > 1) JAPL device gets an interrupt. > 2) JAPL device does a callback into the JAPL "Proxy" Wrapper. > 3) The wrapper takes the interrupt data, puts in in an Embedlet Event and > sends it (note: it does not know who the consumers are going to be). > 4) An Embedlet (registered as a consumer for that particular event type) > receives the event and then does something with it (possibly issuing JAPL API > calls against the originating device, setting/getting attributes). [...] Ok, so the IO does happen with events... How does the external caller request data from JAPL device? I assume that in that case the external "listener" would just have a proxy "event generator" that sent events out into the system... and the "JAPL control embedlet" would be registered as a listener? > Make sense? Do I need to write an example to show you how this is intended > to be implemented? Well, I'll eventually figure it out anyway (key factor is my time is taken with money making at the moment) ;) but I don't think a very simple example could go wrong especially as outside parties begin to take interest. Anyway, I've been using our Outhouse impl for the moment. - Brill Pappin |
Thanks for helping keep SourceForge clean.
X