My experience is that applications do not remain static after their original development phase. They tend to evolve continuously during their lifetime. Existing requirements change and new ones are added. If one disregards bugs and other technical issues and just focus on the change of business rules: how would one solve this in J2EE, with configuration or componentization. How would one technically solve it? (Especially configuration)
Thanks in advance, Theis (a J2EE-newbie).
Component architecture is based on the fundamental principle of reusability. So if you are going to have projects after projects it can reduce your project turn-around time drastically. But for that you have to be really good at understanding, identifying the components besides using the right technology. EJB gives you a layer where you isolate the components based on their behavior. So you have components which incorporate the business logic. Others which are just data elements. I am not sure I understand configuration as "you" mean it, but I assume you meant customization! Never heard of "componentization" - is it a new addition to Webster's? :) and what is ”!! In any case both methods can fail if the design is bad. So we are back to square 1 - booch and rumbaugh and Jacobson...A good design can always mask to a certain extent bad implementations.
Sorry if I was a bit unclear! What I mean is, components will over time change. Which is the best way to build for this change.
Lets say you deliver a warehouse management system to a customer. After a year he wants to change the logic for order handling. As a see it, one could either change the component, repack and deploy it or one could build a way to configure what logic the component for the time being should use (in case one have it).
Exactly thats the case where component architecture becomes imperative. Components have to do with deployment and not implementation. If the component doing the order handling changes you just change that component. But remember components are interfaces and so implementation changes donot affect the clients. You can change the logic 10 times a year but the client doesn't have to do any changes unless you break the "contract" promised by the interface i.e the interface methods. This becomes even more critical if it is a shared one like purchase component. Take a case where you as an IT manager have to provide an application to purchase items. And you have to develop apps for all the departments like IT, QA, provisioning, Adminstration. Now in component based methodology you simply distribute the one interface for the for these various departments. The different implementation are hidden from the users. So now, if you have to change the logic you dont change the interface and so it is transperent to them. Components are inherent part and I'd indispensable of 3 tier architecture model.
If you'd like to "embrace the change", using components is not enough. Components without proper infrastructure and development team means nothing. In my humble opinion the most important things in building reusable software are:
1. Team & Knowledge Management - your team must be flexible and well motivated. Pay attention to knowledge transfer between team memebers. What's the use of the component, if you lose the knowledge about it's business logic? The best way to keep the team at the good level is to use the eXtreme Programming Techniques (eg. pair programming etc.)
2. Process - don't mean any kind of ISO / CMM stuff, rather something like XP (collecting requirements, preparing design and code)
3. Configuration Management - that flows from the above. Good version management, automated builds, branching etc. allows to create multiple application's using the same blocks. CM should cover not only the code, but also documents.
5. Reusable design - which means using proper design patterns and paying for reusability (making code reusable requires much more effort, than preparing it for the single application)
6. Architecture based on "reusability-friendly" technology (such as J2EE).