Hi all,
The topic has been introduced once before, but I did not see any
(satisfactory) answers posted to that one, and hence this one.
One of the 'features' of the new EJB 2.0 local interface architecture is
the Pass-by-Reference (PbR) semantics. Before I go on, I do have to mention
that my views might be wrong on technical matters, given that I am not
a developer (read R&D) merely a user of our j2ee product. So please do
not beat the s**t out of me because of my ignorance :)
That aside, the EJB 2.0 PFD 3 states the following w.r.t
local & remote client views: (I have 'briefed' it even further)
(a) Narrowing remote types requires javax.rmi.PortableRemoteObject.
narrow() rather than Java language casts.
(b) The client has to explicitly program handlers for remote exceptions.
(c) Local calls involve pass-by-reference, Remote calls involve
pass-by-value
(d) Such (remote) calls are still likely to be less efficient than calls
made using the local interface.
Now lets take two common cases:
Case (1) Entity Bean - Session Bean communication (in-process)
Case (2) Session Bean - Session Bean communication (in-process)
Case (1): Assuming CMP (EJB 2.0), the most common cmp fields
are of these types:
- int (or wrapper type java.lang.Integer)
- similarly boolean/Boolean byte/Byte char/Character
double/Double float/Float long/Long short/Short and String
- Dates (java.sql.Date java.sql.Time java.sql.Timestamp java.util.Date)
- CMRs: but 'drilling' down would result in the above types(?).
The common usage of case 1 would be in a session facade.
Now the ejb 2.0 PFD 3 states the following (5.4)
<spec>
Because the local programming model provides lighter weight access to
a component, it better supports more fine-grained component access.
<spec>
Now if the above mentioned field types are used as method parameters,
then PbR has no meaning here because most of the field types are
immutable. So I do not care if I use PbV or PbR. PbR might be faster
as it avoids argument copying, but any quality ejb container should
detect in-process calls and optimize those calls by avoiding
unnecessary argument copying (say in this case of immutable objects)
even if using remote interfaces (EJB 1.1 - and I'm assuming they'll
run as-is on a EJB 2.0 container as well. Don't know if companies are
going to spend time and money rewriting their 1.1 compliant app to a
2.0 one)
Taking the case of value objects, if an entity bean creates a value
object (representing its CMP or subset of CMP fields) and returns this
value object to a session bean in the same process using PbR
semantics, I still cannot modify immutable CMP fields by just setting
these in the value object. Performance of course might be faster
because the ejb container does not perform a copy of the value object
when returning it to the session bean via its local interface,
but as an ejb developer, I cannot do any fancy PbR thingies with
the value object unless of course I use mutable objects as CMP field
types.
So summing up *case 1*, PbR does not bring in any additional
benefit/features to an ejb developer when using mostly immutable
CMP fields. The only additional benefit could be an increase in
performance, which might not even be the case in the case of a
quality ejb container implementation which already optimizes
in-process calls and avoids unnecessary argument copying (eg:
arguments need not be copied for PbV if they are immutable).
And if I do have a few mutable CMP field types (say java.sql.Timestamp)
mixed in with other immutable CMP field types, I want a consistent
view of that entity bean's fields which I do not get - why? because
some fields (mutable) have PbR while for other (immutable) fields it
does not matter (whether I use PbR or PbV - since I cannot modify the
field anyways).
Case (2): There might be benefits in PbR semantics for Session Bean-Session
Bean communication with mutable java objects. Here again, in most
implementations I have worked on, we used normal java classes that had
most of the logic implemented in it and these were called by session
beans in which case, you would get PbR by Session Bean -> Java classes
communication. I.e. we minimized the code (business logic or whatever
you may prefer to call it) within a session bean implementation class
preferring to put those in separate classes _callable_ by EJBs (so you
do not miss out on transactions/concurrency/security, though there
are many cases where I have encountered & used session beans calling one
another). But this is not we are discussing here and I'll leave it at this:
PbR semantics could provide value (no pun intended) for money if
mutable java objects were being passed around [and modified] by
in-process session beans.
So, after all this ranting, is this what PbR implies?:
- Less code, easier to read, maintain (No PRO.narrow, No remote exception
handling etc). For a developer who uses a [j2ee] developer-friendly IDE
and frameworks for exception handling, the gains are marginal.
- In case 1 - for immutable CMP field types, PbR does not provide any
additional benefit (or noticeable performance gains). Even the
value object pattern will not change things. So for an ejb developer,
to take advantage of PbR in case 1, (s)he will need to use mutable
CMP field types (see below) when s(he) might be happy otherwise.
(OODBMS anyone? ;)
- Now patterns and strategies will start appearing that take advantage
of PbR semantics. This would be good thing if you took it with
a pinch of salt. However, I fear PbR might be overused/overrated i.e.
developers might be misled into using PbR when there is no need for PbR
in the first place. A typical case of "Hey ... this feature is cool and
everyone's talking about it - let's use it (regardless of whether it
provides any additional value/benefit)".
- vendors who have not optimized in-process calls (and CMP performance)
will 'claim' that the EJB 1.1 spec was to blame (for their EJB 1.x
product performance) and the new EJB 2.0 spec makes their EJB 2.0
offering better performant than their EJB 1.x offering ... but we'll
leave those discussions to the marketing guys ;)
Comments ... ?
-krish
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
