EJB design: Flexibility of Component Design in Practice?

  1. Flexibility of Component Design in Practice? (2 messages)

    The short question is: "Once I've designed and implemented a large component of my application as EJB beans, how easy or difficult is it to change that component to a different design compared to other kinds of development?"

    The reason I ask is this: up until now we've been taking a very cautious "Specify, analyse, and design everything before you write a single line of code approach". This has given us some very good designs, but development is consequentially slow as slow. Now we have to shift gears to a faster pace of development because we have some tight deadlines, and my philosophy is to switch to "Design a component that fits 90% of current needs, build _that_, change as necessary". But is that, in practice, a realistic way to go about working with EJBs?

  2. Refactoring is pretty much a fact of life with most contemporary "agile" design approaches. This applies to EJBs or anything else. There is no simple answer on what the 20% left will do to your original design.

  3. The beest part about EJB is that you can redeploy your components on another application server by changing your deployment descriptors. Using CMP is especially useful as you do not need to alter any code at all.

    I have worked some ludicrous project timelines and schedules and refactoring is a necessary part of life. I would suggest that you design components to meet 100% of current needs. Anything that you do not need you should NOT implement. However, it is important to note that this does not mean that bad design is acceptable. A firm grasp of good architecture and common patterns is essential in paring your designs down to the essentials.

    The next time you need the components you spend some time refactoring them into something more generic and suitable for the new project...this work should be taken for granted on any projects and a day refactroing an existing component actually saves time in development. It is important to stress this to your managers and stakeholders. Once you have tweaked the esiting code, then you can again code to your current project spec. Slowly, project by project, your framework will evolve into something really useful.

    (And in downtime, and there is always downtime, you get your team refactoring the codebase, extracting and manipulating the architecture into something more generically useful).

    Depending on your application requirements, you can often roll out a new codebase transparently without affecting the a system...especially with some effective patterns in action, you can replace entire layers of the system without changing other. A good deployment and integration plan will help herre as well.

    I reccommend reading some of the eXtreme Programming books for an insight into an approach that might be of use (and remember to take XP with a grain of salt...the philosophy is great, implementation is another matter).

    You must buy 'Refactoring' by Martin Fowler. This is the bible of refactoring, with heaps of patterns of the most common refactorings in java projects. A tool that supports refactoring (I downloaded IntelliJ on the weekend and I am VERY impressed with it's refactoring features) is also a good idea.