% Origo chapter

\svnInfo $Id$

\chapter{Origo with VamPeer}
\label{ch:origo}

As a case study, we tried to build a \ptp{} application with \vampeer\@. We
supply it as an additional example.

Because our task was to prepare \ptp{} support for Origo, it was obvious to do a
test application for Origo. We did not implement the real Origo messaging layer
because the full requirements were not yet available at this
time\footnote{Patrick Ruckstuhl currently writes a master thesis about the
\emph{Origo Core} where he will among others define and implement the entire
messaging layer using \vampeer\@.}. We did therefore a simple Origo example
which supports some core ideas of Origo, especially regarding the \ptp{}
technology.

We will now give an Origo overview so that we understand what our example deals
with.

\section{Origo overview}

Origo is a PhD project by Till~Bay, the supervisor of this master thesis. Origo
is a revolutionary software development, management and distribution platform.
While the main idea exists, the implementation just has started in the last few
months; \vampeer{} is also a contribution to it. We hope that in a few months,
we have a first Origo release supporting the main features.

Many similar platforms exist (SourceForge, BerliOS, Google Project Hosting,
\ldots). The added value by some platform is to provide techniques such that the
components may cooperate. For example when a patch is committed solving a
certain bug, the bug tracker should be able to detect this event and close the
corresponding issue (this could be done by parsing the commit log entry).

While some platforms already support very good services, Origo still is the only
one which will support the following essential features: modularity and
extendability.

The traditional platforms like SourceForge are rather monolithic since their
various services are coupled together in a tight, static manner. Thus, it is not
a simple task to add a new version control system or a bug tracker service
without having to change the system essentially.

That is the reason for Origo to support modularity. Very simplified, this is
done by defining a messaging layer which all components will have to use. They
share messages about what features and event types they provide and may thus
cooperate together. This is why each component has some kind of a wrapper which
integrates the component into the Origo system.

All the resulting Origo services are managed by a central \emph{core} service.
It provides also an XML-RPC API to the public so that central features as
creating a new release could be integrated into the developer's environment.

Origo's main services will be revision control, bug tracker, wiki, single
sign-on and lookup services to find appropriate software components.

Origo wants to scale under heavy load; Origo is therefore designed to run as a
distributed system. When new services are added dynamically to the system, they
must be able to discover and contact the core service. Thus, it is obvious to
use \ptp{} technology for messaging.

As Origo is fully developed in Eiffel, we now can see the impulse for our master
thesis which brings a \ptp{} system, namely JXTA, to Eiffel so that it can be
used in Origo.

\section{Design}

We now look at our Origo example and what features we support. The official
Origo release will be based on another design. We just show how we can handle
the network challenges with \vampeer\@.

\subsection{Task}

In our example, we focus on the task how services can advertise their existence
to the core service and how the core service may start the Origo infrastructure.
We only have two peers: the core peer and a service peer which provides a lookup
service\footnote{The lookup service implementation is managed by Andrea
Gr\"ossbauer who writes a semester thesis about hierarchical lookup queries.}.

Figure~\ref{fig:origo_services} shows the example's \vampeer{} related classes
and their interfaces.

\begin{figure}[h] \centering
\includegraphics[width=.8\textwidth]{origoservices}
\caption{Origo example P2P class structure}
\label{fig:origo_services}
\end{figure}

An Origo service in our example is advertised through
\eclass{O\_SERVICE\_ADVERTISEMENT}. A service has several roles which are each
represented through a \eclass{O\_SERVICE\_ROLE\_ADVERTISEMENT}.

Services may have several roles because a service itself could be distributed
too and may consist of several components. An \eclass{O\_SERVICE} object is the
local representation of the entire service and manages all the roles that are
registered at the current peer.

The lookup service has two roles: a main node responding to queries and a proxy
node which resides on the core node to forward queries to the main node. The
initial idea for the proxy was to hide the real lookup peer from the public
network so that each request must go through the core peer which could also
maintain a special security layer.

The core's task is to know all services and also the status of all its roles.
When a new service joins the Origo peer group, the core peer looks for all
service roles and when they are all available, a request is sent to all involved
peers to start and integrate the entire service into the Origo system.

\subsection{P2P infrastructure}

The Origo example runs in a private peer group, the Origo group. The
\texttt{RdvServer} example described in section~\ref{sec:usage_rdvserver}
also supports this group.

The group uses all \vampeer{} services and additionally introduces a new service
module implemented by the class \eclass{O\_P2P\_MODULE}. This module is used by
the Origo services\footnote{Note the difference between a JXTA/\vampeer{}
service and a Origo service.} to communicate with other peers or vice versa.

The communication between peers is on the one hand done with discovery messages
to share advertisements and on the other hand with XML control messages
(\eclass{O\_SERVICE\_CONTROL\_MESSAGE}) based on endpoint messages.

We can use Origo specific advertisements because we do not share them with the
rendezvous server, we pass them directly to the appropriate peers.

\subsection{Startup procedure}

The core peer must be started first and publishes its peer advertisement to the
peer group. Other peer nodes just propagate a core discovery query.

When a peer node starts, all Origo services register at the network module, so
it knows what services and service roles are available locally.

As soon as it receives the core's peer advertisement, it publishes all the
registered service and role advertisements to the core.

The core checks on each incoming role advertisement whether all roles for the
given service are available now. When they are complete, the core sends a
start control message to all peers which maintain an involved service role.

Once a peer receives this message, it advises the corresponding service object
to start. The lookup proxy node will register its XML-RPC proxy methods on the
local XML-RPC server whereas the lookup main node will start up the lookup
component.

\subsection{Role configurations}

The roles may have to exchange their configuration parameters. Thus, each
service role advertisement can have a configuration XML document attached, for
example a descendant of \eclass{O\_SERVICE\_CONFIGURATION}.

The lookup service for example uses this configuration to tell the proxy on
which IP address and port the lookup main component is listening to answer
XML-RPC queries.

\section{Summary}

The Origo example shows how we may use \vampeer{} for messaging. It uses
endpoint messages as well as Origo specific advertisements and documents.

Although the example has a nontrivial background, it serves as a good code
repository where we can look at how we may implement some nifty tasks, for
example how a private peer group is used or how we may create our own XML
documents.
