Re: RAC vs. J2EE

1. I dont see why not. The primary objectives are
   > availability,
   > manageability, and scalability.
   and oracle has been working longer and harder on those than most app server companies. I think moving large chunks of business logic which is running just fine to EJB's serves no purpose other than to enhance someones resume and add a large overhead. And then people want to do transactions in the J2EE layer ( uggh ) my advice keep it in the DB
2. I dont know anywhere where J2EE beats the DB since if the DB is down pretty much everything goes down .
3. In case you want to manipulate data and have logic that works primarly of the data use PL/SQL. If you have other requirements consider java.

Just my two cents
I am sure many will disagree.

Regds
Dev

glennjcgw_at_yahoo.com wrote:
> Background:
> Our organization has a significant investment in application modules
> written in PL/SQL to support our e-commerce web site and catalog
> business. Such examples would be days to delivery on an order, P&H
> calculations, discounts/rewards for a customer order, SKU
information,
> and line item tax calculations. Currently these applications are
> separately deployed in our e-commerce system and our internal phone
> order system. There is a desire to move some these type of programs
> toward a more service-oriented architecture under a single
deployment.
> The issue that is trying to be addressed is whether these could be
> deployed only to a RAC cluster or should they be deployed on a J2EE
> middle tier running iAS backed by a RAC cluster. The applications
> running under the RAC-only option would be accessed either by remote
> procedure calls through database links or by a thin web services
layer
> run out of the database.
>
> The benefits and features of the J2EE architecture are known and well
> understood but would like some guidance as to if some of these
features
> could/should be provided by deploying the applications on RAC
instead.
>
> The rationale is as follows:
> **the primary objectives of this architecture are availability,
> manageability, and scalability.
> **PL/SQL, not Java, is the core strength of our developers.
> **The database tier, not the J2EE middleware tier, is the core
> strength of our DBAs.
> **A large repository of PL/SQL code exists within our organization.
> **The DBA group has 1 year of experience managing a RAC environment.
> **Features offered by iAS in this deployment such as wireless, B2B,
> Oracle Portal, Web Cache, Sensors, BPEL, and etc are not
> anticipated to be needed.
>
> Questions:
> 1. Given the needs and objectives outlined, would running these
> applications only out of a RAC environment be a practical approach?
If
> not, then why not?
> 2. In terms of AMS (availability, manageability, and scalability),
> performance, and costs, does a J2EE architecture have any significant
> advantages over a RAC architecture?
> 3. For future development efforts, are there recommendations as to
when
> an application should be run in a J2EE middle tier vs. in the
database
> (PL/SQL)?
Received on Tue Feb 15 2005 - 10:34:33 CST