Overview

This document gives a description of the management of Xmarc Services. For those of you who wish to move straight to installation issues, go here.

Xmarc Services

An Xmarc Service is a service which returns data in response to data requests from a Client Application. Data is relayed between a Client Application and an Xmarc Service via a Service Broker resident on an HTTP Web Server with Java servlet capabilities, (e.g. JRun, JServ, Tomcat). Examples of services are:

• Xmarc database interface, which when given an SQL query, returns a set of vector/image data.
• Xmarc data-translator which, when given a data file (e.g. a CAD file), returns a set of vector data.
• Xmarc Fire, deployed as a FireRender service, serving up image data.
• WIISE routing engine which, when given a set of points by a client, returns a set of routing instructions.
• WIISE geolocator which, when given a street address, returns a geographic location.
• WIISE renderer which, when given geographic extents, returns a map image.

The basic architecture for client/service correspondence is:

Figure 1.1

The Client Application, Service Broker (resident on an HTTP Web Server) and Xmarc Service(s) typically, but not always, reside on different host machines. A typical installation might have several Service Brokers (one per web server machine) and several Xmarc Services distributed across many host machines. In contrast, a small installation may have all components running on the same host.

A request from a Client Application to an Xmarc Service is an http-wrapped packet of data. This data contains one or more text commands to be executed by the service. The commands may have parameters attached as binary sub-data, known as binary host variables. This combination of text command and binary parameters is an Xmarc proprietary format, known as the Binary Host Protocol (BHP).

Data returned to the Client Application from an Xmarc Service is also an http-wrapped packet of data. Typically, this data is in a binary form known as the Eim protocol, and will contain instructions to create objects (typically but not necessarily spatial in nature) in the Client Application. This Xmarc proprietary protocol is beyond the scope of this document but is described fully in the Xmarc document Eim Protocol. Alternatively some Xmarc Services, e.g. Fire, can return file data to the client, e.g. html, xml or images.

An Xmarc Service must understand the Binary Host protocol, and a Client Application must understand Eim for correct client/service correspondence with an Eim service. For non-Eim services, the client can be a simple browser.

A Service Broker acts as a marshalling tool and relays data unchanged between a Client Application and an Xmarc Service via HTTP tunnelling. Each Xmarc Service is named and registered to a particular Service Broker, which is then responsible for:

• relaying data to and from the service,

• removing the service if requested,

• setting the message log levels for the service,

• load-balancing multiple instances of a service.

The Service Broker automatically manages multiple instances of an Xmarc Service with the same name. Loads on a service are automatically balanced among the instances. A service is allocated to a request if it is the first free, or the least loaded service. When there are multiple requests queued on a service, requests are synchronized and processed one at a time by the service. Scalability is achieved by running multiple instances of the same service, this set being known collectively as a "Logical Service".

Service Management

There must be a level of behind-the-scenes management of Xmarc Services. This is performed by an administration tool, known as the Service Manager, and enables a system administrator to:

• start (register) Xmarc services,

• remove (unregister) Xmarc services, and

• monitor the state of Xmarc Services, Service Brokers and Service Agents

The Service Manager is another type of servlet, is installed on a Web Server at the same time as the Service Broker, but unlike a Service Broker does not communicate directly with Xmarc Services. Instead it only communicates via URL with Service Brokers and Service Agents, discussed later, who in turn communicate with the Xmarc Services. To avoid too much confusion when we talk generally about a servlet, we are referring to a Service Broker not the Service Manager.

The Service Manager provides a form-based web front end, known as the Service Manager Console, for system personnel to administer the services via a web browser. The Service Manager does not have to be installed on the same host machine as the Service Brokers, Client Applications or Xmarc Services.

Because it is impossible to launch directly, or kill remotely, an Xmarc Service on a remote host, every host which has Xmarc Services running on it also has one or more utility programs running known as Service Agents. Each Service Agent is responsible for starting and terminating Xmarc services on that host. It creates a Java Virtual Machine in which Xmarc services can run and share cached data if necessary. The Service Manager and Service Brokers tell a Service Agent when to start and stop services. A Service Agent also initiates and maintains a message log populated by messages from Xmarc Services. Multiple Service Agents may be running on a host, each acting as agent for a different set of Xmarc Services, typically which share cached data.

The Service Management architecture is as follows:

Figure 1.2 Administration Flow Diagram

Next Chapter