File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes EJB and other Java EE Technologies and the fly likes New Project EJB Vs Corba Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "New Project EJB Vs Corba" Watch "New Project EJB Vs Corba" New topic

New Project EJB Vs Corba

Dave Lawrence

Joined: Nov 12, 2001
Posts: 15
Hi All,
I have been given a project that requires the following:-
1) ftp data from mainframe to Unix Box.
2) Run a kron to activate scripts up update Oracle dB.
3) Run kron to call existing Java classes containing Business
Logic to read the data out of the Oracle dB and use the
result to update different dB tables.
From here on I have to design a web enabled system to display
and update dB table data. The system should allow the users to
update records within the database from the front end.
I have thought about the following:-
a) Use JSP for the Front End.
b) Use Session Beans calling Entity Beans to access and update
data within the database. I would use CMP Entity Beans, but
would I get performance problems using this approach as
compared to BMP. Since the user can also do updates would
I be better of using CMP, allowing the container to deal with
c) I don�t like the idea of having the existing business logic
outside the EJB container and not within a Session Bean.
But if I put the code within a Session Bean how do I activate
it at a certain time each day?.
I think the above design is OK, it puts the business logic,
user display and database into there individual tiers.
a) Applet Front End.
b) Business logic left in existing class accessed via a CORBA (i.e. IDL structure, methods)
I�m unsure which design method to use.
Will Design1 be more a)scaleable than Design2?
b)portable ?
c)maintainable ?
d)better performance
Since this could be my first attempt at using EJB would there be a large learning curve? thus increasing the development time to
production, or should I go for the Applet CORBA approach that I
have experience with.

Dave Lawrence

Joined: Nov 12, 2001
Posts: 15
Hi All,
can somebody help with this design problem.
Matts Smith
Ranch Hand

Joined: Feb 03, 2001
Posts: 113
Hi there,
the way I understand your problem, you have only a few tables to update. Why don't you just code a web application using servlets to remap the HTTP request to an application request and pass it on to your "Real application" or "model". Your application could use straight JDBC for transactions as you only need to update a single DB (no 2PC here). Try to avoid EJBs whenever possible.
Any other advices? I would like to see what others would recommend.
Dave Lawrence

Joined: Nov 12, 2001
Posts: 15
Hi Matt,
thanks for your reply.
Yes there are only a few tables that are going to be updated at present,but we could have up to 50+ users attempting updates at
the same time. I thought by using cmp I could forget about any
problems with locking and transactions updates?. I could go for
the JSP, Servlet, application approach. But would this approach
be limited in scale and maintainability as compared to using EJB.
Why should I try to avoid using EJB?.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 17410

CORBA is at its best when used to connect clients and servers in multiple programming languages. RMI or EJBs (which are built on RMI) are easier to work with for an all-Java solution.
I would be most likely to build a web app if there was something in the system I wanted to be able to deal with from a web browser. If all interactions are from software, I'd just build a simple server or standalone application. You can invoke EJBs without a web framework, several EJB servers (such as JOnAS) don't even have web capabilities in and of themselves, but even all-in-one systems like WebLogic don't REQUIRE that everything you place under their control be a full-blown web app. You certainly can invoke EJBs from a cron-spawned Java app.
It has become fashionable to slam Entity EJBs in favor of Session ones, but so far as I'm aware, the only TECHNICAL reason for this is that often Entity EJBs get a lot over overhead from people setting and getting one property at a time (which can be expensive when done via RMI). You can avoid this (and annoy purists) by supplying them with bulk set/get methods, since Entity EJBs ARE allowed to have "business methods" -- it's just that it's better from a maintenance standpoint to keep data in data objects and processing in processing objects.

An IDE is no substitute for an Intelligent Developer.
I agree. Here's the link:
subject: New Project EJB Vs Corba
It's not a secret anymore!