> The folks who drafted the EJB spec had a certain prototypical application in mind:
>
> * Short, highly-repetitive transactions
> * Components with significant, but relatively lightweight business logic,
> * Persistent storage in a relational database (i.e. JDBC as standard API)
>
> The difficulty is, as we've seen from many recent ejb-interest threads, that the
> EJB model offers several significant advances (such as support for scalability,
> load balancing, and failover) that make it attractive to applications that don't
> quite fit the "prototypical EJB application" profile.
There is a very simple reason for that. Applications that fall under the
above categories yield extremely well to load balancing and failover
through generic APIs. Applications that fall outside of it (e.g. a JDBC
driver, threaded mechanisms, caches, etc) do not yield easily to load
balancing and failover.
The second category of applications can still use certian J2EE features,
like transactions, connectors, JNDI lookup, security, but they cannot be
easily supported by a stock EJB container. This is where you have to
write more code to achieve functionality that you might see EJB as
giving for free (it doesn't).
These arguments are not a limitation of the EJB spec, they are
consistent across the model, whether it's MTS, Tuxedo, CISC, etc.
> Are you saying that the JDBC API can be effectively applied to an object storage
> model? I agree that nothing in the JDBC spec is tightly bound to SQL. The API
Theoretically, but I don't see that happening too quickly. Microsoft has
used ADO (more high level JDBC) to access Exchange and other resources.
I don't believe the industry has bought into it, just too complicated.
If I had to give you access to some other storage model, I would most
probably write a resource manager with a different API, or model entity
beans around it, then try to hammer JDBC to work with it.
> Agreed, although with one clarification/question. My understanding of the EJB spec
> is that it requires all references to EJB's to be to the container object, never the
> bean itself. However, I had understood that EJB Server's were free to optimize
> the local call case (i.e. the client stub calls the container API directly, rather
>than
> going through RMI) without breaking that contract. I agree that there's still extra
> overhead using EJB's instead of Java objects. However, depending on how involved
> the processing is inside of these methods, this overhead might be insignificant.
An EJB server can optimize the local calls, but from the prespective of
an application developer, you have to regard it as a remote call.
You can safely assume that a local call between Bean A and Bean B will
not result in a network failure. But down the road you might move Bean B
to another server, or access someone else's remote server. Lack of
proper handling in Bean A will cause it to fail in such circumstances.
EJB tries to define an environment where you take these issue into
consideration, and then an EJB container can perform certain
optimizations for local calls.
> BTW, your last sentence sounds positively JINI-like. What's the chance
> of EJB and JINI converging sometime soon?
None. The two are designed to solve totally different problems. From a
larger perspective they look the same, but they give different
guarantees in term of how the application will work, and have different
implementations.
Sun has a good article on their Web site (can't remember where)
explaining the differences.
arkin
>
> >
> > I agree completely that a heuristic method, rules, or patterns are much more
>valuable then
> > rules of thumb. But I think we know this already and we understand from the
>beginning that
> > a rule of thumb is not a law, its a generality that is applicable in many but not
>all
> > situations. That said, we should strive to develop architecture patterns that can
>be used
> > as a guide and template for choosing and applying the correct solutions.
> >
>
> Absolutely. All I'm saying is that along with the pattern, it's essential to
>describe the
> situations where use of the pattern is not advised (or risky). It's just like
>marketing
> some prescription drug as a solution to some medical condition. It's pretty crucial
> to mention the conditions that this drub exacerbates, or the other medications that
> it interacts poorly with.
>
> Regards,
> Charlie
>
> ===========================================================================
> 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".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
