|
Can I run Aglets on Java 2 (JDK1.2 +)?
Yes. However, getting Aglets working with Java 2 is somewhat tricky. Your best bet is to download the Aglets 1.2 Dev file release from the SourceForge project and follow these instructions.
Are there any archives of the Aglet Mailing
list?
The current Aglet mailing lists are archived on SourceForge. An archive
of an earlier aglet list exists at http://www.kdel.info.eng.osaka-cu.ac.jp/~aglets/archive/.
I need some help! What should I do?
Just a quick note about asking for help with Aglets. If you do have
a problem, try to include as much information as possible so that those
of us who might know the answer can get straight to the root of the
problem.
You first recourse is read this FAQ and the FAQ at the Aglet
site.
If you do not find your answer there and decide to post to one of
the mailing lists, please make sure you include as much information as
possible. For example:
OS: Win98
JDK version: IBM 1.1.7
ASDK version: 1.0.3
AP: E:\Aglets1.0.3\public
AEP: E:\Aglets1.0.3\public
CP: E:\jdk1.1\lib\classes.zip;E:\Aglets1.0.3\lib\aglets.jar
Also, if you have an error, try to cut and paste the relevant part,
and any code snippets that you think might help. We're not mind readers
;) Also, an explanation of what you are trying to achieve might be
useful too.
Are there any public aglet servers I can send my aglets to?
No. However, there is work underway to establish a network of public
aglet servers using software available
here. If you have a publicly-addressable server free, you are a
candidate for starting the network!
What's this 'HOME' variable all about?
HOME is where the ASDK stores its properties files, logs and the
like. This is usually a hidden directory called .aglets. When you try
to launch Tahiti you may get a message saying:
Please set HOME environment variable!
You should set this variable in the same place as you set the rest of your
environment variables, ie. the same place you set AGLET_PATH. On a UNIX system
this is probably already set by default and should correspond to the location
of your home directory. However, if you wish to launch Tahiti from a script
then you could set the variable with:
setenv HOME /path/to/where/you/want/home
On a Windows system the HOME variable might not be set by default.
Once again, set this where you usually set your environment variables,
usually the file called autoexec.bat. For example:
set HOME=%AGLET_HOME%
set HOME=%JDK_HOME%
set HOME=C:\
OK, I've got Aglets working, now where can I find out some more information?
Well, Aglets comes with several useful documents which are worth a
read. They are found in the AGLET_HOME/doc directory. Worth a read is
the specification doc, which although is not complete has some useful
information.
If you are just starting out with Aglets then why not take advantage
of this tutorial from Jerry Pearson. It shows you how to get the
HelloAglet running, and will take you from start to finish with good
advice.
However, if you want some in-depth information then you obtain a copy of
Danny and Mitsuru's book, "Programming and Deploying Java Mobile Agents with
Aglets." This is the essential guide to developing mobile agents in java, and
contains masses of code examples and snippet
When I try to create Writer-Aglet I get a Security Exception?
If you get the following sort of error then it is related to aglet
privileges:
com.ibm.aglets.AgletsSecurityException: checkPropertyAccess:user.name
at com.ibm.atp.agentsystem.aglets.SimplePrivilege.checkPropertyAccess(filename.java:##)
at com.ibm.atp.agentsystem.aglets.AgletsSecurity.checkPropertyAccess(filename.java:##)
Writer needs to access resources that are normally blocked. You can
fix this problem by altering the privileges assigned to your Aglets.
Add the following line to your 'trusted' file which can be found in
$HOME/.aglets/security.
property.access.user.name=true
You should add this to the 'untrusted' file also. For more detail,
read the "Security" section in the aglet specification which can be
found in the doc %AGLET_HOME%/doc/spec10.html#Security
When I try to access a local file with my aglet the server throws java.jang.SecurityException although all the necessary permissions are set?
There is a little known feature of Tahiti (OK, call it a bug ;) that
when Tahiti is installed, it creates a security domain "file:///*/" and
all permissions are given to this domain. It should mean that any aglet
having its codebase on this machine can access any file. But it's not
true. You have to create another security domain describing exactely
the path to the codebase of the aglet, grant necessary permissions and
then it works.
When I try to get my Aglet to access the file 'test.txt' I get a FileNotFound exception?
When attempting to open a file, any path to a file is relative to
the directory from which the Aglet was created. Therefore, the solution
is that you should specify the filename's ABSOLUTE path (full pathname)
like this:
FileInputStream inputStream = new FileInputStream("c:/test.java"); (UNIX)
FileInputStream inputStream = new FileInputStream("c:\\test.java"); (PC)
Can I run Tahiti with no net connection on Win95?
Normally YES, but if you run into troubles with a standalone
Win95-PC then follow this procedure:
- Locate the file 'hosts.sam' in the "WINDOWS" directory and rename it to 'hosts' (it is an editable ASCII-textfile).
- Open this file with an editor and change the line with the loopback-address '127.0.0.1' to your desired hostname.
It can either be a single name, e.g. "fossy", or a Fully Qualified
Name (FQN) like 'fossy.muppet-show.com'. Names are case-insensitive,
columns are separated with tabs. The 'hosts' file is used for local
resolving of IP-hostnames(IP-addresses) and the first corresponding
line will be used.
In the example below 'fossy.muppet-show.com' will be the result. The
other two lines are just additional examples.
127.0.0.1 fossy.muppet-show.com # fossy (this is comment!!)
127.0.0.1 fossy # fossy
127.0.0.1 localhost # fossy
- Save the file in the "WINDOWS" directory.
- Start Tahiti with "-resolve" option -> local 'hosts' file is used for name-resolution.
(TIP: With the correctly configured 'hosts' file on your standalone Win95-System also the JDK-Debugger works well.)
I want one of my Aglets to connect to a database but when I do I get an error?
com.ibm.aglets.AgletsSecurityException:
Illegal File Access: Write JdbcOdbcSecurityCheck (etc)
You need to enable JDBC as a valid action for your aglets. In
Tahiti, choose the following menu option: Tools->Security Prefs. Then
select Trusted in the left hand list. Select the drop down list on the
right, (probably showing File System). Choose Others. Toggle on Enable
JDBC.
This will allow you to use JDBC for trusted aglets. You should look
into what this really means. You can find out more from the security
documentation. If you don't care, enable it for Untrusted aglets
too.
I want to send my aglet around to lots of different hosts and to pop up a window at each host, but when I try nothing happens, or I get an exception
A permission to create top level window
(java.awt.AWTPermission("showWindowWithoutWarningBanner")) is given to
any aglet in default aglets security policy. If you want to modify
security preferences, do the following instructions on every host where
your aglet will visit.
In the Tahiti GUI
- Choose Options
- Choose Security Preferences
- Select Code Base (generally, "atp://*:*/", or all if required)
- Select "Window" in pull-down menu
- Write "showWindowWithoutWarningBanner" in Name field
- Push "add" button
- Push "OK" button
- Select "Reboot" or "Shutdown"
Add the following lines into files "aglets.policy".
// window
permission java.awt.AWTPermission "showWindowWithoutWarningBanner";
Why would not my stand-alone server take my environment variables into account?
This is a feature of the stand-alone servers, which is they do not
take the Aglets related environment variables into account by default.
So one must not forget to explicitly put the AGLET_PATH and
AGLET_EXPORT_PATH on the java command-line when launching a stand-alone
server (as far as I know, at least).
For example under unix, if your server is called
StandAloneServer:
java -Daglets.class.path=$AGLET_PATH \
-Daglets.export.path=$AGLET_EXPORT_PATH StandaloneServer
Another solution is to include it in the code of the server, with
calls to the java.lang.System.setProperty() method. In the server code
you should then have:
{ ...server main... }
Properties props = System.getProperties();
props.put( "aglets.class.path", );
props.put( "aglets.export.path", );
System.setProperties( props );
{ ... }
Can an Aglet perform SNMP operations?
Yes - an aglet can perform SNMP operations by using a Java class
that provides SNMP operations and that can be serialized. A good
package to look at is jmgmt - it is small, straightforward, and has all
source included. It is available from
http://i31www.ira.uka.de/~sd/manager/jmgmt/
Good overviews of various packages can be found at:
http://www.mindspring.com/~jlindsay/javamgmt.html
http://wwwsnmp.cs.utwente.nl/software/pubdomain.html
There are a few things to watch out for with the various packages.
Some of the packages are sensitive to the version of the JDK you are
using - not just major revisions like 1.0 to 1.1 but minor ones like
1.1.5 to 1.1.7. Some only work with Java2 - so you can't currently use
them from an aglet. Some of the packages use threading- and you have to
be careful when you serialize agents that use threads.
The other big restriction on some of the packages are that they have
a commercial license- even if you are doing research. You are sometimes
limited in the number of active connections, distribution of the code,
etc...
How can an Aglet be used as a HTTP Server?
There are at least a few options. A quick and easy way is to look at
the http example shipped with the AWB. The path to the sample is:
(AGLETS DIR)/public/examples/http/WebServerAglet.java. There are a few
restrictions to watch for with this method: you can only have one aglet
"listening" at the address associated with the context- for example if Tahiti was running at atp://aglet.server:434 - you can have one aglet receive the messages from the HTTP address http://aglet.server:434/aglets/default/test/index.html
You must also set the options in Tahiti as specified in the
comments. If you are coding/adapting the sample - make sure to include
the line:
getAgletContext().setProperty("name.test", getAgletID());
As this is how Tahiti identifies the aglet to forward the HTTP
request to.
Another option is to look at using Fiji. The disadvantage is that
the status of Fiji is uncertain right now. Another option is to look at
finding/coding Java classes to listen for incoming HTTP requests. There
are quite a few HTTP servers written in Java out on the web. Depending
on the requirements for the web server - ie response time/threading/etc , there are a few different servers to use.
A couple of things to watch out for are threading (can cause
problems when you dispatch aglets) and non-serializable code. If a
class used by an aglet has non-serializable code - then your aglet will
throw an exception on may of the aglet operations. There is a good
discussion of some of these issues in Chapter Nine of the aglets book.
Can an Aglet work with other Servers (HTTP, FTP,etc)?
There are a few aspects to communicating with other servers. For
illustation- assume a simple client/server type model. A connection can
be a done as a server or a client. Often the requests follow a specific
protocol or API. A server responds to requests from a remote
connection, and a client connects to a remote server with a request. An aglet can act as a HTTP server at a specific address by using the WebServerAglet exampe shipped with the AWB.
An aglet can really implement almost any server protocol provided
that it has classes available and they are compatible with Aglet
features. (ie like serialization) If you want to connect to a remote
server as a client- you can code an aglet to send the specific client
requests according to the specific protocol. The classes must again be
compatible with Aglet features (ie serializable) So - if you wanted to use an aglet as a HTTP client, you would use a class that provides HTTP commands or connection capabilities. A good starting point would be the URL classes in the JDK. They can be used by adding:
import java.net.URL; import java.net.URLConnection;
to your user aglet. A good JDK reference will have some examples.
There are also other issues with using Aglets for more advanced
operations - like setting the security policies, verifying the DNS,
etc.
How does the AWB determine the hostname?
The hostname is determined by using the system name services or DNS.
The AWB uses the default services and naming provided by the specific
system to resolve hostnames... There are usually two main forms of a
hostname. The long name is fully qualified with the domain while the
short name is just the hostname.
If the aglet is only receiving a short name from the DNS - then this
is the address that it will use. When the AWB queries the DNS (done
internally - you never see this from a user aglet) - it uses what has
been returned. Depending on the environment, some DNS setups return the
fully qualified name (host.x.x.com) or just the plain hostname (host and no .x.x.com).
There are at least of couple of factors to start with:
- version of the AWB
- operating system running the AWB
- DNS resolution order
For the version of the AWB when you use the -resolve and -domain
with AWB1.1beta you have to set these in a properties file as outlined
in the documentation. The operating system is a key factor. The local
files and DNS server setup is completely different on Windows than an
Unix setup. Even between Unix systems the setup varies.
The DNS resolution order is also important. I will give an example
with AWB1.1beta on Linux which will be different if you are using
another platform/version in /etc/hosts I have:
1.1.1.1 machine1 machine1.xbill.com
in /etc/nsswitch.conf I have: hosts: files dns nis
I do not have -resolve or -domain in my aglets startup script or
properties.
If I run a test aglet that uses:
getAgletContext().getHostingURL()
I will get the simple name. (machine1)
If update my /etc/hosts file to:
1.1.1.1 machine1.xbill.com machine1
and restart the AWB. I will get the Fully Qualified name
(machine1.xbill.com)
If I switch my lookup order in the nsswich.conf to:
hosts: dns nis files
And restart the AWB - I will get the fully qualified name - since I
have my DNS setup to give me the full name first.
So what you may be able to do is code a very small test aglet that
just prints out the results of getAgletContext().getHostingURL() and
then test changes on your system DNS files. (ie update the properities
file, then test the hosts, then test the resolution, etc) The specific
files and order will vary on the OS used so the files may not be exactly the same as my example on Linux.
Can an aglet use SSL?
For some good background information on the security model check the
aglets book in Chapter 10.
For AWB1.1b1 - there is some further information in the
documentation shipped with the code. The file (AGLET
HOME)/doc/relnotes11b1.html has some updates about the security model.
Using SSL along with the SDK and your agents seems to be
straightforward - just find an open source SSL java implementation and use the classes.
On further research it looks like it is a more complicated issue
that it first seems. It turns out there are several issues - licensing
SSL technology, open source java classes for SSL, and Aglets SDK
integration.I did a quick search on the web for some related web
sites:
It looks like there was no openly available SSL implementation in
Java (ExpresSSL aims to do this - but they had no code available)
Although Sun includes SSL in the Java Web Server- the classes are not
available for standalone use. For some of the other resources- they are
targeted at JDK1.2 (java2) which is not supported with the AWB.
The other kits seem to be commerical- so you are subject to
licensing costs/distribution/ other issues. For other implementations-
they are currently coded in C/C++ - so it could be possible to call
them but there would be some tricky technical issues.And finally - even
when an open source SSL java toolkit is available- there may be problems using it along with the AWB. Many of the low-level classes used to implement the AWB are not available as source code - so you may not be able to extend the base classes to include SSL.
You may be limited to coding your own aglets to use SSL explicitly
and handle the encryption/decryption in the user aglet code.
How is memory used when a message is sent between two Aglets?
For the basic case -where you are not using threads or the parallel
message handling- Aglet B should block and queue the incoming messages
from Aglet A, and then delivery them sequentially. A good diagram of
this scenario is on pages 104-105 of the aglets book. You may have to
experiment with the exact mechanics of the replies - if you know that Aglet B will send the responses sequentially you can match the replies to the requests.
For the resource questions- you can get a basic picture of the
memory used at each server by using the Tahiti option "View" and then
"Memory Usage". Some basic information is also available from the
Virtual machine, but you will have to check for the exact API calls.
What are the internal operations involved with an Aglet?
For the transport mechanism- the high level description is in the
API documents on the Aglets Web site. The low level implementationof
these mechanisms may or may not be available in source format. Most of
the Aglet code can be browsed if you unzip the src.zip file, but not
all of the source is included. You may be able to get some idea of the low-level operations if some of the transport code has been included in the source.
A good overview of Aglet internals is presented in Chapter 9 of the
Aglets book- "Inside Aglets" However, in most cases you should not need
to know about how the low level implementation has been done, unless
there are specific issues, or you are redefining the basic transport,
or if the aglet implementation does not match the
specifications....
What services does Tahiti Provide?
Tahiti is really a combination viewer/server environment (context).
When you run Tahiti - you get a graphic or text interface that provides
a picture of the running context. The actual low-level operations are
based on the various Aglet API documents. So when you use Tahiti you
are using the context provided in the background. The Aglets you see with Tahiti could not run if Tahiti did not provide a context all Aglets need a context to exist/execute in.
A sample server/context is provided with the examples shipped with
the AWB. The files are usually found under:
(AGLETS DIRECTORY)/public/examples/server
The basic source files for Tahiti are also provided. You can unzip
the src.zip file in (AGLETS DIRECTORY) and browse the directories:
src/com/ibm/awb/launcher src/com/ibm/aglets/tahiti
There are also other options like running Tahiti with a commandline
(text gui) or detached with no gui at all. These options can be
customiz ed when you call Tahiti. The actual flags and steps used differ
in between AWB1.0.3 and Beta1.1. You can check the specific options in
the documentation.
How can the sleep operation be used in an Aglet?
The exact behaviour will depend on where the sleep call is invoked
there are at least a few different cases. It could be called from a
message handling routine, from an event handler like onDisposing(), or
from the main run routine in the aglet.The interesting feature to watch
out for is that the sleep operation works on a thread level- while threads are usually hidden from most aglet operations. (for example the run entry point in the aglet is usually the main thread of the agent, and message handlers are done on other threads - but this implementation is hidden when the user aglet code runs)
From a few of my test aglets I found that if I called the sleep on
the main run routine- all messages would block until the sleep
finished. I could use a call to:
getMessageManager().exitMonitor();
to process messages in parallel while the main run thread sleeps.
The behaviour may vary depending on where the sleep call is made. You
may want to build a couple of test aglets and check the exact behaviour
when the sleep call is placed where you want it.
How can local and remote Aglets discover each other and communicate?
There are a few options available to attempt to discover remote
contexts, depending on what you need to do:
- Atempt to create an agent in the local (known) context and dispatch it to a context that may exist. If it does actually exist you can have this aglet return the proxies in that context. If the context does not exist, an exception will be thrown.
- Same as the first, but use multicasting (page 110) in the aglets book to have the agents respond with their proxies
- In Aglets1.1beta there is a new feature called the MAFFinder - this contains information about active contexts and AgletIds. The information about active contexts is available from the finder - you can see it visually with the finder viewer. The disadvantage to this approach is that I haven't seen the actual API calls to the finder documented yet, so it may be difficult to use from your own aglets
- Build an aglet to maintain information about current proxies
and contexts. I have used this approach in my research - since I
started with Aglets1.0.3 when the finder was not available, and I
also needed to store additional fields.
The key point to the differing approaches is that you need a way to
retrieve a valid AgletID or proxy in order for any aglet to communicate
with any other aglet, local or remote.
| 
