views:

107

answers:

3

A little bit of background first:

Last year I started working at a medium-sized auto insurance company -- we're in several states, but we're not as big as GEICO or Progressive or anything like that (yet). Our primary software system is old (written in RPG) but reasonably stable. We're wanting to make our in-house applications available via the web (both intra- and internet), and we're going to be writing new Java code to access the underlying programs.

I've heard a lot about Enterprise Java Beans , and it seems like there's times they may be beneficial (depending on which article I'm reading to research them). However, I've looked into them and I just can't seem to get a grasp on how to started. I've looked up lots of tutorials, but (like a lot of programming areas) they're either to simplistic to give me any idea of how EJB's could benefit my projects or they're too complex and my eyes start to glaze over. It's a little disheartening, as I've worked with Java for about a decade now and I felt that I was at least able to easily catch on to things I didn't know about.

So, here's the questions I have:

  1. How can I tell if using EJB's would be of any benefit to any development projects I'm working on?
  2. If I'm designing an application from scratch, what would be a good way to implement EJB's -- or what would be a good way to look at my application to start designing EJB's?
  3. What questions should I be asking, if either of these others aren't really appropriate?

We're using WebSphere (6.1) as our primary deployment server, and most of the Java development is done in IBM Rational Application Developer (7.1, I believe) -- it's a flavor of Eclipse, for anyone who's never heard of it before.

If I need to clarify anything, please let me know.

+1  A: 

I can not answer the question directly, but I would suggest that you also consider alternatives to EJB, Spring for example.

A previous topic here has discussed the merits of EJB and Spring before.

http://stackoverflow.com/questions/68527/should-i-use-ejb3-or-spring-for-my-business-layer

Also a somewhat out of date article about EJB vs Spring.

Kris
I will look into Spring -- I haven't paid any attention to it, because I was always under the impression (perhaps wrongly) that it was simply a servlet framework. Lately I've heard there's much more to it though; I just simply haven't had a chance to look much into it yet though.
MCory
You are referring (servlet) to Spring-MVC which is part of Spring Framework.
Hans Westerbeek
+2  A: 

To me, EJB can never be a goal in itself. But since you're looking to modernize your software (which is a Good Thing), and you're an experienced Java developer, here's what I would do:

  1. Learn about Spring Framework. This is quite a daunting task but I have seen plenty of developers picking it up quite quickly, especially if their employer allowed them to do the excellent Core Spring training.
  2. Consider using an ORM tool like Hibernate. If you do, make sure you read the excellent book 'Java Persistence with Hibernate', published by Manning and written by the authors of Hibernate.
  3. Try to ditch Websphere in favour of Apache Tomcat until it is proven that you need something more sophisticated than Tomcat. I find this rarely to be the case.
  4. To help you get started, try the SpringSource Tool Suite (based on Eclipse and free).

Your benefits will be:

  • You will be using the most popular open source tools with lots of mind-share, so lot's of forum support from other developers and commercial support is available as well (if needed)
  • You will find that Spring Framework greatly simplifies developing enterprise Java (web)apps.
  • You will be adding some of the most popular open source technologies to your skill sets
  • Your employer will not have any problem finding other, motivated developers to help you. Most enterprise java developers love Spring.
Hans Westerbeek
Yeah, I am going to look into Spring -- and I've threatened to look into Hibernate as well, just (as always) haven't had the time. We're going to be sticking with Websphere and IBM RAD though. Pretty much all of our infrastructure is IBM based, the boss is happy, and I haven't had any problems yet with either products. I've worked with Tomcat in the past, and it's a great product -- if we weren't already using Websphere, then that's what I'd get them to use.
MCory
+2  A: 

I think the answers are going to be subjective at least to some degree for this question.

First thing to know is that whatever you can do with EJBs can be done by many other ways - other frameworks/you-own-code and so on. Being said that, I'll write @ EJBs so you can decide for yourself.

EJBs are more justified for applications requiring scalability. Another aspect is the component based design and development. The idea is to develop application in components and then scale only those components which are bottlenecks/critical/heavily-used.

Also by using EJB you'll be following a well established standard and some of the best practices for enterprise grade application. This is important for a business critical application which needs to be maintained over the years.

EJB applications make it easy to maintain them over the years by the very simple fact that if designed correctly they work on individual business concern and hence can be modified without affecting or even stopping rest of the application.

Please note again that all this is possible without EJBs too.

Now:

How can I tell if using EJB's would be of any benefit to any development projects I'm working on?

  • If you want to scale your application as and when required without writing code.
  • If your application is sufficiently large and can benefit from component based design.
  • If the application is going to evolve over the years, business requirements may change or may get added/removed and you want the change to be smooth.

If I'm designing an application from scratch, what would be a good way to implement EJB's -- or what would be a good way to look at my application to start designing EJB's?

  • Component Based Design.
Elister
Thanks, and that's (at least kind of) the plan -- the company is expanding relatively quickly, and scalability is definitely something I'm wanting to focus on.One more question that you've brought up: you mention component based design; what level of granularity should I work towards on that? I'm assuming you don't mean "component" as similar to GUI component, which is my first thought coming from C# and Delphi in my earlier days. What would you consider a "component"? The Data Access Layer? A group of related models/views (i.e. add/edit/delete/list users, etc)?
MCory
Granularity should be guided by the re-usability, modularity and cohesiveness of the resulting components. A good component design finds its component definitions in business requirement document. The idea is to separate business concerns like for example make-payment, open-account, generate-statement-for-duration and so on. It is a good idea to focus first on business concerns.
Elister
Thanks Elister -- now I simply need to break our system up into it's various concerns ;)
MCory