BTW, the J/JS idea of leasing would be very useful for such a tuple space. Gervas
--- 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 <*> 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/
