Infrastructure for building service-oriented prototypes ...

The logo has been designed by Dominik Heim



In the following text the term component will be used for a piece of software that realizes a certain part of functionality and which offers this functionality through an interface (or a set of interfaces) hiding implementation details from component users. The component will be used locally through method calls.

The term service will be used for components which offer their functionality remotely. Calling a service can be either synchronous (e.g., RPC) but it can also be asynchronous (e.g., through sending a message or raising an event).


The intention of the Servicia project is it to run a service-oriented system with all vital properties with minimum burden for the developers. This framework focuses on an environment where

  • different software components and services are developed by various people, usually not software engineers but researchers. So people should spend their time on developing the components and not with technical stuff like serializing method parameters ...
  • the components should be easily assembled to prototypical software systems
  • multiple instances of such a system may run in parallel
  • the use of the file-system as storage backend is allowed
  • some of the components may run in separate address-spaces (on other virtual machines)
  • services/components ideally use their functionality via method invocations when running in the same address space but the components should also be accessible via a standard web-protocols
  • non-java components (written, for example in javascript) should also be able to communicate with the services.
  • developers should not be bothered with technical details of invoking other services, like generating stubs.

by the way

  • developers should be forced to define proper interfaces for their components

Servicia Approach

Servicia tries to tie components, services and web services together in a pragmatic way. Roughly, at an early development stage a developer is able write a bunch components and plug them together. At this point the developer is not bothered by considerations for example about remote calls and how to serialize messages. The developer can concentrate on understanding the domain.

Later on, some of these components may become services and previously developed components may be grouped to run separately in an own virtual machine.


First we introduce some assumptions we do about our runtime environment. They will justify some of the design decisions we made for the Servicia infrastructure.

  • Services will run on the same machine, either in the same address space or on a different virtual machines. Anyway, latency for network operations between the services will be low. This allows to soften the strict distinction between local and distributed computing allowing Servicia to handle local and distributed method invocations transparently to the client.
  • All services will run in the same file-space. Thus, data can be shared among services more easily than for example when using pure web applications.

Servicia features

To ease development in the above mentioned way Servicia offers some features to achieve this goal:

  • project layout close to a web application layout, known to almost everyone
  • web applications can be embedded within the service environment
  • each service owns a private area of the common file-space to operate on
  • services can run on different virtual machines
  • services can be configured to support Java's JMX making them manageable by the JConsole tool
  • services can communicate with each other through
  • method invocation (synchronous, one-to-one), local and remote, switching to remote invocations is done automatically by the framework and transparent to the services
  • event-based messaging (publish, content-based subscription), explicitly create events and publish them
  • messaging over a message bus (one-way, one-to-many) utilizing shared interfaces

How does Servicia relate to other architectures

Jini -

Rio -

Jini addresses development of distributed service-oriented environments. Services can dynamically form federations of services over the network. Capabilities like security, scalability and flexibility are supported. Services define explicit boundaries for communication with other services. Communication of services is based on Java technology. Communication protocols in use are defined by the services and may include RMI, CORBA or SOAP.

Rio is based on JINI and introduces additional monitoring and management facilities. Services can be run on each dynamic container registered with the distributed system based on attached SLAs ensuring a certain quality of service. Service may be relocated or replicated according to the attached service level agreements. Rio additionally eases development of services.

Servicia does not focus on completely distributed or highly scalable systems with redundant service deployment. Even RIO introduces some nice convenience operations and tools to build services, every service has to offer a remote interface. Servicia intends bring together components and services with an homogeneous invocation mechanism.

OSGi -

OSGi provides a service architecture for services that live in the same process address space. Services (bundles) can be loaded, updated and removed at runtime. Distributed service interaction is not part of the specification.

Specifying bundles and bundle dependencies is supported by eclipse wizards, but working with OSGi introduces a steep leaning curve to "standard java programmers". Also integration of external web services is not trivial.

Downloading Servicia

Servicia is meant to run in an eclipse-based environment. So from within eclipse it can be downloaded directly from the subversion repository using the SVN Repository Exploring perspective.

The SVN repository is available at

To get a running Servicia you need at least the following two eclipse projects:

ServiceRuntimeLauncher from

Dependencies from

To see a running example service also get the

ExampleService from


Servicia is published under the LGPLv3 license.

Presentation (8.8.2008)


PDF: *pending*

Ideas for the Future


  • add a public/private attribute to Servicia service apis. This emphasizes that some apis represent public interfaces of a service (possibly used remotely) whereas private interfaces are only meant to be used locally from inside the service.
  • couple Servicia with RIO features (for example, a runtime instance may run in a RIO dynamic container; already running instances can be located with Jini/RIO tools)
  • use Spring to create service api implementations. Advantages? A "springified" service infrastructure may offer a bridge to OSGi ...
Last modified 10 years ago Last modified on 01/14/09 11:43:27

Attachments (1)

Download all attachments as: .zip