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" <[EMAIL PROTECTED]> wrote: > >> On 4/13/06, Elias Sinderson <[EMAIL PROTECTED]> 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/
