Product Standards | Art of Software Reuse

Add Transports Iteratively For Service Capabilities

July 14, 2009

You can add transport bindings to your reusable services iteratively as necessitated by project needs and timelines. A service can start out getting consumed over HTTP, and then support additional ones such as HTTP-S and JMS over time. The key is to not place transport logic in your service capability. This will give you a great deal of flexibility in adding and supporting new transports.

For example, your service can be initially consumed by a user interface application via request/reply SOAP over HTTP. Day 2, you might have a backend process that consumes the service via asynchronous request/reply SOAP over JMS. This should be a graceful extension for you if there was nothing in the service logic specific to HTTP or synchronous request/reply.

In essence, you are decoupling request processing, service business logic, and response handling:

transport-svc-capability

Like this post? Subscribe to RSS feed or get blog updates via email.

: : : : :

2 Comments | agile, Design, Planning, Product Standards, Reuse, SOA | Tagged: Java Message Service, SOA, SOAP, software reuse, transport protocol | Permalink
Posted by vijaynarayanan

Reuse connectivity components across your product line

April 15, 2009

Connectivity components such as database connection pools, messaging broker connection pools, HTTP thread pools, and others should be decoupled from your business logic components and managed separately. If you are using an application server that provides connection pooling out of the box this will be a non-event. But if you have applications outside an application server that need pooling functionality encapsulate them as separate components. Provide configuration options so each application that leverages these components can customize it. If there is code that couples connectivity and other types of logic actively refactor them out. Most importantly, when these components are in a production environment provide a means to reset or reinitialize them. As Michael Nygard points out in painstaking detail in his book Release It! this is going to make the difference with stability and availability. From a reuse perspective, if the components are stable and robust it saves time for the consumer when leveraging the asset. Most importantly, this will increase trust in the quality of these assets which is key to ensuring your investments into reuse don’t go wasted.

Like this post? Subscribe to RSS feed or get blog updates via email.

: : : : :

Leave a Comment » | Design, Product Standards, Reuse | Tagged: Design, software reuse, tactics | Permalink
Posted by vijaynarayanan

Standardize error codes for reusable error handling

April 14, 2009

Standardize error codes across reusable assets so that multiple assets can report errors in a consistent manner. If error codes are consistent, how you to chose to log them or react to them can also be standardized across the product line. If each reusable asset gives you a unique set of error codes it makes it difficult for dealing with them. Standard error codes themselves could have a naming convention depending on where the error occurred, which component/module/service the error originated, and type of resource impacted by the error etc. I like to use a dot (“.”) notation when reporting errors – e.g. when the XYZ module in ABC product cannot fetch a database connection the error code is: DB_CONNECTION_ERROR. You can have stack trace and error location to pinpoint where the error occurred but it is important that all database connection errors across your reusable inventory use the same error code. If we need to retry the connection, or notify a database support team, or whatever remedial action needs to be taken can be initiated across the product line using a single mechanism to handle errors.

Like this post? Subscribe to RSS feed or get blog updates via email.

: : : : :

1 Comment | Product Standards, Reuse | Tagged: error codes, software reuse | Permalink
Posted by vijaynarayanan