% $Id: acceptor.tex,v 1.8 2006/02/12 17:38:39 gokhale Exp $
\subsection{Modeling of Acceptor and Connector Pattern}
\label{sec:acceptor}

 It is a design pattern that 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{dk:Acc-Conn:Doug}. 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{dk:Active-passive:Doug}.
 Establishing connection between endpoints involves two roles: 

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

It is important to know the communication role in terms of server and
client. Mostly client is the one who plays an active role in
connecting with an passive server but reverse is also possible. So, in
Acceptor-Connector pattern, acceptor provides us with this passive
role and connector plays an active role. 

\subsubsection{Participants:}
\label{sec:reactor_participants}

\begin{figure}[htb]
	\centering
		\includegraphics[width=13.5cm,height=7cm]{figs/Acc-Con}
	\label{fig:Acc-Con}
	\caption{UML diagram of Acceptor-Connector Pattern}
\end{figure}

The structure and participants of Acceptor-Connector
pattern~\cite{dk:Acc-Conn:Doug} is illustrated in
Figure~\ref{fig:Acc-Con}.  This UML diagram which shows the
relationship between different participants of this pattern. There are
six key participants in this pattern. These participants are described
as follows: 

\begin{enumerate}
\item Acceptor: It is a factory that implements passive strategy to
establish a connection and initialize the associated Service
Handler. It creates a passive mode endpoint transport factory
(transport handle) that has necessary endpoints needed by the Service
Handlers. 

\item Connector: It is a factory that implements the active strategy
to establish a connection and initialize the associated Service
Handler. It initiates the connection with a remote Acceptor. It has
synchronous (using Reactor pattern) and asynchronous mode (using
Proactor pattern) of connections  

\item Dispatcher: It is in charge of registering, removing and
dispatching the events that occurs on the registered handles by
calling back application-specific Event Handlers. Dispatcher is for
management of registered Event Handlers. In case of Acceptor,
Dispatcher demultiplexes connection indication events received on
transport handles. Multiple Acceptors can be registered within
Dispatcher. And for Connector, the dispatcher demultiplexes completion
events that arrive in response to connections. 

\item Service Handler: It is an abstract class that is inherited from
Event Handler. It implements an application service, typically playing
the client role, server role or both roles. It provides a hook method
that is called by an Acceptor or Connector to activate the application
service when the connection is established. The Service Handler uses
the Handle component referencing to its peer for data-mode exchange
with its connected peer Service Handler. So once the Service Handler
is completely initialized by Acceptor and Connector factory it
typically does not interact with these components any further. 

\item Transport endpoints: It is a factory that listens for connection
requests to arrive, accepts those connection requests and creates
transport handles that encapsulate the newly connected transport
endpoints. Using these end points data can be exchanged by reading or
writing to their associated transport handles. A transport handle
encapsulates transport endpoint. 
\end{enumerate}

\subsubsection{Acceptor-Connector Metamodel}
In order to understand the detailed relationship between various
participants of Acceptor-Connector pattern, we will discuss different
phases that are there in the Acceptor and Connector.  
Connector pattern contains options to have synchronous or asynchronous
type of connection but in POSAML language as of now we are supporting
only synchronous mode of connection. 

Now we will talk about the collaboration between server and client
among different participants of Acceptor and Connector patterns at a
very low level of abstraction. 
Both Acceptor and Connector pattern metamodel is part of single
paradigm sheet called Acceptor-Connector. In order to understand
Acceptor-Connector metamodel and model properly we have simplified it
by dividing metamodel into two parts.  
These two parts are shown in fig~\ref{fig:acceptor} and
~\ref{fig:connector} and are based on  the UML diagram of
Acceptor-Connector pattern shown in fig~\ref{fig:Acc-Con}. 
In fig~\ref{fig:connector} we can see that the root element of this
metamodel is Acceptor-Connector proxy model (1) and it is a proxy of
Acceptor-Connector model, which is a part of our basic paradigm meta
model called middleware shown in
fig~\ref{fig:middleware_meta}. Acceptor-Connector model proxy is in
equivalence relation with local Acceptor-Connector model
(1). Dispatcher atom(2) and Reactor atom proxy are equivalent and
these are basically proxies of Reactor atom of Reactor pattern shown
in fig~\ref{fig:reactor_meta}. And this Dispatcher atom acts as event
handler for both abstract Acceptor atom and Connector atom. 
Now we will discuss metamodel of Connector and Acceptor separately:

\textbf{Collaboration of Connector:}
The behavior and flow of connector can be seen in
figure~\ref{fig:Conn-dyn}. And, the collaboration between the
participants in the synchronous Connector scenario can be divided into
following stages: 
\begin{figure}[ht]
	\centering
		\includegraphics[width=10cm, height=7cm]{Conn-dyn}
	\caption{Connector Dynamics}
	\label{fig:Conn-dyn}
\end{figure}

\begin{figure}[ht]
	\centering
		\includegraphics[width=13cm, height=11cm]{connector}
	\caption{Connector part of metamodel}
	\label{fig:connector}
\end{figure}
\begin{enumerate}
\item	Connection \& Service initialization phase:
In figure~\ref{fig:connector} a client creates a Dispatcher atom(2)
that handles the events associated with that client. 
 Then it creates one concrete Connector atom(3) derived from Abstract\_Connector atom(3). It also activates concrete Service\_Handler atom(4) derived from Abstract\_Service\_Handler atom(4) (that will be in charge of requesting the server peer service handler) for each type of service needed using Activate\_Connector connection. For this, then the Connector atom generates an event and sends it on the Transport\_Handle\_Connector atom(5) of the server Acceptor of fig~\ref{fig:acceptor} in charge of the desired service. 
In return, the Connector atom gets a connection using End\_Point atom(6) that corresponds to the Transport\_Handle\_Connector atom(5) of the peer Service\_Handler atom(4). This End\_Points atom(6) is again equivalent to End\_Points atom proxy got from feature metamodel~\ref{sec:features}. This atom has three attributes like host name, listening port and the protocol. It can then register itself to the Dispatcher atom(2).
\item Service processing phase:
When the Dispatcher atom(2) detects an event on the Transport\_Handle\_Connector atom(5) of the client Service\_Handler atom(4), it notifies the handle event method of this Service\_Handler atom(4) using Notify\_Connector connection . When the Dispatcher atom(2) detects a ready event on the client Service\_Handler atom (4), it calls its handle event method. The Service\_Handler atom (4) then gets the results from server.
If a client Service\_Handler atom(4) wants to close the service, it generates a close event on its server Service\_Handler atom(4) Handle. Then it is removed from the list of Dispatcher atom (2) by calling the remove handler method.
\end{enumerate}

\textbf{Collaboration of Acceptor:}
The behavior and flow of acceptor can be seen in figure~\ref{fig:Acc-dyn}. Acceptor component provides means passive connection establishment. The collaboration between Acceptor and service handler participants and are divided into three phases:
\begin{figure}[ht]
	\centering
		\includegraphics[width=10cm, height=7cm]{Acc-dyn}
	\caption{Acceptor Dynamics}
	\label{fig:Acc-dyn}
\end{figure}

\begin{figure}[ht]
	\centering
		\includegraphics[width=13cm,height=11cm]{acceptor}
	\caption{Acceptor part of metamodel}
	\label{fig:acceptor}
\end{figure}
\begin{enumerate}
\item Initialization phase:
In figure~\ref{fig:acceptor}, Acceptor atom(7) is derived from Abstract\_Acceptor atom(7) and it acts as server and initializes a connection passively. When an application calls the open method on Acceptor atom. This method creates
a passive mode Transport\_Handler\_Acceptor(9) atom which encapsulates End\_Points atom(6). 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 End\_Points are used by Transport\_Handlers(10) using End\_Point\_Connection connection proxy got from feature view of POSAML. Transport\_Handler\_Acceptor is owned by Acceptor by using Owns\_Acceptor connection. After this the open method registers the Acceptor atom(7) object itself to Dispatcher atom(2). Dispatcher atom(2) is equivalent to Reactor proxy atom. This Reactor proxy atom and AbstractEvenHandler proxy atom(8) are defined in Reactor pattern in section~\ref{sec:reactor} as Reactor atom(2) and AbstractEventHandler atom(3). After this the Dispatcher atom(2) can notify using Notify\_Acceptor connection to Acceptor atom(7) whenever a connection event is coming from a client on the Transport\_Handle\_Acceptor atom(9).  
\item	Service handler initialization phase:
Dispatcher atom(2) detects some event on the Transport\_Handle\_Acceptor atom(9) of some Acceptor. It then calls the handle event method of this Acceptor atom(7) for him to handle this
particular event. Acceptor atom(7) uses passive mode transport endpoint to
create a new Transport\_Handle atom (10) using Create\_Connection connection. It next activates a new Service\_Handler atom using Activate\_Acceptor connection that will be in charge of processing the requests of the client. This Service\_Handler(4) stores these new Transport\_Handles atom(10) information and registers itself to the Dispatcher atom(2). 
\item Service processing phase:
This stage is about the service use and closure. After above two
stages, Dispatcher atom(2) will directly initiate server client communication
using Service\_Handler atom(4). In this stage exchange of data between peers
can happen directly using already connected Transport\_Handles (using transport endpoints). And
after the whole process is done, Service\_Handler(4) atom will call the remove
handler method of the Dispatcher atom(2) to make it stop listening on its
Transport\_Handle for the events he had registered before.  
\end{enumerate}
%\itembf{Acceptor-Connector Model}
\begin{figure}[ht]
	\centering
		\includegraphics[width=10cm, height=7cm]{Acc-Con-model}
	\caption{Model of Acceptor-Connector}
	\label{fig:Acc-Con-model}
\end{figure}

A modeler can model Acceptor-Connector pattern in POSAML as shown in
Figure~\ref{fig:Acc-Con-model}. Various constraints are there to
minimize the risk of choosing wrong combination of elements in the
pattern. Only correct combination of connections and features are
allowed to add for a particular pattern. For example only End Point
feature can be added to Acceptor-Connector pattern. Some of these
constraints comes in picture when we try to do model transformation
using interpreters i.e., checking of connections between different
objects of model.It is assumed that modeler will have basic knowledge
of patterns i.e., flow between different objects. Modeler can have
more than one acceptor in his model. 

