JBoss development, The document "Requirements: EJB Proxies", was updated Mar 17, 2010 by David Lloyd. To view the document, visit: http://community.jboss.org/docs/DOC-14983#cf Document: -------------------------------------------------------------- This is a requirements document for EJB proxies.  *Please direct questions and comments to this thread:* http://community.jboss.org/thread/149477   Please do *not* remove any sections.  If a requirement is to be removed, please strike it out so that the numbering remains consistent.   * #Invocation_Dispatch ** #Invocation_Components *** #Proxy_Invocation_Handler *** #Invocation **** #Serialized_Format *** #Invocation_Processor *** #Invocation_Dispatcher **** #Default_Simple_Implementations *** #Invocation_Target *** #Client_Invocation_Context **** #Local_Invocation_Processor_Chain **** #Remote_Invocation_Forwarder_Registry **** #Remote_Invocation_Forwarders *** #Server_Invocation_Context **** #Exportable_Dispatchers * #Remote_Proxies * #EJB_Proxies ** #Remote_Proxies_915629 *** #Invocation_554653 **** #Proxy_Deserialization_Constraints ***** #Remote_Invocation_Context **** #Proxy_Serialization_Constraints ***** #Remote_Invocation_Context_489119 *** #High_Availability_and_Clustering h1. Invocation Dispatch h2. Invocation Components h3. Proxy Invocation Handler The invocation handler of an EJB proxy shall convert the invocation details into an +Invocation+ object which contains the details of this invocation. The invocation will then be passed to an +Invocation Processor+ to be handled. h3. Invocation The +Invocation+ object shall consist of the reflection Method which was invoked, as well as the parameters of the method invocation.  In addition, it shall provide an +Attachment+ mechanism by which contextual information may be associated with the Invocation (for example, security and transactional information). h4. Serialized Format The serialized format of the invocation should consist of no more or less than a means to identify the target method, the arguments passed to the target method, and the set of attachments which are associated with the invocation. h3. Invocation Processor A mechanism shall be provided by which each Invocation may be preprocessed in one or more steps before it is +dispatched+ to its final target.  Such processors should have the opportunity to add, remove, or modify Attachments on the Invocation.  Processors should also have the opportunity to "short-circuit" an invocation and reply directly, either with a successful return or an exception of some sort. h3. Invocation Dispatcher The Invocation Dispatcher represents the path to the target of the Invocation and shall have the ability to execute an Invocation.  For Remote proxies this typically will entail transmitting the Invocation across the network in some form, to be received and forwarded to another Invocation Dispatcher to be executed directly, or passed through another set of Invocation Processors which may or may not correspond to the sending side's Processor set before handing it to a Dispatcher to be executed.   Since the Invocation Disptacher is solely responsible for the execution of the method, it can and should impose whatever policy is appropriate for the management of any target objects which may exist (such as a registration policy, or instance pooling, or session management).  The Dispatcher need not correspond to one single target object instance, though that may be the common usage outside of EJB. h4. Default (Simple) Implementations A Dispatcher implementation shall be provided which calls the Invocation method on a given fixed Object.   A Dispatcher implementation shall be provided which passes an Invocation through an Invocation Processor to a delegate Invocation Dispatcher. h3. Invocation Target The +target+ of an Invocation is an object upon which the Invocation is ultimately intended to be executed.  Since there is not always a one-to-one correspondance between a remote proxy and a target instance, the task of passing an invocation to a target is always fulfilled by an +Invocation Dispatcher+. h3. Client Invocation Context A +Client Invocation Context+ is an environment which is aware of how to forward Invocations from an +Exported+ Dispatcher to its corresponding +Server Invocation Context+(s). h4. Local Invocation Processor Chain Each Client Invocation Context has a local Invocation Processor chain which is used for any Invocations which are sent through an exported Dispatcher.  The purpose of this Processor chain is to associate any local context - such as transactional or security information - with the outbound Invocation, to be consumed the the Processor chain on the receiving side. h4. Remote Invocation Forwarder Registry The Client Invocation Context shall maintain a registry of +Remote Invocation Forwarders+ which are responsible for forwarding Invocations to the appropriate destination +Server Invocation Context+.  The registry is keyed by a +Server Invocation Context Identifier+.  This registry may be maintained statically or by some dynamic detection mechanism. h4. Remote Invocation Forwarders A Remote Invocation Forwarder is responsible for implementing the transport layer for forwarding an Invocation to a specific Dispatcher in a specific Server Invocation Context.  A Forwarder may forward to exactly one Server Invocation Context, or it may have a clustering policy of some sort.   Forwarders may have a specific policy for dealing with connection or networking failures, changes in networking topology, or any other transport-specific concerns. h3. Server Invocation Context A +Server Invocation Context+ is an environment which can receive and act upon incoming remote Invocations.  In addition, a Server Invocation Context has an associated Client Invocation Context which is responsible for handling outbound Invocations as well as Invocations which are handled locally by the Server Invocation Context. h4. Exportable Dispatchers In order for a Dispatcher to be sendable to, and usable by, Client Invocation Contexts (i.e. Serializable), it must be exported via the Server Invocation Context which "owns" it.  This registration may optionally include an Invocation Processor which should be applied to any Invocation before it is passed to the corresponding local Dispatcher.   Any exported Dispatcher shall always be processed by the current Client Invocation Context.  When a Server Invocation Context is active, the Server Invocation Context's associated Client Invocation Context shall be used to process Invocations.  The local Invocation Processor chain associated with the Client Invocation Context shall always be used to process Invocations, even if the Invocation is forwarded to the currently active Server Invocation Context. h1. Remote Proxies h1. EJB Proxies h2. Remote Proxies h3. Invocation Proxy Serialization and Deserialization When a proxy is deserialized, it is expected that the deserialized Proxy will be functional regardless of where and when the proxy is deserializaed.  There shall be constraints on the functionality of deserialized proxies, as follows. h4. Proxy Deserialization Constraints h5. Remote Invocation Context In order for a proxy to be functional after deserialization, it shall be required that the user provide, directly or indirectly, a +Remote Invocation Context+ which is necessary to fully reconstitute a working remote proxy.  Proxy instances which are deserialized without the presense of such a context will not be usable and will cause an exception to be thrown upon invocation. h4. Proxy Serialization Constraints h5. Remote Invocation Context A proxy must be serialized in the presence of a Remote Invocation Context.  Attempting to serialize a proxy without such a context will cause an object validation exception.  A remote invocation proxy will be associated with a Remote Invocation Context, which may contribute to the serialization of a proxy.   h3. High Availability and Clustering --------------------------------------------------------------