Web Services are usually, if not always, developed and deployed using a library (toolkit) that takes care about SOAP messaging and about the transport protocol (such as HTTP). For Java, one of the most used toolkit is Apache Axis. Also the Java part of Bionanny was developed with and for Axis. Therefore, it uses some Axis specific concepts - such as chain/handlers for intercepting requests.

The most used Perl library (module) for Web Services is SOAP::Lite. Its current version does not have a similar concept for intercepting SOAP messages, but it is a planned feature. Therefore, until it happens, Bionanny has only Perl clients. But this may change fast.

Here are several scenarios how to put together Bionanny pieces:

But first, let's look at some common terms used later:

  Glossary of terms

  A default model for Java Web Services

This is the basic scenario - it uses Axis's concept of intercepting requests by a monitor.

A default model for Java Web Services

A client (1) calls a Web Service (3) without knowing (meaning without any need to know) that its request will be intercepted before it reaches its target. A Monitor (2) spawns as fast as it can a separate thread to log the event and passes the original request to the Web Service (3). It does the same when it intercepts a returning response. The thread logs data using a local (meaning: a normal Java class loaded as any other Java class) Bionanny implementation (4) - which stores data in a local database (5).

A default Bionanny monitor is implemented by the class org.bionanny.server.MonitorHandler and it tries to delay the request as little as possible. On my laptop I measured that it spent by average (from about 5000 requests) 85 milliseconds for one-way, which means that a client gets back response delayed for about 170 milliseconds.

The immediate question is how to get back collected data. Because in this case the Bionanny implementation is not a Web Service but an ordinary Java class we need a program that can load such class and get through it an access to the local database. Such program is shown below.

  An extended model for Java Web Services

This scenario is almost the same as the default model above except that Monitor (2) now logs data by using a Bionanny Web Service (4). The Bionanny Web Service can be located on the same server as the Monitor, but does not need to. This scenario allows to collect data from several different monitors in one place.

An extended model for Java Web Services

The Bionanny Web Service (4) - because it is a Web Service - can be now accessed also by its own client (7) in order to get and to show collected data. If such access is allowed depends on the local configuration (which is not part of the Bionanny project but can be built using regular security mechanisms for any Web Service).

  A standalone Bionanny Java client

The most simplest figure shows a standalone Java client (1) that accesses a local Bionanny implementation (2). No Web Services involved.

A standalone Bionanny Java client

The Bionanny client allows not only to get data (which is quite handy, for example, for the default model shown above) but also to log data. The logging is, however, meant mainly for testing purposes because it does not have connection with any real monitored Web Service.

Because at the moment there is no Perl implementation that can access local database with Bionanny data, there is no such simple equivalent of a Perl client. As you see below, there is a Perl client but it needs to access Bionanny data via a Bionanny Web service.

  Perl Bionanny clients

There are several Perl clients (at least two: (1), (2)) that can get data, once collected, and display them, even graphically (see the screenshots). They all get data through a Bionanny Web Service (3).

Perl Bionanny clients

The both Perl clients are implemented using a set of Bionanny Perl modules that hide all SOAP communication. See the Bionanny API for details.

  Self-monitoring Web Services

There may be cases where a Web Service (2) itself can be involved in monitoring its own data. Of course, such case requires a change in its code - but Bionanny provides a class (3) org.bionanny.server.SelfMonitor that makes this change minimal (well, the class is not yet implemented, but is coming soon...).

Self-monitoring Web Service Self-monitoring Web Service with Bionanny as another Web service

As you can see from the figures above, depending on the configuration the SelfMonitor can log data either directly using a Bionanny class, or by calling a Bionanny Web service (which again can be on the same or a different server).

Martin Senger, Mike Niemi
Last modified: Thu Apr 7 23:35:33 2005