| That sounds good but it also sounds like your either doing
| sql directly (eg. not CMP)which in my view brings with it
| some tradeoffs as well or you're creating a facade to
| other beans - which still needs to be managed carefully
| since the underlying beans need to be manifest for the
| facade to get its data.
Our large applications teams have found that they cannot
build non-trivial applications that perform without having
total control over the SQL to control exactly *how much*
data they need for the task at hand, as well as controlling
(via hand-tuning) exactly the query plan the database query
optimizer should use to get that data. BC4J lets them build
reusable ViewObject components that encapsulate these
queries and *coordinate* the slice/view/joins of information
from *any* SQL queries over the tables/views that store their
business information with the entity beans that encapsulate
their business component's behavior, process, and business
rules.
Our whitepaper explains this in detail so I won't elaborate
here on how this works. Needless to say, the unique thing
about our solution is that unlike what you suggest, we
*don't* need to materialize the entire persistent structure
(can be *large* for non-trivial apps, of course) of the
business entities just to access a small fraction of a slice
of a join of their attributes in an XML message or a Java or
HTML user interface. My use of the word "facade" is not
meant to specifically refer to any textbook meaning of the
word, only that the remotable lightweight proxies we create
can be used as a way to work with the underlying entities
through a specific, restricted view of attributes and
methods of any combination of underlying entities which
remain protected in the server tier and are conciously not
*directly* exposed to clients in their totality.
| In fact, am I right in saying that you don't support
| entity beans at all? Or is this just confusion from the
| recesses of my mind? Unfortunately, I can't seem to get
| hold of your paper so I can't really comment.
An upcoming release of Oracle8i's EJB container will support
EJB Entity Beans. The BC4J framework assists developers to
achieve an optimal application architecture for
"non-trivial" applications by encouraging an EJB
Session-Bean centric approach, managing lightweight entities
internally. Future releases of BC4J may, in addition, offer
the developer the ability to selectively expose our entities
or views over those entities as EJB Entity Beans, but we
focussed on the Session-Bean-centric approach first because
two years of internal prototyping with the framework has taught
us that that more coarse-grained, sevice-centric approach works
best. This strategy appears to be the opposite of what people
experimenting with EJB do, where they *first* start out with
an EntityBean-centric approach, only to realize that perhaps
a Session-Bean-managing-entities strategy is going to work
better as they really scale their prototypes up.
Our Technet site at http://technet.oracle.com/tech/java is
where you can find the paper.
Thanks.
________________________________________________________
Steve Muench, BC4J Development Team & XML Evangelist
http://technet.oracle.com/tech/java
http://technet.oracle.com/tech/xml
===========================================================================
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".
