\section{\name~Implementation}\label{sec:impl}

This section first presents our Eiffel implementation of the model described in Section~\ref{sec:model}. Thereafter, we show how to use the implementation of \name in practice.

\subsection{Implementation}

The implementation of the \name~model consists mainly in the specifications, templates and the surrounding component infrastructure. Currently the framework consists of 21 classes with 1700 lines of code altogether. We are extending it to more component models and plan on making it available as open source.

\paragraph{Specifications.}

\lstinline!LL_SPECIFICATION! is a list of \lstinline!LL_SPECIFICATION_TERM!s.
The deferred (abstract) class \lstinline!LL_SPECIFICATION_TERM! should be subclassed by a programmer who wants to define his own matching module. The only mandatory feature to be implemented returns a \lstinline!STRING! representing the name of the corresponding matching module.
The infrastructure already implements the features to look through the specifications given that the \lstinline!LL_SPECIFICATION_TERM!s return the correct matching module name. 
This enables an implementation based on hashtables.
Just like for templates, which are described in following subsection, we use the possibility to define our own infix operators for setting constraints on the specifications that describe a component. The Eiffel programming language makes it easy to define these operators and together with automatic conversion functions they allow writing easily readable code.

%\begin{figure}[h]
%\begin{lstlisting}
%deferred class
%	LL_SPECIFICATION_TERM
%	
%feature name: STRING is
%		-- Name of specification term
%	deferred
%	ensure
%		a_name_not_void: name /= Void
%		a_name_not_empty: not name.is_empty
%	end
%end
%\end{lstlisting}
%\caption{Parent class for custom specifications}\label{fig:customMMspecification}
%\end{figure}

\paragraph{Templates.}

To implement our prototype, we relied on two features of the Eiffel language, namely (1) user-defined infix operators and (2) user-defined automatic type conversion.
Infix operators allow us to compose templates using the infix operators as defined by the natural mathematical intuition while automatic conversion lets us have valid types for general mathematical operations.
According to the latest definition of Eiffel and the priority of the operators, the usual priorities apply.
The infix operators are coded into \lstinline!LL_TEMPLATE! and are thus inherited by all templates.
The automatic conversion from \lstinline!DOUBLE! to \lstinline!LL_TEMPLATE! ensures that we can compose doubles and templates in a same expression containing infix operators.
In short, the Eiffel compiler (ISE Eiffel 5.7) converts mathematical formulae containing templates by transforming the doubles that they contain into \lstinline!TEMPLATES!.
As an example, the formula

\begin{lstlisting}
template:= 2.0*template0-1.0/(template1-template2)
\end{lstlisting}

is automatically transformed by the compiler into:

\begin{lstlisting}
template:=
	((create {LL_TEMPLATE}.make_from_double(2.0))*template0) - 
	((create {LL_TEMPLATE}.make_from_double(1.0))/(template1-template2))
\end{lstlisting}


The deferred class \lstinline!LL_TEMPLATE_TERM!, inherits from the class \lstinline!LL_TEMPLATE!. 
A programmer wishing to implement a matching module should subclass it and implement the feature \lstinline!match! that takes an \lstinline!LL_SPECIFICATION_TERM! as an argument and he should also provide a feature returning the name of the matching module as mentioned previously. 
Note that in our infrastructure the only \lstinline!LL_SPECIFICATION_TERM!s that can be passed as parameter to the \lstinline!match! feature are the ones actually belonging to the same matching module.

%\begin{figure}[h]
%\begin{lstlisting}
%deferred class LL_TEMPLATE_TERM 
%inherit 
%	LL_TEMPLATE
%redefine
%	calculate_with_specification
%end
%	
%feature -- Access
%	
%	name: STRING is
%		-- Name of matching module it is issued from
%		deferred
%		ensure
%			a_name_not_void: name /= Void
%			a_name_not_empty: not name.is_empty
%		end
%
%feature -- Commands
%         ...
%	match (a_specification_term: LL_SPECIFICATION_TERM): DOUBLE is
%		-- Evaluate value of current object
%		-- Used by matching module to evaluate matching
%		-- Should be effected with an implementation for respective LL_SPECIFICATION_TERM
%		require
%			a_specification_term_not_void: a_specification_term /= Void
%		deferred
%		end
%end
%\end{lstlisting}
%\caption{Parent class for custom templates}\label{fig:customMMtemplate}
%\end{figure}


\paragraph{Decentralized lookup.} \label{subsec:p2pimpl}

The current matching prototype infrastructure performs centralized component lookup. 
We are currently in the process of augmenting our implementation for efficient component lookup in peer-to-peer (P2P) settings, which will make our infrastructure available as a service within a peer group of JXTA networks~\cite{JXTA}.

In order to complete such a decentralized lookup efficiently, it is very useful to be able to ``decompose'' the matching. The idea can be viewed as a generalization of the problem of content-based event routing in P2P networks, where event contents are viewed as consisting in several properties which are each matched against values, and an overlay network can be built which regroups participants with common interests and whose nodes many perform matching of only subsets of the properties (e.g. \cite{EG02}). 
%TODO: Add description of EG02 here

In order to be able to decompose the matching in the lookup problem, a little help is however required from the programmer. Both specifications and templates have to provide access to a tree-based representation of themselves, akin to abstract syntax trees. The individual tree nodes represent elementary matching operations, and can be performed in a decentralized, yet minimally redundant, manner. 

The logical regrouping of several \emph{tModel}s to a \emph{bindingTemplate}, several  \emph{bindingTemplate}s to a \emph{businessEntity}, and several instances of latter kind to a \emph{businessService} in UDDI (see Section~\ref{par:uddi}), is but an illustration of such a decomposition.



\subsection{Using the Implementation}

In the current state of the implementation of \name, a programmer wishing to use the component lookup mechanism can simply instantiate the class \textit{LL\_COMPONENT\_\-COL\-LEC\-TION} and the components along with their specifications. 
By subclassing the two deferred (abstract) classes \lstinline!LL_SPECIFICATION_TERM! and \textit{LL\_TEMP\-LATE\_\-TERM}, the programmer can implement a matching module. It implies setting two variables and redefining the feature \lstinline!match!. 
Note that keeping a reference to the object encapsulating a component with its specification allows revoking parts of the specification dynamically. 

In the following example (see Figures~\ref{listing:loadSpec} and~\ref{listing:loadLookup}) we show how one describes a component and then uses our lookup mechanism to match requirements against the entire component repository. We see how the specification terms are first declared and enriched with the corresponding information. Then they are added to the component's specification. Note how the \textit{less} operator is used to impose a constraint on the specification about the component's load. In the second listing (see Figure~\ref{listing:loadLookup}) of the example it is shown how to prepare a component lookup. Instead of specifications we are now preparing templates that are put together to match against the component repository. The \lstinline!^!-operator is used to initiate the matching. In the resulting list the components are ordered according to rating of the matching in respect to the template formula. In this case we are only interested in the component with the highest rating and we are therefore only obtaining the first component of the resulting list.

\begin{figure}[t]
\begin{lstlisting}
uid_specification_term: LL_UID_SPECIFICATION_TERM
regexp_specification_term: LL_REGEXP_SPECIFICATION
load_specification_term: LL_LOAD_SPECIFICATION
... 
create uid_specification_term.make ("1337")
create regexp_specification_term.make ("This component... 
                     author: John Doe")
create load_specification_term.make (Current.component)

Current.add_specification_term_to_spec(uid_specification_term)
Current.add_specification_term_to_spec(regexp_specification_term)
Current.add_specification_term_to_spec(load_specification_term<10.0)
... 
\end{lstlisting}\vspace{-2mm}
\caption{Specification declaration}\label{listing:loadSpec}\vspace{3mm}
%\end{figure}
%
%
%\begin{figure}
\begin{lstlisting}
uid_template: LL_UID_TEMPLATE 
regexp_template: LL_REGEXP_TEMPLATE 
load_template: LL_LOAD_TEMPLATE 
component: LL_COMPONENT
components: LL_COMPONENT_COLLECTION
...
create uid_template.makr ("1337")
create regexp_template.make ("*author: John Doe*")
create load_template.make
component:= (components^((uid_template+regexp_template)/(1.0+load_template))).get_first_component
...
\end{lstlisting}\vspace{-2mm}
\caption{Using the lookup infrastructure}\label{listing:loadLookup}
\end{figure}


