File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB and other Java EE Technologies and the fly likes Please reply fast 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 "Please reply fast" Watch "Please reply fast" New topic
Author

Please reply fast

Arathi Raj
Ranch Hand

Joined: Nov 22, 2002
Posts: 90
Hi,
I have a doubt. Can EJB be used for an intranet application. We are developing an intranet website for our company. Will it be good idea if we use entity bean to retrive and store data from and to database and to use stateless session bean for performing business logic.
I feel we can complete this job just using servlets,jsp and jdbc. but by EJB technology will there be any use. and will it be possible in future to move this intranet website to internet.
thanks
arathi
Randall Stevens
Ranch Hand

Joined: Jul 01, 2003
Posts: 65
Although an Entity bean can be used in bothe Internet and Intranet settings, most of the people that I have dealt with do not like to use Entity beans. The preferred method appears to be session beans and jdbc.
My suggestion would be to make a list of reasons to choose each configuration based on speed, security and ease of development.
Andres Gonzalez
Ranch Hand

Joined: Nov 27, 2001
Posts: 1561
Originally posted by Arathi Raj:
Hi,
I have a doubt. Can EJB be used for an intranet application. We are developing an intranet website for our company. Will it be good idea if we use entity bean to retrive and store data from and to database and to use stateless session bean for performing business logic.
I feel we can complete this job just using servlets,jsp and jdbc. but by EJB technology will there be any use. and will it be possible in future to move this intranet website to internet.
thanks
arathi


If your requirements tell you that you can achieve your solution with servlets/jsp, then avoid EJB
[ September 10, 2003: Message edited by: Andres Gonzalez ]

I'm not going to be a Rock Star. I'm going to be a LEGEND! --Freddie Mercury
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
The fact that the application is for intranet use has no relevance on the decision to use or not use EJB. However, EJB for the sake of EJB is idiotic.
Arathi Raj
Ranch Hand

Joined: Nov 22, 2002
Posts: 90
Hi,
One more quick question. Can we use just stateful session bean to reterive and store data to and from database?
Thanks
Arathi
Andres Gonzalez
Ranch Hand

Joined: Nov 27, 2001
Posts: 1561
Originally posted by Arathi Raj:
Hi,
One more quick question. Can we use just stateful session bean to reterive and store data to and from database?
Thanks
Arathi

yes.
Idly Vada
Ranch Hand

Joined: Sep 02, 2003
Posts: 135
Hi !
EJB approach is used to separate business logic from presentation logic.Choosing EJB(n-tier) vs servlets,jsp,odbc(3-tier) depends on various factors like scalability,maintainability,distributed transaction support ..etc.If the application grows in size, servlets,jsp and odbc will not scale up.
Using EntityBeans for small applications will be overkill.Instead you can go for DAOs.
It all depends on your application.
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Originally posted by Murthy Narasimha:
EJB approach is used to separate business logic from presentation logic.

Not really. Nothing in EJB makes it inherently easier to separate business logic from presentation. I could as easily throw all my business logic in plain Java classes (POJO) and have just as nice of a separation.
Originally posted by Murthy Narasimha:
If the application grows in size, servlets,jsp and odbc will not scale up.

Sure they will. Servlet/JSP applications can be clustered just as easily as EJB applications, easier in fact. There is nothing in EJB that makes scalability inherently easier.
Originally posted by Murthy Narasimha:
Using EntityBeans for small applications will be overkill.Instead you can go for DAOs.

I won't comment much on this except to say that I think Entity Beans are pretty much useless for all applications... large and small.
Originally posted by Murthy Narasimha:
It all depends on your application.

At least we can agree on this.
[ September 11, 2003: Message edited by: Chris Mathews ]
Idly Vada
Ranch Hand

Joined: Sep 02, 2003
Posts: 135
One of the advantages of J2EE is that one can concentrate on the business logic than concentrating on the middleware.
If some one wants to write their own middleware and miss the container facilities, I won't mind.
If u write JDBC code for an app, what if the databse vendor changes? do u rewrite the code again? what if u need your application needs to run many databases? Do u want to miss container services like caching and pooling?
Do u want to miss services like state management and write your own? What is the need of the app server then?
I think Entity Beans are pretty much useless for all applications... large and small.

I certainly don't agree with this
Performance is not the only issue in enterprise applications. Things like productivity and maintanability are also important.
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Originally posted by Murthy Narasimha:
If u write JDBC code for an app, what if the databse vendor changes? do u rewrite the code again? what if u need your application needs to run many databases? Do u want to miss container services like caching and pooling?
Do u want to miss services like state management and write your own? What is the need of the app server then?

One word: Hibernate
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Originally posted by Murthy Narasimha:
Performance is not the only issue in enterprise applications. Things like productivity and maintanability are also important.

I completely 110% agree! Which is why I don't like Entity Beans. Notice I didn't say anything about performance. The biggest hit when it comes to Entity Beans is developer productivity, testability, and maintainance. Entity Beans lose out to a good O/R Mapper on all fronts.
Idly Vada
Ranch Hand

Joined: Sep 02, 2003
Posts: 135
Few more points?
How will u handle distributed transactions?what about security? by writing ur own code (and probably miss deadlines)? do u want to miss RAD benifits of J2EE?
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Chris,
How many organization use hibernate? I havent heard many guys talk of hiberante. Why?
BTW, is your JMX timer article done?


Groovy
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Originally posted by Murthy Narasimha:
How will u handle distributed transactions?what about security? by writing ur own code (and probably miss deadlines)? do u want to miss RAD benifits of J2EE?

EJB != Entity Beans.
I said that I don't like Entity Beans. However, I find Session Beans and MDBS perfectly good technologies. I can get all the benefits of EJB (minus the crappy persistance of Entity Beans) from using Session Beans.
Therefore, I will get my transaction management, security (which sucks in EJB anyways), and remoteability from a Service Layer built using Session Beans. Presto!!!
Idly Vada
Ranch Hand

Joined: Sep 02, 2003
Posts: 135
Dear Chris !
What you said about entity beans is true. But one should remember that entity beans are for representing coarse-grained data objects rather than fine-grained ones( which many people fail to recognize) . If one needs fine grained access then they should use other ways like DAOs.

But if your application needs coarse grained aceess then I think entity beans are the best solution.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Does any one use the method level security in EJB.
Idly Vada
Ranch Hand

Joined: Sep 02, 2003
Posts: 135
You can use method level security using caller roles ..etc. But what if security rules/roles change if u want to add new security rules/roles? you have to edit the EJB code. Instead you can specify security conditions in deployment descriptor.And change descriptor accordingly.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Murthy, you got me wrong. I wanted to know in real life who many define those roles.
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Originally posted by Murthy Narasimha:
You can use method level security using caller roles ..etc. But what if security rules/roles change if u want to add new security rules/roles? you have to edit the EJB code. Instead you can specify security conditions in deployment descriptor.And change descriptor accordingly.

Unfortunately, most of the time in real applications the roles and users must change dynamically at runtime and modifying the DD doesn't cut it. This makes the standard security for J2EE pretty much unless because to do anything interesting you need to make calls to a vendor API.
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Originally posted by Murthy Narasimha:
What you said about entity beans is true. But one should remember that entity beans are for representing coarse-grained data objects rather than fine-grained ones( which many people fail to recognize) . If one needs fine grained access then they should use other ways like DAOs.

The original intent of Entity Beans was to represent fine-grained data. People started using Composite Entity Beans (coarse-grained if you will) to work around the horrid performance of Entity Beans. With the release of EJB 2.0, which includes local interfaces, improved CMP, and CMR, the recommendation is back to not using coarse-grained Entity Beans. If you don't believe then check the lastest edition of Core J2EE (the bible of J2EE best practices). At no point in time were Entity Beans ever truely meant for representing coarse-grained data, it was just a hack.
Originally posted by Murthy Narasimha:
But if your application needs coarse grained aceess then I think entity beans are the best solution.

Coarse-grained access is best provided thru a Service Layer (possibly built on Session Beans). There is no reason why the client code needs to know what type of persistance technology is being used.
Idly Vada
Ranch Hand

Joined: Sep 02, 2003
Posts: 135
Building your entity beans to be coarse-grained is a common performance optimization. It allows modeling the business objects with plain java classes rather than as entity beans, reducing the inter-remote object communication and transactional overhead associated with entity beans.
These plain classes typically have a life cycle dependent on a parent entity bean, do not have a distinct identity of their own and do not need to be referenced remotely by a client. For CMP, these objects are called dependent objects, and EJB 2.0 defines a standard way to define CMP dependent objects, leaving the complex task of persisting them to the underlying application server.
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Originally posted by Murthy Narasimha:
Building your entity beans to be coarse-grained is a common performance optimization. It allows modeling the business objects with plain java classes rather than as entity beans, reducing the inter-remote object communication and transactional overhead associated with entity beans.

Exactly. So if much of our model is represented by POJO (by your own admission) and if we spend a lot of our time working around the performance problems with Entity Beans... then why even use them? What do Entity Beans offer that for all our trouble that Session Beans + POJO do not?
Idly Vada
Ranch Hand

Joined: Sep 02, 2003
Posts: 135
Entity beans provide a clear model to represent persistent business objects in applications and their design. In object models, simple Java objects are normally represented in a straightforward way, but do not include the transactional persistence management functionality usually required for business objects.
Entity beans not only allow the same type of modelling and thinking about business objects in an object model, but they also encapsulate persistence mechanisms while hiding all complexity behind the bean and container services which is not the case with POJO.
This allows applications to manipulate them as Java object references. By hiding the persistent form and persistence mechanism from any calling code, entity beans allow for creative persistence optimizations by the container, while keeping the data store open and flexible, only to be determined at deployment time.
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Originally posted by Murthy Narasimha:
Entity beans provide a clear model to represent persistent business objects in applications and their design. In object models, simple Java objects are normally represented in a straightforward way, but do not include the transactional persistence management functionality usually required for business objects.
Entity beans not only allow the same type of modelling and thinking about business objects in an object model, but they also encapsulate persistence mechanisms while hiding all complexity behind the bean and container services which is not the case with POJO.
This allows applications to manipulate them as Java object references. By hiding the persistent form and persistence mechanism from any calling code, entity beans allow for creative persistence optimizations by the container, while keeping the data store open and flexible, only to be determined at deployment time.

That's all fine and good... if Entity Beans were the only technology to provide this. JDO and Hibernate both offer a far more powerful and transparent persistance mechanism then Entity Beans could ever hope to achieve... and they are based on POJO. All I have to do to make a POJO persistant is to tell JDO or Hibernate a little bit about it and *bang* I have a persistant object. It is much more natural to represent a Domain Model as regular Java classes then it is to shoehorn it into Entity Beans (especially pre-EJB 2.0).
[ September 12, 2003: Message edited by: Chris Mathews ]
Idly Vada
Ranch Hand

Joined: Sep 02, 2003
Posts: 135
It seems that Chris is a strong supporter of JDO/hibernate :-)
we also considered JDOs in one of our projects. But I don't think JDO/hibernate will ever be added to the J2EE specification. Even container support remains a question. Will all container providers consider JDO/hibernate? Will they follow same standard/specification for them?
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

It seems that Chris is a strong supporter of JDO/hibernate :-)

Particluarly of Hibernate I have created a thread comparing JDO and Hiberante. Some one bother to answer
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Originally posted by Pradeep Bhat:
Particluarly of Hibernate I have created a thread comparing JDO and Hiberante. Some one bother to answer

Hey!!!
I plan on responding. I just don't have time to formulate a decent response while I am here at work with deadlines hanging. I will try to get to this a bit later when I get home.
Rufus BugleWeed
Ranch Hand

Joined: Feb 22, 2002
Posts: 1551
With the release of EJB 2.0, which includes local interfaces, improved CMP, and CMR, the recommendation is back to not using coarse-grained Entity Beans. If you don't believe then check the lastest edition of Core J2EE (the bible of J2EE best practices). At no point in time were Entity Beans ever truely meant for representing coarse-grained data, it was just a hack.

My copy of the 2nd ED arrived lasted week. The ink is still wet. But, I won't argue that it is up-to-date.
It is recommending using coarse grained entity beans.
Have you been reading Patterns of Enterprise Architecture or some web document?
Gayathri Prasad
Ranch Hand

Joined: Jun 25, 2003
Posts: 116
Hi,
The arguement continues.... I always go for EJB when I am making justice to the container services. When I cant do justice to the container services I undoubtedly go for the POJO mechanism.
Cheers,
Gaya3

---------------------------------------
When U can decorate the wheel, why redesign ?
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Would it be easier to load balance with EJBs than any other framework ?
I am still debating whether to bother with EJBs at all. seeing as there's still so much controversy surrounding it and there's so much to learn.
If you are writing components for networks would you still reject EJBs ?
I am guessing but I think most people responding are not writing re-usable components to be used with networks, unless that's what they mean by container services.
regards
[ October 02, 2003: Message edited by: HS Thomas ]
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Perhaps JDO and Hibernate deserves a separate forum? It's confusing this space no end.
regards
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Please reply fast