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?