This package is the top-level package for the PEPt Remoting Architecture. PEPt enables remoting (i.e., RPC and Messaging) systems to dynamically use alternate encodings, protocols and transports.
For papers, slides and examples of the PEPt architecture, please see:
PEPt stands for:
ClientDelegate
to initiate and complete a message send (and a possible
response). ClientDelegate
is a "portability" interface,
to allow different vendors to plug in their implementation into a
standard presentation block.ContactInfo
associated
with a ClientDelegateContactInfo
.ClientDelegate
to select an
EPT-specific ContactInfo. That ContactInfo
serves as a factory for EPT-specifc
ClientRequestDispatcher
,
Input/OutputObjects
and Connection
.
Aceptor
serves as a factory for EPT-specifc
ServerRequestDispatcher
,
Input/OutputObjects
and Connection
.InputObject
to
retrieve programming language typed data from encoded data sent in a
message.OutputObject
to
post programming language typed data to be encoded and sent in a
message.ClientDelegate
for an
OutputObject
.ClientDelegate
gets an EPT-specific
ContactInfo
.ClientDelegate
uses the chosen
ContactInfo
as a factory to get an EPT-specific
ClientRequestDispatcher
.ClientDelegate
transfers control to the
EPT-specific ClientRequestDispatcher.beginRequest
.
ClientRequestDispatcher.beginRequest
uses
ContactInfo
as a factory to get EPT-specific
OutputObject
, MessageMediator
and
Connection
.ClientRequestDispatcher.beginRequest
may marshal
or set header information on the OutputObject
and it
may execute interceptors (which may add additional header
information) before returning the OutputObject
to the
presentation block. OutputObject methods.
ClientRequestDispatcher.marshalingComplete
.ClientRequestDispatcher.marshalingComplete
sends the
headers and data encoded in OutputObject
on the
Connection
. ClientRequestDispatcher.marshalingComplete
may return
immediately (i.e., an asynchronous message send with no
acknowledgment), may wait to get an indication that the message send
was successfully (i.e., an acknowledged asynchronous send) or wait for
a response (a synchronous message send). The following steps assume
waiting for a response.ClientRequestDispatcher.marshalingComplete
waits for a
response. This may mean blocking on a read of the
Connection
(e.g., SOAP/HTTP), or putting the client
thread to sleep while another thread demultiplexes replies (e.g.,
RMI-IIOP), or using the client thread itself to perform the
server-side operation (e.g., colocation optimization).Connection
it gives
the raw bits of the response to ContactInfo
which creates
an EPT-specific InputObject
and calls
ProtocolHandler.handleRequest
to determine the message
type.ProtocolHandler.handleRequest
determines the
message type (e.g., Request, Response, Error, Cancel, Close, ...).MessageMediator
which
originated the request and wake it up, after having passed it the
response InputObject
.ClientRequestDispatcher.marshalingComplete
may run
interceptors and use reply header metadata befor returning control to
the presentation block.ClientRequestDispatcher.marshalingComplete
would return
the response InputObject
.InputObject
.ClientRequestDispatcher.endRequest
.ClientRequestDispatcher.endRequest
may clean up
resources used in the invocation.Suppose a server support several EPTs.
Acceptor
.Acceptor
is responsible for adding its EPT
information (e.g., address information) to the object reference.Acceptor
acts as a "listener" for client
connection requests.Acceptor
receives a connection request it
creates an EPT-specific Connection
on which to receive
messages.Connection
receives a message, it gives the raw
bits of the message to Acceptor
which creates an
EPT-specific InputObject
and calls
ProtocolHandler.handleRequest
to determine the message
type.ProtocolHandler.handleRequest
determines the
message type.Acceptor
to get an
EPT-specific InputObject
,
ServerRequestDispatcher
and MessageMediator
.ServerRequestDispatcher.dispatch
.ServerRequestDispatcher.dispatch
uses header
information to obtain appropriate presentation block artifacts
(e.g., Ties, DSI handlers).InputObject
.InputObject
and make it available to user
code.ServerRequestDispatcher
for an
OutputObject
.ServerRequestDispatcher
would use the
Acceptor
as a factory to create the EPT-specific
OutputObject
.OutputObject
. ServerRequestDispatcher.dispatch
would send the
header and response data encoded in OutputObject
on
the Connection
.ServerRequestDispatcher.dispatch
may clean up
any resources used in the invocation. ContactInfo
and Acceptor
are the
factories for all other objects involved in a message for a particular
EPT. The question naturally arises, how are these created?