Building Reusable Components Using a StateChangeListener Pattern

Introduction

Today, server-side Java development has become simpler because of component models using EJBs. The fundamental concept behind these component models is to allow components to do only business logic and let the application server manage the non-functional features such as threading, performance and so forth. However, these components still do logging, billing, and other functionalities, which vary based on the deployment scenarios. If a framework or an application server could either provide these functionalities or allow plugging of components providing these functionalities, the reuse of these components would attain a much higher level. This article talks about obtaining such a reuse of components using the StateChangeListener design pattern, which is an extension of the Observer-Observable pattern.

Scenario Illustrated

Consider a Java component that does some useful business logic: It may talk to a database, interface with EAI like SAP, and so forth. The component owner inserts log statements into his component for varying purposes such as debugging, auditing, billing, and the like. The "debugging" reason is valid to be owned by the component owner because it helps him fix bugs in the component. However, the other aspects such as auditing, billing, and so forth, the component owner cannot decide by himself. Rather, it depends upon the situation/environment where the component is deployed. For example, some scenarios may require audit logs to directly go into their ERP system, whereas for some other scenarios, it may have to be logged in a database. Though logging packages such as log4j allow a flexible configuration for file formats, storage (file or database) into a file or database as well as allowing custom appenders, it may not cover all the unforeseen circumstances that would arise during application deployment. So, instead of a component doing audit logging and billing by itself, it can express its intention by raising events about it.

Why Express State Change

Typically, a component does audit logging or generates billing information when there is a change in the component's state. If it raises an event about its state change, it allows listeners to be plugged to take care of these events. These listeners can be pre-built and could be provided by the Application Server itself as pre-packaged listeners. This allows custom handling of state change events and hence gives full flexibility during deployment. This also removes the burden on the component developers from doing audit logging and billing, and allows them to concentrate on business logic alone.

Illustrated with Example

The following code snippets throw light on possibility of development of frameworks based on StateChangeListener pattern. Note that the intention of the code snippets is to make the readers understand the requirement of such frameworks and is not, by any means, the only way of achieving the requirements.

Author's Profile

Mr. R. Venkatavaradan has been working as a Technical Consultant for Hewlett-Packard. He has a Masters Degree from the School of Automation, Indian Institute of Science, Bangalore. He has about 13 years of industry experience. The field of his work ranges from signal processing to Web services, J2EE, Enterprise Application Integration, and so forth. He has extensively worked on Web service technologies such as WSDL, SOAP, and UDDI and has provided technical consultancy to various projects in the field of mobile, telecom, and EAI, which have been architected based on Web service concepts.

Please enable Javascript in your browser, before you post the comment! Now Javascript is disabled.