Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

use of EJBs ?  RSS feed

 
satish bodas
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have googled and also reading some books for EJB .

Some of the major driving forces for EJB's usage specified are ::

1 >Component based architecture
2 >Distributed environment
3 >security ( Declarative )
4 >Transaction management ( CMT as preferred )

My queries are ::
1 >In case of local transactions ONLY being present - there wouldnt be a need of Tx mgmt ?

2 >I find the tx mgmt done manually ( BMT ) much easier than CMT ?
( Maybe There are complex scenarios that I havent worked on )

3 >Security - This particularly is not very well understood by me .
In a web application - I am assuming that all the authentication and authorization is done upfront - even prior to hitting some business methods .

What I mean is using some filter to do necessary checks ( server side )
Why do I even need to add an additional check at the model layer - is this just a backup to ensure that if things fail at the front end we have a secondary check ?

Thoug again .... unless I duplicate code both will really do the same thing !

Thanks ,
~satish
 
Scott Selikoff
author
Bartender
Posts: 4093
21
Eclipse IDE Flex Google Web Toolkit
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by satish bodas:
In case of local transactions ONLY being present - there wouldnt be a need of Tx mgmt ?

What do you mean by local transactions? Transaction management is always a good thing for database-dependent systems.

Originally posted by satish bodas:
2 >I find the tx mgmt done manually ( BMT ) much easier than CMT ?
( Maybe There are complex scenarios that I havent worked on )

Depends what you consider easier. To some people having 100% control of transactional logic (BMT) is easier than fully automated solutions (CMT). On the other hand, CMT offers the ability to change transactional behavior of your system through XML files without recompiling any code. Also, if you working in a team of multiple developers its a lot easier (and safer) to manage their transactional methods via CMT than BMT where a developer may have neglected to put the BMT code in the proper place.

Originally posted by satish bodas:
3 >Security - This particularly is not very well understood by me .
In a web application - I am assuming that all the authentication and authorization is done upfront - even prior to hitting some business methods.

Who is the authentication/authorization done by? You, or the web server? Its not so much that EJB can do better security than non-EJB world, but that EJB integrates with security systems quicker and easier than non-EJB systems allowing for some very customized security configuration.

Originally posted by satish bodas:
What I mean is using some filter to do necessary checks ( server side )
Why do I even need to add an additional check at the model layer - is this just a backup to ensure that if things fail at the front end we have a secondary check ?


That's a tricky one and perhaps the subject or my next tech blog... checking the same requirements on multiple levels is often required for large systems and often a huge pain. Ultimately, EJB systems are designed to be componentized with many possible configurations. In other words, the advantages of component-oriented development is that you can mix and match components to build better systems... the downside is you never quite know who's the consumer of your service and therefore have to recheck logic that may have all ready been verified. For example, imagine your EJB is used by a Web Service, a JSP-based front-end, and a Swing-front end. Some of the clients which you have 100% control over (the JSP/Swing service hopefully), you may be checking things twice, but the web service may come to you completely unverified. If you add the code perform the validation at each level, you make your code more reusable by other systems.

I feel like I should add, EJBs are not designed for development teams of only a handful of people. If you're the sole developer then yes, EJBs don't buy you much at all. On the other hand if you have systems of hundreds of developers and huge amounts of code, the reusability and management features of EJBs are (theoretically) unmatched. Does it work like that in practice? Depends on if your architects can get over the inherent difficulties with setting up good EJB systems in the first place.
[ August 04, 2008: Message edited by: Scott Selikoff ]
 
satish bodas
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In case of local transactions ONLY being present - there wouldnt be a need of Tx mgmt ?


What I meant was actually if I have only local / single resource Transactions ( not distributed ) than I dont see any use of ejb ( which are supposedly useful using JTA for distributed tx )

Regarding CMT and BMT I agree that with a configurable CMT - changes are easier to make and maintain code

My only point was many books say that Tx mgmt is tough - its actually very simple ( I am sure given human interactions people including me will definitely miss and introduce bugs )

Regarding security - I am really ignorant about the security offered by EJB as well as the container .

In almost all our applications I have worked on - user is stored on session .

All authentication is against LDAP .
All authorization is driven through Database which has a few tables for this purpose .

All incoming requests go through a common authorization / authentication class .

If success only then is call propogated to ejb layer

I will google and read - but curious using roles specified in an xml file ( dont remember the exact name of file that i saw for tomcat - was it tomcat-users.xml ? and yes I know tomcat is not an app server ) - is that a good thing to do ( roles in a server specific file ?

How do you map new users who have same role but can perform different functionality ?

I somehow dont like to distribute logic in files and db
I prefer DB

Regarding the last point of checking requirements at multiple layers ......
I will await for your blog .... read some more and then comment .

Thanks Scott for your explanation .

~satish
 
Scott Selikoff
author
Bartender
Posts: 4093
21
Eclipse IDE Flex Google Web Toolkit
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by satish bodas:
What I meant was actually if I have only local / single resource Transactions ( not distributed ) than I dont see any use of ejb ( which are supposedly useful using JTA for distributed tx )


Still not quite following this. Perhaps you should read on transaction management in general. Even if you have a single resource, you could have hundreds of users connecting to it. In such a case, users may be performing complex processes such as creating records, deleting items and updating tables. Without transactional support, how these processes interact would be highly chaotic.

Originally posted by satish bodas:
My only point was many books say that Tx mgmt is tough


Again, depends what they define as difficult. With BMT you have 100% control, so if you have a pen and paper and a lot of time, you could have a perfect (much faster and smarter) system. But that puts a huge burden on developers to know about every transaction in the system that could affect them, something almost impossible in practice.

As for CMT, it can be difficult depending on how high your concurrency and resource utilization is. For example, while database total normalization (BCNF) is theoretically wonderful, in practice it leads to terrible performance such that most queries tend to join almost every table in the database. Like database performance, transactional management is one of those things that is very difficult to plan for, especially when developers aren't informed exactly how something is going to be used in the real world. For example, in medical environments developers may not have access to a production database. In such cases, their test database may incorrectly represent common processes and resource contention in the real system.

The solution in a nutshell? While you try to plan your system around any potential bottlenecks often time you can't fix transaction management problems until they occur in the wild. But no fear, that just gives developers better job security


About validating layers, I ended up writing about JDBC again, although I'll have something up soon enough.
[ August 05, 2008: Message edited by: Scott Selikoff ]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!