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.

This pattern:

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

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.

Here is an example implementation for a a Spring Interceptor extending the HandlerInterceptorAdapter:

package com.yourapp.learn;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.springframework.web.servlet.handler.HandlerInterceptorAdapter;

public class LoginInterceptor extends HandlerInterceptorAdapter {

 @Override
 public boolean preHandle(HttpServletRequest request, HttpServletResponse response,
 Object handler) throws Exception {

 Boolean userAuthenticated = (Boolean)request.getSession().getAttribute("userAuthenticated");

 if (userAuthenticated) {
    return true;
 } else {
    return false;
 }

 }
}

This interceptor simply checks to see if the user is authenticated by looking for a session attribute. If the result is true, the request is processed further.
Here is an example bean definition fragment for utilizing the above:

<bean id="testInterceptor" />

<bean id="testSimpleUrlHandlerMapping"
 class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">

<property name="interceptors">
 <list>
 <ref bean="testInterceptor"/>
 </list>
</property>

 <property name="mappings">
 <props>
 <prop key="/test">someController</prop>
 </props>
 </property>
</bean>

The actual logic can be in another component that is leveraged in the interceptor. The component itself could be reused across several apps. If such a component isn’t available, you can refactor existing logic to carve out the common functionality.

Technology is an important, essential, and necessary ingredient for systematic reuse. However, it isn’t sufficient to achieve widespread reuse. Hyperbole? No – widespread reuse is being touted from the days of mainframe routines, functions, object oriented design, and component based development to service oriented architecture and domain specific languages. Yes, the level of abstraction is inching closer to the business domain and the tools have certainly gotten richer and more reuse-friendly (for instance, refactoring support in IDEs).

So why hasn’t systematic reuse happened? There are equally relevant considerations with systematic reuse (ones that often get ignored):

• Process - are your teams performing design and code reviews? how much thought is given to architecture – not only at a system level but when systems interact and exchange data? are requirements reused across projects? if not, are overlapping/similar requirements resulting in duplicate functionality?
• Training- how can a new developer who joins the organization come to know about reusable assets? how do we reduce the learning curve and demonstrate utility of existing assets? how do we align architecture efforts to better leverage reusable assets?
• Infrastructure - how are reusable assets identified, developed, managed, and retired? what if a team needs to contribute a patch to an existing asset? are there continuous/daily builds and automated tests for reusable assets? who ensures the quality of reusable assets? who “owns” these assets and how do they get supported?
• Culture- do your teams collaborate and cross-pollinate ideas? is there a not-invented-here syndrome prevalent when it comes to leveraging existing solutions? how do technical leads and developers come to know about reusable assets?
• Resource - how are resources allocated when they are meant to be useful for multiple applications? are there incentives for developing and leveraging reusable assets? are there resources allocated for horizontal components that are non-functional in nature – but extremely useful for several apps?

This is only scratching the surface and is meant to illustrate that technology alone isn’t a silver bullet to achieving systematic reuse. No single product or technology can guarantee reuse to happen organization-wide overnight. You can make it easier with the right set of technology tools/libraries/products but time, sustained effort, and calibrated strategy (one that takes into account your organization’s challenges and constraints) are essential for enduring success.

The Software Product Line (SPL) practices from Software Engineering Institute pursues a comprehensive set of practices that address the above considerations. It takes a holistic view of reuse covering multiple perspectives including people, process, technology, and places a common architecture at the heart of achieving widespread reuse. It isn’t promising a panacea and is a much better approach than buying a technology that is being touted to hand you reuse success.

Freemarker is a templating engine that can be leveraged to perform object to text transformations – with freemarker it is easy to generate RSS feeds or delimited text or plain old XML very easily. Below are some code fragments that illustrate freemarker usage:

Below is a code fragment for setting up the template configuration:

try {
	// Initialize configuration;
	cfg = new Configuration();
	cfg.setDirectoryForTemplateLoading(new File(templatesLocation));
	cfg.setTemplateUpdateDelay(0);
	cfg.setTemplateExceptionHandler(TemplateExceptionHandler.HTML_DEBUG_HANDLER);
	//Use beans wrapper (recommmended for most applications)
	cfg.setObjectWrapper(ObjectWrapper.BEANS_WRAPPER);
	cfg.setDefaultEncoding("ISO-8859-1");
	//charset of the output
	cfg.setOutputEncoding("UTF-8");
	//default locale
	cfg.setLocale(Locale.US);

} catch (Exception e) {
	//handle the exception
}

The templatesLocation variable is the path to a folder with freemarker templates (referred to as FTL templates). These are similar to templates used with frameworks such as Velocity. For example, below is a template fragment:

<Name>${myBean.firstName} ${myBean.lastName}</Name>

“myBean” is the java object that has first name and last name properties supported by JavaBeans style getXYZ() methods.

Below is the code fragment when trying to invoke a template with a java object:

// loading the template file
Template template = //get template from a map
Writer out = new StringWriter();
template.process(dataObject, out);
String strResponse = out.toString();

The above code fragment essentially takes a java object (dataObject) as input and creates a string as output. Using the template above, the output for example could be:

<Name>John Smith</Name>

Freemarker also supports loops and conditions and offers a rich library of built-in functions as well.

1. Every project seems to reinvent business abstractions that are fundamental to your problem domain. No sharing or consistency of information models – this will be painfully evident when projects are happening back to back and your teams seem to be running into overlapping data modeling, data definition, and data validation issues.
2. Directly linked to above – is service definitions seem to not reuse schemas – i.e. each service has a unique schema definition for a customer or product (or some key object from your domain) and your service consumers are forced to deal with multiple conflicting schemas.
3. Legacy capabilities are leveraged as-is without mediation - increasing coupling between consumers and legacy systems. Tell tale sign here is if you see arcane naming and needless legacy data attributes sprinkled all over service interfaces.
4. Services seem to have inconsistent runtime characteristics – new service capabilities are added without regard to performance requirements – issues tend to manifest in production where users or entire processes/applications get impacted to service behavior.
5. Business processes bypass a service layer and directly access underlying data stores – if you have seen a business process invoking several stored procedures, doing FTP, publishing to multiple messaging destinations – all from a monolithic process definition that is a clear sign that governance is non existent.

These are few signs but key indicators that services are being built in a tactical fashion. In a follow up post, will expand on how governance can be leveraged appropriately to address these issues.

SOA Adoption Using Agile

Part 1 of a two part Article series on SOA adoption is up on the SOA magazine

There is always a deadline (or many deadlines) to meet and technical debt to accumulate. Since we are always in a hurry, it helps to be aware of what should be reusable – even if we won’t get to it in this iteration . So here are some ideas that can help you decide whether or not a capability should be developed for reuse:

• is the capability unique to your enterprise? i.e. it captures logic and/or process variations that provide competitive differentiation.
• is the capability making something incredibly hard/defect prone simpler and/or easier?
• is there a desire for customers to have a capability across business channels? i.e. from the web, from a mobile device etc.
• is it specific to your domain and potentially relevant to multiple applications in the domain? this may or may not be obvious – if it isn’t, delay commitment.
• is the capability only available in a particular technical platform but is solving  an often needed problem?
• is it automating boiler plate code generation or preventing defects?
• is there an in-house/external alternative that achieves your functional requirements? if so, seriously consider stopping investment in the asset.

This is a starter list – the idea that we keep coming back to is this – treat a reusable asset like a real investment. Every iteration and release is an opportunity to review and update the investment. When you make a decision, continuously refactor to make the capabilities less app specific and reusable.

This is a simple but significantly useful perspective to adopt. Capabilities are tangible units of functionality – regardless of implementation technologies used or systems that they are part of. When capabilities are identified, you can make more informed decisions about whether or not it is a reuse candidate. This is also handy every time there is a discussion on which part of a functionality should reside in a server component or a presentation component etc. Capabilities, when aligned with business needs, gives you the right level of abstraction when considering refactoring efforts. Are we refactoring the right capabilities from a legacy codebase? is this a capability that is useful as-is or is it only relevant within the context of a specific business process? is the current implementation assuming (aka coupling) too much about a business capability?

These are extremely relevant questions – and notice how we haven’t talked about technology implementation decisions. That is on purpose – if we are not careful, impatient technology choices could adversely constrain business capabilities. Once you are clear on the capabilities – technology decisions and need for variability, agility, and other quality attributes can be made appropriately.