IberAgents Features

This document explains the most prominent features of IberAgents from an external point of view, and is intended for evaluation of the platform. Security is discussed in a separate page.

Online documentation for architecture is available, along with a user guide for developers. The status of the framework can be useful to decide whether IberAgents is suitable for use in a given project.

Introduction

During the design of IberAgents, we considered those features most commonly used in distributed web applications.

The framework is oriented towards data management using Java Beans and web communication, either by web services using SOAP or through a regular web application that displays web pages. The first section describes those features related to distributed systems, and the second explains bean object management (including persistence).

Performance is discussed next with an emphasis on web service requests, followed by security concerns. Testing is the focus of the last section.

Distributed Systems

Support for distributed computing is usually sparse in most frameworks. A developer must tweak it so that it works in the intended way. With IberAgents, several nodes may work in conjunction; communication is transparent to the user, if she chooses to see it so.

Reliable Communication

When a SOAP message is about to be sent, it is stored in the deliverer, which sends it on a different thread -- freeing the current one if possible, e.g. for asynchronous messaging. This component will retry the communication if the network is down.

SOAP Library

IberAgents includes its own SOAP library. There is currently no free library which satisfies our needs, in terms of speed, reliability and accuracy; therefore we had to build one.

As SOAP support includes a lot of stuff beyond the basics, it is not yet complete, though.

XML Library

As part of the effort of developing a SOAP library, we also had to build our own XML library, called iberxml for consistency.

iberxml supports namespaces, CData sections and much more. while retaining its original simplicity. Detailed information is available on a separate page.

Performance

When choosing a framework, it is important to check that its speed matches the requirements. For example, if startup time exceeds a few seconds, it will not be possible to perform a lot of tests that require a complete restart of the platform in a reasonable time.

Extensive tests have been conducted with IberAgents, followed by some optimizations. Performance is quite good on middle-class machines, but there is still room for further optimization.

All tests have been performed using Mandrakelinux 9.1 on two test machines: one PIII @ 800 MHz and one PIV @ 2.4 GHz, and Windows 2000 Professional on a PIII @ 1133 MHz. All test machines had 512 MB of RAM memory. The results tend to be linear (i.e. tests take three times longer on the slower machine) on Mandrakelinux; yet there are several differences between platforms.

Platform Startup

In this test we start and stop the platform several times, using the test case com.iberagents.test.PlatformTest. It was performed several times, and the lowest (and highest) results were considered; mean time is only orientative.

Platform Startup Times
startup time (ms)	PIII @ 800 MHz	PIII @ 1133 MHz	PIV @ 2.4 GHz
min	207	60	141
mean	270	170	160
max	414	260	221

It is worth pointing out that startup is quite faster on the Windows machine, yet has bigger variations.

Requests per Second (SOAP)

A lot of testing has been done to verify how many SOAP requests per second were accepted by the platform, using a simple service (ping()) which does not perform any server-side computations. Therefore the times shown below are raw times just for communication.

A couple of helper libraries for communication are used: Jetty is embedded as a web server, and HttpClient makes the POST requests. The components to use are FastSocketSender and FastSocketBinder. This combination is for some reason not optimum for communication; there seems to be a weird synchronization issue that prevents CPU load to reach 100%: requests take very long to be processed while the CPU is sitting idle. This happens both under Linux and Windows, and is more noticeable on Linux. We have not been able to discover the cause.

We have also performed some tests without those libraries; instead, we built our own custom classes using raw sockets for read and write, which can be found in the package com.iberagents.dummy. They are not fully functional, but merely show that further optimizations are possible. FastSocketSender and FastSocketBinder send and receive non-HTTP soap messages where the payload is encoded as two bytes with message length and then the message itself; compare with SocketSender and SocketBinder which send and parse HTTP headers. Times for all possible combinations are shown

The test class used is com.iberagents.bind.test.LoadTestRunner; it is not a test case but rather a command line utility. Usage is simple:

	java LoadTestRunner -[w|s|t] host port directory [requests]

where -w sends a batch of web requests, -s sends a batch of SOAP requests and -t sends threaded SOAP requests continously. Here we will use the -s option.

SOAP Message Requests
messages per second	PIII @ 800 MHz	PIII @ 1133 MHz	PIV @ 2.4 GHz
SoapSender - IberBinder	24.9	49.7	177.7
SoapSender - SocketBinder	236.0	205.7	414.7
SocketSender - IberBinder	239.9	219.6	416.8
SocketSender - SocketBinder	394.3	302.4	765.5
FastSocketSender - FastSocketBinder	420.1	311.7	790.0

Tests were performed after one round warm-up, for a number of iterations ranging from 10 to 1000. Results above are for 1000 iterations.

Requests per Second (SOAP Threaded)

Our next test will also measure the performance of SOAP requests, but this time in a more realistic setting: instead of making a number of requests in rapid succession, we will start a number of threads that make one request per second each. Continous or throughput performance can thus be calibrated.

We will use the -t option to LoadTestRunner. The process is not as automated as before: we have to manually set the number of threads, or requests per second, and adjust it to the maximum value with which it stabilizes over time. Therefore the values shown are just an approximation of the highest number of threads that does not cause excessive lags.

The results should be a bit slower than with successive SOAP requests, because of the computational cost of switching threads. They are shown below for SoapSender and IberBinder, i.e. using HttpClient and Jetty as web server.

Threaded SOAP Message Requests
threaded SOAP messages	messages per second
PIII @ 800 MHz	~ 65
PIII @ 1133 MHz	414.7
PIV @ 2.4 GHz	416.8

The weird synchronization issue has disappeared, since it only affected minimum request time: it seems that Jetty accepts a lot of requests per second but each one suffers high latency (about 35 ms for the slowest machine).

Testing

IberAgents contains a high number of test cases (more than 150). Test code is roughly one third of the total, and we have spent a lot of effort trying to keep tests consistent and comprehensive.

Development follows the agile paradigm of constantly developing and running the test suites. All unit tests are currently running (as of version 1.1). The constant refactoring that the platform undergoes makes it essential to develop and maintain the set of tests.