September 8, 2010
As a follow up to the earlier post on using freemarker, here is an example of creating RSS 2.0 feeds using a freemarker template. This FTL will work assuming there is an input javabean that has a collection accessible via getItems() and returns a list of Item objects. Each Item would have a title, description, link, and last modified date properties as shown below:
<#list items as myitem>
September 6, 2010
The Service Refactoring pattern facilitates changes in service logic and/or underlying service implementation while preserving existing consumer contracts.
The Service Refactoring pattern allows the service provider to change the service implementation while preserving existing service contracts. This allows the provider the flexibility to honor existing consumers while taking advantage of streamlined service logic and/or better technologies. If this idea sounds familiar, it is based on the refactoring principles and techniques advocated by Martin Fowler in the object oriented design paradigm and aims to achieve the same result for services in a SOA context. This pattern requires the development of an adapter – that will translate messages conforming to the existing contract into the refactored contract and vice versa.
- Allows for phased migration of consumers who use existing contract to a new one
- Allows the provider to upgrade/enhance service behavior in phases. The refactoring can be accomplished via multiple steps and don’t all have to be bundled in a single release
- Eliminates the need for consumers to change code to take advantage of refactored service
- Allows new consumers to bind to the enhanced service contract and allows for new and existing consumers to co-exist
- Potentially enhance performance, availability, and scalability as new consumers come on board
There is a need for strong and coordinated service governance to make sure that consumers are aware of the refactoring effort, retest to validate the behavior, and ultimately provide sign-off for the service capability to be turned on in a production environment. At a minimum, this pattern needs to make sure that existing consumers conduct regression testing to guarantee that the refactored service doesn’t necessitate code changes.
September 5, 2010
Received an email from a reader on the continuous alignment post and wanted additional examples. Practicing continuous alignment entails refactoring existing code to align assets better towards a reuse strategy.
Here are a few scenarios where refactoring opportunities can be utilized:
Horizontal logic mixed with app-specific logic: This is typically manifested in two flavors – cross-cutting functionality that is horizontal across several applications or domain-specific functionality that is applicable to a product line. Cross cutting functionality such as authentication, logging, error handling etc. can be refactored from app-specific to distinct components.
Redundant definition of business objects: maybe two or more of your projects are redefining a core concept from your problem domain and refactoring can help align them to a common definition. Once a common definition is used, add tasks into your iteration plans.
Manage application configuration: If several applications use ad-hoc set of practices to manage runtime configurations (e.g. xml configurations, property files etc.), refactoring them to use a consistent strategy would certainly make sense. This refactoring can be done one component at a time if time constraints make it harder to transform an entire suite of components in the app.