GBBopen

I'm trying to wrap my brain around GBBopen. I have never heard of Blackboard Systems before, and so a paradigm shift seems necessary.

The nearest similarity in my experience appears to be the Linda System of Galertner, where any number of disjoint and cooperating threads could interact on a common data pool (the Tuple Space), based on recognizing certain tuple patterns as appropriate for their activities. The threads transmute those tuple items they recognize, in hopes that another thread might be able to use them.

Is this even close?

David McClain

Chief Technical Officer

Refined Audiometrics Laboratory

4391 N. Camino Ferreo

Tucson, AZ 85750

email: dbm@refined-audiometrics.com

phone: 1.520.390.3995

web: http://www.refined-audiometrics.com

Skype: dbmcclain

Re: GBBopen

Hi David,

I'm trying to wrap my brain around GBBopen. I have never heard of Blackboard Systems before, and so a paradigm shift seems necessary.

<smile>

The nearest similarity in my experience appears to be the Linda System of Galertner, where any number of disjoint and cooperating threads could interact on a common data pool (the Tuple Space), based on recognizing certain tuple patterns as appropriate for their activities. The threads transmute those tuple items they recognize, in hopes that another thread might be able to use them.

I would say yes, it's very similar but Dan's the man to listen to.

Gary Warren King, metabang.com

Cell: (413) 885 9127

Fax: (206) 338-4052

gwkkwg on Skype * garethsan on AIM

Re: Blackboard Systems

David McClain wrote:

> I'm trying to wrap my brain around GBBopen. I have never heard of
> Blackboard Systems before, and so a paradigm shift seems necessary. 
> 
> The nearest similarity in my experience appears to be the Linda System
> of Galertner, where any number of disjoint and cooperating threads could
> interact on a common data pool (the Tuple Space), based on recognizing
> certain tuple patterns as appropriate for their activities. The threads
> transmute those tuple items they recognize, in hopes that another thread
> might be able to use them. 
> 
> Is this even close?

Close (but no cigar).  Linda is the original of what is now being called
"space-based architectures."  (I suppose the old tuple-based name
doesn't sound modern enough.)  These include Linda, T-Spaces,
JavaSpaces, etc.  Linda uses a tuple-space repository to implement
anonymous and temporally decoupled triggering of software modules
(knowledge sources in blackboard-system speak), but it is missing the
separate moderator/control aspects of the blackboard-system approach.
(There are other, detailed technical, reasons why tuple-space approaches
don't perform well in some blackboard-system settings, but I'll only
wave a caution flag now).

Note that Linda was created nearly a decade after Hearsay-II (the first
blackboard-system, circa 1975-6).  The open-source GBBopen system
supports building blackboard systems, but many are using some of the
core layers of GBBopen in non-blackboard-system applications (for
example, using only the repository, event signaling, and objecting
linking facilities, without running a blackboard-system control shell).
 That's fine with us...!

-- Dan

P.S.  For some background reading, see BBTech Corporation's annotated
bibliography: http://BBTech.com/bibli/

I'd recommend the historical AI Expert intro article
(http://bbtech.com/papers/ai-expert.pdf) and the more recent ILC paper
(http://dancorkill.home.comcast.net/pubs/ilc03.pdf), but I'm biased!

RE: Blackboard Systems

Dan Corkill wrote:

>These include Linda, T-Spaces, JavaSpaces, etc.

Can you compare GBOpen with JavaSpaces ? What are the
differences/similarities ?

Regards,
Vagif Verdi.

Re: Blackboard Systems

Vagif Verdi wrote:

> Can you compare GBBopen with JavaSpaces ? What are the
> differences/similarities ?

GBBopen provides Common Lisp extensions that support blackboard-system
development.  GBBopen includes a memory-resident, object-based
repository with high-performance multidimensional proximity-based
search/retrieval.

JavaSpaces are best viewed as providing distributed shared memory with
additional features such as transactional integrity and failure handling.

Both GBBopen and JavaSpaces provide repositories with retrieval
capabilities.  GBBopen's repository is based on a
dimensional-abstraction mechanism (similar to the class of
range-retrieval/spatial data structures used in GIS systems) and
JavaSpaces is based on a tuple abstraction.  (Conventional RDBs are
based on table abstractions.)

JavaSpaces provide only the repository (distributed shared memory)
mechanism, while GBBopen includes lots of other capabilities needed by
blackboard systems (such as control-shell facilities).  These days, RDF
stores have become all the rage (the additional benefits/pitfalls of
those "restricted tuple" stores are for another discussion)...

>From far enough away, both GBBopen and JavaSpaces provide anonymous and
atemporal repositories (meaning that objects/tuples can remain in the
repository for a long time before they are used, allowing for
considerable flexibility in control/synchronization).  Of course, the
keys to performance in real-world application settings is all in the
details of the underlying approaches, their implementations, and how
they are used by applications.  For very loosely coupled software
entities, it hardly matters; for tightly collaborating entities that
cannot be pre-scripted into carefully designed workflows, things like
persistence/transaction expense can greatly influence the cost of
"aggressive sharing" which is an important aspect of many
blackboard-system applications.

-- Dan

RE: Blackboard Systems

Thx for very informative answer.
Does GBOpen have persistence/transaction facilities like Prevayler or RDBMS
?
How is the data stored long term ?

-----Original Message-----
From: owner-lisp-hug@lispworks.com [mailto:owner-lisp-hug@lispworks.com] On
Behalf Of Dan Corkill
Sent: Monday, August 06, 2007 9:12 AM
To: Vagif Verdi
Cc: 'Lisp Hug Lispworks'
Subject: Re: Blackboard Systems

Vagif Verdi wrote:

> Can you compare GBBopen with JavaSpaces ? What are the
> differences/similarities ?

GBBopen provides Common Lisp extensions that support blackboard-system
development.  GBBopen includes a memory-resident, object-based
repository with high-performance multidimensional proximity-based
search/retrieval.

JavaSpaces are best viewed as providing distributed shared memory with
additional features such as transactional integrity and failure handling.

Both GBBopen and JavaSpaces provide repositories with retrieval
capabilities.  GBBopen's repository is based on a
dimensional-abstraction mechanism (similar to the class of
range-retrieval/spatial data structures used in GIS systems) and
JavaSpaces is based on a tuple abstraction.  (Conventional RDBs are
based on table abstractions.)

JavaSpaces provide only the repository (distributed shared memory)
mechanism, while GBBopen includes lots of other capabilities needed by
blackboard systems (such as control-shell facilities).  These days, RDF
stores have become all the rage (the additional benefits/pitfalls of
those "restricted tuple" stores are for another discussion)...

>From far enough away, both GBBopen and JavaSpaces provide anonymous and
atemporal repositories (meaning that objects/tuples can remain in the
repository for a long time before they are used, allowing for
considerable flexibility in control/synchronization).  Of course, the
keys to performance in real-world application settings is all in the
details of the underlying approaches, their implementations, and how
they are used by applications.  For very loosely coupled software
entities, it hardly matters; for tightly collaborating entities that
cannot be pre-scripted into carefully designed workflows, things like
persistence/transaction expense can greatly influence the cost of
"aggressive sharing" which is an important aspect of many
blackboard-system applications.

-- Dan

Re: Blackboard Systems

Vagif Verdi wrote:

> Does GBBopen have persistence/transaction facilities like Prevayler or RDBMS ?
> How is the data stored long term ?

GBBopen does not have persistence built in.  One reason is that there is
no single persistence solution that is reasonable across the range of
applications in which GBBopen is used.  Trying to make everything
persistent or transactional may not be a good strategy when lots of
rapid "what-if" brainstorming is being performed.  GBBopen's repository
was designed to support different approaches to persistence & long-term
data storage including: no persistence, snapshots & journals,
object-level persistence (using facilities like elephant or
AllegroCache), conventional RDBs, etc., and all of these approaches have
been used in applications.  Out of the box, GBBopen provides only a
main-memory repository and support for saving/restoring snapshots &
partial snapshots of the repository.

The landscape in some high-volume situations seems to be changing as
well, moving away from disk-based persistence to net-centric
duplication/redundancy in situations when network throughput and
distributed access requirements make communication faster than disk
writing/reading.  An example of this from the JavaSpaces perspective
(where this thread began) is the GigaSpaces XAP enterprise data grid.

It makes one wonder if the days of disk-based persistence may be
numbered...?

-- Dan