
\iffalse
% We don't need all this
\textbf{Acceptor-Connector Pattern}
The Acceptor-Connector pattern pair decouples connection establishment 
and service initialization in a distributed system from subsequent 
processing performed by the two end points of a service once they are 
connected and initialized~\cite{Schmidt:97c}.  This decoupling is 
achieved by acceptors, connectors, and service handlers.  
Connection-oriented protocols provide reliable delivery of data between 
two or more end points of communication~\cite{Schmidt:00a}.  
Establishing connection between end points involves two roles:  

\begin{itemize}
	\item \textit{Passive role}: This type of role initializes end points of
  communication at a particular address and waits passively for
  other end points to connect with it.  
	\item \textit{Active role}: This type of role actively initiates a
  connection to one or more end points that are playing the passive role. 
\end{itemize}

It is important to know the communication role in terms of server and 
client.  Most often the client plays an active role in connecting with 
a passive server.  Thus, in the Acceptor-Connector pattern, the acceptor 
provides the passive role and the connector plays an active role.  
  
\textbf{Metamodel of Acceptor-Connector Pattern}

In order to understand the detailed relationship between various 
participants of Acceptor-Connector pattern, we will discuss different 
phases that are in this pattern. 
This pattern is actually composed of two patterns called Acceptor and 
Connector.  
The Connector pattern contains options to have synchronous or asynchronous 
type of connection but in POSAML we are supporting only synchronous mode 
of connection. 

Now we will discuss about the collaboration between server and client among 
different participants of Acceptor and Connector patterns at a very 
low-level of abstraction. 
Both the Acceptor and Connector pattern meta-model is part of a single 
paradigm sheet called Acceptor-Connector. In order to understand the 
Acceptor-Connector meta-model and model properly we have simplified it by 
dividing the meta-model into two parts.
These two parts are shown in figure~\ref{fig:acceptor} and ~\ref{fig:connector} 
and are based on  the POSA pattern Acceptor-Connector pattern.

In figure~\ref{fig:connector} we can see that the root element of this 
meta-model is Acceptor-Connector proxy model and it is a proxy of 
Acceptor-Connector model, which is a part of our basic paradigm meta model 
called middleware shown in figure~\ref{fig:middleware_meta}. Acceptor-Connector 
model proxy is in equivalence relation with local Acceptor-Connector model. 
Dispatcher atom and Reactor atom proxy are equivalent and these are basically 
proxies of Reactor atom of Reactor pattern. The Dispatcher atom acts as event 
handler for both abstract Acceptor atom and Connector atom. 

Now we will discuss meta-model of Connector and Acceptor separately:

\subsubsection{Collaboration of Connector:}

\begin{figure}[htbp]
	\centering
		\includegraphics[width=11cm, height=7cm]{Conn-dyn}
	\caption{Connector Pattern Dynamics}
	\label{fig:Conn-dyn}
\end{figure}\begin{figure}[htbp]
	\centering
		\includegraphics[width = 12cm, height = 13cm]{connector}
	\caption{Metamodel of Connector Pattern}
	\label{fig:connector}
\end{figure}

The behavior and flow of connector can be seen in figure~\ref{fig:Conn-dyn}. 
The collaboration between the participants in the synchronous Connector 
scenario can be divided into following stages: 

\begin{enumerate}\crunchlist
\item	\textbf{Connection \& Service initialization phase:}
In figure~\ref{fig:connector} a client creates a Dispatcher atom that 
handles the events associated with that client.  Then it creates one 
concrete Connector atom derived from \url{Abstract\_Connector} atom. 
It also activates concrete \url{Service\_Handler} atom that is derived 
from \url{Abstract\_Service\_Handler} atom. This will be in charge of 
requesting the server peer service handler for each type of service 
needed using \url{Activate\_Connector} connection. For this, then the 
Connector atom generates an event and sends it on the 
\url{Transport\_Handle\_Connector} atom of the server Acceptor of 
figure~\ref{fig:acceptor} in charge of the desired service. 
In return, the Connector atom gets a connection using \url{End\_Point} 
atom that corresponds to the \url{Transport\_Handle\_Connector} atom 
of the peer \url{Service\_Handler} atom. This End\_Points atom is again 
equivalent to \url{End\_Points} atom proxy from the feature 
meta-model. This atom has three attributes like 
host name, listening port, and the protocol. It can then register 
itself to the Dispatcher atom.

\item \textbf{Service processing phase:}
When the Dispatcher atom detects an event on the \url{Transport\_Handle\_Connector} 
atom of the client \url{Service\_Handler} atom, it notifies the handle 
event method of this \url{Service\_Handler} atom using \url{Notify\_Connector} 
connection . When the Dispatcher atom detects a ready event on the client 
\url{Service\_Handler} atom, it calls its handle event method. The 
\url{Service\_Handler} atom then gets the results from server.
If a client \url{Service\_Handler} atom wants to close the service, it generates 
a close event on its server \url{Service\_Handler} atom Handle. Then it is removed 
from the list of Dispatcher atom by calling the remove handler method.
\end{enumerate}

\subsubsection{Collaboration of Acceptor:}
\begin{figure}[htbp]
	\center
	\includegraphics[width = 11cm, height = 7cm]{Acc-dyn}
	\caption{Acceptor Pattern Dynamics}
	\label{fig:Acc-dyn}
\end{figure}

\begin{figure}[hbtp]
	\center
	\includegraphics[width = 12cm, height = 13cm]{acceptor}
	\caption{Metamodel of Acceptor Pattern}
	\label{fig:acceptor}
\end{figure}

The behavior and flow of acceptor can be seen in figure~\ref{fig:Acc-dyn}. 
Acceptor component provides a means for passive connection establishment. 
The collaboration between Acceptor and service handler participants are 
divided into three phases:

\begin{enumerate}\crunchlist
\item \textbf{Initialization phase:}
In figure~\ref{fig:acceptor} we can see the meta-model of the acceptor part. 
The Acceptor atom is derived from \url{Abstract\_Acceptor} atom. It acts as 
a server and initializes a connection passively. When an application calls 
the open method on Acceptor atom. This method creates a passive mode 
\url{Transport\_Handler\_Acceptor} atom which encapsulates \url{End\_Points} 
atom. It binds to end points i.e., IP address, TCP Port and Protocol and then 
like a server it listens to connection requests from peer Connectors. These 
\url{End\_Points} are used by \url{Transport\_Handlers} using 
\url{End\_Point\_Connection} connection proxy obtained from feature view of 
POSAML. \url{Transport\_Handler\_Acceptor} is owned by Acceptor by using 
\url{Owns\_Acceptor} connection. After this the open method registers the 
Acceptor atom object itself to the Dispatcher atom. The Dispatcher atom is 
equivalent to the Reactor proxy atom. After this the Dispatcher atom can notify 
using \url{Notify\_Acceptor} connection to Acceptor atom whenever a connection 
event is coming from a client on the \url{Transport\_Handle\_Acceptor} atom.  

\item	\textbf{Service handler initialization phase:}
The Dispatcher atom detects some event on the \url{Transport\_Handle\_Acceptor} 
atom of some Acceptor. It then calls the handle event method of this 
Acceptor atom for it to handle this particular event. Acceptor atom 
uses passive mode transport endpoint to create a new \url{Transport\_Handle} 
atom using \url{Create\_Connection} connection. It next activates a new 
\url{Service\_Handler} atom using \url{Activate\_Acceptor} connection that 
will be in charge of processing the requests of the client. This 
\url{Service\_Handler} stores these new \url{Transport\_Handles} atom 
information and registers itself to the Dispatcher atom. 
\item \textbf{Service processing phase:}
This stage is about the service use and closure. After the above two stages, 
the Dispatcher atom will directly initiate server client communication using 
\url{Service\_Handler} atom. In this stage, exchange of data between peers 
can happen directly using already connected \url{Transport\_Handles} 
(using transport endpoints). After the whole process is done, \url{Service\_Handler}
 atom will call the remove handler method of the Dispatcher atom to make it 
stop listening on its \url{Transport\_Handle} for the events he had 
registered before.  
\end{enumerate}
\fi

\textbf{Metamodel of Feature View}
\label{feature_meta}

This part of the section discusses about the GME meta model of feature 
aspect of POSAML shown in figure~\ref{fig:feature-meta}. Some of the 
features designed in the meta model are as following:

\begin{figure}[htbp]
	\centering
\includegraphics[width=13cm, height=9cm]{feature-meta}
	\caption{POSAML Metamodel: Feature View}
	\label{fig:feature-meta}
\end{figure}

\begin{enumerate}
\item \textbf{Concurrency: }  This feature is important for different 
middleware to manage concurrency and allow long running operations to 
execute simultaneously without impeding the progress of other operations.  
It specifies the concurrency strategy an ORB uses. Concurrency has 
\url{Concurrency\_Option} as attribute and this attribute has two 
strategies as menu items. 
Server concurrency strategies found in contemporary middleware solutions, 
such as the TAO CORBA middleware~\cite{Schmidt:02g}, support different 
types of concurrency strategies  
(1) {\em Reactive} : This is a default concurrency type. It registers 
the connections transport end points with Reactor. When events occur, 
it starts dispatching these events to the reactive connections in order. 
In this mechanism, an ORB handles each request reactively  i.e., the 
ORB runs in one thread and service multiple requests/connections 
simultaneously using the \url{ACE_Reactor}, which uses select or a 
similar event demultiplexing mechanism supported by the platform. 
Its connections are single-threaded and that is it is scalable but 
is not a very good concurrency mechanism.
(2) {\em Thread Per Connection} : The ORB handles new connections 
by spawning a new thread whose job is to service requests coming from 
the connection.

\item \textbf{Reactor Type:} This feature is used to specify the kind 
of reactor used by the system.  For example, depending on the concurrency 
strategy chosen, the reactor could be single-threaded or multi-threaded.  
It is an advanced resource factory option and if this type of factory is 
loaded, any default directives of original resource factory will have 
no effect. 
Different strategies can be plugged within the reactor for event 
demultiplexing.  
This depends on whether the reactor is used to demultiplex network 
events or GUI events.
\url{Reactor\_Type} has \url{Reactor\_Type\_Option} as attribute and 
this attribute has five strategies as different reactor types:
(1) Thread pool (tp) :  It uses the \url{ACE_TP_Reactor}, a select based 
thread pool reactor which is the default.
(2) Multi threaded (select\_mt) :  It uses the multi-thread select 
based reactor.
(3) Single threaded (select\_st) :  It uses single-thread select based 
reactor.
(4) Wait for multiple objects (wfmo) :  It uses WFMO reactor and can be 
used only for windows.
(5) Message Wait for multiple objects (msg\_wfmo) :  It uses Msg WFMO 
reactor. It is used only for Windows.

\item \textbf{Thread Queue:}  In the case of concurrent request 
handling by a reactor, different strategies can be selected for 
handling queued events (e.g., FIFO or LIFO).
Thread Queue has an attribute called \url{Thread\_Queue\_Options}. 
This attribute has two options i.e., first-in-first-out (FIFO) and 
last-in-first-out (LIFO). This feature applies only to the 
\url{ACE_TP_Reactor}, i.e., when the reactor type is thread pool. 
This specifies the order, LIFO, the default, or FIFO, in which waiting 
threads are selected to run by the \url{ACE_Select_Reactor_Token}. 
Thread Queue is also a part of an advance resource factory.

\item \textbf{End points:} This feature applies to the acceptor-connector 
patterns, which instructs the system of the listening end points for 
the server role.  The range of available end points in POSAML include 
listening ports (e.g., TCP port number), host IP addresses or canonical 
names, and the protocol used (e.g., TCP, UDP, Shared Memory or other 
custom transports).  

\end{enumerate}


%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "JVLC-2007"
%%% End: 
