Monthly Archives: January 2009

WebMethods and TIBCO CUF – Common Utility Framework Services

The Common Utility Framework or CUF is a set of utility services created by any enterprise for their internal usage.

These utility services form the backbone and will provide a set of APIs to the applications which will be written for any enterprise solution.

The major advantage of using a CUF in your enterprise solution is to have a common standard implemented with respect to change of human resource in any organization.

Basic Features of CUF

A CUF should be responsible for everything which is used again and again and a programmer doesn’t like to code for it. All extra work which is most necessary but one doesn’t want to waste time in implementing it should go inside CUF.

CUF services would include:

Auditing (Transaction Logging)
Say you have a long process; you break it down and want to insert logging of the process as checkpoints. You really need some good utility to log all of this. Apache log4j is a good thing, but it needs to get into your CUF so that all other application can access it easily.

One can even log the following:
Complete Message Traceability : Track the entire message
Performance – Time spent in each transaction

Logging (General Logging)
You just need some general debug logging, or any other log.

You may want to put the logs on files or database. It depends on your organization.

There should have varied levels of log. How much data you want to capture?

This CUF service should also be responsible to change the levels of the logs at runtime

Exception Handling
There will always be happy path and sad path, what to do in that case? A common framework to handle common exception scenarios.

You may want to log these errors.

The best practice is to create a generic handler for all common exception.

Error Notification and Escalation
System Errors –Internal Errors, Mis-configuration, Database errors, Timeouts etc.
Business Errors – Component or Application Errors related to resources, processes, static data etc.

One should also keep in mind the following

Error levels – Critical, High, Medium, Low etc.
Alert levels – Whom to escalate, what level?

Escalations procedures – FIX, Root Cause and Prevention mechanism.

Message Repair:
Correct Missing Data – Human is notified, fixing and reprocessing work flow afterward

Reprocessing:
CUF should ideally be responsible or rather say intelligent enough to have reprocess logic
There should be different levels of retry:
For example –Retry from start, retry from last error checkpoint etc.

Medium:
What medium to use for notification?
Emails, Dashboards, alert screens, SMS
This should be configurable as per the interface
It should also be reliable

Initialization and Cleanup

Initial setup on start up
To reserve some memory
To initialize a data feed.
To initialize a pool of objects etc.

Locking mechanism: A set of common locking mechanism for shared services.
To ensure only one instance of the service is running
To ensure concurrency at service call level.

Cleanup of memory
To ensure your service terminates properly
To ensure you release all garbage data and clear unused memory

Custom garbage collectors.
May be a custom garbage collector on the service level.
For example, if a service has been running for more than X hours. Where X is max limit, it should get killed.

Shared Resources:

Database Pooling:
A common database pool of database and adapters which can be used as shared resources.

Middleware:
A message driven middleware or JMS/EMS shared adapters to PUB-SUB messages.

Service Management:
Manage service calls, Thread Management, Interrupt and reset shared object pools.

As a conclusion –A CUF should be responsible to make life easy.

There are hard and fast rules or concrete standards that organizations should follow but the above points should help you getting started to have CUF implemented at your enterprise.