From mingfang at mac.com  Sun Oct  7 00:39:37 2007
From: mingfang at mac.com (Ming Fang)
Date: Sun, 7 Oct 2007 00:39:37 -0400
Subject: Should Cougaar built-in services be implemented as plugins?
Message-ID: <01FFEF70-FEF1-4B96-86BA-8D4408AA4A59@mac.com>

Hi,

I'm just beginning to explore Cougaar by reading the Architecture and  
Developer guide.
I like the concept of the blackboard and plugins.
However I was curious as to why many of the built-in "services" are  
not themselves plugins.
Instead there exist a huge service framework with things like binders  
etc.
IMHO, the blackboard and plugins concept is great and can be used for  
implementing all the services.
In fact things like Binders for security won't be needed in that case.
I'm sure there was a good reason for this design, I'm just wondering  
what that reason was.

Thanks,
--ming


From jzinky at bbn.com  Mon Oct  8 10:16:24 2007
From: jzinky at bbn.com (J Zinky)
Date: Mon, 08 Oct 2007 10:16:24 -0400
Subject: Should Cougaar built-in services be implemented as plugins?
In-Reply-To: <01FFEF70-FEF1-4B96-86BA-8D4408AA4A59@mac.com>
References: <01FFEF70-FEF1-4B96-86BA-8D4408AA4A59@mac.com>
Message-ID: <C909B1F7-E913-4206-A1F9-8F7F780FE5B5@bbn.com>

The Cougaar agent system really has two parts, the Agents and the  
Environment. "Agents sense and act on the Environment"
1) Agents implement the application business logic. Agents manage  
both the local state for their role and coordinate with other agents  
to create the whole business application.
2) The Environment is the encapsulation of the external world. The  
Environment manages both the cyber-resources and interfaces to  
external services.

The job being done by these two layers have radically different  
system properties and in the end they need different system  
architectures.
1) An Agent captures the application's business logic (typically rule- 
based and asynchronous), the code is written for flexibility, and  
processing is data driven. Agent implementation lends itself to a  
blackboard architecture.
2) The environment interfaces to legacy libraries (typically  
synchronous or at best callback based), the code is tightly written  
for efficiency, and processing is event driven. The Environment  
implementation lends itself to a Service Oriented Architecture (SOA).  
Note the Cougaar environment does NOT implement a distributed SOA (as  
advocated by web services). In Cougaar SOA, all the services are  
local to the Node.

Cougaar is successful as a middleware framework, because it tailors  
the programming interfaces to the different needs of these two  
layers. Cougaar is not dogmatic, advocating the same academic  
technique for all situation (no matter how contrived).   Cougaar is  
pragmatic, trying to use the right tool for each situation.


On Oct 7, 2007, at 12:39 AM, Ming Fang wrote:

> Hi,
>
> I'm just beginning to explore Cougaar by reading the Architecture and
> Developer guide.
> I like the concept of the blackboard and plugins.
> However I was curious as to why many of the built-in "services" are
> not themselves plugins.
> Instead there exist a huge service framework with things like binders
> etc.
> IMHO, the blackboard and plugins concept is great and can be used for
> implementing all the services.
> In fact things like Binders for security won't be needed in that case.
> I'm sure there was a good reason for this design, I'm just wondering
> what that reason was.
>
> Thanks,
> --ming
>
> _______________________________________________
> Cougaar-developers mailing list
> Cougaar-developers at cougaar.org
> http://cougaar.org/mailman/listinfo/cougaar-developers