[Agentfactory-developer] Re: SQL Service

[Rem C. <rem...@uc...>]

Okay,

Donal, I accept your point on the database querying versus message 
passing, however personally i think that this has a number of key drawbacks:

1. loss of robustness (as mentioned by Rob)

2. Security of data - what if we don't want an AMS to have access to ALL 
the data held by a SuperDF? i.e. we may, in the future, want to apply 
domain based security policies that constrain who an agent can contact etc.

3.  It forces all developers to use a database - this would seem to be a 
sizable overhead, and would make installation somewhat more difficult - 
they not only may not use the service (as rob points out), they may not 
use agent factory either.  This is a SERIOUS issue, given we are 
starting to get increased exposure!

While I understand Robs "Against" point that developers may not use the 
SQL based Super DF, I would argue that developers will use it if there 
is an advantage to using it.  I perceive that such an advantage could be 
gained through the development of tools to support domain-oriented 
security policies, visualisation tools, etc.

Finally, I think that we should use the sourceforge mailing lists for 
these discussions as they allow us to share our ideas and thoughts with 
other developers who may find these topics of interest...  As a result, 
I have also CC'd this email to the agentfactory-developers mailing list!

Rem

Robert Ross wrote:

> Hey lads,
> Thanks a million for the replies. I now have a much better 
> understanding of the issues. I'll just list out some of my thoughts, 
> but bare in mind my naivety when it comes to superDF issues.
>
> Points on superDF architecture:
>
> * While I completely take Donal's point about communication overhead 
> in passing SuperDF information between multiple SuperDFs, I have a 
> problem with using one, or a small number of, superDF databases. This 
> introduces a point of critical failure into the entire MAS -- surely 
> not a good thing for a distributed system. If for any reason that 
> database because inaccessible, then all multi-platform applications 
> dependent on that database are going to have issues. I'm not saying 
> that a single or small number of databases isn't a possibility, I'm 
> just saying that we have to consider this introduction of a point of 
> critical failure.
> * A second point on the centralized database approach is that for 
> practical or security reasons, many developers may need to create 
> multi-platform applications which are not dependent on a centralized 
> superDF database.
>
> Points on superDF implementation:
> Now, as to whether a hashtable implementation of the superDF backend 
> has to be introduced, well that is just an issue to pros and cons:
> FOR:
> * Agent Platform remains lightweight, with no additional constraints 
> for multi-platform implementations
> Against:
> * Multiple superDF backends have to be maintained.
> * Newcomers would be unlikely to use SQL based superDF (or a 
> centralized superDF)
>
>
> thats all for now,
>
> rob
>
>
>
> Donal O'Kane wrote:
>
>> Rob,
>>
>> 2 is easier to answer, this is my fault I was debugging agentfactory 
>> on an ipaq and must have forgotten to uncomment the startup lines for 
>> the system agents. Sorry.
>>
>> 1 is a bit harder.
>>
>> Pro for database:
>> A single database gives all the superDF agents the ability to pool 
>> their  naming knowledge and so they can easily query from the entire 
>> set of registered agents and can avoid costly messaging of all 
>> superDF's.
>>
>> Initially the plan was to have only 2 superDF's running, on servers 
>> here in the department, and all agent platforms would connect to them 
>> (unless they were quick tests and just wanted to create their own 
>> local superDF).
>>
>> But the number of superDF's is scalable, and the central database 
>> seems to be the best approach form a message cost point of view.
>>
>> Cons:
>> Well .. you need to run a database, if any user want to run a superDF 
>> they need a database ... OR they need to have a url, username and 
>> password for an already existing agent factory database .... which is 
>> how it most likely would be., agentfactory.com could run an sql 
>> database and get new platform admins to register to get a database 
>> username and password ..
>>
>> pros for hashtables:
>> No worries with databases
>>
>> Cons:
>> Increased communication costs and query complexity.
>>
>> Notes about the hashtable approach:
>>
>> The lightweight hashtable approach means that upon receiving a new 
>> registration the superDF must either
>> A: send this registration to all other superDF's (so that all 
>> superDF's contain a full list of all registered agents)
>>
>> or
>>
>> B: the superDF must check to all other superDF's to ensure that the 
>> newly registered agents name is unique
>>
>> Also their must be methods that will allow a superDF to poll all 
>> other superDFs to see does a queried agent name exist, which with a 
>> small number of superDF's is ok but if you want to scale up, this can 
>> become a huge overhead of communication.
>>
>> Is my opinion anyway ... Sorry about the horribly written mail, it 
>> was a bit of a brain dump, hope it makes sense.
>>
>> Donal
>>
>> Robert Ross wrote:
>>
>>> Hi Donal,
>>> I cc'ed Rem on this, because it is more of a topic for group 
>>> discussion then the usual code/CVS things.
>>>
>>> Anyway, my first question is:
>>> 1. Are SQL databases really a good idea for the SuperDF?
>>> I admit that I know little about what range of information the 
>>> SuperDF does usually have to retrieve and store, but requiring any 
>>> 'connected' Agent Factory platform to run an SQL database sounds a 
>>> bit harsh to me. I understand that there might be an argument for 
>>> developing a fall-back to Hashtables when SQL is not available, but 
>>> this sort of approach means that the light weight hashtable approach 
>>> is not developed sufficiently.
>>>
>>> 2. Why were the 
>>> agentManagementSystem.resumeAgent(<agent>.getName()); lines 
>>> commented out of the AgentPlatform.createSystemAgents() method? Is 
>>> this part of some new AMS control model or something? Because, for 
>>> me it just meant that my system agents never started.
>>>
>>> rob
>>>
>>> Donal O'Kane wrote:
>>>
>>>> Hi,
>>>>
>>>> Sorry about the late reply, this is an error I have yet to fix (ie 
>>>> if you do not have an sql database running use hastables or an 
>>>> arraylist to store the data in.
>>>>
>>>> So to run a superDF currently you must configure an sql server .. 
>>>> the superdf will setup the correct table for you if it does not exist.
>>>>
>>>> (note because the superdfs all share the one database currently, 
>>>> you have to either drop or empty the table before you start the 
>>>> superdf (or else some agents will already be registered in the 
>>>> database)
>>>>
>>>>
>>>> The line you need is :
>>>>
>>>> SERVICE common.sql_service.superDFDatabase 
>>>> com.agentfactory.plugins.services.database_service.SQLCommandService 
>>>> jdbc:mysql://localhost/agentfactory agentfactory agentfactory 
>>>> agentregistry
>>>>
>>>> where the parameters are:
>>>>
>>>> a) jdbc:mysql://localhost/agentfactory
>>>> # The URL to the database (here agentfactory is the dtabase name on 
>>>> the server localhost
>>>>
>>>> b) agentfactory
>>>> #The username for the database
>>>>
>>>> c) agentfactory
>>>> #The password for the database
>>>>
>>>> d) agentregistry
>>>> # An optional argument for the SuperDF, It tells the 
>>>> SQLCommandService to setup the agentregistry table.
>>>>
>>>>
>>>> hope this helps
>>>>
>>>> Donal
>>>>
>>>> Robert Ross wrote:
>>>>
>>>>> hey,
>>>>> thanks, it's compiling now. Now, as for running it, what line do I 
>>>>> need to add to the platform configuration file for the SQQL 
>>>>> service. I'm getting an error that the SuperDF failed to bind to 
>>>>> common.sql_service.superDFDatabase.
>>>>>
>>>>> I'm guessing that the line should be something like:
>>>>> SERVICE 
>>>>> com.agentfactory.plugins.services.database_service.SQLCommandService
>>>>> But, does it need parameters?
>>>>>
>>>>> cheers
>>>>>
>>>>> rob
>>>>>
>>>>>
>>>>> Donal O'Kane wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I think i have fixed that now, really sorry about that I was 
>>>>>> heading to a wedding early on Friday and spent a frantic 20 mins 
>>>>>> here trying to get all of my new stuff committed. I hope it work 
>>>>>> now, I think it was just the one class, DomainDescription that 
>>>>>> was causing problems.
>>>>>>
>>>>>> Donal
>>>>>>
>>>>>> Robert Ross wrote:
>>>>>>
>>>>>>> Donal,
>>>>>>> I noticed that you've checked in most of your stuff -- thanks. 
>>>>>>> But, are you finished? cause I still have two compilation bugs; 
>>>>>>> namely:
>>>>>>>
>>>>>>> The method containsPlatform(String) is undefined for the type 
>>>>>>> DomainDescription    SuperDFModule.java 
>>>>>>> AgentFactory/src/0.2-branch/com/agentfactory/plugins/core/fipa/superdf/module 
>>>>>>> line 92    15 April 2005 13:29:27
>>>>>>>
>>>>>>>
>>>>>>> The method newPlatform() in the type DomainDescription is not 
>>>>>>> applicable for the arguments (String)    SuperDFModule.java 
>>>>>>> AgentFactory/src/0.2-branch/com/agentfactory/plugins/core/fipa/superdf/module 
>>>>>>> line 111    15 April 2005 13:29:27
>>>>>>>
>>>>>>>
>>>>>>> Hope this helps
>>>>>>>
>>>>>>> rob
>>>>>>>
>>>>>>> Donal O'Kane wrote:
>>>>>>>
>>>>>>>> will do now
>>>>>>>>
>>>>>>>> sorry still getting to grips with cvs
>>>>>>>>
>>>>>>>>
>>>>>>>> oh and I checked out the agent platform and hard coding of the 
>>>>>>>> database service ... I already had removed the coded for that 
>>>>>>>> .. just had not removed the initialisation of the object.
>>>>>>>>
>>>>>>>>
>>>>>>>> Donal
>>>>>>>>
>>>>>>>> Robert Ross wrote:
>>>>>>>>
>>>>>>>>> Hey Donal,
>>>>>>>>> Sorry to bug you again, but I been having some problems 
>>>>>>>>> merging my code back into the tree. Specifically, it seems 
>>>>>>>>> that the database_service plugin has not been added to CVS, 
>>>>>>>>> thus causing compiler errors for the SuperDFModule.
>>>>>>>>>
>>>>>>>>> Could you check to see if it seems to have been added to CVS 
>>>>>>>>> from your end?
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>>
>>>>>>>>> rob
>>>>>>>>>
>>>>>>>>> Donal O'Kane wrote:
>>>>>>>>>
>>>>>>>>>> Em .. my bad ..
>>>>>>>>>>
>>>>>>>>>> its currently hard coded so I could get it working fast ...
>>>>>>>>>>
>>>>>>>>>> A lazy way to do it i know, but i'm in the process of fixing it.
>>>>>>>>>>
>>>>>>>>>> Donal
>>>>>>>>>>
>>>>>>>>>> Robert Ross wrote:
>>>>>>>>>>
>>>>>>>>>>> Hey there lads,
>>>>>>>>>>> Listen, I'm a little confused about this addition of an SQL 
>>>>>>>>>>> service to the Agent Factory platform. Or, more to the 
>>>>>>>>>>> point, I'm a bit concerned over how it was added to the 
>>>>>>>>>>> platform.
>>>>>>>>>>>
>>>>>>>>>>> I've no doubt that an SQL writing/querying service is very 
>>>>>>>>>>> continent for a number of agents, and no doubt a platform 
>>>>>>>>>>> service plugin is ideal for this. However, why has the 
>>>>>>>>>>> 'plugin' been hard-coded into the agent platform (c.f. 
>>>>>>>>>>> AgentPlatform.java)?
>>>>>>>>>>>
>>>>>>>>>>> The MTS and RCS are both hard-coded services, and I can 
>>>>>>>>>>> understand that since they are both provide 'core' 
>>>>>>>>>>> functionality. I'm not so convinced about SQL access; if we 
>>>>>>>>>>> just add services ad-hoc to the platform it's going to bloat 
>>>>>>>>>>> and become a pain in the ass to maintain.
>>>>>>>>>>>
>>>>>>>>>>> Anyway, thats my point of view, but naturally I could be 
>>>>>>>>>>> wrong. What do the two of you think?
>>>>>>>>>>>
>>>>>>>>>>> cheers
>>>>>>>>>>>
>>>>>>>>>>> rob
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
------------
Dr Rem Collier
Room A1.02, Department of Computer Science,
University College Dublin, Belfield, Dublin 4, IRELAND
tel: +353 (0)1 716 2465
www: http://agentfactory.sourceforge.net