--- old/src/java.corba/share/classes/com/sun/corba/se/pept/package.html 2018-01-30 20:21:08.000000000 -0500 +++ /dev/null 2018-01-30 20:21:08.000000000 -0500 @@ -1,359 +0,0 @@ - - - - - - - -

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.

- -

Related Documentation

- -

-For papers, slides and examples of the PEPt architecture, please see: -

-

- -

PEPt Architecture

- -

-PEPt stands for: -

-

- -

Key PEPt Interfaces

- -

- -

PEPt Client-side Interfaces

- -

- -

PEPt Server-side Interfaces

- -

- -

PEPt Client and Server Interfaces

- -

- -

High-level view of PEPt Operation

- -

PEPt Client-side Operation

- -
    -
  1. Presentation asks ClientDelegate for an -OutputObject.
  2. -
      -
    1. ClientDelegate gets an EPT-specific - ContactInfo.
    2. -
    3. ClientDelegate uses the chosen - ContactInfo as a factory to get an EPT-specific - ClientRequestDispatcher.
    4. -
    5. ClientDelegate transfers control to the - EPT-specific ClientRequestDispatcher.beginRequest. -
        -
      1. ClientRequestDispatcher.beginRequest uses - ContactInfo as a factory to get EPT-specific - OutputObject, MessageMediator and - Connection.
      2. -
      3. 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.
      4. -
      -
    -
  3. Presentation block sets data objects to be sent by calling -OutputObject methods.
  4. -
  5. Presentation block signals the PEPt architecture to send the -message by calling -ClientRequestDispatcher.marshalingComplete.
  6. -
  7. ClientRequestDispatcher.marshalingComplete sends the -headers and data encoded in OutputObject on the -Connection.
  8. -
  9. Depending on the EPT, -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.
  10. -
  11. 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).
  12. -
  13. When a response arrives on the 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.
  14. -
      -
    1. ProtocolHandler.handleRequest determines the - message type (e.g., Request, Response, Error, Cancel, Close, ...).
    2. -
    3. Suppose it is a response to an RMI-IIOP request. In that case - it would find the thread and MessageMediator which - originated the request and wake it up, after having passed it the - response InputObject.
    4. -
    -
  15. ClientRequestDispatcher.marshalingComplete may run -interceptors and use reply header metadata befor returning control to -the presentation block.
  16. -
  17. The presentation block call to -ClientRequestDispatcher.marshalingComplete would return -the response InputObject.
  18. -
  19. The presentation block would get response data objects from the -InputObject.
  20. -
  21. The presentation block would signal the PEPt architecture that -the invocation is complete by calling -ClientRequestDispatcher.endRequest.
  22. -
  23. ClientRequestDispatcher.endRequest may clean up -resources used in the invocation.
  24. -
- -

PEPt Server-side Operation

- -

Suppose a server support several EPTs.

- -
    -
  1. For each EPT, register an Acceptor.
  2. -
  3. If the system supports the concept of an "object reference" then -the Acceptor is responsible for adding its EPT -information (e.g., address information) to the object reference.
  4. -
  5. The Acceptor acts as a "listener" for client -connection requests.
  6. -
  7. When the Acceptor receives a connection request it -creates an EPT-specific Connection on which to receive -messages.
  8. -
  9. When 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.
  10. -
      -
    1. ProtocolHandler.handleRequest determines the - message type.
    2. -
    3. Suppose it is a request. In that case it would read enough - header information to give to Acceptor to get an - EPT-specific InputObject, - ServerRequestDispatcher and MessageMediator.
    4. -
    5. Control would then transfer to - ServerRequestDispatcher.dispatch.
    6. -
        -
      1. ServerRequestDispatcher.dispatch uses header - information to obtain appropriate presentation block artifacts - (e.g., Ties, DSI handlers).
      2. -
      3. As an example, a Tie would be given the InputObject.
      4. -
          -
        1. The Tie would get the request data from the - InputObject and make it available to user - code.
        2. -
        3. In the case of a synchronous message, the Tie would ask the - ServerRequestDispatcher for an - OutputObject.
        4. -
            -
          1. The ServerRequestDispatcher would use the - Acceptor as a factory to create the EPT-specific - OutputObject.
          2. -
          -
        5. The Tie would set the response data (normal or error) on - the OutputObject.
        6. -
        -
      5. ServerRequestDispatcher.dispatch would send the - header and response data encoded in OutputObject on - the Connection.
      6. -
      -
    7. ServerRequestDispatcher.dispatch may clean up - any resources used in the invocation.
    8. -
    -
- - -

Initial ContactInfo and Acceptor Creation

- -

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?

- -
    -
  • From a tool reading service descriptions (e.g., WSDL).
  • -
  • By reading the contents of an object reference (e.g., CORBA IOR).
  • -
  • From a configuration file.
  • -
- -

Other PEPt Interfaces

- -
    -
  • {@link com.sun.corba.se.pept.broker.Broker Broker} - A repository -of resources such as transport managers, thread pools, thread local -data structures, etc.
  • -
- - -