When is a J2EE framework the right solution?

pven wrote:
> frebe wrote:
>
>
>>The big questing is if entity beans should be used or not. I strongly
>>advice you not to use entity beans. The model is flawn and after 5
>>years, Sun has realized this and is rewriting the entire concept.
>>
>
>
> Hi,
>
> I have read some debates on EB and most of them
> are against its usage.
>
> But when I look at it the concept of wrapping a record
> as an object and the container owning the responsibility to
> persist the content to the content sounds very neatfor me.
> (Separation of concerns..... )

I don't like them because very rarily do you work with just a single
table/row. So now you need to encapsulate several tables (and columns)
in a single object. And different "use cases" use different mixes of
tables/rows/columns.

I separate each use case into its own package, then each class therein
acts in concert to satisfy that one use case. Yes, there is redundancy
in SQL code (and some classes), but I have clean separation. Only the
framework is common.

> But when I look at it the concept of wrapping a record
> as an object and the container owning the responsibility to
> persist the content to the content sounds very neatfor me.
> (Separation of concerns..... )
> Can you share on why the concept is flawed ?

Mapping a record to an object is a good solution, but when you select
records from the database, entity beans only allow to to select from
one table. Related records have to be fetched in other database calls.
This can give you very bad performance in a relational database. The
concept would work fine in a network database, but network databases is
not used anymore because the poor querying capabilities and the
problems with data integrity.

Fredrik Bertilsson
http://butler.sourceforge.net

On Wed, 13 Jul 2005 00:27:51 -0700, frebe wrote:

>> But when I look at it the concept of wrapping a record as an object and
>> the container owning the responsibility to persist the content to the
>> content sounds very neatfor me. (Separation of concerns..... )
>> Can you share on why the concept is flawed ?
>
> Mapping a record to an object is a good solution, but when you select
> records from the database, entity beans only allow to to select from one
> table. Related records have to be fetched in other database calls. This
> can give you very bad performance in a relational database.

Are there better alternative (particularly Java based) ???

Thanks

Yes,
OR mappers such as Hibernate or my own http://butler.sourceforge.net.

Fredrik Bertilsson
http://butler.sourceforge.net

On Mon, 11 Jul 2005 06:54:59 GMT, DRM <NoSpamPlease@yahoo.com> wrote:


> Well, I certainly don't want to step on any toes, but as the person who
> will
> be responsible for maintaining the system, I think I've got some say in
> the
> technologies used. Would the following be more appropriate?
>
> 1) The system must be platform-independent.
> 2) The client tier must be completely decoupled from the business
> tier
> using
> open standards and protocols (XML/Soap over http(s)).

Why - what direct business value does this provide ? such a constraint
may well drive the technical architecture in the wrong direction and
compromise scalability and make the system needlessly complex to
administrate
(for example).

> 3) The business tier must be completely decoupled from the model tier
> using
> open standards (ODBC).

How do you know that you need physically seperate "business" and a "model"
tiers -
maybe direct method invocations are the best way ?.
And even if you do - have you (as above) considered the profound effects
such
a constraint may have on the viability of the system going forward.

[ BTW, ODBC is not a protocol for addressing a model - it is a protocol for
addressing a relational database.]

Solve logical problems with logical solutions. Imposing a physical protocol
purely for the purpses of logical decomposition of the system is virtually
guaranteed to be *disaterous*.

Paul C.

On 11 Jul 2005 22:24:08 -0700, pven <prasanth.venkatachalam@gmail.com>
wrote:

> frebe wrote:
>
>> The big questing is if entity beans should be used or not. I strongly
>> advice you not to use entity beans. The model is flawn and after 5
>> years, Sun has realized this and is rewriting the entire concept.
>>
>
> Hi,
>
> I have read some debates on EB and most of them
> are against its usage.
>
> But when I look at it the concept of wrapping a record
> as an object and the container owning the responsibility to
> persist the content to the content sounds very neatfor me.
> (Separation of concerns..... )
>
> Can you share on why the concept is flawed ?
> Is it the implementation of EB by vendors which
> is flawed .. or is it the J2EE specifications that
> do not allow vendors to provide a good implementation.

The EB spec attempts to address too many problems at once -
authorisation, distribution, transactionality and persistence.

However in every system Ive ever seen (or heard of) only
persistence is directly relevent at the entity layer, with
all the others being delt with at the session level.

As a result of this the persistence facet of EB is extremely
clumsy limited and intrusive especially compared with state of
the art O/R mappers like hibernate and toplink.
(I used toplink about 3 years ago and even then it was probaly
3 years ahead of where EJB is *now*).

Paul C.

"paul campbell" <paulc@.o.b.je.ct.vis.sion.co.uk> wrote in message
newspst11wgeod1al5o@main.main...
> On Mon, 11 Jul 2005 06:54:59 GMT, DRM <NoSpamPlease@yahoo.com> wrote:
>
>
>> Well, I certainly don't want to step on any toes, but as the person who
>> will
>> be responsible for maintaining the system, I think I've got some say in
>> the
>> technologies used. Would the following be more appropriate?
>>
>> 1) The system must be platform-independent.
>> 2) The client tier must be completely decoupled from the business
>> tier
>> using
>> open standards and protocols (XML/Soap over http(s)).
>
> Why - what direct business value does this provide ? such a constraint
> may well drive the technical architecture in the wrong direction and
> compromise scalability and make the system needlessly complex to
> administrate
> (for example).
>

The value is that it allows us to more easily integrate applications from
partners by providing an api to our system over standard protocols. If
I know that disparate clients will have to communicate with the system,
why would I use anything other than an open standard?


>> 3) The business tier must be completely decoupled from the model tier
>> using
>> open standards (ODBC).
>
> How do you know that you need physically seperate "business" and a "model"
> tiers -
> maybe direct method invocations are the best way ?.
> And even if you do - have you (as above) considered the profound effects
> such
> a constraint may have on the viability of the system going forward.
>
> [ BTW, ODBC is not a protocol for addressing a model - it is a protocol
> for
> addressing a relational database.]
>

I'm using model tier as a synonym for RDBMS -- yeah, I know they're not
the same thing. I simply require the ability to talk to any RDBMS.

> Solve logical problems with logical solutions. Imposing a physical
> protocol
> purely for the purpses of logical decomposition of the system is virtually
> guaranteed to be *disaterous*.
>
> Paul C.
>
>
>

According to Phlip <phlip_cpp@yahoo.com>:
>
> You are declaring that your highest priority features are...
>
> > 1) The system must be platform neutral.
> > 2) The client/presentation tier must be completely decoupled
> > 3) The system must be able to support 100,000 users
> > 4) talking to a plethora of legacy systems
> > What if the system must support 1,000,000 users
>
> Select the team who tells you they will write an automated test for each of
> those things during the first week, and will pass those tests - alongside
> all the other tests they will write - for the remaining duration of the
> project.

Hmm. If this were my project, I would select that team to explain just
how they propose to accomplish this particular miracle, and short of
a really convincing detailed explanation, fire their sorry asses in favor
of a team that had actually read the requirements and thought about
how to meet them. The first team has shown evidence that they are
a team of yes-men and yes-women who are more concerned with telling you
what they think you want to hear than actually solving the problem
at hand. In all probability, they will happily tell you that everything
is hunky-dory while the project smartly marches off the nearest cliff.

That's not to say that their approach wouldn't work with some detailed sets
of requirements - just that it seems hopelessly unrealistic for
this particular set of requirements. I do acknowledge that I'm not
an expert in this kind of system, but I think even I can tell when
someone is blowing that much smoke at me.

To take the requirements one by one:

1) The system must be platform neutral.

This sounds like the kind of issue that requires a design review rather
than an automated test to assure. Sure, I would expect to see a line
in the overall test plan that specifies acceptance tests to be run on
multiple platforms, but that's not sufficient to assure true platform
neutrality. You need designers who can identify what technologies
are truly portable across the platforms of interest, and implementers
who know how to distinguish between portable and platform-specific code.

2) The client/presentation tier must be completely decoupled
from the business/middle tier. (I should be able to talk to the
middle tier via applets, flash, CE, perl, PHP, etc.)

Again, something that is primarily addressed in an architecture
review. You will probably be able to add tests for individual
communication methods with the middle tier over time, but how
do you plan to test "complete decoupling" of the tiers via an
automated test in week 1? Send the chief architect an email
asking him/her if there are any hidden dependencies?

3) The system must be able to support 100,000 users. (Aside:
how does that translate into concurrent users? 10%?)

Sounds to me like you will need some sort of load simulator
and enough of the system working that you can generate a sample
workload before you can start to test this. How do you plan
to automate this in week 1? Call the stub for "create user"
100,000 times and follow with a couple of transactions?
"Yeah, this test verifies that we can support 100,000 users
as long as only one of them is using the system at a time."

4) The system will be sold to a variety of organizations, so the
system must be capable of talking to a plethora of legacy systems
with no (or minimum) custom programming. For example, we
may need to interface to an existing database for authentication
purposes.

This sounds like an open-ended requirement that will evolve over
the lifetime of the product into many specific examples.
At project start, the best you can hope for is to have a few examples
of such legacy system requirements and think about what common features
might help support them. I really want to know how the proposed
automated test is going to measure the amount of custom programming
required to support a given system.


--
Dave Wallace (Remove NOSPAM from my address to email me)
It is quite humbling to realize that the storage occupied by the longest
line from a typical Usenet posting is sufficient to provide a state space
so vast that all the computation power in the world can not conquer it.

"DRM" <NoSpamPlease@yahoo.com> wrote in message
news:f%xCe.160193$x96.7382@attbi_s72...
>
> The value is that it allows us to more easily integrate applications from
> partners by providing an api to our system over standard protocols. If
> I know that disparate clients will have to communicate with the system,
> why would I use anything other than an open standard?
>
>
>>> 3) The business tier must be completely decoupled from the model
>>> tier
>>> using
>>> open standards (ODBC).
>>
>
> I'm using model tier as a synonym for RDBMS -- yeah, I know they're not
> the same thing. I simply require the ability to talk to any RDBMS.
>

Your requirements are fascinating. I can't help on the core question
(Whence J2EE). Sorry.

That said, it appears that you are putting technical constraints on your
application that could be relieved with a little market research. You say
that you want to connect to every database. I've seen many partners who
write apps to work against both SQL Server and Oracle, but all of the
companies who buy their app use Oracle. In hindsight, it was pretty
fruitless to develop agnostic code.

Same goes for the "platform agnostic" part of it. It is perfectly fine to
write your app in such a way as to make it reasonable to achieve platform
independence, but on the other hand, there is nothing wrong with starting
somewhere first and going to platform and DB independence as a later
innovation.

Many successful products did exactly this. My favorite example is Microsoft
Excel, which released first on the Mac. Windows compatibility was added
later. This was because, at the time, there was no other spreadsheet
competitor on the Mac platform, so the market was wide open. The customers
were on the Mac, so the product went there first.

So, before you add all these technical constraints, consider the features
you need on day one by actually *asking your customers*, not just predicting
how you want to sell it. Go where your customers are, and actually engage
them. You may find that you are making a product that is too complex.

I had an ad agency exec tell me once that he had no trouble getting CEO and
CFO types to come in to his marketing focus group and give an hour of their
time in exchange for a free lunch at the Russian Tea Room. For basically
$150 each, the ad agency exec got some of the heaviest hitters in New York
to tell him really useful marketing information. Lesson: information is
usually undervalued by the person who has it. You'd be surprised how much
you can learn if you simply ask.

By the way, open standards are great. I love 'em.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--