Software Reuse Quick Tip # 21

October 28, 2009

Tip # 21 – Identify Repetitive Steps Consumers Perform

There are a variety of places to look for reuse opportunities – one that is my favorite is looking for patterns with customer integrations. If a customer is setting ten properties to execute a common service call or method, why not provide a convenience function to accomplish the same in fewer steps? The other classic example is initializing objects. If every consumer is creating the same set of objects and initializing it in a specific way – resulting in a lot of repetitive code – you can provide a factory class or a façade interface. Additionally, look for activities that customers do that should be part of the reusable asset or can be useful to others. For instance, maybe after receiving output your customer converts that data to another format (say from XML to JSON or XML to plain text) – why not provide an option to get that right out of the reusable asset? Note of caution here though: what I am referring to is only common capabilities that aren’t specific to a single consumer. If you place logic that is specific to a consumer the asset is no longer reusable.

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

tweet this add to del.icio.us post to facebook

Advertisements

SOA Patterns and Practices

October 4, 2009

In an earlier post I listed a set of anti-patterns when pursuing service orientation within the context of building reusable capabilities. As promised, here are a set of patterns and practices that will increase the likelihood of success with reusable services.

Build with an enterprise mindset – Build service capabilities that are project/initiative specific and pursue reuse in a systematic manner. When designing and building services, try your best to decouple them from implementation-specific, distribution channel-specific, or consumer-specific logic. The goal should be to build reusable services unless you cannot. Similarly, actively refactor existing capabilities to be more reusable as necessary.

Be transport agnostic – Support transports other than HTTP; specifically, reliable transports. Reliable transports help decouple the sender and receiver from being available at the same time for data exchange. Reliable delivery, automatic retry, and a host of other features relevant to SOA are provided by messaging middleware out of the box.reuse-investment

Complement on-demand with event driven offerings – Asynchronous messaging for supporting request/reply and publications will need to be supported sooner or later. Asynchronous request/reply will provide consumers reliability and flexibility to consume data. Standard publications will facilitate large scale reuse of data services. When a new consumer needs an existing service, they can be subscribed to a standard publication.

Embrace platform heterogeneity – platform homogeneity is an illusion. Your services will be invoked from several platforms. .Platforms such as NET , Java/J2EE, mainframe systems, perl may all be applicable. Use tools such as WS-I to ensure interoperability.

Mediate Service Access introduce a service mediation layer that can provide protocol bridging, data transformation, enforce security policy, and capture metrics. They are specially relevant when wrapping legacy capabilities and you don’t want consumers to be too tightly coupled with systems slated to retire.

Achieve semantic & syntactic symphony – XML schemas, data types, web service contracts should be aligned with your business domain entities and not individual systems or packaged products. Achieve consistent naming, definitions, across operations – this will not only make it easy for consumers but will be. Effectively reuse business data types and data object definitions across operations.

Validate service requests- service capabilities need to validate incoming requests prior to interacting with operational data stores and transactional systems. If your validation logic is spread across capabilities and is complex, strongly consider externalizing decisions in a rules engine.

Robust consumer integration – High quality customer integration function will reduce pressure on the development team and help in creating and maintaining service documentation. More importantly, you will build useful knowledge on integration challenges and issues with consumers. This function will be the bridge between consumers & service development teams providing feedback and enhancements. They can also report on access patterns, invalid messages/exceptions, consumer usage trends, SLA violations/adherence etc. Finally, they provide a consistent experience for consumers during provisioning, integration, and while in production.

This isn’t an exhaustive list but will put you on the path to building the right set of reusable capabilities for automating business processes and modernizing applications.

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

Slide 3

 

ØWe need to build services that are project agnostic and foster reuse across initiatives. Reuse needs to be given a ‘first class citizen’ status when designing and building data services. The goal should be to build reusable services – reuse needs to be in our DNA!
ØWe need to support transports other than HTTP; specifically, reliable transports such as MQ even if web service continue being a popular metaphor.
§Reliable transports such as MQ will be able to handle large payloads
§Queues decouple the sender and receiver from being available synchronously for data exchange
§Reliable delivery, retry, are features provided by messaging middleware out of the box
ØIn addition to on demand services, we need to build event driven services. Asynchronous messaging for supporting request/reply and publications will need to be supported.
§Asynchronous request/reply will provide consumers reliability and flexibility to consume data
§Standard publications will facilitate large scale reuse of data services. When a new consumer needs data from an existing service, they can be subscribed to a publication via configuration
ØPlatform homogeneity is an illusion. Data services will be invoked from several platforms:
§.NET platform
§Java/J2EE platform
§Mainframe
§PERL
§ JavaScript.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :


%d bloggers like this: