Thread: Re: [Embedlets-dev] Interested in sharing a J2EE perspective
Status: Alpha
Brought to you by:
tkosan
|
From: Gregg G. W. <gr...@sk...> - 2004-02-14 15:25:27
|
As I've discussed here before Cyte Technologies has been building device to boardroom systems since 1997. The issues that Ted brings up are very real. It is important to understand these points and implement solutions, communications and strategy messages that work from the bottom of these organizations to the top. Some key issues related to the scalability Ted discussed revolve around making the correct decisions about responsibilities at all levels to minimize 'network' traffic and administrative load. o If a device is able to detect a particular status, it should be able to throttle the reporting of that status based on configuration and importantance. o Polling is not a generally scaleable strategy. At the upper levels of the system, you must use report by exception for status data. A timely healthcheck must be included to allow you to determine that the device is still operating, and to refresh the world with the 'current' status periodically. Think of the MPEG-4 I-Frame mechanism which allows video displays to randomly be inserted into the video stream without having to see the very first frame in order to understand what the current display should be. o Data that must be delivered should use an appropriate transactional mechanism that allows the data brokers to fail, and for the field devices to know what data is still undelivered. This helps to eliminate large scale data recovery which can be impossible to administrate as the number of devices reporting data grows large. o In line with the previous issue, administration of the field devices must be automated as much as possible. Any variant data/configuration must have an enterprise wide storage location that can be reached from all locations in the system. Replacement devices can then be reconfigured for their installed location in an automated way that guarantees they are operating with the correct software and configuration. Our system was started before J2EE existed and we've continued to use it because it is well tuned and instrumented for this type of application. One of our current applications is doing approximately 120,000 transactions per hour against 3 different databases, as well as delivering 40,000+ data and status valued events into our system monitoring and control application. There are over 1500 end devices being polled by approximately 150 relay devices that do the status monitoring and reporting by exception and required, timely data reporting. The devices are delivering data at a rate of approximately 70 packets per second. There are 2 machines receiving this data, each a hot standby for the other. These machines are running linux, and have load averages < 2. Our data routing software architecture is a multi-tiered system with decoupled inbound and outbound data delivery using extensive multi-threading. The primary latency that we deal with is database transactions. We typically run between 5 and 10 threads for each type of data delivery into the databases. This is necessary to help make sure that we keep up with the inbound data rates. Having a well tuned, well maintained enterprise database system is a real necessity. One of our customers is an aluminum melting enterprise. We are building furnace control systems that include data gathering and remote furnace control capabilities. They have little experienced IT infrastructure. So, we have to do more hand holding and provide less technical and more do-it documentation to make it possible for them to successfully utilize the power of the systems that we are deploying. So, everthing that Ted is discussing is not a single persons experience. These are many of the primary issues that everyone needs to be aware of. I'm really interested in hearing about other experiences that the J2EE folks have had, and in particular are there common themes present in other types of integration applications. ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Gregg G. W. <gr...@sk...> - 2004-02-28 23:20:50
|
>Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] >_______________________________________________ > > >> My take on this is that this is more a pitch to push high end >> hardware. Even if a truck full of tags were to move past a reader, the > >This is more real then pitch I can assure you. James, what kind of transaction rates are working and what rates are just not possible? ----- gr...@cy... (Cyte Technologies Inc) |
|
From: James T. <Jam...@Su...> - 2004-02-28 23:34:20
|
I do not work directly on this application but my colleagues do. I have asked them to join in on the discussion ... that said, they are *really* busy these days. Please realize that Sun sells a broad spectrum of h/w products so to pigeon hole reference architectures, products and the like as motivated primarily to sell high end h/w alone is missing the boat, pretty much entirely. That and the bulk of the s/w offerings run on a myriad of h/w and o/s platforms, the deployment choices are quite broad. Lastly, some apps are mission and/or life critical and as such the respective architect should do due diligence is scoping out solutions and the like and the thusly I assert the drive to "beige box" everything is, again, likely missing the "bigger picture" boat. hth, - james Gregg G. Wonderly wrote: > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > > >>Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] >>_______________________________________________ >> >> >> >>>My take on this is that this is more a pitch to push high end >>>hardware. Even if a truck full of tags were to move past a reader, the >> >>This is more real then pitch I can assure you. > > > James, what kind of transaction rates are working and what rates are just not > possible? > > ----- > gr...@cy... (Cyte Technologies Inc) > > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer -- Java == platform independence XML == application independence JXTA == network independence Secure End-to-End Computing |
|
From: Holger B. - b. <ho...@bi...> - 2004-02-29 00:48:19
|
Am 29.02.2004 um 00:09 schrieb Gregg G. Wonderly: > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > >> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] >> _______________________________________________ >> >> >>> My take on this is that this is more a pitch to push high end >>> hardware. Even if a truck full of tags were to move past a reader, >>> the >> >> This is more real then pitch I can assure you. > > James, what kind of transaction rates are working and what rates are > just not > possible? With the advanced transaction, dynamic distributed caching and customization features of the JMX based JBoss.org General Purpose Architecture there is no end ... With "standard" hardware: 200Mbyte/s fibre channel array (the bottleneck in or calculation cpu oriented versus the I/O oriented mainframe world), 2 dedicated 1GBit direct links, two 2,8 MHz/2GByte standard PC (P4P800) Oracle 8.7.1 and dynamic on-demand precreated CMP EntityBeans i got around 1000 continous inserts per second. The query time on the optimized _beans_ (m:n ID query) was clearly below 1ms. Bottleneck here was the Client request time. Other approaches for not-allowed mass checking are JMS approaches with MQSeries and a dead letter queue for unexpected ID's. But IMHO checking a 10k bunch of RFID's on one point in the logistical chain smells. just 2ct bax > > ----- > gr...@cy... (Cyte Technologies Inc) > > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Gregg G. W. <gr...@sk...> - 2004-02-29 04:04:42
|
>What kinds of designs can automatically handle these dynamic load changes? How >can thousands of dynamically-connected Enterprise Outposts be managed by >existing IT personnel? How can Enterprise Outposts be configured and deployed >by existing IT personnel without the help of the Java developers who designed >them? > >These are the bigger-picture problems that keep some of us nights ;-) We've had no problem with this issue as long as we've kept the configuration nightmare out of the way. As I've stated here before, we designed our container architecture before J2EE existed, and we avoided configuration for everything, by designing systems that adapt, or discover. We've added 100's of devices into systems day and night with zero impact to the existing devices. The systems don't have per device configuration, or automatically recognize and configure the system for the new devices if device specific configuration is needed. We haven't used the Jini Surrogate stuff yet, but some of the things that we do are similar to the that solution space. Eliminatination of IP address configuration is one thing that must be dealt with in large scale network deployments. Many small network devices don't implement DHCP because of code footprint, or because of the thought that fixed IP addresses provide some kind of security :-( The configuration of such devices network parameters can be made simple, but it is still an administrative step... Out status monitoring software automatically creates new standard views for new devices. As soon as a new device is sending traffic in the system, you can search for a device by id and get a list of views to look at. We typically have a status related view that shows communications and general health data, and a current 'values' view that shows the data that is important to the enterprise. In our largest system, we have 6000+ views, most of which are generated automatically. Everyone doesn't need to see all of these views. Views are placed into view groups which are assigned access by user groups. Users of the system are placed into user groups administratively based on responsibilities. At these kinds of scales, automation of configuration, or the elimination of it is a must! ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Ted K. <tk...@ya...> - 2004-03-01 06:49:44
|
Gregg wrote: > We've added 100's > of devices into systems day and night with zero impact to the existing > devices. Is the 'we' here Cyte employees or customer IT personnel? Who decides what types of devices are deployed and where? > The systems don't have per device configuration, or automatically > recognize and configure the system for the new devices if device specific > configuration is needed. Can you give an idea again of what types of devices are typically connected to these systems? What are some of the things they are doing? Are they only monitoring or are some of them also doing control? > Out status monitoring software automatically creates new standard views for > new devices. As soon as a new device is sending traffic in the system, you > can search for a device by id and get a list of views to look at. [snip] It sure would be interesting to visit one of your installations! The Cyte website shows that Cyte has a Midwest regional contact. Does Cyte have any installations like you described above anywhere near Ohio? Ted __________________________________ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools |
|
From: Gregg G. W. <gr...@sk...> - 2004-02-29 04:07:18
|
>With the advanced transaction, dynamic distributed caching and >customization features of the JMX based JBoss.org General Purpose >Architecture there is no end ... > >With "standard" hardware: 200Mbyte/s fibre channel array (the >bottleneck in or calculation cpu oriented versus the I/O oriented >mainframe world), 2 dedicated 1GBit direct links, two 2,8 MHz/2GByte >standard PC (P4P800) Oracle 8.7.1 and dynamic on-demand precreated CMP >EntityBeans i got around 1000 continous inserts per second. The query >time on the optimized _beans_ (m:n ID query) was clearly below 1ms. I have numbers that indicate this kind of performance is possible. I just asked to see if there was real experience with huge transaction rates that didn't work as I think it should. We're preparing to do some evaluations at this kind of performance level. It will be exciting to see what's possible. ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Gregg G. W. <gr...@sk...> - 2004-03-01 18:13:16
|
>> We've added 100's >> of devices into systems day and night with zero impact to the existing >> devices. > >Is the 'we' here Cyte employees or customer IT personnel? Who decides what >types of devices are deployed and where? Field technicians and IT staff, depending on the customer and the application. >> The systems don't have per device configuration, or automatically >> recognize and configure the system for the new devices if device specific >> configuration is needed. > >Can you give an idea again of what types of devices are typically connected to >these systems? What are some of the things they are doing? Are they only >monitoring or are some of them also doing control? Metering equipment as well as control equipment. >It sure would be interesting to visit one of your installations! The Cyte >website shows that Cyte has a Midwest regional contact. Does Cyte have any >installations like you described above anywhere near Ohio? Not Yet. We have pipeline based equipment throughout the lower midwest and going west into wyoming. The equipment is not that special Ted. It's mostly the arcom control systems director. It is monitoring and controlling equipment via modbus and/or digital and analog I/O. The director would be an outpost class device. It does all the work of a realtime environment. We just send it things to do (mostly via modbus) for certain controls. It also has scheduled reporting and exception based reporting that it is performing unattended. We use a proprietary binary protocol from the directors in many cases. In others, we shoot back XML. It just depends on what is the easiest. These programmable controllers are available everywhere. What is not being done is the publish/subscribe model. Instead, everyone is polling these devices with modbus or similar protocols. Polling doesn't scale well to large numbers of devices, comming from a single source. So, we do the polling at the Director devices, and then have them publish the data back into the enterprise. There is a whole series of error management strategies that come into play when you have networking between the enterprise and its vital data. For each type of application/data, we've engineered solutions that make sure the data can be retrieved within reasonable contraints of communications failures. There are things like 30days of history that needs to be archived at the remote sites so that someone can drive out there and collect manually if needed. Some of the end devices do this themselves already. Some need the director to buffer data. So, it needs certain size flash for certain apps. It's really an end to end engineering job. But, once you have the pieces engineered, then anyone can drop them into the network and plug them together. ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Gregg G. W. <gr...@sk...> - 2004-03-01 18:19:54
|
>From what Gregg indicated, it appears that Cyte has developed some patterns >that effectively handle the 'large number of devices' management problem. It >would be nice to start collecting these device-oriented patterns so that they >can be made available to distributed system's architects. > >Hey Gregg, now that I am thinking about it, wouldn't a pattern like this be >considered a secret that Cyte would want to use for competitive advantage? Well, mostly yes. We've developed software technologies that let us, as a small company, tackle large scale data collection. There's lots of practical engineering involved. There's also nothing like real world experience to help shape your thought processes. My previous email highlights the points that I think are important to understand about what we do from an end to end perspecive. There are other things that I've discussed on the list over the past year as well. ----- gr...@cy... (Cyte Technologies Inc) |
|
From: <ra...@pr...> - 2004-03-02 04:13:35
|
Just wondering.. what would be the relationship between Outpost container and Savant? Would Outpost be a possible implementation layer for Savant? Or, would outpost feed into Savant- as an intermediary between the devices and Savant? While Outpost is an implementation platform for any apps involving devices, may accelerate adoption if we can have a clear articulation for RFID absed solutions? Cheers, Ramesh |
|
From: Ted K. <tk...@ya...> - 2004-03-02 07:22:36
|
Ramesh wrote: > Just wondering.. what would be the relationship between Outpost > container and Savant? Would Outpost be a possible implementation layer > for Savant? Or, would outpost feed into Savant- as an intermediary > between the devices and Savant? An 'Enterprise Outpost' was conceived to be an open 'black-box' Internet-connected computer platform that is specifically designed to be easily interface to a company's physical processes and also easily integrated with its backend enterprise systems. The idea is to allow backend Enterprise systems to monitor and control all aspects of a company's physical processes through the use of standardized 'black boxes' that embody standardized embedded software and hardware components. As part of this process, this group developed what we call Embedlets (embedded system software components, think servlets for embedded systems) and an Embedlet Container to run them in in order to help achieve this goal. Another goal that we have is to enable Outposts to be easily managed and re-configured in the field so that their numbers can be scaled up into the thousands. Given this definition of an Enterprise Outpost, I see an RFID Savant server as being a software system that simply runs on an Outpost. The Outpost black-box computer would be directly interfaced to an RFID reader and it would then host the Savant software. In addition to this, the Outpost would provide the capability to interface to other physical things around the Outpost along with providing the ability for the whole system to be managed remotely. This group now has the ability to make at least an alpha-level version of these Enterprise Outposts but now we are at a point where we need to partner with a community of J2EE developers to help evolve the technology. > While Outpost is an implementation platform for any apps involving > devices, may accelerate adoption if we can have a clear articulation > for RFID based solutions? I agree with this completely. Our group of Embedded Java developers has been in need of an embedded systems related problem that the J2EE community needed help solving and it appears that RFID meets this requirement very well. At this point, it appears that no one knows exactly what the main RFID-oriented problems and best-practice solutions are going to be and this is why I think that an open, experimental RFID project (like the proposed one involving TSS members) would be useful in starting to figure things like this out. We can handle the hardware and embedded software aspects of an open project like this if we could get a group of J2EE developers to handle its Enterprise Software aspects. Ted __________________________________ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com |
|
From: John S. <jsp...@ne...> - 2004-02-15 00:35:27
|
In the world of SECS GEM, where I worked we use a thing called event reports to recieve data when the equipment wants to send it. And have of course programs to interface to the MES. ----- Original Message ----- From: "Gregg G. Wonderly" <gr...@sk...> To: <emb...@li...> Sent: Saturday, February 14, 2004 7:22 AM Subject: Re: [Embedlets-dev] Interested in sharing a J2EE perspective > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > > As I've discussed here before Cyte Technologies has been building device to > boardroom systems since 1997. The issues that Ted brings up are very real. > It is important to understand these points and implement solutions, > communications and strategy messages that work from the bottom of these > organizations to the top. > > Some key issues related to the scalability Ted discussed revolve around making > the correct decisions about responsibilities at all levels to minimize > 'network' traffic and administrative load. > > o If a device is able to detect a particular status, it should be > able to throttle the reporting of that status based on configuration > and importantance. > > o Polling is not a generally scaleable strategy. At the upper levels of > the system, you must use report by exception for status data. A timely > healthcheck must be included to allow you to determine that the device > is still operating, and to refresh the world with the 'current' status > periodically. Think of the MPEG-4 I-Frame mechanism which allows video > displays to randomly be inserted into the video stream without having to > see the very first frame in order to understand what the current display > should be. > > o Data that must be delivered should use an appropriate transactional > mechanism that allows the data brokers to fail, and for the field devices > to know what data is still undelivered. This helps to eliminate large > scale data recovery which can be impossible to administrate as the number > of devices reporting data grows large. > > o In line with the previous issue, administration of the field devices > must be automated as much as possible. Any variant data/configuration > must have an enterprise wide storage location that can be reached from > all locations in the system. Replacement devices can then be > reconfigured for their installed location in an automated way that > guarantees they are operating with the correct software and configuration. > > Our system was started before J2EE existed and we've continued to use it > because it is well tuned and instrumented for this type of application. One > of our current applications is doing approximately 120,000 transactions per > hour against 3 different databases, as well as delivering 40,000+ data and > status valued events into our system monitoring and control application. > There are over 1500 end devices being polled by approximately 150 relay > devices that do the status monitoring and reporting by exception and required, > timely data reporting. The devices are delivering data at a rate of > approximately 70 packets per second. There are 2 machines receiving this > data, each a hot standby for the other. These machines are running linux, and > have load averages < 2. > > Our data routing software architecture is a multi-tiered system with decoupled > inbound and outbound data delivery using extensive multi-threading. The > primary latency that we deal with is database transactions. We typically run > between 5 and 10 threads for each type of data delivery into the databases. > This is necessary to help make sure that we keep up with the inbound data > rates. > > Having a well tuned, well maintained enterprise database system is a real > necessity. One of our customers is an aluminum melting enterprise. We are > building furnace control systems that include data gathering and remote > furnace control capabilities. They have little experienced IT infrastructure. > So, we have to do more hand holding and provide less technical and more do-it > documentation to make it possible for them to successfully utilize the power > of the systems that we are deploying. > > So, everthing that Ted is discussing is not a single persons experience. > These are many of the primary issues that everyone needs to be aware of. I'm > really interested in hearing about other experiences that the J2EE folks have > had, and in particular are there common themes present in other types of > integration applications. > > ----- > gr...@cy... (Cyte Technologies Inc) > > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |