Reduce Platform Risks Using Proxy Pattern

June 8, 2016

There are a number of risks when your platform integrates with an external service / dependency. For instance, here are a few risks and things that can go wrong:

  1. Doesn’t respond at all. Just blocks indefinitely eating client-side resources.
  2. Responds progressively slower – i.e. response time degradation.
  3. Needs retry logic to deal with transient failures (Note: obviously care needs to be taken if the call isn’t idempotent!)
  4. Responds with an unexpected return code – e.g. internal server error or service unavailable error, etc.
  5. Gets overwhelmed by the rate of requests being set to it. Ideally, it should have protection against this but what if it is not entirely in your team’s control.
  6. Becomes unavailable throwing runtime exceptions forcing undesirable side-effects on the caller rather than failing fast.

Michael Nygard in his book Release It! talks about leveraging circuit breakers to deal with integration risks. Broadening that idea a bit, we could combine circuit breakers and mediation into a more generic Integration Proxy component. This proxy could implement a number of common concerns when working with external APIs:

  • Capture response time and route metrics to an analytics agent asynchronously
  • Monitor stale connections and automatically reset them if possible
  • Host the circuit breaker with associated logic to toggle based on service health
  • Provide “fallback” responses if circuit breaker kicks in to disable integration point.
  • Host sleep / retry invocation logic using parameters like interval and max attempts
  • Automatically flush pending / bufferred messages when service is available again.
  • Enable request and response capture – specially for debugging production issues.
Advertisements

Leverage the Service Refactoring Pattern

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.

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.


The Template Method Design Pattern

November 16, 2009

The template method design pattern defines a generic algorithm and specify hooks for plugging in extension points and variations. How does this fit in with systematic reuse? It supports two levels of reuse: reuse the overall template algorithm over and over. Basically, an entire set of steps that gets repeated as-is or reuse specific steps across one or more template algorithms.

Template method can be used in a variety of scenarios. For example, the following steps could be performed for handling requests:

  • validate input request using security token
  • standardize data – remove whitespaces, unify upper/lower case, correct misspelling
  • pre-processing e.g. transform request prior to processing
  • processing step – e.g. executing specific business logic
  • post processing e.g. transform response message in a specific format, encrypt sensitive data

Key question here: what are the variations in the above steps?
– authenticating requests – using a LDAP provider vs. using X509 certificates
– standardizing data – use custom implementation or open source tools to fix request data and perform pattern matching
– transformation: might vary by format (XML, plain text, JSON etc.)
– processing: might vary by use case

The security module itself could be used by other apps requiring authentication. the transformation module could be used for a batch process and processing logic could be reusable for more than one project as well. As always, it is key to keep the template algorithm simple, cohesive, and loosely coupled via well designed application programming interfaces.

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

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


Message Exchange Patterns For Service Capabilities

October 15, 2009

Service capabilities can be reused mainly from the user interface tier, the business services tier, batch processes, and real-time processes and could be consumed from a plethora of platforms.  These capabilities could be accessed via message exchange patterns – request/reply (tight or relaxed SLA) and publish/subscribe.  All of these patterns drive your SOA and systematic reuse efforts. Some capabilities might always be available only via a single exchange mechanism but  you will increasingly be offering similar capabilities across these three patterns.

Note: the illustrations below depict a data source behind the service capability. This isn’t a requirement but if you are exposing core data as entity services or business services that access underlying data you will be needing one or more data sources for the service to be functional.

request_reply#1 Request/Reply (tight SLA – typically synchronous)

Most common pattern when executing on-demand data services. This is typical of interactive applications that send requests and block on a response. When doing a synchronous request/reply via JMS, a temporary/physical response queue could be created. Regardless of transport used, the idea is to get a response very quickly.

#2 Request/Reply (relaxed SLA – typically asynchronous)

request_reply_relaxed_slaThis pattern is used when executing long running service capabilities. The consumer sends a request and does not block on a reply. When the response is sent from the data service, the consumer can use a callback mechanism (a message listener) to process the data. This pattern also typically uses correlation identifiers to relate request and response messages. When using JMS, a physical queue is used to obtain the response messages. A queue receiver drains the message from the queue and proceeds with processing.

#3 Publish/Subscribe

This pattern is used by publication services that execute based on a business event or a data operation even. The service will publish standardized messages that align with your business-specific or domain-specific data model. This is very useful when multiple consumers need to get notified upon updates/changes to core data. Using this model, new consumers can be added via configuration in a message broker as opposed to writing code for each integration. The service will publish to a destination (i.e. a Topic) and subscribers (consumer applications or processes) will each get the appropriate publication.publish_subscribe

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

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


Using Design Patterns To Build Reusable Assets

October 2, 2009

Design patterns are common solutions to design problems based on a given context. When used appropriately, they help address changing requirements. There are several books on design patterns and I don’t want to repeat that information here. Instead, we will look at design patterns in the context of building and integrating reusable assets. Here is a starter list:

  • Strategy – Polymorphically bind concrete implementations to execute a flavor of logic. This is useful when encapsulating product variations. If you need to support multiple flavors of a feature at runtime it is applicable. For instance, searching a product catalog feature could use exact text matching for product A while using fuzzy matching for product B. This could also be used to support multiple flavors within the same product and choosing a concrete implementation based on criteria. For this feature, it could be type of user or the nature of input parameter or volume of potential results.
  • Adapter – Used for translating one interface from another in order to integrate incompatible interfaces. This is useful in a couple of situations. Introduce an adapter when reusing a legacy asset. It is also useful when there are multiple versions of a reusable asset that you need to support in production. A single implementation can be reused to support the new version and the old version. The old version of the asset can be wrapped by an adapter for backward compatibility.
  • Template method – Used to define a generic set of steps to execute with placeholders for concrete steps that need customization. I tend to use this pattern for reusing business process flows across varying product types. It can also be used when implementing a standard request processing flow for both library components and web services. This is a common pattern when introducing horizontal concerns (such as security, logging, auditing etc.) as part of the processing algorithm.
  • Abstract factory – Used to build a family of products that need to be created as a cohesive unit. You also don’t want your calling code to know the nuances and complexity of constructing domain objects. This pattern is very useful when creating domain objects that require business rules and you want the complex creation in a single place in your codebase. I typically use this pattern with supporting bundling of product features. If you want to reuse a set of product features across bundles you will have several objects that all need to be carefully chosen at runtime for consistent behavior.
  • Decorator – Used with a core capability that you want to augment at runtime. Decorators are pluggable components that can be attached or detached at runtime. The upside is that the decorators and the component being decorated are both reusable but you want to watch out for object proliferation. I use this for pattern when the same data needs to be formatted or rendered differently or when you have a generic set of data fields that needs to be filtered based on some criteria.
  • Command – Used to encapsulate information that is used to call a piece of code repeatedly. Can also be used to support undo/redo functionality. The commands can be reusable across different product interfaces and act as entry points to invoke backend logic. For instance, I have used this pattern to support invocation of services from a self-service portal and interactive voice response channels.

There are additional patterns that help you organize your application code better (such as Model, View, Controller (MVC) and avoid point to point coupling between applications (publish/subscribe) fostering reuse.

what patterns have you used?

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

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


Refactoring To Reuse #2

September 5, 2009

#2 Separate Presentation From Domain Entity

Many projects that you undertake might have a presentation component to it – it could be a browser based app, thick client on a desktop, or even a kiosk-type interface. Regardless of specific the presentation technology, you have to ensure that your domain or business logic is effectively decoupled from the user interface code. This is in fact the foundation of the Model View Controller design pattern. You can move business logic in the model layer, presentation logic in the view layer, and the glue code that orchestrates across user actions and domain entities into the controller layer. Often times this separation might not reveal itself in a clean way. In those cases it is important to refactor the code appropriately.

Here is an example – say you have a class named Organization which holds a collection of Units and a collection of Employees. For the sake of integration ease, the Organization class contains a toString() method that generates HTML markup code that formats an Organization object into a neat nested table structure. If you change the way the markup is generated or change rendering output format from HTML to PDF you will end up touching the Organization class. Not a good idea from a reuse standpoint. You want Organization to be about the business entity and nothing else. The fact that it was generated for a web application should be decoupled from the core domain object. You can refactor this class in a number of ways. One way to refactor would be to remove HTML code from the object’s toString() method and move it to a OrganizationFormatter class. This new class could be in a new package structure that is specific to a presentation. If you envision need to support multiple formats you can make OrganizationFormatter an interface and have multiple implementations – a HTMLFormatter, a PDFFormatter, and so on. Based on need a SimpleFactory can be used to return the appropriate formatter at runtime to generate the output. Regardless of the format, you can reuse the Organization class as-is.

Another case where this is needed is when your domain entities make assumptions about the user interface layer. This would require refactoring for enabling reuse as well – will elaborate on this in a future post.

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

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


Model View Controller Pattern and Reuse – Podcast Episode

August 16, 2009

Want to listen using iTunes?

Using iTunes?

podcast Just posted a new episode on the software reuse podcast series about the Model View Controller (MVC) pattern and how it helps with software reuse.

 

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

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


%d bloggers like this: