[jboss-as7-dev] More! EJB Remote client design

[David M. Lloyd]

Here's some more EJB client stuff.

Interceptors
------------

Client interceptors are really a different beast than server 
interceptors.  On an EJB, particularly one which is invoked 
asynchronously, the traditional blocking wrapping interceptor just 
doesn't do the job anymore.  An EJB client interceptor needs two 
methods: one for the request and one for the response.  Also, the 
interceptor context for an EJB client interceptor may need to be 
protocol-aware to attach byte payloads to the request.

Because of these extra requirements, using the jboss-invocation library 
on the client does not seem appropriate.  Instead, we'll have to have a 
separate client interceptor notion.  I have a rough prototype which I'll 
push up to my repository sometime today.

Handles
-------

EJB handles and home handles (as used by home interfaces) must be a part 
of the client library in order to produce the proper proxies.  This will 
ultimately include Entity EJB handles too.  I have that stuff roughed 
out here (see the EJB*Handle.java files):

https://github.com/dmlloyd/jboss-ejb-client/tree/master/src/main/java/org/jboss/ejb/client

EJB Verify
----------

It has been pointed out that there may be a mode of operation in which 
we verify the existence of an EJB before we try to do anything with it. 
  While such verification doesn't really give any guarantees, it can at 
least help avoid simple errors in some situations.  I've provisionally 
added an EJB verify request & response to the protocol spec (see 2.2¾. 
and 2.2⅞.).

Affinity
--------

There are certain cases which will require various kinds of affinity. 
If a ClientUserTransaction is in force, then a client invocation context 
has an affinity to a specific Receiver for the duration of the 
transaction.  Proxies may have an affinity to a protocol type.  Stateful 
session EJBs and Entity EJBs may "stick" to a Receiver.  Thus the 
concept of temporary affinity at various scopes must be introduced and 
needs a bit further discussion.


-- 
- DML