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?