Wednesday, August 10, 2005

Extensibility layers of a "SW Product"

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.

registerStudent() {

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.....


88Pro said...
This comment has been removed by a blog administrator.
88Pro said...

Business Delegate Pattern (EJB Design Patterns by Floyd Marinescu)

Once again a Great post. Just wanted to add a few things I read

The methods implementing the business process needs to run within transactions (e.g registerStudent() should roll back completely if one of three methods fail. Specially the chargeStudentBankAccount()) One way to achieve this is by the usage of Session Façade (page 5) which are Session Beans which runs within the container and thus get benefit of transaction.

So how to decouple Client Layer from the Kernel, the answer proposed in the book is Business Delegates (Page 98) (POJOs). Business delegates address the problems of directly invoking session facades and thus tying your client layer to EJBs.

1. Delegate method calls to a EJB (most of the time to a Session Façade which implements the business process methods)
2. Hides EJB Specific System Exceptions
3. Hides complex JNDI look up from client developers.

Business delegates have one-to-one mapping between the session facades methods.

One of the most interesting aspects about business delegates(after skimming through that chapter) for me is that it can pump out dummy data until the facades and kernels are developed. For example say two developers are working on a new functionality, one implementing the business process and other the implementing the client, the guy who is developing the business layer can first add a method to the business delegate and (say getAllContact() which returns an List) and create a ArrayList of few contacts hard coded and return a List which enables the client developer to start implementing the client side feature parallel without waiting until the kernel implementation is over. Once the actually kernel implementation is over the dummy list can be replaced by the actual called to a session façade method.

A different view about Business Delegates

Anonymous said...

Very good and relevent stuff for us at RippleVault. BIG thank for both of u guys..

Hasith Yaggahavita said...

Thanks Senthoor for the valuable inputs. I went through A different view about Business Delegates article. But I dont think assembling your business process on a delegate would be a very good idea all the time. It will make you to handle transaction rollbacks your self. I believe Kernal (atomic operations), Session Facades (business process) and Business Delegates (1-1 in session facade) approach will be more appropriate...