System Overview

A Servicia-enabled system is composed out of services. Each service provides a set of functionality and uses functionality offered by other services. Services run on top of a Servicia backbone, one per virtual machine. Several backbones can federate to build a distributed service pool. In that case one backbone enacts the role of a primary backbone, the other backbones are called secondary backbones. Services within this pool can call each other in the same way independent of their locations.


Basic building block of the architecture is a service. This is a piece of software offering a programming interface to use it's functionality. A service splits up into three parts (where the third part may be automatically generated). The parts are:

  • the programming interface (a plain old java interface, POJI)
  • the service implementation providing the service's behaviour and thirdly,
  • the remote client. The remote client manages method invocations from beyond other address spaces (other java virtual machines). It is responsible for serializing the request and to transport back the result, if any. Typically the remote part is generated automatically from the interface class.

Runtime Infrastructure

All services run on top of Servicia's so called Backbone providing the core platform functionality:

  • service life-cycle management (startup and shutdown)
  • service lookup facilities (service registry)
  • service invocation management (invoking service methods locally and remotely, transparent to the calling client)
  • event management (raising and distributing events, registering event handlers, ...)
  • XML-RPC endpoints for remote service invocations
  • management facilities (JMX support, tray icon support under Java 6)
  • web container for embedding web-applications


A single service may offer a bunch (zero or more) APIs. Each API has a name which is unique in the scope of the service. Each API contains the three parts mentioned above: an interface definition, an implementation and an optional remote client managing remote calls to the service. When omitted in the service descriptor a XML-RPC remote client will be generated automatically based on the service interface class. (see XML-RPC Delight for details)

Serveral serivces run on a java virtual machine (VM) comprising a runtime instance. Each service can call other service's methods by pure method calls. Service APIs can additionally be called by external components via XML-RPC. Invoking service methods using JMX (JConsole) is also possible:

In a multiple VM scenario services are hosted on both virtual machines running separate backbones. Services can call each other in a way independent of their location. If the called service resides on the same VM than the caller a simple method invocation will be performed. If the called service lives on a distant VM a remote call will be performed, based on the remote client of the service (or the XML-RPC client automatically generated by the delight framework). In both cases the client calls methods of the service interface as if they were local methods.

One-to-one communication

The following sequence diagram illustrates how Servicia manages service invocations. Called services may be local services, that is, services running on the same virtual machine as the caller, or they may be distant services running on another VM. The method accessApiForClass retrieves an access object used by the client to perform it's service calls. The access object is either the concrete service api implementation. Then, a call on the access object is equivalent to invoking the implementation method. Or the access object is a remote client (for example an auto-generated XML-RPC proxy). Then, a call on the access object is send remotely to the distant service and the result is returned over wire accordingly.

Sequence Diagram 'accessApiForClass'

One-to-many communication

Event-based communication

The third way to exchange messages between services is by raising events. Events are mainly key-value maps. Services can create events populate them with values and raise them. Other services can subscribe to receive messages. They can apply a content-based filters to control what sort of events they receive.

Last modified 11 years ago Last modified on 06/11/08 13:52:35

Attachments (5)

Download all attachments as: .zip