> From mani@cs.caltech.edu Tue Oct 8 16:05:42 1996
> Subject: Aglets
>
> Tim Collins from Novell called and said that IBM has a project very
> relevant to us. The program is called aglets (for agent-lets?) and Tim
> thinks was developed in Japan. They have a notion of sessions and
> session archetypes (star: master-server,...). We should look this up on
> the web. Session archetypes is almost exactly what we are doing, but
> there's bound to be some differences.
According to http://www.ibm.co.jp/trl/aglets/
> Think of the Internet as a distributed, massively parallel supercomputer
> that connects information repositories, data bases, intelligent agents,
> and mobile code. Imagine sending your own personalized agents to roam
> the Internet. They will monitor your favorite Web sites, get you the
> ticket you couldn't get at the box office, or help you to schedule
> meetings for your next overseas trip. Sounds like science fiction?
> Maybe, but at IBM Research and Development we decided to do something
> about it. First, we invented the aglet (an agile little agent written in
> the Java programming language). Then we created the Java Aglet API
> (JAAPI) and the Agent Transfer Protocol (ATP) that made the aglet secure
> and mobile on the Internet. Now we have made all this, including
> reference implementations, publicly available on the Internet as Aglets
> Workbench.
Then, according to http://www.ibm.co.jp/trl/aglets/whitepaper.htm
> Aglets Workbench is a first-of-its-kind visual environment for building
> network-based applications that use mobile agents to search for, access,
> and manage corporate data and other information.
Next, at http://www.ibm.co.jp/trl/aglets/aglets/JAAPI-whitepaper.html
> Distributed Meeting Scheduling
>
> An aglet can be dispatched by a client to arrange a meeting. The agent
> will use an itinerary to visit other hosts (meeting participants) in
> order to negotiate an acceptable meeting schedule. At each host it will
> accommodate the host's calendar system. When negotiation has finished
> the aglet will notify all participants of the meeting time and place.
>
> The meeting scheduling takes place in a truly heterogeneous and
> distributed fashion with no central calendar system. Multiple mobile
> clients can have meetings arranged this way, since not all participants
> need to be connected to the network at the same time. The meeting
> scheduling aglet acts like an electronic secretary.
Whoops. And...
> Auction
>
> A client can dispatch an aglet that offers an item for sale. Other
> clients can dispatch aglets that are in search for specific items.
> When such aglets meet they may bargain. "Smart" aglets may make a good
> bargain and less clever aglets may make less good bargains.
>
> There is no central auction or marketplace server. Commerce aglets may
> meet on any host. There is no fixed algorithm for accepting or
> rejecting a bid. It is all up to the individually programmed aglets.
However, it doesn't look like they have any notion of "session" on their
web site as a method of structuring, designing, implementing, and
reasoning about these applications. At least, not from their web site.
In fact, all that's there is an API at
http://www.ibm.co.jp/trl/aglets/aglets/api-doc/Package-aglet.html
> Class index:
> Aglet
> AgletIdentifier
> AgletProxy
> Arguments
> Itinerary
> Message
So, to summarize, aglets are good for several reasons:
1. They are implemented entirely in Java, meaning that
they get all the good things from Java like portability.
2. They allow applications to have swarms of aglets
(mobile agents) that transfer data.
3. They are useful for *some* network-based applications.
4. They set up a postcondition Itinerary object as to where each
aglet should go after a session.
5. You can clone aglets.
6. They have a proxying service for aglets that controls and
limits direct access to aglets.
Aglets are no good for several reasons:
1. They are implemented entirely in Java, meaning that
they get all the bad things from Java like security.
2. They have no concept of sessions or virtual organizations
as we know them. What most resembles our "sessions" are in a
sense just applications that only can take place between aglets,
which means applications can only occur between mobile agents that
use the aglet API.
3. They're based on IBM's object model, which is different
from standard object models.
4. They're implemented all in TCP -- which means the ports get
used up fairly quickly.
5. Very data-oriented as opposed to infosphere djinns, which can
be used for just about any task.
6. Requires RMI to work -- thus restricting the communication model.
7. How do you keep track of the aglets you've cloned and spawned?
8. Their messaging scheme allows both synchronous and asynchronous
message passing. Why would you want that?
9. Commercialization possibilities -- IBM might keep people
from looking at the source.
Final analysis:
We can learn from them, but we shouldn't use them. Joe's downloading
the new release to play with it.