Value of Service Interfaces

January 4, 2015

Wrote earlier about why interfaces are important and in this post want to elaborate on their advantages for building reusable services. Service interfaces contain only the operation or method definitions and have no implementations. They can be used in a variety of ways:

  • Package service interfaces into a separate artifact to make it easy for client teams to integrate with services without pulling in bulky set of transitive dependencies
  • Bind the interfaces to one or more transport / integration technology via standard Dependency Injection (DI). For example, service interfaces can be integrated with a REST-ful Resource or a EMS listener.
  • Service interfaces can be backed by stub and/or mock implementation for automated unit and regression testing.
  • Service interfaces can be decorated with common cross-cutting concerns to separate them from the implementation. This is the strategy implemented via the Java Dynamic Proxy example.
  • Service interfaces can be implemented as a proxy to a remote implementation. For example, the client invokes the functionality via the interface but the runtime implementation makes a call to a server side API. This is useful if your teams need the flexibility to swap local / remote implementations depending on performance / dependency management related requirements

Pursuing BPM? Avoid Reuse Inhibitors

December 20, 2010

Implementing business process re-engineering and/or automation involves several moving parts from a technology perspective – stateful business process data, interfaces for external systems/user interfaces to interact with process information, and rules that determine several aspects of process behavior.

Here are some practices to avoid/minimize when pursuing BPM projects:

  • Building monolithic process definitions – as the number of process definitions increase there will be opportunities to refactor and simplify orchestration logic. As projects start to build on existing processes, there will be an increasing need for modular process definitions that can be leveraged as part of larger process definitions.
  • Placing business rules that validate domain objects in the process orchestration graphs. This will effectively tightly couple rules and a specific process hurting the ability to reuse domain-specific rules across process definitions. Certain class of rules could change often and need to be managed as a separate artifact.
  • Invoking vendor specific services directly from the process definition. Over time this will result in coupling between a vendor implementation and multiple process definitions. This also applies to service capabilities hosted on legacy systems. Hence, the need to use a service mediation layer.
  • Defining key domain objects within the scope of a particular process definition. This will result in multiple definitions of domain objects across processes. Over time, this will increase maintenance effort, data transformation, and redundant definitions across processes and service interfaces.
  • Integrating clients directly to the vendor-specific business process API. This will result in multiple clients implementing boiler plate logic – better practice will be to service enable these processes and consolidate entry points into the BPM layer.

This isn’t an exhaustive list – intent is to to highlight the areas where tight coupling could occur in the business process layer.


The Value of Service Mediation

June 14, 2009

Service Mediation is an abstraction layer in between the service consumer and the service provider. What is the need for mediation and what benefits does it provide? There are several benefits:Service Mediation

  1. Apply cross cutting concerns such as authentication, encryption, logging, metrics across all service requests. The mediation layer can have hooks in place to perform these concerns so individual service capabilities don’t have to invoke them each time.
  2. Provides the service provider the flexibility to change implementations or service fulfillment strategy. For example, you can migrate a service capability from one programming language to another or get off a legacy system.  You can also switch technologies fundamentally – instead of looking up data from a database to fulfill a service request you can read from an in-memory cache or introduce an indexed search engine.
  3. Mediation can also be used to translate physical transports to fulfill a service request. For example, you might have a capability that is available over HTTP and the consumer might need the capability to be accessed via a Java Messaging Service (JMS) queue. The mediation layer can intercept the request via a JMS input queue and turn around and invoke the underlying HTTP service.
  4. Services may not always expose the right input/output contracts. There might be legacy syntax/semantics exposed, or inconsistent error codes or too many parameters being exposed etc. More importantly service contracts need to align with your firm’s logical data models. This provides consistent business names, data structures, and decoupling from physical data.

This is just a starter list and there are many additional benefits when adding a mediation layer. I didn’t touch upon governance specifically but they are present in the points above.

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: