Personally I think you should go for it.
My reasons are:
1) Security. Not the "You can log into the system therefore can do anything
any other user of your role can do" but the "You are Edward Kenworthy
therefore when I look up Pension Details I'll only show you yours" or "You
are Edward Kenworthy, who is a User, but I see you have expertise in Selling
Mortgages so I'll let you do this stuff extra" ie more fine grained access
control based on potentially complex and dynamic combinations of access
rights.
2) Scalability. 'nuff said.
3) Portability. (Probably not important to you but it is to us ;) with care
you can write for one EJB AppServer and have your applicaiton run on any EJB
AppServer (and therefore pretty much any extant operating system).
4) Failover. Tricky one this. The spec' says that AppServers should handle
failover of entities (ie nothing gets lost, but you could lose your
connection) but doesn't specify that stateful session beans are maintained
(statless of course doesn't matter). I suspect, for a straightforward,
non-ecommerce, web-site this isn't a problem.
Database independence is a red herring really. JDBC gives you that (as long
as your are careful not to use ANY non-standard features of your database.
Like joins ;) What the container transparently adds is support for
concurrent access etc etc.
Oh and forget CMP. It is just awful (I'm talking about the spec in general
here not jBoss's implementation of it). Frankly CMP is a waste of time. It's
only useful if you're writing a teeny-tiny system - and if that's the case
why are you using an AppServer ? ;-)
-----Original Message-----
From: Hunter Hillegas [mailto:[EMAIL PROTECTED]]
Sent: 06 December 2000 20:11
To: jBoss
Subject: Re: [jBoss-User] J2EE Too Much for Small App? Rocky Honeymoon!
Thanks for the defense Edward!
Thanks to the list for all the responses.
Maybe I should clarify a few points.
1. My company does it's own hosting so that's not a problem. I can use
whatever I want (they might balk at a WebLogic license however ;-)).
2. I am re-writing the site no matter what. I need to add many new features
and PHP doesn't cut it for OO design or logic/presentation abstraction. I
also need to be able to change databases easier since I may need to move to
Oracle in the future. The site will basically be TOTALLY new when it's
completed.
3. The site does make money and is growing very quickly but it's a hobby. If
the whole thing crashed down in flames the only one seriously impacted would
be me.
The whole reason I wrote the list was to get a feel for whether or not I
should go with EJB in ADDITION to the JSP/Servlet approach I am planning.
I am NOT some buzzword crazy manager that doesn't know better. I will be
doing the coding. I want to create a base that I can expand on in the future
to offer some cool Web services to the public.
At this point I haven't decided what route to take. I know I don't NEED EJB
at this point but it might be helpful in the future when I need to deploy
the backend across several machines portably, etc...
Again, thanks for your input. I appreciate it.
--
Hunter Hillegas
[EMAIL PROTECTED]
> From: "Kenworthy, Edward" <[EMAIL PROTECTED]>
> Reply-To: "jBoss" <[EMAIL PROTECTED]>
> Date: Wed, 6 Dec 2000 13:36:51 -0000
> To: "'jBoss'" <[EMAIL PROTECTED]>
> Subject: RE: [jBoss-User] J2EE Too Much for Small App? Rocky Honeymoon!
>
> Gosh! Lay off the guy. You have no idea why he's decided to re-write his
> site, so why is everyone coming down on him like he's some kind of a moron
?
>
> -----Original Message-----
> From: fred [mailto:[EMAIL PROTECTED]]
> Sent: 06 December 2000 22:20
> To: jBoss
> Subject: Re: [jBoss-User] J2EE Too Much for Small App? Rocky Honeymoon!
>
>
> Hi Hunter,
>
> I think you need to read this article, by Brett Mclaughlin, "Enterprise
> Applications in Java and J2EE: A Rocky Honeymoon."
>
> visit: http://java.oreilly.com/news/j2ee_0700.html
>
> An excerpt:
>
> All too often, people
> go overboard with their applications. In geek talk, this is
> called "buzzmania." Buzzmania is the tendency to buy
> more, get more, and use more, simply because more
> "buzzwords" are in a product. This is a large part of the
> J2EE problem. With the J2EE product descriptions and
> specifications reading like a meeting of exotic 12-step
> programs--JSP, XML, JMS, EJB, CMP, BMP, OR, JDBC--it's
> no wonder managers' eyes light up at sales presentations.
>
> However, the reality is few companies, and few
> industries, need all these services. I'd estimate 50% to
> 70% of the companies that have purchased or are
> purchasing J2EE solutions could easily get by with a
> simple servlet and a JDBC-based solution. Presentation
> logic housed in the servlet coupled with database access
> through JDBC would suffice for most types of
> applications, including many e-commerce solutions.
> Adding JSP, or another presentation technology, such as
> Enhydra XMLC, makes this an even more robust option.
>
>
> Regards
> Fred
>
>
>
> Hunter Hillegas wrote:
>
>> I am new to J2EE.
>>
>> I have been using Servlets and JSP for some time but have never touched
> EJB.
>> I recently took a class from Sun on J2EE and I want to get started with
> some
>> of it.
>>
>> I have a Web site that's currently powered by PHP and mySQL called
>> RateVegas.com.
>>
>> I've been planning a total site makeover for several months with many new
>> features. I've decided to move to PostgreSQL and Java.
>>
>> The question is whether to use JSP/Servlets/Taglibs or to include EJB in
>> that equation.
>>
>> What I'm really asking is if J2EE is "too much" for a relatively simple
>> application?
>>
>> RateVegas.com basically lets users rate hotels and restaurants in Las
> Vegas.
>> There is a fair amount of DB activity but they are simple queries.
>>
>> The new version of the site will be totally personalizable and will be
>> somewhat more complex.
>>
>> Do you think using J2EE is overkill?
>>
>> Hunter
>>
>> --
>> --------------------------------------------------------------
>> To subscribe: [EMAIL PROTECTED]
>> To unsubscribe: [EMAIL PROTECTED]
>> Problems?: [EMAIL PROTECTED]
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
