Aleksander Slominski wrote:
> 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).
>
Why? I've deployed a number of tuplespace solutions that have worked
very well and scale nicely.
Some of them pass around XML messages, some of them do mass computation,
some of them do workflow and they have appropriate levels of reliability
and performance.
I've also worked with several companies to develop their own tuplespace
based products, typically these fall into two categories:
(1) Wide area
(2) High performance
In fact, I've got a framework product in the works which provides
reliable queueing, distributed locks, reliable storage and messaging
which embodies all the tuplespace knowledge I've accrued.
> 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 ...
>
Re: the low level protocol thing:
(1) At least in the world of JavaSpaces, there's now an additional API,
JavaSpace05 which provides bulk operations, the equivalent of "select *
where" (method is contents) and a notify implementation that supports a
fuller event'ing model to make messaging more reliable, more easily.
(2) A lot of people treat tuplespaces like they are databases and they
design that way - big mistake.
(3) A lot of people make the mistake of trying to store all state in the
tuplespace with synchronous updating as opposed to adopting lazy
updates, with caching etc.
(4) A lot of people try and model their entire application using
JavaSpace constructs as a result of (3) and fail for that reason.
I think the real problem is not the flexibility of the tuplespaces model
but the perception that there's a lack of readily available design
patterns and implementation knowledge. In addition, I think a lot of
people are used to method-based implementation and have little
experience with messaging or similar asynchronous systems. Even those
that are doing "distributed systems" are typically using either an
RPC/RMI/CORBA/Other remote method protocols.
In fact, the information _is_ available from specialized consultancies
(including my own, Lone Crusader Ltd) etc but most companies are
unwilling to try anything different from the norm. I suspect this is
because they want to make use of infrastructure they already have which
is more than fine but they make this mistake:
Anything new they look at is expected to have similar properties to what
they already have and, if it doesn't it's ignored.
i.e. the problem is space-based models are different rather than hard.
Dan.
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/
