\section{Introduction}\label{sec:intro}

The evolution from the Internet to the World Wide Web, more recently boosted by the advent of the semantic web and Web Services, has marked the gradual transformation of a communication infrastructure consisting of bare metal into a mighty platform fostering interaction of business parties. %solutions. 

The possibilities currently offered to conduct business at an electronic level are amazingly vast. Service providers offer access to their attendances through components placed on the Internet; such components can be combined to build applications, which can themselves be used as components by further business units. Web Service technologies typically provide the glue between individual components by proposing safe, efficient, and flexible communication protocols.

%Components are everywhere! 
%They span from internal structures to distributed ones.
%Once a real challenge, building components infrastructures has become common.
%Thus, the numerous existing components infrastructures populate the Internet, offering remote procedure calls as well as web services.
%In such electronic cities it becomes more and more acute to have solutions that provide %better solutions to tie relations between citizens.
%In particular, it becomes more and more important to go beyond the traditionnal white %pages and yellow pages.
%After all, in real life, white pages and yellow pages are but some of the means to select %partners.
%While the decision processes are difficult to describe in the real world, they should be %easy to formulate in a software.
%Identifying \textit{which} components serve the most adequate services to build a final %application is of crucial importance.


% biggest problem: coordinating/finding appropriate components. many different schemes/models of finding components
The most critical ingredient to the success of a business idea remains the task of setting up interactions, that is, choosing one's business partners. The success -- or failure -- of an entire business plan can depend on a single participant. 
At a technical level, the selection of appropriate business partners translates to the issue of identifying \emph{which} components represent the most adequate services to build a final application.
In particular, application designers have to face the challenge of specifying their own components, and choosing foreign components according to potentially several specifications. Coding algorithms to perform such selections is an onerous task, and the outcome is usually an ad-hoc solution of limited application scope. 
% present a generic model of describing component queries, based on specifications of components, and its implementation

Each middleware technology and system proposed in the past has typically been described with its own scheme for ``looking up'' components, i.e., seeking, selecting, and connecting to components.
In fact, the high number of non-redundant systems for looking up components advocates for a tighter integration or a composition model for such systems.
In this paper, we try to distill the fundamentals of component lookup. 
We propose a generic model of multiple specifications component lookup based on mathematical formulae, called \name ~(generic COmponent LOokup based on Specification matching).
By differentiating between \emph{explicit} and \emph{implicit} component specifications, as well as between \emph{internal} and \emph{external} ones, our model becomes
applicable to settings as diverse as tagged sets, name-based schemes, or even method dispatch. What we propose is thus a framework intended to provide programmers with an infrastructure to use and freely encode specifications and add them to associated components.
By offering the possibility of combining specifications by the means of mathematical operators, our system is able to sort the components that match with a \emph{group of specifications} and put first the components that match \emph{best} according to user-defined criteria.


Our way of combining specifications and their matching is robust to distribution as results can be collected in a peer-to-peer manner.
Our implementation is itself based on collections of components that can be combined, and
% Our implementation is itself based on a peer-to-peer backbone which provides both reliable and efficient component lookup.
%It also 
includes the foundations for building secure matching as it can also be used for locking.

We illustrate our model through various examples of existing lookup schemes. 
Quite interestingly, it turns out that in the generic context we consider, the traditional differentiation made in the past between value-based (``white pages'') and type-based (``yellow pages'') is artificial.


\paragraph{Roadmap.} Section~\ref{sec:back} presents preliminary material, including our model of components and their specifications, and related approaches. Section~\ref{sec:model} elaborates on our generic model of component matching. Section~\ref{sec:xamples} illustrates that model through various matching schemes. Section~\ref{sec:impl} discusses the deployment and the use of our implementation based on \name. Section~\ref{sec:conc} draws final conclusions.
 
