embedlets-developer Mailing List for Outpost Embedlet Container (Page 9)
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-07-21 21:04:20
Attachments:
RS232 MultiDrop.svg
|
Hi Ted, All The RS232-MultiDrop design is very straight forward. All you need is a single Maxim device to handle the communications between the PC and the first element of the chain for the voltage conversion and from there on it looks quite similar to an I2C or 1-wire pullup configuration. I have created a partial diagram from virtual breadboard in the Scalar Vector Graphics output (SVG) If you haven't already got a viewer for SVG you need to install one http://www.adobe.com/svg/viewer/install/main.html To note: 1) The PIC is just a placeholder to show the connection to TX/RX you have to change the actual pins according to the actual PIC used obviously 2) The RX/TX top right connect to the MAXIM device or other RS232 level shifting device. The idea is very simple, We are using a pulldown diode to prevent the discrete PIC's from driving each others outputs to the wrong levels. This works because the master will transmit and all will listen but only one device will respond to any one request (it has a matching IP address) so there is no collision in the return TX all we need to do is to prevent each device from effecting the output driver of the other devices which we do with the diode. I haven't build one yet.. But when I do I will publish more complete schematics but if you want to get started early this is what I am thinking. James Caska www.muvium.com uVM - 'Java Bred for Embedded' -----Original Message----- From: emb...@li... [mailto:emb...@li...] On Behalf Of Ted Kosan Sent: Thursday, 17 July 2003 7:27 AM To: emb...@li... Subject: [Embedlets-dev] Light Blinker update and uVM serial multidrop network Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] _______________________________________________ I submitted the Global Light Blinker proposal to the JXTA community and the feedback that I received on the idea was all +1s so I have been moving ahead with developing the software. The next step in the process is to submit the project idea for formal approval and I will do this as soon as I have a working demonstration. The demonstration application is currently 90% functional and the main thing that is preventing 100% functionality is a method in the JXTA core libraries that has not been implemented yet. I have been using the JXTA lists in order to resolve this issue as soon as possible. In the meantime, I am now ready to start working on the reference implementation hardware design. James, Do you happen to have a diagram of your RS232 serial line multidrop design? My initial plan was to go with 1-Wire for the reference hardware but I am very reluctant to deal with Dallas Semiconductor directly to obtain serial-to-1Wire converters (DS9097Us) and it looks like we are about 3 months away from having a second source for an equivalent serial-to-1Wire board. uVMs using your RS232 multidrop idea seem to be an excellent non-1Wire based solution to the problem and so I would like to proceed with this strategy Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: Christopher S. <cs...@oo...> - 2003-07-21 18:35:35
Attachments:
Counter.java
CounterContext.java
|
Andrzej, The approach that I have taken is an attempt to accomplish three objectives: 1. A reduced embedlet footprint for the low end uVm type processors. 2. A flexible context/persistence structure. The idea is to remove context awareness from the Embedlets and apply an adapter pattern to the components in order to integrate with the context infrastructure. In this design the Embedlet is created with the lifecycle methods and standard bean patterns to expose the properties. The Embedlet is decoupled form the specifics of the container environment unless it is required for the task at hand eg. external communication or logging. A system could be built without the complexities of the context environment by 'hard-wiring' the components in an initialization method of the container, thus allowing 'Level I' containers to provide streamlined Embedlet systems. The 'Level II' Containers would provide initialization context by matching the 'Level I' Embedlets with a context adpater. The type and level of service provided by the adapter would be defined by the vendor and may include local flash based initialization, remote configuration or full persistence. This will allow the same Embedlet code to scale to the container environment. Here is an example of a component and it's context/persistence adapter as well as the xml snippet for initialization. <Component identity="COUNTER_001" class="org.outpost.components.digital.CounterContext" emb.description="Watch Dog Counter" initialValue="0" threshold=10000 thresholdAction=0> <producer href="TOGGLE_01"/> </Component> I am testing a three component Embedlet system with this approach. The system is made up of a timer, a binary toggle and a counter, wired together with the synchronous event model. Chris > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > ...my gig at The Hartford is winding down, and so....in my best > Arnold voice: > > I'LL BE BACK! > > I'm playing a bit of catchup on the lists for the last couple of > months and > will be posting some thoughts/ideas on things like Container > Architecture, > JXTA/JINI, PicoContainer, some derogatory comments about Java > chips in the > latest Embedded Systems rag and more... > > Hope to get back to slinging some more Embedlets code shortly, > before I get > trapped into another heads down gig. Chris...maybe I can help > you get past > the Persistence integration and other design issues.... > > Stay tuned. (That's a threat...not a promise <grins>). > > Andrzej Jan Taramina > Chaeron Corporation: Enterprise System Solutions > http://www.chaeron.com > > > > ------------------------------------------------------- > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Ted K. <tk...@ya...> - 2003-07-19 02:54:53
|
James wrote: > Well.. Here I am at PICMASTERS and might I say it has been a very very > VERY interesting conference for me. > > I won't say much more just yet but for those who have been following the > development of the thinking behind my business model.. Well it's looking > good with microchip at this (early) stage ;-) [...] Well this and other > technology I introduced them to has left some people from microchip > 'breathless'...Lots' more to come on this.[snip] This is absolutely spectacular news James! I was wondering what MicroChip's reaction was going to be to what you are doing with uVM but it looks like they are finally interested in moving forward with these new technologies. I am looking forward to hearing more! > I produced on the SLIP/JAPL > infrastructure is actually the same sort of thing as the .NET > infrastructure.. I am very keen though to demonstrated platform > independence of the HOST though and have already started on this... So > the answer is yes. Will happen sooner than later. This is funny because I stumbled across some interesting information while researching the most efficient way to implement your SLIP based RS232 multidrop idea in a cross-platform way. During the past few days I have been looking very closely at RXTX (which is an open-source version of the javax.comm communications API, http://www.rxtx.org/) and guess what? They have already started putting in support for things like I2C and RS485. It seems to me that this would be a good code base to start with in order to build cross-platform SLIP capabilities on top of. Anyway, we can talk more about this when you get back. Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
|
From: James C. <ca...@vi...> - 2003-07-18 18:31:40
|
Feels like the gang is getting some clean air again :-) James Caska www.muvium.com uVM - 'Java Bred for Embedded' -----Original Message----- From: emb...@li... [mailto:emb...@li...] On Behalf Of Ted Kosan Sent: Thursday, 17 July 2003 6:36 PM To: emb...@li... Subject: Re: [Embedlets-dev] Fair warning.... Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] _______________________________________________ Andrzej wrote: > I'LL BE BACK! Geez Andrzej, when I read your "Fair Warning" subject line I thought perhaps you were going to give us some bad news! Anyway, it is going to be very good to have you back. Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: James C. <ca...@vi...> - 2003-07-18 18:17:57
|
Hi! Well.. Here I am at PICMASTERS and might I say it has been a very very VERY interesting conference for me. I won't say much more just yet but for those who have been following the development of the thinking behind my business model.. Well it's looking good with microchip at this (early) stage ;-) RS232 Multi-drop for uVM.. Great news on this front also.. I demo'd WebServices here at PICMASTERS for microchip where I showed Remote Mothod Invocation (RMI) from a .NET Visual Studio C# application to uVM devices over SLIP and discussed the advantages of the serial multi-drop concept over slip and the advantages of serial slip from a ethernet/ppp hub. Well this and other technology I introduced them to has left some people from microchip 'breathless'.. Lots' more to come on this. So yes.. I am on it on a priority basis anyhow because it looks like I am doing a full presentation and workshop with microchip in the coming weeks and demonstrating this 'daisy chaining' webservice connected uVM devices is high on the list. The one piece of work to get it running on the JSTamp though is I need to reproduce the '.NET remoting infrastructure' ie that diagram I produced on the SLIP/JAPL infrastructure is actually the same sort of thing as the .NET infrastructure.. I am very keen though to demonstrated platform independence of the HOST though and have already started on this... So the answer is yes. Will happen sooner than later. So much to say..! Stay tuned.. James Caska www.muvium.com uVM - 'Java Bred for Embedded' P.S Thanks for the comments on the Technology Evaluation Guide.. It was quite an effort to put all those concepts into a digestable form. -----Original Message----- From: emb...@li... [mailto:emb...@li...] On Behalf Of Ted Kosan Sent: Thursday, 17 July 2003 7:27 AM To: emb...@li... Subject: [Embedlets-dev] Light Blinker update and uVM serial multidrop network Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] _______________________________________________ I submitted the Global Light Blinker proposal to the JXTA community and the feedback that I received on the idea was all +1s so I have been moving ahead with developing the software. The next step in the process is to submit the project idea for formal approval and I will do this as soon as I have a working demonstration. The demonstration application is currently 90% functional and the main thing that is preventing 100% functionality is a method in the JXTA core libraries that has not been implemented yet. I have been using the JXTA lists in order to resolve this issue as soon as possible. In the meantime, I am now ready to start working on the reference implementation hardware design. James, Do you happen to have a diagram of your RS232 serial line multidrop design? My initial plan was to go with 1-Wire for the reference hardware but I am very reluctant to deal with Dallas Semiconductor directly to obtain serial-to-1Wire converters (DS9097Us) and it looks like we are about 3 months away from having a second source for an equivalent serial-to-1Wire board. uVMs using your RS232 multidrop idea seem to be an excellent non-1Wire based solution to the problem and so I would like to proceed with this strategy Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: Andrzej J. T. <an...@ch...> - 2003-07-18 13:07:01
|
Ted sed: > Geez Andrzej, when I read your "Fair Warning" subject line I thought perhaps > you were going to give us some bad news! Hey...some folks might consider it such. ;-) > Anyway, it is going to be very good to have you back. Yup...I've felt bad not being able to devote any time to the Embedlets project recently due to other commitments. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Ted K. <tk...@ya...> - 2003-07-17 16:35:50
|
Andrzej wrote: > I'LL BE BACK! Geez Andrzej, when I read your "Fair Warning" subject line I thought perhaps you were going to give us some bad news! Anyway, it is going to be very good to have you back. Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-07-17 14:41:06
|
...my gig at The Hartford is winding down, and so....in my best Arnold voice: I'LL BE BACK! I'm playing a bit of catchup on the lists for the last couple of months and will be posting some thoughts/ideas on things like Container Architecture, JXTA/JINI, PicoContainer, some derogatory comments about Java chips in the latest Embedded Systems rag and more... Hope to get back to slinging some more Embedlets code shortly, before I get trapped into another heads down gig. Chris...maybe I can help you get past the Persistence integration and other design issues.... Stay tuned. (That's a threat...not a promise <grins>). Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-07-17 13:56:09
|
Bruce > You can now pre-order (shipments are *scheduled* to > start 18 July) TStik (TINI400) and a TILT400.Pro socket board, which has an > Embedlet connector. What's the cost of this kit? Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Ted K. <tk...@ya...> - 2003-07-17 05:27:13
|
I submitted the Global Light Blinker proposal to the JXTA community and the feedback that I received on the idea was all +1s so I have been moving ahead with developing the software. The next step in the process is to submit the project idea for formal approval and I will do this as soon as I have a working demonstration. The demonstration application is currently 90% functional and the main thing that is preventing 100% functionality is a method in the JXTA core libraries that has not been implemented yet. I have been using the JXTA lists in order to resolve this issue as soon as possible. In the meantime, I am now ready to start working on the reference implementation hardware design. James, Do you happen to have a diagram of your RS232 serial line multidrop design? My initial plan was to go with 1-Wire for the reference hardware but I am very reluctant to deal with Dallas Semiconductor directly to obtain serial-to-1Wire converters (DS9097Us) and it looks like we are about 3 months away from having a second source for an equivalent serial-to-1Wire board. uVMs using your RS232 multidrop idea seem to be an excellent non-1Wire based solution to the problem and so I would like to proceed with this strategy Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
|
From: Kelly S. <be...@ea...> - 2003-07-09 11:54:46
|
All - I know that some of you are involved in home automation applications for TINI/1-Wire, and I thought I would share this... Applications: detect indoor lighting conditions, and the determination can be made by the user to turn these lights on or off, based on the return status of LightSensor. Also, this can be used for a sunrise/sunset sensor. David MacMahon- Yes, you can also use this also for your next release of TiniHttpServer. 8-) Ted Kosan - This might fit in well for your Global Light Blinker... Best regards, Kelly Smith P.S. - Cut'n'paste from here... /** * Title: House Monitor<p> * Description: TINI project to monitor door, window, door-bell * sensors via 1-wire network.<p> * LightSensor using a DS2406 (Sensor 12)<p> * Copyright: Copyright (c) Bob Hinton and Kelly Smith<p> * Company: RH Associates<p> * @author Bob Hinton and Kelly Smith * @version 1.0 * * Created a new class to sense lighting conditions. Returns "light is ON" or "light is OFF" * * LightSensor uses a standalone garden/path lighting from Home Depot - $8.97 for a one * lamp, and includes two "AA" NiCad batteries for charging via a solar cell during the * daytime for each LED "Lamp Post". Brand: Hampton Bay, Model #: 79689. * * Ref: http://www.homedepot.com/prel80/HDUS/EN_US/diy_main/pg_diy.jsp?CNTTYPE=PROD_ META&CNTKEY=Products_2%2fLighting+%26+Fans&BV_SessionID=@@@@1253899723.10577 49258@@@@&BV_EngineID=ccdcadcikkhddkjcgelceffdfgidgjm.0&MID=9876 * * I "dead-bugged" a DS2406 TO-92, across the visible yellow LED (LED cathode to ground and * DS2406) pin-1, with LED anode and DS2406 pin-3 is PIO-A; DS2406 Data pin-2 is 1-Wire). * The solar cell is sufficiently sensitive that it can detect indoor lighting conditions, * and the determination can be made by the user to turn these lights on or off, based on * the return status of LightSensor. Also, this can be used for a sunrise/sunset sensor. */ package housemonitor; import com.dalsemi.onewire.adapter.*; public class LightSensor extends Sensor12 { static final int UNKNOWN_STATE = 0; static final int OPEN_STATE = 1; static final int CLOSED_STATE = 2; private int old_state = UNKNOWN_STATE; private int current_state = UNKNOWN_STATE; // If there is a long distance from the DS2406 to the sensor // then we can get spurious activity events. So include the // facility to ignore any where the state doesn't change private boolean ignore_spurious_alarms = false;; public LightSensor(DSPortAdapter adapter, String address,String description) { super(adapter,address,description); } public LightSensor() { super(); } public String getDescription() { return super.description + " light"; } public void configure_device() throws Exception // Specific configuration for this type of device { EnableActivityAlarm(true); setIgnoreSpuriousAlarms(true); } public String getStateAsString() { try { clearActivityAndRead(); // re-read in case of spurious alarms } catch(Exception e) { return " Exception - " + e.getMessage(); } if(alarm_valid()) return(IsOpen() ? " is ON" : " is OFF"); return null; } public boolean IsOpen() // if current_state is valid - indicating a previous call to // alarm_valid - then return that, else return the value read // from the device { int output; if(current_state != UNKNOWN_STATE) output = (current_state == OPEN_STATE ? CHAN_TRUE : CHAN_FALSE); else output = (getLevel() ? CHAN_TRUE : CHAN_FALSE); setOutputState(output); return output == CHAN_TRUE ? true : false; } public boolean alarm_valid() { if(ignore_spurious_alarms) { current_state = getLevel() ? OPEN_STATE : CLOSED_STATE; if(current_state != old_state) return true; else return false; } return true; } public void clearActivityAndRead() throws com.dalsemi.onewire.OneWireException { super.clearActivityAndRead(); if(ignore_spurious_alarms) { old_state = current_state; current_state = UNKNOWN_STATE; } } public void setIgnoreSpuriousAlarms(boolean value) { ignore_spurious_alarms = value; } public void enableAlarm(boolean enable) throws com.dalsemi.onewire.OneWireException { EnableActivityAlarm(enable); } public boolean readIfThis(long address_long) throws com.dalsemi.onewire.OneWireException { return super.readIfThis(address_long); } } |
|
From: Ted K. <tk...@ya...> - 2003-07-09 05:24:47
|
Bruce, > which show P4, the embedlet connector, a simple and > easy-to-find-at-any-electronics-store 5x2 shrouded ribbon cable header with: > > I2C > 1Wire > SPI MOSI, MISO, SCK and SCS0 > Vraw, 5V and GND > > all these signals, and more, are also available on the JSimm expansion > slot. TILT400.Pro includes one JSimm.proto board, so warm up your soldering > iron! I think that this is going to make it *so* much easier to create the class of snap together I/O modules that we have been discussing. Dallas Semiconductor's 1-Wire API for their 1-Wire network was a nice step in this direction but hopefully now we can have both speed and plugability. > We are not "publicly" announcing this until they are actually in stock. We > want to give selected groups such as Embedlets users the first crack at > these. (The next production run is already planned for mid-August, and we > plan monthly builds from here on out.) Ok, at what point will you be able to take Purchase Orders instead of credit cards? I am in the process of putting together a Systronix order but my University only issues POs. > We're also open to producing some kit for the embedlet connector, such as a > small PCB or white push-in proto board, with the embedlet connector on it, > and the mating cable to TILT400. This would let you quickly experiment with > I2C, SPI, and/or 1Wire devices. Comments? Ideas? I will need to think about this further before I can provide useful feedback. Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
|
From: Christopher S. <cs...@oo...> - 2003-07-08 17:41:49
|
Bruce, That's great! Are you going to publish the spec on the Embedlet site? (embedlet/doc) That would go a long way to focus efforts on a standard pinout. The importance of hardware standardization cannot be overemphasized. Scalability can be limited as much by the hardware decisions as the software limitations. We can develop a JAPL package to support the connector and a hook it up to the Blinker demo application that I am putting together. The demo is very simple: A Timer, Toggle and DigitalOutput, but it demonstrates all of the core containment, initialization and wiring functionality. Chris > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Please forgive the somewhat commercial and self-promoting nature of this > message, but we wanted to let you know about the first > embedlet-supporting > commercial hardware. You can now pre-order (shipments are *scheduled* to > start 18 July) TStik (TINI400) and a TILT400.Pro socket board, > which has an > Embedlet connector. > > Here is the TStik.72.nb data page: > http://www.systronix.com/tinistik/tstik72nb_data.html > > And TILT400 schematics: > http://www.systronix.com/tinistik/schematics.html > which show P4, the embedlet connector, a simple and > easy-to-find-at-any-electronics-store 5x2 shrouded ribbon cable > header with: > > I2C > 1Wire > SPI MOSI, MISO, SCK and SCS0 > Vraw, 5V and GND > > all these signals, and more, are also available on the JSimm expansion > slot. TILT400.Pro includes one JSimm.proto board, so warm up your > soldering > iron! > > photos: > http://www.systronix.com/tinistik/photos.html > but note that, since this is an earlier prototype, the Embedlet connector > is *not* shown. It will be present on all the TILT400.Pro boards > which are > currently being built. > > We expect the first small production run of boards to sell out quickly. > > We are not "publicly" announcing this until they are actually in > stock. We > want to give selected groups such as Embedlets users the first crack at > these. (The next production run is already planned for mid-August, and we > plan monthly builds from here on out.) > > As a small bonus, you can request (in one of the order comments boxes) > *two* free additional JSimm.proto boards (normally $8 each) just by > mentioning that you are an Embedlet developer. > > We're also open to producing some kit for the embedlet connector, > such as a > small PCB or white push-in proto board, with the embedlet > connector on it, > and the mating cable to TILT400. This would let you quickly > experiment with > I2C, SPI, and/or 1Wire devices. Comments? Ideas? > > BTW all these systems are being built in an ISO9002 facility. These are > industrial-quality systems, suitable for OEM volume use. > > Thanks > > Bruce Boyes > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Parasoft > Error proof Web apps, automate testing & more. > Download & eval WebKing and get a free book. > www.parasoft.com/bulletproofapps > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Bruce B. <bb...@sy...> - 2003-07-08 16:21:09
|
Please forgive the somewhat commercial and self-promoting nature of this message, but we wanted to let you know about the first embedlet-supporting commercial hardware. You can now pre-order (shipments are *scheduled* to start 18 July) TStik (TINI400) and a TILT400.Pro socket board, which has an Embedlet connector. Here is the TStik.72.nb data page: http://www.systronix.com/tinistik/tstik72nb_data.html And TILT400 schematics: http://www.systronix.com/tinistik/schematics.html which show P4, the embedlet connector, a simple and easy-to-find-at-any-electronics-store 5x2 shrouded ribbon cable header with: I2C 1Wire SPI MOSI, MISO, SCK and SCS0 Vraw, 5V and GND all these signals, and more, are also available on the JSimm expansion slot. TILT400.Pro includes one JSimm.proto board, so warm up your soldering iron! photos: http://www.systronix.com/tinistik/photos.html but note that, since this is an earlier prototype, the Embedlet connector is *not* shown. It will be present on all the TILT400.Pro boards which are currently being built. We expect the first small production run of boards to sell out quickly. We are not "publicly" announcing this until they are actually in stock. We want to give selected groups such as Embedlets users the first crack at these. (The next production run is already planned for mid-August, and we plan monthly builds from here on out.) As a small bonus, you can request (in one of the order comments boxes) *two* free additional JSimm.proto boards (normally $8 each) just by mentioning that you are an Embedlet developer. We're also open to producing some kit for the embedlet connector, such as a small PCB or white push-in proto board, with the embedlet connector on it, and the mating cable to TILT400. This would let you quickly experiment with I2C, SPI, and/or 1Wire devices. Comments? Ideas? BTW all these systems are being built in an ISO9002 facility. These are industrial-quality systems, suitable for OEM volume use. Thanks Bruce Boyes |
|
From: Ted K. <tk...@ya...> - 2003-07-07 18:42:40
|
Gregg wrote: > Okay, I'd like to suggest that you go look at the escadanet.org website. Hey, great suggestion! After educating myself a bit more about what SCADA is (http://members.iinet.net.au/~ianw/primer.html for those who are interested) I looked through the escatanet site and I liked what I saw. I especially liked the philosophy that was presented there because it seemed to be the result of very clear thinking. > I can certainly take up the task of talking up this project on the Jini > community lists that I am on. I would guess that there are perhaps a handful > of people interested and able to contribute. The Sun engineers might > actually be the most interested, as they seem to be looking for a good public > example of the v2.0 code. Well, it looks like you would definitely be in the best position of any of us to act as the main Embedlets/JINI liaison for an effort like this. At the very least I think that it would be great if we could provide the JINI community with Embedded Java devices that they could experiment with. However, having them actually participate in the Global Light Blinker project would certainly provide them with a very visible and understandable demonstration that they can show to people. Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
|
From: Gregg G. W. <gr...@sk...> - 2003-07-07 17:55:03
|
>My primary driving goal is to find a large market for Embedded Java. At this >point, whatever strategy for accomplishing this goal proves to me most >effective is where I would like to spend most of my efforts. Okay, I'd like to suggest that you go look at the escadanet.org website. This is a non-profit organization with several different partners that our company started. We are trying to provide a large, visible place for the old SCADA crowd to find out about new technologies. We are a Java shop, and as I have shared in the past, we have an interest in promoting the use of Java both through this organization, and through partnerships with others using Java in the SCADA arena. >But anyway, I am fairly sure that the Global Light Blinker project is feasible >even using the imperfect technologies that we currently possess. Are you >interested in approaching the JINI community and seeing if they would like to >participate in it? I can certainly take up the task of talking up this project on the Jini community lists that I am on. I would guess that there are perhaps a handful of people interested and able to contribute. The Sun engineers might actually be the most interested, as they seem to be looking for a good public example of the v2.0 code. ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Ted K. <tk...@ya...> - 2003-07-07 07:29:55
|
The Light Blinker test application that I have been developing is close to being completed. I did, however, run into a deprecated class and I made the decision to try to use the undocumented replacement class which has put me a bit behind on the late Sunday evening schedule that I had guessed at. I have, however, done enough testing to be very confident that the idea is going to work. After reading the JXTA project proposal guidelines I have discovered that it is a 2 step process. Step 1 is simply submitting the project proposal idea to the main JXTA list for discussion. If the discussion is favorable then the project can be officially submitted for approval or rejection as step 2. Since this is the case, I would like to submit the following proposal to the main JXTA list for comments early in the week. If you have comments or suggestions on the proposal please post them to our list. Ted <proposal> Proposed Project: Global Light Blinker project Hello, My name is Ted Kosan and I am the project administrator for the Embedlets Embedded Java group (http://embedlets.org). Most of our group's members have been involved with Embedded Java since at least 1999 and our main area of expertise is monitoring and controlling things in the physical world using Embedded Java devices like the following: http://embedlets.org/target_systems.html For nearly the past year now, the Embedlets group has been working on a Java based embedded software component technology (called Embedlets) along with a container to run them in (think Servlet container for embedded software components). We have recently completed an alpha level version of the Embedlets software and we have been looking for some real-world applications to start applying it to. At JavaOne a few weeks ago some of our Embedlet group members attended most of the JXTA related sessions and BOFs and they also had some interesting discussions with a few project JXTA members. From this experience we learned that the newly released JXTA 2.0 offers network-related capabilities that our group has been looking forward to levering and this lead to the conception of the Global Light Blinker project idea. GLOBAL LIGHT BLINKER PROJECT DESCRIPTION The purpose of the Global Light Blinker project is to create a world-wide JXTA GlobalLightBlinker PeerGroup which will allow people to experiment with remotely controlling embedded devices through the internet. The project will have both a software component and a hardware component and we envision that the initial hardware platform will look similar to the following: http://tkosan.javadevices.org/misc/embeddedjava/blinker_hardware2.jpg As this diagram shows, a typical GlobalLightBlinker's edge peer will consist of a Windows, Linux or Macintosh PC interfaced to an appliance controller box through a serial port. The controller box will be plugged into whatever type of wall power socket is present in the area of the world where the edge peer is located and it will be capable of controlling up to 2 small appliances. The controller box will also be capable of reading temperatures and the status of an input switch (which could be used to monitor things the state of a door, a motion sensor, etc.). For simplicity's sake the initial version of the project will use an Embedlet Container hosted on a PC in order to perform the control and monitoring functions but the Embedlets group also has the capability of implementing Embedlet Containers on stand-alone Embedded Java systems which can use JXME in order to communicate with the PC based edge peer using ethernet or other network technologies. JXTA PROJECT CATEGORY For a number of years now, the vision of a world where billions of embedded systems are connected to the internet has been discussed and eagerly awaited. So far, however, the Computer Science oriented software community and the Embedded Systems community have been unable to integrate these diverse fields to the point needed to make this vision a reality. It is the opinion of the Embedlets Group that the time to begin this necessary integration has now arrived and it is our hope that a joint JXTA/Embedlets Global Light Blinker project can be an initial step in this process. We would like the project to serve as a demonstration of the wonderful opportunities that the bringing together of Embedded Systems and advanced network technologies provides in a way that even non-technical people can easily understand an participate in. We therefore think that the project fits best in the JXTA DEMOS category. Respectfully, Ted Kosan, on behalf of the Embedlets Group. http://embedlets.org </proposal> __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
|
From: Ted K. <tk...@ya...> - 2003-07-07 04:44:15
|
Gregg wrote: > In JXTA there is no code mobility. You have to implement these policies > everywhere, or have a central server that implements some of these policies > (local caching always has to be implemented locally), and then the > applications have to know which version of the service to use to get the > special services, and if the interface to those services changes, your > specialized service breaks. My understanding of JXTA is that one can move code/services around too. The code is called 'Modules' in JXTA and a peer can join a PeerGroup, find out that it does not have the needed Module implementation in order to participate in the group, it can obtain the needed Module, install it and then it can provide the needed service. The Modules are tightly versioned to accommodate changes too. > Well, I would return your question with a some counter questions. What do you > want to enable the most with JAPL and Embedlets? Do you want to enable all > the devices to talk to each other? Do you want to make it possible for > non-java environments to participate at all levels and on all fronts? My primary driving goal is to find a large market for Embedded Java. At this point, whatever strategy for accomplishing this goal proves to me most effective is where I would like to spend most of my efforts. But anyway, I am fairly sure that the Global Light Blinker project is feasible even using the imperfect technologies that we currently possess. Are you interested in approaching the JINI community and seeing if they would like to participate in it? Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
|
From: Ted K. <tk...@ya...> - 2003-07-07 04:24:33
|
Jac wrote: > The 'Secure' in your mail is bothering me. AFAIK JXME does not include > security at this moment (due to midp limitations according to the > whitepaper), so if we're going to base control equipment on it we'll have > a potential nightmare on our hands. > > Hmmm, from your proposal drawing it looks like you're proposing a PC to > host the embedlet, so the full JXTA stack is available with all security > features. Yes, since any JXME devices will only be communicating with a JXTA proxy that is in a PC we will not need to worry too much about secure communications between the two for the time being. > Makes for a nice demo, but using embedded Java hardware would be > more impressive and on target for what we set out to do, wouldn't it? :-) As soon as people see these lights blinking I think that they are going to come up with a large number of ideas for things to remotely control in the home and also in companies. Most of these ideas are going to require a significant amount of computing horsepower and I think that the Embedded Java hardware that we have been working with for the past few years will meet this demand excellently. The GlobalLightBlinker project is just a simple first step towards this larger goal but we need to start somewhere and this seems like an excellent place to start. Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
|
From: Ted K. <tk...@ya...> - 2003-07-07 03:56:46
|
Chris wrote: > On the JAPL front... has anyone had a chance to look over the JAPLEvent and > Network API's? > > They are in the japl module under: > > org.japl.event > org.japl.net > org.japl.media > > Just looking for feedback. I have been pounding hard on JXTA since JavaOne and have not had time yet. As soon as I get the proof of concept application working I will look at this too. Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
|
From: Ted K. <tk...@ya...> - 2003-07-07 03:52:43
|
Chris wrote: > Level I (no partner required) > - Life cycle > - Logging > - Event management > - Requires hard code initialization > > Level II > - Dynamic initialization (Context/Persistence) > - Networking/Remote management > > Level III > - Enterprise integration > - Web Services (SOAP RPC) > [...] > > Feedback? This kind of thinking seems to mirror the J2EE, J2SE and J2ME level concept and at first look it seems to be a good idea. It also enables us to start implementing compliant Level I Embedlets now without having to wait for the Level II and III capabilities to be finished. I will post some more detailed feedback after I finish with the current Light Blinker work I have been pursuing. Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
|
From: Gregg G. W. <gr...@sk...> - 2003-07-07 01:00:44
|
>One only needs a well known initial rendezvous address to bootstrap a >PeerGroup. After a PeerGroup is bootstraped the PeerGroup's rendezvous can >dynamically scale up and down in number and move around. If all of the >rendezvous in a PeerGroup would somehow drop offline, the Peers themselves are >designed to fire up their own Rendezvous services in order to keep the >PeerGroup online. Beyond this, Rendezvous can even be situated behind >firewalls and NATs. There are of course scenarios where all the relay and proxy mechanisms can breakdown and create failure. This is what you have to recognize about distributed systems. This is why Jini uses leasing. When partitioning occurs, you have to be ready to deal with it. >The main server infrastructure that is absolutely needed on the open internet >are JXTA Relays so that devices behind firewalls and NATs can participate in a >PeerGroup. But, this is not the be-all/end-all solution for participation. There is not solution that provides 100% connectivity, that is just life! >Anyway, I think that remotely controlling devices is unlike illegal file >sharing where one is in danger of having one's servers shut down. The cost for >server hosting of Rendezvous and Relays is very reasonable and so I do not view >this issue as being a major problem. See the above two points. >Agreed. And the JXTA reference implementation already comes with the proper >tools for creating world-community class UUIDs and so I am not too concerned >about this issue either. If this issue eventually does become a problem I >think that the JXTA developers can be relied upon to come up with a solution. Jini (and RMI underneath) and CORBA and many others have such concepts to aid in discovery and group isolation as well as participation. It is a 'good' thing when everyone follows the rules. It is interesting to note that MAC address allocation has never been free assignment, and one form of security in wireless networks is to specify allowed MAC addresses. And you can specify your mac address using the advanced dialog of most network cards (wired or wireless). In the end, UUID is a mechanism, but not a solution. Certificates are a better step, but like anything that involves mathematical generation (the signature), they can be eventually compromised by the determined. This we all know... >> This is where you have to be careful. JXTA provides protocols between JXTA >> clients that allow a proxy (of sorts) to interconnect them. This is a well >> known architecture. I have a proxy at my work location that an X-10 server >> at my house (whose network is NAT'd) connects to. My J2ME phone connects >>to the proxy which then provides the connecting pipe between the two 'worlds'. > >Is the connection between your phone and your in-home proxy secure at the >transport level (including over multi-hop networks) and also as the >authentication level? Can anyone who has the appropriate credentials securely >log into your in-home domain from anywhere on the internet using any class of >device? JXTA 2.0 includes the technologies which are needed to do these things >which is one of the main reasons that I am excited about it. It is quite insecure, because I did not want to spend time on that issue without underlying support. I could change the phone to use https and provide a password instead, and then make the proxy demand SSL and a password from the home machine to connect. Now that Jini 2.0 has these things built into the RMI infrastructure, I can easily secure the link to the home. The J2ME environments https is the easiest way to secure the phone to the proxy link. >> There are many competing technologies working in the world of distributed >> computing. JXTA is very interesting. I'm on the Jini wagon because it >> provides the solutions that I need for the same types of problems. [...], and >> in the end, the first technology to deploy the next killer application, >> may end up with the momentum to carry the lead... > >As people like Bruce Boyes can tell you, at JavaOne this year I expended a ton >of energy trying to determine whether to go with JINI or JXTA. After sitting >in on most of the JINI and JXTA sessions, and asking developers in both >communities where these technologies excelled and where they overlapped, I >still did not have a good answer by the last day of the show. I did discover, >however, that the JINI and JXTA communities do not talk very much and this >surprised me. The reason is that they are not compatible technologies at the same levels. JXTA does not use RMI and is not designed to capitalize on Java's security model. Jini is very much slanted in the direction of using solutions that have already be designed and implemented so that it can pivot on those technologies rather than spend time recreating them for no apparent technical gain. There are always licensing, political and personal reasons that drive people to recreate technologies. Does it strike you as strange that Bill Joy was involved in both Jini and JXTA development and introduction to the world community? Read below... >Thankfully, the last session of the last day of the show was about using JINI >and JXTA together and during this session it all fell into place for me. The >presenter showed how JINI was operating at a higher level of abstraction than >JXTA was and that a very reasonable thing to do was to use JINI on top of JXTA >and to not worry too much about the levels where they overlap. This is key. They overlap in that they implemen many of the same technical concepts. I believe that they deploy these technologies for the use of different audiences. Jini is about exploiting mobile code with well advertized interfaces. Jini pivots off of the RPC mechanism first defined by RMI. Jini 2.0 greatly improves the RMI model with a new wire transport protocol that includes Authentication, Authorization, code verification, and pre-unmarshalling security checks to make sure that you only unmarshall objects from codebases that you expect. JXTA is about exchanging information. If you want to build services, you have a lot more work to do to create the services' programming model and to manage all kinds of issues. One example for Jini/RMI vs JXTA might be an information search service (like google). If I provide an implementation of a information search facility that is defined in a Java interface, I can decide in my implementation what the most efficient and effective transport, caching and security implementation is, and when you get the 'proxy', you don't have to know about that implementation. In JXTA there is no code mobility. You have to implement these policies everywhere, or have a central server that implements some of these policies (local caching always has to be implemented locally), and then the applications have to know which version of the service to use to get the special services, and if the interface to those services changes, your specialized service breaks. So, the Jini/RMI model brings the abstraction/compatibility level up to the code interface level, instead of at the wire protocol compatibility level where JXTA is positioned. >I very much admire both of these amazing technologies and after attending this >session I felt relieved about there being a good chance that they will >cooperate in the future. There is a JXTA protocol JERI connector implementation that has been discussed on the Jini-users list. So, there are people thinking about how these two things work together. What this would allow is for an RPC call to propagate through the JXTA network, utilizing its transport features. This is an interesting concept, and could be interesting for a number of types of applications where NAT isolated systems need RPC calls to occur between them. >Bringing the Embedded Java and 'Computer Science' Java worlds closer together >is one of the Embedlet Projects stated goals and so including the JINI >community in this project seems like a great way support this goal. Well, I would return your question with a some counter questions. What do you want to enable the most with JAPL and Embedlets? Do you want to enable all the devices to talk to each other? Do you want to make it possible for non-java environments to participate at all levels and on all fronts? Jini requires a slightly different mindset for the type of problem you talk about with the global light blinking business. With JXTA, and no mobile code, people can easily open up all kinds of rendevous and they don't need to worry about security related to code. With Jini, security has to be your first consideration in the design of your system because mobile code demands that. With JXTA, security doesn't become a concern until you get worried about the content of your messages, or if your messages are driving service actions. So, people have to do more work up front to make sure they have the security model that makes sense for mobile code, and then for user access... This upfront work is usually what most people complain the most about when using Jini. It requires thought and dedication to details. This frustrates many people and the perils that result from the range of decisions that can be botched do make many belive that Jini is flawed or unproven. You have to know what you're doing. The Jini2.0 contributed implementation from Sun includes many examples of various types of security. Reading is required and this also presents a barrier. My startnow.jini.org project is a place where I have tried to start providing some abstrations and convenience classes that reduce what you have to learn. I haven't directly attacked the security issues. The sun provided examples provide some good starting points, as I said... Now I am rambling... ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Marc N. <ma...@ge...> - 2003-07-06 22:26:06
|
Going off on a tangent for a second...have any of you looked at Apple's Rendezvous technology for ideas/clues/comparisons/affirmations? AFAIK, the specs and some code are OSS. -marc On 6/7/03 18:20, "Ted Kosan" <tk...@ya...> wrote: > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Gregg wrote: > >> In the end, IP routability does not disappear. Thus, there have to be well >> known addresses for rendezvous. This means that while the peer groups might >> be dynamic, you must have a server infrastructure with well known addresses >> somewhere [...] there is still no possibility of two NAT'd JXTA peers finding >> each other without some well known address to find a rendezvous. > > One only needs a well known initial rendezvous address to bootstrap a > PeerGroup. After a PeerGroup is bootstraped the PeerGroup's rendezvous can > dynamically scale up and down in number and move around. If all of the > rendezvous in a PeerGroup would somehow drop offline, the Peers themselves are > designed to fire up their own Rendezvous services in order to keep the > PeerGroup online. Beyond this, Rendezvous can even be situated behind > firewalls and NATs. > > The main server infrastructure that is absolutely needed on the open internet > are JXTA Relays so that devices behind firewalls and NATs can participate in a > PeerGroup. > > Anyway, I think that remotely controlling devices is unlike illegal file > sharing where one is in danger of having one's servers shut down. The cost > for > server hosting of Rendezvous and Relays is very reasonable and so I do not > view > this issue as being a major problem. > > > >> While 128 bits is a big number, it is still possible for duplicates, so the >> UUID must be generated with many important considerations such as MAC >> address, date/time etc. So, you must follow the rules, and thus consider > some > aspect of your physical environment if you are going to operate in the > world >> community. > > Agreed. And the JXTA reference implementation already comes with the proper > tools for creating world-community class UUIDs and so I am not too concerned > about this issue either. If this issue eventually does become a problem I > think that the JXTA developers can be relied upon to come up with a solution. > > > >> This is where you have to be careful. JXTA provides protocols between JXTA >> clients that allow a proxy (of sorts) to interconnect them. This is a well >> known architecture. I have a proxy at my work location that an X-10 server >> at my house (whose network is NAT'd) connects to. My J2ME phone connects >> to the proxy which then provides the connecting pipe between the two >> 'worlds'. > > Is the connection between your phone and your in-home proxy secure at the > transport level (including over multi-hop networks) and also as the > authentication level? Can anyone who has the appropriate credentials securely > log into your in-home domain from anywhere on the internet using any class of > device? JXTA 2.0 includes the technologies which are needed to do these > things > which is one of the main reasons that I am excited about it. > > > >> There are many competing technologies working in the world of distributed >> computing. JXTA is very interesting. I'm on the Jini wagon because it >> provides the solutions that I need for the same types of problems. [...], and >> in the end, the first technology to deploy the next killer application, >> may end up with the momentum to carry the lead... > > As people like Bruce Boyes can tell you, at JavaOne this year I expended a ton > of energy trying to determine whether to go with JINI or JXTA. After sitting > in on most of the JINI and JXTA sessions, and asking developers in both > communities where these technologies excelled and where they overlapped, I > still did not have a good answer by the last day of the show. I did discover, > however, that the JINI and JXTA communities do not talk very much and this > surprised me. > > Thankfully, the last session of the last day of the show was about using JINI > and JXTA together and during this session it all fell into place for me. The > presenter showed how JINI was operating at a higher level of abstraction than > JXTA was and that a very reasonable thing to do was to use JINI on top of JXTA > and to not worry too much about the levels where they overlap. > > I very much admire both of these amazing technologies and after attending this > session I felt relieved about there being a good chance that they will > cooperate in the future. > > > So Gregg, what about bringing the JINI community into this Global Light > Blinker > project too? As an Embedded Java developer, I am extremely excited about the > prospect of any group making use of Embedded Java technologies and if we are > about to go through the effort of coming up with a Secure Outpost standard, > why > not make it so that JINI based software can use these devices too? > > Bringing the Embedded Java and 'Computer Science' Java worlds closer together > is one of the Embedlet Projects stated goals and so including the JINI > community in this project seems like a great way support this goal. > > > Ted > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > -------------------------------------------------- Marc Nicholas Geekythings Inc. C/416.543.4896 UNIX, Database, Security and Networking Consulting |
|
From: Ted K. <tk...@ya...> - 2003-07-06 22:20:59
|
Gregg wrote: > In the end, IP routability does not disappear. Thus, there have to be well > known addresses for rendezvous. This means that while the peer groups might > be dynamic, you must have a server infrastructure with well known addresses > somewhere [...] there is still no possibility of two NAT'd JXTA peers finding > each other without some well known address to find a rendezvous. One only needs a well known initial rendezvous address to bootstrap a PeerGroup. After a PeerGroup is bootstraped the PeerGroup's rendezvous can dynamically scale up and down in number and move around. If all of the rendezvous in a PeerGroup would somehow drop offline, the Peers themselves are designed to fire up their own Rendezvous services in order to keep the PeerGroup online. Beyond this, Rendezvous can even be situated behind firewalls and NATs. The main server infrastructure that is absolutely needed on the open internet are JXTA Relays so that devices behind firewalls and NATs can participate in a PeerGroup. Anyway, I think that remotely controlling devices is unlike illegal file sharing where one is in danger of having one's servers shut down. The cost for server hosting of Rendezvous and Relays is very reasonable and so I do not view this issue as being a major problem. > While 128 bits is a big number, it is still possible for duplicates, so the > UUID must be generated with many important considerations such as MAC > address, date/time etc. So, you must follow the rules, and thus consider some > aspect of your physical environment if you are going to operate in the world > community. Agreed. And the JXTA reference implementation already comes with the proper tools for creating world-community class UUIDs and so I am not too concerned about this issue either. If this issue eventually does become a problem I think that the JXTA developers can be relied upon to come up with a solution. > This is where you have to be careful. JXTA provides protocols between JXTA > clients that allow a proxy (of sorts) to interconnect them. This is a well > known architecture. I have a proxy at my work location that an X-10 server > at my house (whose network is NAT'd) connects to. My J2ME phone connects >to the proxy which then provides the connecting pipe between the two 'worlds'. Is the connection between your phone and your in-home proxy secure at the transport level (including over multi-hop networks) and also as the authentication level? Can anyone who has the appropriate credentials securely log into your in-home domain from anywhere on the internet using any class of device? JXTA 2.0 includes the technologies which are needed to do these things which is one of the main reasons that I am excited about it. > There are many competing technologies working in the world of distributed > computing. JXTA is very interesting. I'm on the Jini wagon because it > provides the solutions that I need for the same types of problems. [...], and > in the end, the first technology to deploy the next killer application, > may end up with the momentum to carry the lead... As people like Bruce Boyes can tell you, at JavaOne this year I expended a ton of energy trying to determine whether to go with JINI or JXTA. After sitting in on most of the JINI and JXTA sessions, and asking developers in both communities where these technologies excelled and where they overlapped, I still did not have a good answer by the last day of the show. I did discover, however, that the JINI and JXTA communities do not talk very much and this surprised me. Thankfully, the last session of the last day of the show was about using JINI and JXTA together and during this session it all fell into place for me. The presenter showed how JINI was operating at a higher level of abstraction than JXTA was and that a very reasonable thing to do was to use JINI on top of JXTA and to not worry too much about the levels where they overlap. I very much admire both of these amazing technologies and after attending this session I felt relieved about there being a good chance that they will cooperate in the future. So Gregg, what about bringing the JINI community into this Global Light Blinker project too? As an Embedded Java developer, I am extremely excited about the prospect of any group making use of Embedded Java technologies and if we are about to go through the effort of coming up with a Secure Outpost standard, why not make it so that JINI based software can use these devices too? Bringing the Embedded Java and 'Computer Science' Java worlds closer together is one of the Embedlet Projects stated goals and so including the JINI community in this project seems like a great way support this goal. Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
|
From: Jac K. <j.k...@th...> - 2003-07-06 21:40:55
|
On Sun, 6 Jul 2003, Ted Kosan wrote: > Anyway, my 'gut feel' is that as soon as people see these remotely > controlled lights blinking that the demand for Secure Outpost devices is > going to be strong enough to keep the device manufactures busy for a > long time... Ted, The 'Secure' in your mail is bothering me. AFAIK JXME does not include security at this moment (due to midp limitations according to the whitepaper), so if we're going to base control equipment on it we'll have a potential nightmare on our hands. I'm not up to speed with the JXTA 2.0 spec, but from what I understand this will not change the security issues for JXME. Hmmm, from your proposal drawing it looks like you're proposing a PC to host the embedlet, so the full JXTA stack is available with all security features. Makes for a nice demo, but using embedded Java hardware would be more impressive and on target for what we set out to do, wouldn't it? :-) Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com |
11 messages has been excluded from this view by a project administrator.
Thanks for helping keep SourceForge clean.
X