Richard Monson-Haefel wrote:
>
> Charlie Alfred wrote:
>
> > Richard Monson-Haefel wrote:
> > >
> > > 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.
>
That's OK, I suspected from the beginning that we agreed more than we disagreed,
but I guess the "buzzwords" dismissal set me off :-)
>
> 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.
>
The real point that I was getting at is that it's difficult to really define what makes
a component. In this case, I could make an case that the "flight availability search"
tool is a component that might well be represented by a Stateless Session Bean.
It performs a well-defined function with a well-defined API. It has use in several
applications, such as reservation sales, passenger-initiated itinerary changes, and
rebooking due to irregular operations (delays, cancellations, etc.). As a result, it
centralizes business logic and policy decisions (i.e. how much time should be allowed
for flight connections, which fare class is an acceptable substitute for the one the
passenger currently holds, etc).
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.
IMO, this is the force that is behind several of the recent protracted ejb-interest
threads debating subjects like:
* should EJB's be permitted to use threads, or access shared objects that
require synchronization?
* should EJB's have full interoperability with CORBA and exchange security
and transaction context in both directions?
* should certain units of business logic be implemented as EJB's, Servlets,
CORBA objects, or RMI objects?
>
> 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.
>
I agree that relational and object caches pose different design problems. I also agree
that the RDBMS vendors have invested considerable effort in improving their cache
designs and implementations. The only point I was trying to make is that to the best
of my knowledge, RDBMS caches reside on the server host. This means that a network
round trip is required to access their contents.
<vendor>
I have some familiarity with the Javlin product because it's based on Object Store
(which has been working on client-side object-oriented cache technology since
1989). A significant difference in approach is that Javlin's cache management occurs
on the client side (i.e. on each EJB Server host). In addition, they use a patented
approach, known as cache callbacks (AKA lazy lock release), to improve throughput.
In order to make best use of this capability, it helps to use a load-balancing strategy
that routes client operations on a related set of objects to one primary EJB servers
(using one or two others as backups). This strategy might not be applicable for many
applications, because it's difficult or time consuming to determine which objects will
be referenced when the transaction starts. However, in many applications, there are
natural boundaries (product lines, geography, etc.) for establishing effective
partitioning.
</vendor>
>
> 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.
>
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
methods Statement.executeQuery and Statement.executeUpdate contain String
arguments that could be SQL, OQL, or anything else. However, all of the ODBMS's
that I'm familiar with also support navigational access, which doesn't seem to map
to the JDBC model very well. I guess that all the JDBC examples that I've seen to
date all access an RDBMS.
>
> 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.
>
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.
BTW, your last sentence sounds positively JINI-like. What's the chance
of EJB and JINI converging sometime soon?
>
> 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".
