Comments: Interesting problem, subset of the VO task setup. No task self-assembly component. Registries do not compose components. ACL provides a super set of their event-bus. No reasoning about component capabilities (a la trader), name assumed to indicate capability.
Hall,R., Heimbigner,D. et al., The Software Dock: A Distributed, Agent-Based Software Deployment System - Tech Rep, CU-CS-832-97,1997. (Go to Heimbigner's home page for this and related papers)
Comments: The problem as stated is interesting, and the premise (s/w whose components span multiple autonomous administrative domains, autonomy in component evolution) is valid also applying agents to the VO. The effort itself looks a lot like CORBA despite their vehement protests to the contrary (except that the proxy spec is derived by Java reflection, rather than IDL writing). Their ambassadors (equiv of proxies) do have some interesting differences from proxies. Ambassadors are explicitly created by negotiation between service providers and consumers. The usage contract may have temporal constraints (e.g may expire). There is an autoupdate design pattern built-in to their framework, whereby anytime an object changes its interface, all its ambassadors are automatically notified. There is some notion of state associated with ambassadors, although a compelling case is not made for why. There is a coordination language looks like an attempt to define a bottom-up ACL. Hard to figure out how they deal with dynamic interoperability problems differently/better than Corba.
See HADAS site:
Both Hadas and Software Dock show a fairly strong influence of agent ideas into the software engg community. Agent-based software engineering (i.e good design principles for constructing agent-based applications) may be a theme.
HADAS: A Network-Centric Framework for Interoperability Programming A Negotiation Model for Dynamic Composition of Distributed Applications
Comments: Separation of taskbots from userbots is useful, and allows the task algorithm to evolve independently of communication with the user. For example, userbots can incorporate new modalities of locating and/or communicating with the user (e.g login monitoring, audio communication w/user, paging etc.) without affecting the taskbot. Rather like the model-view paradigm, but for the agent world. They experienced some problems that I anticipated as well, in my e-mail prototype experiment. Folks will not like bots mucking around with their email. Their solution to allow bots to read but not modify e-mail was the one I gravitated to as the most tolerable.
There are some interesting points to SodaBot's component architecture. An agent is a task specification more than an object specification. Sections in an agent specify not only the code that is invoked when the agent is fired up, but also code sections that need to move to different sites to help the agent accomplish the task. The agent spec. is like a pod, that bursts and scatters little sub-agents to other sites. There is a quaint bootstrap (self-installation) design pattern which is part of SodaBot, whereby elements of this pod are distributed to remote sites by exceptions raised in remote BSAs, which causes them to dynamically load sections from the caller agent to fulfill their role.
Example: Let's say that there is an OBJS tech report site, and we need C/D/S to signoff for anything to be published here. Suppose there is an authorize agent that encapsulates this behavior, an instance of which I have on my site. When I invoke the local authorize agent with "authorize trader tech report X", it sends a message to C/D/S'es Sodabot-BSA to the effect "invoke the grant-permission section of C/D/S'es authorization agent". If C/D/S don't have an authorize agent in their space, their Sodabot-BSA sends back a message to my agent saying "gimme the code for grant-permission etc." (the "pull" or bootstrapping).
Comment: I like this notion that agents are distributed objects that have some self-installation smarts buried in them. Agent = object+software-distribution-strategy. Software distribution strategy is different from mobility. The former is a policy , the latter a mechanism.
Sodabot Home Page - http://alpha-bits.ai.mit.edu/people/sodabot/