Charlie Alfred wrote:
> Richard Monson-Haefel wrote:
> >
> > Charlie Alfred wrote:
> >
> > >
> > > Would you also say that this analysis holds true if the EJB Server supports
> > > in-memory caching of read-mostly Entity Beans? Or, if it uses an EJB-side
> > > hot-cache with multi-version concurrency control, like eXcelon Corp's Javlin
> > > product?
> >
> > Nice collection of buzz words, but most of them don't mean much in the context of
> > this discussion.
> >
>
> I'm sorry that all you took away from my question was a list of buzzwords.
> Let me try to make my point more clearly, because I still think that the
> original question was relevant to the thread.
Sorry about that little snipe, Charlie. It was inappropriate comment and generally not
my
style.
>
>
> If I'm not misrepresenting your last post, you said that high-volume read-only
> operations (i.e. product catalogs, etc.) should be performed with Servlets and
> JDBC, and EJB should be reserved for the update-style transactions (i.e.
> making purchases).
Well it *is* a rule of thumb; not a law.
>
>
> In general, I agree with your advice, however there are several cases where
> things aren't that simple. You allude to these cases near the end of your post,
> but I'd like to take a few minutes to explore one. Consider an airline reservations/
> customer service system. Some transactions (reservation purchase, passenger
> check-in, etc.) fall into the high-volume update category, and would be a
> natural fit for EJB.
Your example of an Airlines reservation system is a good one. In my opinion it doesn't
really fall within the same category as the systems I was recommending for Servlets.
In
your example you describe the flight search system as being "transactional" and the
requirement that data be "isolated". This sounds like a OLTP system to me. You also
describe fairly sophisticated business logic for figuring out logistics. The system
you
describe is more sophisticated than systems I was referring too. Of course its quite
possible that in my effort to convey a "rule of thumb", I didn't express myself clearly
enough. I accept the blame for that.
> > Lets face it, relational databases have been working on their cache technology for
>a
> > couple of decades (or more) while the EJB vendors have been developing it for a few
> > years (at best).
>
> So? United, Delta, and American Airlines have been operating for at lot
> longer than SouthWest Airlines. Does this mean that they are way ahead on
> their flight planning, piloting, or maintenance technology learning curves?
>
> Experience has a way of spreading. I'd be surprised if most of the EJB vendors
> are trying to figure out how to design caching mechanisms, rather than leveraging
> the current state of industry research.
A RDBMS cache is quite a bit different from an Object cache because the data and
pointers
are organized differently. My point is that the relational world has had a lot of
time to
figure out how to cache data in their paradigm compared to the object world AND that
the
relational caches are, IMO, more mature and performant.
> > When I need to share a database across several systems (legacy and
> > modern) I'll leverage a relational database cache so that all systems benefit from
>a
> > consistent view of the data.
>
> Agreed. Especially for data where the frequency of update (across all database
> clients) exceeds the frequency of access.
>
> > On the other hand, if I have a complex object model and
> > only access the database through one platform (like Gemstone/J) then an object
>cache
> > is great performance gain. Gemstone for example can maintain something like 6 Gig
>of
> > object cache in memory -- that's incredible and valuable under the right
>conditions.
> >
>
> This is essentially the point that I was making above with the airline example.
> Gemstone provides this capability. Javlin provides it for WebLogic server.
> I'm sure that other vendors do, as well.
Good. I'm glad we agree.
> > >
> > > However, unless I'm missing something, if the relevant info is cached then
> > > this overhead is significantly reduced on the EJB case. Its performance
> > > would be much closer to the straight JDBC case for the simple case (i.e.
> > > select of fields from few tables with simple joins). In the case where
> > > the read-mostly data takes on a more complex, object-oriented structure
> > > (such as a product catalog with lots of cross-references) the EJB cache
> > > might even have a much lower impedence mismatch for the Servlet.
> > >
> >
> > There is no impedance mismatch issue with Servlets and JDBC. You access the data
>in
> > the same way its organized, relationally. There is, however, an impedance mismatch
> > anytime you model your business in objects and persist them to a relational
>database.
> >
>
> This assumes that the Servlets want to "see" them organized relationally.
> If the Servlets perform operations that require an object model (i.e. if
> we did the flight availability search example from above in a Servlet)
> then the impedence mismatch definitely exists.
How the Servlets "want to see" the data depends on how you design the servlets. If you
decide the servlets need an object model view of the data, but you use straight SQL,
then
*you* are introducing the impedance mismatch. Its not inherent in the use of JDBC from
Servlets.
>
>
> > But this is besides the point. EJB is not objects in the purest sense of the
> > concept, they are components.
>
> I'm not sure why this discussion is relevant. Yes, components exist at a
> higher level of granularity than objects. Yes, it's appropriate to decompose
> a EJB component into a set of finer-grained objects. However, at some
> level, any component (implemented using EJB or any other mechanism) has
> a set of functionality and quality of service requirements. And the choice
> of how to design it must be driven by them.
Object are built on the premise that references are immediate; that they exist in the
same
address space. This makes objects incredibly flexible. Distributed components like
EJB, do
not assume local references which introduces a lot of complexity having to do with
particle
failure, latency, newtwork awareness (location transparency in distributed computing
is a
myth.), etc.
>
>
> The Servlet vs. Session Bean question is an appropriate one. And while I'm
> generally in favor of rules of thumb, I think that broad generalizations
> such as "EJB is appropriate for high volume transactional sites like an
> electronic trading site, but for sites that provide read-only access to
> product catalogs or primarly textual material (documents, articles, etc..)
> with no transactional requirements" can be misleading if taken out of
> context.
>
> Isn't it better to highlight the issues that should be considered in framing
> the decision. I'm a big fan of Design Patterns, and what I particularly like
> is the fact that the standard format covers:
>
> a. a description of what the solution is and what problem it addresses,
> b. what forces operate that make this solution attractive, and
> c. what forces might also be present that reduce the attractiveness
> of the solution.
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.
Thanks,
Richard
--
Author of Enterprise JavaBeans
Published by O'Reilly & Associates
http://www.EjbNow.com
EJB FAQ
http://www.jguru.com/faq/EJB
===========================================================================
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".
