Gervas Douglas wrote: > --- In [email protected], Gregg Wonderly > <[EMAIL PROTECTED]> wrote: >> Steve Jones wrote: >>> On 18/12/06, Stuart Charlton <[EMAIL PROTECTED] >>> <mailto:stuartcharlton%40yahoo.com>> wrote: >>> > --- Steve Jones <[EMAIL PROTECTED] >>> > > REST is _not_ a silver bullet, remote invocation is _not_ a > challenge >>> > > and REST is only disruptive in that it stops people looking > for the >>> > > true disruption which will come when we consider remote > invocation a >>> > > true commodity. >>> > >>> > In 1971, this might read as: "Relations are _not_ a silver > bullet, data >>> > management is _not_ a challenge, and relational databases are only >>> > disruptive in that they stop people looking for the true disruption >>> > which will come when we consider data management a true commodity." >>> >>> Ummm I don't think so, lots of people thought that data was a massive >>> issue in 1971 and the concept of data relations wasn't well >>> understood. Relational databases were disruptive (although not for >>> quite along time) once they became more of a commodity, and the degree >>> to which they were disruptive was that they replaced Hierachical (ummm >>> XML anyone?) data structures. >> One of the important parts of database history is that RDBMs were > created and >> evolved in the timeframe that opensource projects visible on > 'usenet', were all >> about non-data computing problems. Mainly it was all about > networking and >> administration back in those days. Also, the size of database > systems was >> "huge" compared to the average project for opensource at that time. > The cost of >> those systems was huge as well. Only more recently have opensource > RDBMs come >> of age to commoditize that aspect of computing systems. >> >> Opensource software system development is a well oiled machine these > days. The >> next thing that will be disruptive is the $100.00 PC. That will > cause many >> consumer electronics companies to rethink their business. Small > companies will >> be able to create vertical market devices with just software > investment. This >> is the type of device where Jini and other mobile code platforms > will accel at >> delivering systems that actually evolve and mature without the user > interacting >> with them. >> >> Gregg Wonderly >> > > Was not Jini originally conceived for embedded devices so as to enable
No - Jini was conceived to build distributed, co-operating, spontaneously assembling _software_ services which could be running on _anything_. The whole device thing was a Sun marketing screw up - someone somewhere thought that trying to explain Jini by relating it to the connecting together of devices (like toasters and fridges urgh) was a good idea. Everybody knows plugging in a toaster or a fridge is easy and a solved problem space. What was missing was the explanation of software services binding to each other dynamically at runtime with minimal prior knowledge of each other. I'm not going to try and concoct a reason for software services on a toaster to talk to those on a fridge so, off the top of my head a better example of the sorts of things you can do with Jini would be having a cache on one machine that can detect and cache elements of new information sources as they come and go. As it happens there's some stuff going on in the blogosphere re: Jini and it's uses which caused me to write this earlier: http://www.jroller.com/page/dancres?entry=jini_in_a_nutshell > such devices to interact in a resilient manner? This would fit into > what Accenture calls "silent commerce", although at present the main > technology to which they refer in this context is RFID. > > Gervas > > > > > Yahoo! Groups Links > > > >
