System Summaries

Venu Vasudevan
Object Services and Consulting, Inc.

Index

 The Software Dock (U. of Colorado - Heimbigner and Wolf)

Deploying ((de)installing, (re/de)configuring) componentized software across multiple sites is a complex config mgmt problem. Addressing it requires: They propose the software dock architecture as a solution. The automated deployment architecture uses agents and docks. Docks are things that provide agents a platform-neutral API for querying and manipulating a site (e.g API to query a customer m/c's registry) and prevent agents from doing damage. Collectively, the docks provide a federated registry. Agents are components (potentially mobile) that perform specialized tasks (e.g detecting that a customer does not have latest release of X, travelling to the site to query the dock, installing software Y). A proprietary event bus allows agents at one site to subscribe to events at other sites.

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)

    • Hadas (Technion U, Israel)

    The net allows us to construct systems using large numbers of globally distributed third-party components.  However, these components live in multiple administrative domains and may change their designs autonomously.  Needed is a system that allows you to become aware of available components, compose them into a task, negotiate with the domains for component usage, or for uploading a component to their domain to interact with their services. Hadas aims to provide a framework for such "just-in-time" composition and deployment. It claims to provide a framework for interoperability programming, whereby the system adapts to run-time interoperability issues.

    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:

  • HADAS: A Network-Centric Framework for Interoperability Programming
  • A Negotiation Model for Dynamic Composition of Distributed Applications
    • 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.

    AT&T's VisitorBot

    An implementation of an agent-based system to automate meeting scheduling (specifically, scheduling a visitor's meetings with AT&T researchers).  There is a separation between the scheduling agent (visitorbot) and a collection of GUI agents (userbots). The visitorbot runs the scheduling algorithm (e.g. using integer programming). Userbots know how to find and communicate with a particular user, e.g fax/page the user if he is not logged in. Bots communicate by sending structured messages to each other via e-mail. The visitor/user bot communication language has 3 primitives - pick a choice of good meeting time, help, here is some info about meeting (i.e. not a general purpose ACL). Their wisdom on what distinguishes a bot from other programs (in decreasing order of persuasiveness from my point of view) : more complex communication patterns, some notion of time and periodicity, autonomy, platform-independence, robustness, responsibility.

    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.

    Sodabot (Coen, MIT)

    SoadaBot provides a toolkit that is useful in building personal online assistants(electronic secretaries) and application agents (coordinate tasks or information transfer amongst people). SodabotL is a Perl-like language for defining agent semantics.  SodaBot-BSA  is the operating environment (sandbox) on each machine (rather like Heimbigner's dock)  that executes SodaBotL programs. The bus used by agents to communicate/move is layered over e-mail.

    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/