Gervas Douglas wrote: > BTW, the J/JS idea of leasing would be very useful for such a tuple space. > hi Gervas,
from my experience working with APIs that use leases (and having my own implementations of such systems as well including grid systems and my own XML tuple space implementation): using the concept of a lease to maintain garbage collecting of unused distributed resources is very enticing but in practice it leads to all kinds of problems. issues range from deciding on suitable lease duration/renewal policy to actually dealing with large failures - it is not great when some resources decide to commit "suicide" because lease was not renewed (not mentioning possible domino effect) ... i think that for many application i prefer a more manual cleanup/garbage collection (as one could say: some app garbage maybe treasure to others :) ). i found myself often using "forever" leases what leases had to be used as a workaround (that is completely defeating purpose of leases ...) best, alek > > > --- In [email protected], "Gervas > Douglas" <[EMAIL PROTECTED]> wrote: > >> Thanks, Aleksander. My idea was to use an XML Tuple Spaces program as a >> middleware engine. This would mean that it would not necessarily have >> direct exposure to raw applications. Although by its nature the >> > datasets it > >> handled would be in XML format, the middleware could communicate with >> applications with different proprietary data formats through >> > adaptors, just > >> as a pub-sub bus does. The actual space/spaces (a distributed model >> > would > >> be logically feasible) would accommodate a variety of XML formats. For >> example certain applications might want to use XBRL for reporting, >> > others > >> might want to use tailored formats for vertical or EDI markets. Just as >> packets can be routed by means of their addresses, so these >> > specialist XML > >> datasets could pass between sets of PUTters and GETters (whatever >> > syntax you > >> prefer) by unique identifying fields, while still sharing the same >> asynchronous tuple space. >> >> You are certainly right about higher level protocols/code. Each >> > application > >> set using a specific specialist XML dataset might need its own wee >> > stub of > >> code for instance. The whole package could be engineered with the >> > maximum > >> of extensibility in terms of formats and applications whilst >> > shielding the > >> tuple spaces nature of the engine from application programmers. I think >> this is important as most programmers would not understand the wide >> versatility of a tuple spaces engine and how to make the best use of >> > it. I > >> suspect that this has been one of the reasons JavaSpaces never took off, >> putting aside the marketing promotion (or lack of) issues. >> >> If you want an example of how to wrap a JavaSpace (as an example of >> > a tuple > >> space) with code to turn it into usable middleware, have a look at >> > Patrick > >> May's paper, publish-subscribe-whitepaper.pdf, which you can find at >> >> > <http://groups.yahoo.com/group/jini_javaspaces/files/Whitepapers-Articles/> > >> in my J/JS Group. >> >> BTW, I have only a very superficial technical understanding of these >> matters, so if any of you are in a sharp, acerbic mood, feel free to >> slaughter the above (my musings, not Patrick). >> Gervas >> >> -----Original Message----- >> From: [email protected] >> [mailto:[EMAIL PROTECTED] On Behalf Of >> Aleksander Slominski >> Sent: 14 April 2006 12:45 >> To: [email protected] >> Subject: Re: [service-orientated-architecture] TSpaces (was: Re: XML >> > Tuple > >> Spaces as Middleware) >> >> Gervas Douglas wrote: >> >>> I have never heard a single simple convincing explanation for why >>> > no tuple > >>> spaces implementation has taken off. >>> >>> >> hi, >> >> one data point from my own experience: writing non trivial applications >> that *uses* tuple spaces is hard (that is irregardless of implementation >> or tuple space API design). >> >> tuple spaces are very nice when considered as an idea (and their >> potential ...). in particular as they decouple processes that use tuple >> space(s) that may lead to more resilient to failure and scalable >> applications. however programming such processes and coordinating them >> into a coherent and maintainable application is not an easy task - in a >> way pub-sub APIs has an advantage as they provide more restricted but >> flexible _enough_ model for many applications and still are providing >> enough decoupling whereas tuple spaces provide even more freedom but >> then one needs to provide higher level protocols on top of low level >> tuple space operations and that is hard ... >> >> best, >> >> alek >> >>> JavaSpaces was undoubtedly stillborn due to Sun's senior management's >>> failure to see its significance (not being integral part of a SPARC >>> chip?). TSPaces is more of a puzzle: why were the lads at Almaden >>> abandoned by IBM, a company which supposedly has some comprehension of >>> infrastructural software? Was it due to internal rivalry (competition >>> for DB2?), or did IBM decide it was so valuable they would keep it for >>> internal use? I have never heard anyone suggest that the product was >>> rubbish. >>> >>> I don't see why a tuple spaces package should be seen as direct >>> competition to a DBMS - if they are, perhaps the users do not >>> understand their respective strengths and weaknesses. You mention the >>> big boys backing alternative solutions with big bucks, but that in >>> itself does not preclude an innovator coming up with a disruptive >>> competitor based on tuple spaces. >>> >>> Gervas >>> >>> --- In [email protected], "Michael >>> Champion" <michaelc.champion@> wrote: >>> >>> >>>> On 4/13/06, Elias Sinderson <elias@> wrote: >>>> >>>> >>>> >>>>> Indeed, and the conclusions no less relevant now than they were >>>>> >>>>> >>> when it >>> >>> >>>>> was published -- did you even read the article? :-) FYI, here is a >>>>> more recent paper published out of the TSpaces group: >>>>> >>>>> >>>> I read it (or a similar paper on TSpaces) about 4 years ago :-) >>>> > FWIW I > >>>> really did buy the "sweet spot" argument in section 1.1 of that >>>> > paper. > >>>> My only question is whether others still do? Technically, I >>>> > like the > >>>> idea very much-- "loosely coupled in location, platform, and time" is >>>> how I remember Patrick Thompson (or Ruple fame) describing the basic >>>> design pattern. >>>> >>>> The non-technical problems I see are: >>>> - The web (now that most serious sites are backed by DBMS) >>>> > plucked the > >>>> low hanging fruit. I can reserve hotel rooms, synch my cellphone >>>> > with > >>>> Outlook, etc. etc. over the web now, maybe not as cleanly as one >>>> > might > >>>> with J/T/X-Spaces, but some VC or telco has put up the big bucks to >>>> make these things work by brute force. >>>> - Worse is better -- The value of the web's network effect overwhelms >>>> its kludginess (sorry Mark, no +1 from you today!) as a platform for >>>> the kinds of apps that J/T/X-spaces envisioned. >>>> - WS-* grabbed the mindshare among people who have enterprise-class >>>> problems to solve that are too difficult to kludge around with raw >>>> HTTP+XML. >>>> >>>> I would be very happy to be wrong on the non-technical issues, but >>>> need some evidence that they are being overcome before I can get too >>>> excited about this stuff again. >>>> >>>> >>>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Yahoo! Groups Links >>> >>> >>> >>> >>> >>> >>> >>> >> -- >> The best way to predict the future is to invent it - Alan Kay >> >> >> >> >> >> >> Yahoo! Groups Links >> >> > > > > > > > > > > Yahoo! Groups Links > > > > > > > > -- The best way to predict the future is to invent it - Alan Kay Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
