Extensibility layers of a "SW Product"
Few days ago my friend Senthoor and I were discussing on use of Facades for sessionbeans to hide the complexity of EJB 2.x. That discussion made me to think more on the architecture of a "Product" based software system. Here is a little thought on SW product design..
Broadly we can catogorize software projects in to two catogories.
1) Product development
2) Custom service software develoment
In my openion, compared to "Service software architecture", we need to pay special attension on some of the design aspects when designning a "Product architecture". During the continuous development stage of a Product based software,
a) Developers need to customize the product for different customers.
b) Product need to withstand against technological changes which happens over the time.
So by paying a little more attension on following factors in the design phase, we will be able avoid many extensibility problems in the long run.
Layered aspect of a "Product" architecture needs to be designed to support high level of extensibility. In a product, we should distinguish and identify the Kernal layer, customization layer (business process layer), service interfaces, and the presentation layer of our product for better software management.
Kernal consists of fine-grained operations and will include "data access layer" and "utility services" ( In a J2EE project entitybeans and utility sessionbeans performing atomic operations will make your kernal of the product). For an example "sendSMS(to, messge)", "insertStudent(student)" can be two operations in the kernal components. These opeartion should be atomic and should not compose business processes.
It is really important to understant the difference between fine-grained operation and a business process. for an example "insertStudent(student)" is a fine-grained operation where as "registerStudent(studentData)" will be a business process. Your customization layer should compose your business processes. In the above example, "registerStudent" business process may look like the following.
You can define your transactions, security constraints on your business process. Also this is the layer which may be customized for different customers of your Product (For an example a customer may request to send a mail to the registered student instead of a SMS). Ideally kernal should not be touched in customizations and should be managed as a seperate sub-project. Kernal can be associated to customizations as binary libraries. This will also force developers to document the components and will improove project documentations :). Also it is not recommend to build the kernal with your customizations in a single build script. But Kernal should also be evolved by adding new features which are required by new customizations in a seperate sub-project.
Another important thing is to hide the technology used in your business layer from the presentation layer. This can be achived through simple facedes. For an example you may write POJO model Facades to hide your sessionbeans and let developer to instanciate Facade with "new" operator and call business methods. Your facede will hide JNDI lookups and EJB specific exceptions, etc.. This will allow the developers to consentrate on business logics rather than configuring framework specific stuffs. On the other hand this allows you to switch the technology managing your business components with out impacting your presentation layer. (e.g. switching from EJB2.x to EJB3)
In this blog posting I tried to discuss some design concepts related to the layered view of a "Product" software architecture. In my openion, even in a "Service Software" architecture, extensibility should be provided to a certain extent , but there you may have to compromize it with the cost and performance.....