When is a J2EE framework the right solution?

We are currently interviewing consulting/architect/development
groups for a new web-based project. The winner of this project
will architect, design and develop the project. Currently, we have
no expertise in the Java world and we want to make sure that we
get the architecture right the first time (assumng that's possible).
Some of our interviewees recommend going with a J2EE
framework whereas others claim that it's overkill and/or bloated.
Given the following minimum requirements, which group is
correct?

1) The system must be platform neutral.

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.)

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

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.

5) Cost is not a factor.

6) Speed is a factor. We want a system tested and running
within 9-12 months.


We foresee the need for distributed transactions down the road.
Would this influence your decision. Would this influence the
architecture of the system or the design pattern that you would use?

What if the system must support 1,000,000 users -- would this
influence your decision?

If other newsgroups are appropriate, please adjust headers.

Thanks!

I'm no expert, but it seems like what you need to know is how successful the
potential group has been at implementing similar systms for other clients,
-not- what technology they used to do it.

The group you will hire contains the people qualified to determine what the
platform should be, not you. If you choose a technology first, you're making
the decision with insufficient exprience to do so, and also artificially
limiting the number of groups you might be able to recruit to do the work.

On Sat, 09 Jul 2005 21:03:19 GMT, "DRM" <NoSpamPlease@yahoo.com> wrote:

>
>We are currently interviewing consulting/architect/development
>groups for a new web-based project. The winner of this project
>will architect, design and develop the project. Currently, we have
>no expertise in the Java world and we want to make sure that we
>get the architecture right the first time (assumng that's possible).
>Some of our interviewees recommend going with a J2EE
>framework whereas others claim that it's overkill and/or bloated.
>Given the following minimum requirements, which group is
>correct?
>
> 1) The system must be platform neutral.
>
> 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.)
>
> 3) The system must be able to support 100,000 users. (Aside:
>how does that translate into concurrent users? 10%?)
>
> 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.
>
> 5) Cost is not a factor.
>
> 6) Speed is a factor. We want a system tested and running
>within 9-12 months.
>
>
>We foresee the need for distributed transactions down the road.
>Would this influence your decision. Would this influence the
>architecture of the system or the design pattern that you would use?
>
>What if the system must support 1,000,000 users -- would this
>influence your decision?
>
>If other newsgroups are appropriate, please adjust headers.
>
>Thanks!
>
>
>

DRM wrote:
>
> We are currently interviewing consulting/architect/development
> groups for a new web-based project.

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.

Your question is essentially this: "How can I tell the team I pick now will
write something that still has these features a long time from now, after we
start deploying?" The answer is you cannot. Your team could pick J2EE, or
Ruby on Rails, or Apache with mod Perl, or COBOL, and their programs'
performance now will have nothing to do with its performance after they have
loaded it up with all the business features you will request.

Pick a team known to do good work with a low defect rate and a fast
turnaround on feature requests. Such teams typically write automated tests
for everything they do, as they write the tested code. The team should not
treat you as their QA department. They _should_ provide a new version, with
new bug-free features, every few days. Give them small enough feature
requests so they can develop incrementally.

Order that team to implement the most important features first. This is so
you know you have those features, and so their tests will constrain the
development of all future code. Nobody will be able to make a mistake, and
put a bottleneck into the system, if the test that supports 100,000 users
per day (or 500 per second) fails. They will immediately back out that
mistake and try again.

Writing tests in order of business priority is an incredibly powerful way to
constrain development, so all future changes support the most important
goals.

I'm against J2EE myself, but you will find many Java programmers who write a
ratio of test to production code > 3:1.

--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand

The biggest adavantage you stand as a firm with J2EE is the number of
people available in the market who have the skill in using the
platform.

However, the biggest factor you need to consider is the selection of an
architect who had or designs the system considering your requirements
of the user-base size.

With a possible user base of 1,000,000, the infrastructure components
like load balancers, clustering etc would need to come in to play to
help you provide through put. Here, the architect has to consider this
and plan the design on J2EE accordingly.

An example: the biggest bottle neck for any system is the retreival of
data from the data store. For your system, lets say if I have an RDBMS
with 100 tables, the architect should layer all the database
transactions ( beans that retreive data, update data ) as a separate
service and this service should be hosted on the database server. The
database server should be a cluster running the RDBMS alone. All other
business processes should be running on a separate servers...

Also, there is no support for multiphase transactions that cross system
boundaries in J2EE. You will have to design and build the system for
this which can be pretty complex....

"Steve Jorgensen" <nospam@nospam.nospam> wrote in message
news:1963d1l1if2m69f4mhpgk5iv8rn60hhlr8@4ax.com...
> I'm no expert, but it seems like what you need to know is how successful
> the
> potential group has been at implementing similar systms for other clients,
> -not- what technology they used to do it.
>
> The group you will hire contains the people qualified to determine what
> the
> platform should be, not you. If you choose a technology first, you're
> making
> the decision with insufficient exprience to do so, and also artificially
> limiting the number of groups you might be able to recruit to do the work.
>

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)).
3) The business tier must be completely decoupled from the model tier
using
open standards (ODBC).
4) We will gradually assume maintainence of the system. The vendor is
expected to transfer skills to our team members.
5) System must be scalable.

Is that saying enough? Seems to me that, for example, "System must be
scalable" isn't going far enough. What are the appropriate questions to
ask?

Thanks.

"Phlip" <phlip_cpp@yahoo.com> wrote in message
news:a%gAe.81$ES6.45@newssvr31.news.prodigy.com...
> DRM wrote:
>>
>> We are currently interviewing consulting/architect/development
>> groups for a new web-based project.
>
> 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.
>
> Your question is essentially this: "How can I tell the team I pick now
> will
> write something that still has these features a long time from now, after
> we
> start deploying?" The answer is you cannot. Your team could pick J2EE, or
> Ruby on Rails, or Apache with mod Perl, or COBOL, and their programs'
> performance now will have nothing to do with its performance after they
> have
> loaded it up with all the business features you will request.
>
> Pick a team known to do good work with a low defect rate and a fast
> turnaround on feature requests. Such teams typically write automated tests
> for everything they do, as they write the tested code. The team should not
> treat you as their QA department. They _should_ provide a new version,
> with
> new bug-free features, every few days. Give them small enough feature
> requests so they can develop incrementally.
>
> Order that team to implement the most important features first. This is so
> you know you have those features, and so their tests will constrain the
> development of all future code. Nobody will be able to make a mistake, and
> put a bottleneck into the system, if the test that supports 100,000 users
> per day (or 500 per second) fails. They will immediately back out that
> mistake and try again.
>
> Writing tests in order of business priority is an incredibly powerful way
> to
> constrain development, so all future changes support the most important
> goals.
>
> I'm against J2EE myself, but you will find many Java programmers who write
> a
> ratio of test to production code > 3:1.
>
> --
> Phlip
> http://www.c2.com/cgi/wiki?ZeekLand
>

Some of our interviewees have assumed that we would do the QA and we
let that go right by without comment. I've modified my requirements to
reflect
your suggestion.

Thanks for your comments!

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

>
>"Steve Jorgensen" <nospam@nospam.nospam> wrote in message
>news:1963d1l1if2m69f4mhpgk5iv8rn60hhlr8@4ax.com...
>> I'm no expert, but it seems like what you need to know is how successful
>> the
>> potential group has been at implementing similar systms for other clients,
>> -not- what technology they used to do it.
>>
>> The group you will hire contains the people qualified to determine what
>> the
>> platform should be, not you. If you choose a technology first, you're
>> making
>> the decision with insufficient exprience to do so, and also artificially
>> limiting the number of groups you might be able to recruit to do the work.
>>
>
>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?

I didn't mean to indicate that you shouldn't have a say, but since
1. You have a question about what technology is appropriate
2. You don't have the answer yourself
3. You're trying to hire a group to do the work

It seems to me that the group you will hire should be who will answer the
question.

>
> 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)).
> 3) The business tier must be completely decoupled from the model tier
>using
>open standards (ODBC).
> 4) We will gradually assume maintainence of the system. The vendor is
>expected to transfer skills to our team members.
> 5) System must be scalable.
>
>Is that saying enough? Seems to me that, for example, "System must be
>scalable" isn't going far enough. What are the appropriate questions to
>ask?

That sounds excellent to me.

To use J2EE or not does not have to be a big question. First J2EE is
many things. You talk about web solutions, so under any circumstances
you will use some parts of J2EE, although you don't use a J2EE
application server.

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.

Next question is in what extent they are going to use session beans. My
advice is to only use one or a few session beans as facade objects. All
other classes should be plain old java objects (POJO). In EJB3.0 all
objects can be POJOs, you don't have to implement specific interfaces.

If you ask your developers to minimize the coupling to EJB, it will be
easier to convert your application to live outside a J2EE container
(server).

The number one benefit with a J2EE application server is support for
distributed transactions. Doing this without an J2EE application server
is possible if you have developers that knows that they are doing (and
if you use an application server you also need developers that knows
what they are doing). But at present time I would recommend a J2EE if
you really need this feature. If you don't need distributed
transactions (there are many ways to live without them), I would
strongly recommend not using an J2EE application server. There are many
light-weight componentes providing features like connection pooling and
caching.

Fredrik Bertilsson
http://butler.sourceforge.net

DRM 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.

In addition to requiring your team to express the list as tests, if you
indeed will maintain this system then you should start that endeavor as
early as possible too. That means each time they deliver, you take delivery,
deploy to a reference system, manually test, and see if you can tweak the
configurations and code.

You will still do QA. It just shouldn't be the "clean up the slops" kind.
Inspect the test coverage, over time, too.

--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand

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.

This query is something out of context from the
original post, my apologies.