Re: FW: custom finder in CMPs (SLSB facade)
IMHO, facades are only useful when they do some extra-work, e.g. consolidating the work with many other EJBs. When you just use a facade to plainly forward any request to exactly one EntityBean (1:1 relationship between facades and EntityBeans) than it's not worth the trouble. I am just about to write such 1on1 facades - because I need some extra level of security (checkout original topic of this thread). If I didn't have to cope with such security issues, I wouldn't use these facades; I'd rather prefer to directly communicate with my EntityBeans (for the sake of simplicity). Yours Armin Michel --- On Monday 07 May 2001 10:07, you wrote: The call to a SFSB cause you (with Orion) at max the additional penalty of an extra Activation and Passivation cycle. Depending on the amount of resource usage for these extra cycli as percentage of the overall resource usage, the use of SFSBs will hit you. The thing which puzzles me is why not go to the Entity Bean directly itself? It saves both computer and programming resources. In all discussions and readings I have found no decent arguments that prevent me from going direct, unless you throw in the -valid- information hiding argument. The system I'm working on uses a Swing client. Most important reason: Using an application client you can validate user input the moment it gets entered. One of the things we do is validating keys against the server the moment someone has entered the complete key. The validation is done against the Entity Bean itself, not against a facade. Now I know that the quality of constructive comments does not necessarily have a positive correlation with the price of a suite, but an expensive (and thus highly regarded) consultant claimed that using a SLSB facade is better. I still can't figure out why (although I do agree that the extra performance overhead is little), so I'm tending to the position that it's probably bollocks. Stuborn at the risk to get shot ... FE
Re: FW: custom finder in CMPs (SLSB facade)
Armin Michel wrote:
IMHO, facades are only useful when they do some extra-work, e.g.
consolidating the work with many other EJBs.
When you just use a facade to plainly forward any request to exactly one
EntityBean (1:1 relationship between facades and EntityBeans) than it's not
worth the trouble.
Except if there's a need to keep the design uniform. I am always using a
following layered architecture in my J2EE applications:
+---+---+ +---+---+---+
| P | I | | S | D | P |
| r | n | | e | o | e |
| e | t | | r | m | r |
| s | e | | v | a | s |
| e | r | | i | i | i |
| n | a | | c | n | s |
| t | c | | e | | t |
| a | t | | | | e |
| t | i | | | | |
| i | o | | | | |
| o | n | | | | |
| n | | | | | |
+---+---+--+---+---+---+
|Framework |
+--+
Presentation and interaction layers are deployed on web container.
Presentation layer contains HTML, WML or XML specific code (e.g. JSP tag
extensions). Interaction layer contains MVC command classes and
presentation related model components. The rest of the tiers, service,
domain and persistence are deployed on EJB container. Service tier,
implemented as session beans, provide the use case implementations and
serves them as a facade to the interaction tier. Domain layer contains
CMP entity beans and dependent objects. Persistency tier contains
possible data source specific code. For instance BMP entity beans. The
framework package contains some common classes used everywhere. I
usually deploy the framework jar file to ${JAVA_HOME}/jre/lib/ext.
The good thing about this architecture is that it is easy understand
even complex use case realizations since every use case follow exactly
the same design. The bad thing is that it requires some extra code (and
an extra EJB call) when doing simple things (like mentioned in previous
mails). But I later hope to resolve this extra programming overhead by
using code generators.
--
Joni
[EMAIL PROTECTED]
RE: FW: custom finder in CMPs (SLSB facade)
Not at all, I completely disagree (well not completely, but often ;))
As for the previous poster, SLSB facades are useful whereever they perform
more than one call on an entity bean because the potential network round
trips are reduced.
Example:
Swing Client - SLSB (travels over the network) - EJB (on the server all
the time)
SLSB.setOneTwo(String foo, String bar)
{
EJB.setOne(foo);
EJB.setTwo(bar);
}
You've just reduced your network calls by 50% over going to the EJB
directly.
(Note: I know this is a grossly simplified example but I hope it illustrates
the point)
-mike
Mike Cannon-Brookes - Founder, Core Developer
OpenSymphony - http://www.opensymphony.com
The Open Source J2EE Component Project
Latest News
- Cache in on faster, more reliable JSPs
http://www.javaworld.com/javaworld/jw-05-2001/jw-0504-cache.html
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Armin Michel
Sent: Monday, May 07, 2001 8:32 PM
To: Orion-Interest
Subject: Re: FW: custom finder in CMPs (SLSB facade)
IMHO, facades are only useful when they do some extra-work, e.g.
consolidating the work with many other EJBs.
When you just use a facade to plainly forward any request to exactly one
EntityBean (1:1 relationship between facades and EntityBeans)
than it's not
worth the trouble.
I am just about to write such 1on1 facades - because I need some
extra level
of security (checkout original topic of this thread). If I didn't have to
cope with such security issues, I wouldn't use these facades; I'd rather
prefer to directly communicate with my EntityBeans (for the sake of
simplicity).
Yours
Armin Michel
---
On Monday 07 May 2001 10:07, you wrote:
The call to a SFSB cause you (with Orion) at max the additional
penalty of
an extra Activation and Passivation cycle. Depending on the amount of
resource usage for these extra cycli as percentage of the
overall resource
usage, the use of SFSBs will hit you.
The thing which puzzles me is why not go to the Entity Bean directly
itself? It saves both computer and programming resources. In all
discussions and readings I have found no decent arguments that
prevent me
from going direct, unless you throw in the -valid- information hiding
argument.
The system I'm working on uses a Swing client. Most important
reason: Using
an application client you can validate user input the moment it gets
entered.
One of the things we do is validating keys against the server the moment
someone has entered the complete key. The validation is done against the
Entity Bean itself, not against a facade.
Now I know that the quality of constructive comments does not
necessarily
have a positive correlation with the price of a suite, but an expensive
(and thus highly regarded) consultant claimed that using a SLSB
facade is
better.
I still can't figure out why (although I do agree that the extra
performance overhead is little), so I'm tending to the position
that it's
probably bollocks.
Stuborn at the risk to get shot ...
FE
Re: FW: custom finder in CMPs (SLSB facade)
The thing which puzzles me is why not go to the Entity Bean directly itself? It saves both computer and programming resources. In all discussions and readings I have found no decent arguments that prevent me from going direct, unless you throw in the -valid- information hiding argument. Because you may be accessing more than one EB via the SLSB, as I explained in my previous posting. Did you read it? I specifically CC-ed you on that email. Now I know that the quality of constructive comments does not necessarily have a positive correlation with the price of a suite, but an expensive (and thus highly regarded) consultant claimed that using a SLSB facade is better. I still can't figure out why (although I do agree that the extra performance overhead is little), so I'm tending to the position that it's probably bollocks. Unless you consider network latency. I take it you have not done I lot of RPC programming in your many years as a developer? Stuborn at the risk to get shot ... Cocking gun... ;) tim.
Re: FW: custom finder in CMPs (SLSB facade)
Another important thing to consider is transactions. If you have several setX methods that you want to call on the entity bean, and their transaction type is required, then you either have to handle the transaction in your client or pass the transaction handling off to a SLSB by making one method in the SB that does all the setX calls on the entity bean (with the transaction type set to required, as well). Just remember that if you call a method on a bean that needs a transaction, and you don't have one started yet, then when that method completes an ejbStore call is made. If you want those setX methods to be in a single transaction, I personally prefer putting the burden of that on the EJB Container vendor by moving all those calls inside a SLSB. Jeff Hubbach. Frank Eggink wrote: The call to a SFSB cause you (with Orion) at max the additional penalty of an extra Activation and Passivation cycle. Depending on the amount of resource usage for these extra cycli as percentage of the overall resource usage, the use of SFSBs will hit you. The thing which puzzles me is why not go to the Entity Bean directly itself? It saves both computer and programming resources. In all discussions and readings I have found no decent arguments that prevent me from going direct, unless you throw in the -valid- information hiding argument. The system I'm working on uses a Swing client. Most important reason: Using an application client you can validate user input the moment it gets entered. One of the things we do is validating keys against the server the moment someone has entered the complete key. The validation is done against the Entity Bean itself, not against a facade. Now I know that the quality of constructive comments does not necessarily have a positive correlation with the price of a suite, but an expensive (and thus highly regarded) consultant claimed that using a SLSB facade is better. I still can't figure out why (although I do agree that the extra performance overhead is little), so I'm tending to the position that it's probably bollocks. Stuborn at the risk to get shot ... FE -- Jeff Hubbach Internet Developer New Media Designs, Inc. www.nmd.com
