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 Web Service is an application running on a remote
server, with well-defined API (a set of methods and their signatures)
that is accessible by sending requests (or invoking
operations or methods) wrapped in XML as defined by the
SOAP protocol. The purpose of Bionanny project is to measure how often
and for how long are individual Web Services called without any need
for changing their own code.
- A Monitor (or an Interceptor) is a specialized
code that runs on the same machine where a Web Service is running, and
all incoming requests and produced responses of such Web Service are
redirected through this Monitor. Having such monitor allows to know
about all requests without a Web Service knowing about their
interception. It behave like a Big Brother.
- A Bionanny implementation is a piece of code that is
called to record monitored data. Most often, it is called by a monitor
(but for testing purposes, it can be called also by a standalone
client). Note that this implementation can be itself a Web Service
(but not a monitored Web Service) - such scenario is
described in details below.
- A Bionanny implementation stores data in a mySQL
database. The database is usually running on the same machine
where a Bionanny implementation is located. It may be elsewhere, but
connection between Bionanny and the database is a JDBC connection, not
a Web Service connection.
- Last but not least, there are also clients - programs
that either call ordinary Web Services (to get whatever they provide),
or to call a Bionanny Web Service (to get and display monitored
data). Some clients can also get data from a local Bionanny
implementation, without invoking any Web Service protocol - see such
scenario below.
|
| |
A default model for Java Web Services |
This is the basic scenario - it uses Axis's concept of intercepting
requests by a monitor.
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.
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.
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).
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...).
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).
