Selecting a Strategy for New IT

There are many advantage that you can gain from moving to new IT that connects business data with customers, partners and general public in general. “New IT” here refers to pretty much any process/mechanisms that you take to move away from siloed applications and having a more integrated experience to make day to day business more efficient. From a business and project management standpoint this can mean gaining more visibility into ongoing projects and the business impact they make. From an engineering stand point this can mean, versions of each project that’s in production, projects that will be going to production soon, critical bugs affecting a release schedule and so forth. This blog tries to explore couple of existing problems and how API management helps to move forward with adopting “new IT” for a connected business.

Existing processes

Everyone has some sort of a process/methodology that works for them. No 2 places or teams are alike. When there are already systems and certain ways of doing things are in place, it’s hard to introduce change. First and foremost the battle seems to be from the developers who are accustomed to doing certain things in certain ways. When introducing something that’s new, it’s always helpful to position it as filling a gap in the current process, doing incremental improvements.

Possible problems

Let’s see what some of the usual problems and how API management can solve those.

Standard method for writing services

If you have a rigid standard when introducing a new service, that might not be optimal. Rigid standards in the sense that tied to particular architectural style like REST or everything being a SOAP service. There are some services and scenarios where a SOAP service make sense and there are other situations where an HTTP service accepting a JSON message would be much simple and efficient. Having a one true standard which forces non-optimal creation of services will lead to unhappy developers/consumers and end up not being reused at all.

Challenges in service versioning/consistent interfaces

When a new version of a service is to be released, there has to be a way of versioning the service. If you can disrupt all the client and force them to upgrade then that’s easy (in case of an API change). Otherwise there has to be a way of deprecating an exising service and moving it to the new one.

Finding an existing service. Encouraging service reuse

If there are services available, then there should be a way to discover existing services. Not having a place to discover existing services is going to make service reuse a nightmare. This is not about holy grail of service reuse most SOA literature talks about. Think about how a developer in another team or a new hire discover services.


When you have a service, you need to find out who’s using that service, what are the usage patterns, should certain clients be throtted out to give priority for other clients and so on. If you don’t have any metering, it’s near impossible to determine what’s going on. Problems (if you have any) service consumers face. It also helps to have historic data for doing projections that’ll result in resources expansions accordingly.


Here I would like to present a solution and how it will address some of the problems we listed out earlier. Make APIs the interfaces for services. There is a difference between a service and an API. API will be the consistent interface to everything outside (users within the organization/partners/suppliers/customers etc…), anything or anyone who will consume the service.

Having an API faƧade will be the first step. You can expose a SOAP based service without any problem. Exposing a REST service falls naturally. Exposing a service is not bound by any imposed standard anymore. A service can be written by analysing the best approach based on the problem at hand.

Versioning is enabled at the service definition level. The API layer. Following picture shows how to create a new version of an existing API.

In the picture above it shows the current API version in the top and you can give a version when you’re creating the new one. Once you create the API, at the publishing stage you can choose whether to deprecate the existing API or to have them coexist so that the new version is taken as a separate API. As following picture shows,

Another cool thing is that you can choose whether to revoke existing security tokens, forcing all clients no re-subscribe.

Next up is having a place for developers to find out about existing services. API Manager has a web application named API Store that list out published APIs. Here’s an example for the store that’s developed on top of API Manager. Monitoring is equally simple and powerful.

This is how API Manager helps to make life easy as well as help making the right technical choice. Allowing developers and other stakeholders to choose right service type, message formats encouraging service implementation to be diverse but still, having a consistent interface where monitoring/security/versioning etc… can be applied with ease.

Implementing an SOA Reference Architecture

A reference architecture try to capture best practices and common knowledge for a particular subject area or a business vertical. Although you can define a reference architecture at any level, for the purpose of this blog we’ll be talking about an SOA reference architecture. When tasked with implementing an SOA architecture, blindly folloing a reference architecture might not give optimal results. If business requirements are not considered sometimes it will be not the right fit for the issues at hand.

When an SOA architecture is going to be implemented, close attention should be given to business requirements and any other technological constraints. Having to work with a specific ERP system, having to work with a legacy datastore which otherwise, too expensive to replace with a whole new system and so on. Based on these facts a solution architecture should be developed that’s aligned with the business requirements.

Looking at the solution architecture a toolset should be evaluated that maximize ROI and possible future enhancements that might come in the next 1 - 2 years. Evaluating an existing architecture every 1 - 2 years and making small refinements saves the time and effort for doing big bang replacements and modifications for critical components. While selecting a toolset having a complete unified platform helps to build the bits you need right away and still have room for additions later. If you’re looking for a complete platform you probably want to consider WSO2 middleware platform provide a complete open source solution.

I’m biased for open source solutions and having a platform that makes connected business possible is mighty cool.

Twitter Scale

High scalability has a great blog about architecture of Twitter. How Twitter grew up from just a web application to handle thousands of tweets and the internal architecture of components they have. Last week I wrote a blog about how a simple web application might evolve according to different requirements with time and how it will save you a lot of time to come up with a loosely coupled architecture between your componets and how it would help immensely when it comes to handle difficult problems. Above article is a wonderful real life example of how Twitter evolved to handle massive number of users and tweets. Twitter is all about posting messages that are only 140 characters long. How hard can it be to write a webpage to handle that?! Great example how simple things can yield to a complex architecture on the backend to give a responsive user experience.

The article has a lot of details about problems specific to Twitter and tweets. Couple of big picture points I want to highlight are (straight from High Scalability article),

  • Twitter no longer wants to be a web app. Twitter wants to be a set of APIs that power mobile clients worldwide, acting as one of the largest real-time event busses on the planet.
  • Internal clients use roughly the same API as external clients.
  • 1+ millions apps are registered against 3rd party APIs
  • Tweets are forked off in many different ways, mostly to decouple teams from each other. The search, push, interest email, and home timeline teams can work independently of each other.
  • For performance reasons the system has been being decoupled.

Read the original article.

Understanding an Enterprise Service Bus (ESB)

This blog tries to give you an understanding of what an Enterprise Service Bus is and what are the typical functionalities of an ESB. What scenarios that it can be utilized, for what purpose, and how it will help you to solve similar problems you’re having in a consistent, standardized way. Also incorporating a wealth of knowledge from real life production deployments. That’s important. If you have something which can solve world hunger or claim to be the world’s best at something and if it’s not used in real life production scenarios, it’s good as dead. Those stuff tend to make great folk stories, like bed time stories that you tell your geek younglings of how, once upon a time this great and complex thing was built over a weekend with some pizza and mountain dew ;-)


Let’s forget about ES part in ESB and concentrate about the B. The bus. This is not something new. You probably have learned about busses when you read about PC architecture. If you look at how data is being transferred from CPU to memory and also how data is received from keyboard, mouse and other peripheral devices plugged into a PC they all use a bus. Why? Main reason being, it eleminate point to point links between those systems. In todays world, where there are thousands of different peripherals that can be plugged into a computer, imagine the mess it would create if all of them need point-to-point links to the CPU, memory etc… So you have a single bus that everything connects to. That will take care of transferring information back and forth between connected peripherals.

Integration problems

Companies tend to use a lot of software for their day to day activities. This will only increase with time, not decrease. Also, things that were done using manual labour or hardware also tend to be converted to software as this excellent blog explains. Using software is great you can increase the efficiency of business operations. Even this is true, there are instances where you want the data in one system to be fed into or do some form of consolidation to have a unified overview of what’s going on. Otherwise there’s little to no advantage of having disconnected systems. Then you have to some kind of manual intervention for keeping data in sync among all these different systems.

Collection of services

Because of sheer tediousness all these enterprise software systems started exposing their functionalities as web services. Now you have easier ways of connecting one system to the other. Importing data and exporting to another system is just a matter of writing some glue code to call several web services. Just like that your data synchornization issues between two systems can be solved.

When the number of systems gets increased then you have to maintain point to point links with different glue code that connects these systems. Again, it gets error prone and tedious when you have more than a handful of systems in place. It’s not going to be a scalable solution to the problem.

As you can see from the above image, it gets very complex and hard to maintain when the number of systems are increased. Add to the complexity, each and every system or the service that’s exposed might be operating on their own message format. Which you have to map from one message format to the other through your glue code when connecting different systems.

This is where a bus architecture is useful again. A service bus. Since it’s connecting all enterprise systems, enterprise service bus. Although I have no idea how the name came probably something along those lines :-)

As you can see, this simplifies the process a LOT. Now you can move all the “glue code” logic you had to the ESB.

Functions of an ESB

When you’re integrating different systems with some glue code that should have certain functions which can be different from one system to another, you need to take all those into account when you’re selecting an ESB. An ESB should allow you to do all those things. Let’s see what they are.

Expose services

An ESB as the name says, a service bus. It should have the ability to expose services. For example, taking the above diagram as an example, it should connect the CRM and expose CRM’s connectivity as a service to other systems. CRMService may be. That service we call it as a proxy service because it proxies request for the actual CRM service.

Message transformation

Since the message format one system accepts can be different from another, an ESB should allow you to transform one message format to another. This can typically be transforming from one XML format to another XML format. XML -> JSON, JSON -> XML, Binary -> XML and so on.

Protocol transformation

There are instances where systems expose their service through different protocols. HTTP, HTTPS, JMS, FIX, FTP, SFTP, WebDAV etc… So an ESB should support accepting messages from one protocal and sending it in a different protocol.

Routing messages

This is another commonly used function of an ESB. You receive a message and based on certain values in the message you want to route the message to different systems/services. So ESB should allow you to traverse through the content of the message and filter on any attribute that’s there in message content.

Message cloning/splitting/aggregation

Another useful functionality is being able to clone an incoming message and send it to one, two or several services that accept the same message format, all at the same time. Also, splitting a message before sending and aggregating messages that comes from different services.

There are many such forms of communications and different ways of processing messages. Based on this knowledge of systems and different ways of connecting and message processing, you can identify certain patterns from these integrations.

Enterprise integration patterns

This fortunately has been documented in the excellent Enterprise Integration Patterns book. The book has a pattern catalog that’s has been developed or extracted from by looking at different real life integration scenarios in the industry. Now an ESB should be able to support or fascilitate implementing these patterns. When you see how different patterns can be implemented through an ESB with the configuration, it becomes easy to understand how the pattern is to be implemented as well as if you need alterations to match it to your specific use case, then you can do so very easily. Here’s all the configurations how an ESB can be use to implement these enterpise integration patterns.

What Is Platform as a Service?

Tech industry is filled with acronyms. People build new acronyms and buzzwords all the time which contributes to this confusion. One such acronym is PaaS - Platform as a Service. If you ask 5 people what does PaaS mean, you probably will hear 5 different stories. All of them would be right! So what is PaaS?

To answer that we need to ask what a platform is. as-a-Service part is easy. You give something as a service. There’s no downloads involved, it’s hosted somewhere on the internet and is accessible through a browser or some other tool that will know how to communicate with with a service that’s hosted on the Internet. So what is a platform? This can mean many things and that’s where the confusion lies. So platform can mean,

  1. An operating system
  2. A programming language and associated libraries/frameworks
  3. A suite of products
  4. An application container (e.g.: application servers)

There are companies and products out there which provide a “PaaS” at all these different levels. Also they refer to them as PaaS providers or companies that enable to you use a platform as a service. Which is not wrong considering different meanings for the word platform. Gartner, your friendly neightborhood researh company has tried to defined these terms and some additional terms to clear out this confusion. Gartner difines PaaS as,

A platform as a service (PaaS) offering, usually depicted in all-cloud
diagrams between the SaaS layer above it and the IaaS layer below, is
a broad collection of application infrastructure (middleware) services
(including application platform, integration, business process management
and database services). However, the hype surrounding the PaaS concept
is focused mainly on application PaaS (aPaaS) as the representative of
the whole category.

This clearly state a PaaS is about an entire middleware platform. Not about any specific application server or a programming language/framework. Also, Gartner has introduced some more acronyms for clarifying this confusion. aPaaS and iPaaS.

Gartner definition for aPaaS is,

Application platform as a service (aPaaS) is a cloud service that offers
development and deployment environments for application services.

That covers offering an application server as a service giving users to develop and deploy on top of that.

Gartner definition for iPaaS is,

Integration Platform as a Service (iPaaS) is a suite of cloud services
enabling development, execution and governance of integration flows
connecting any combination of on premises and cloud-based processes,
services, applications and data within individual or across multiple

Even though the Wikipedia page for Google App Engine and the intro document on Google help site mention it’s a PaaS, Google App Engine is not a PaaS. It’s an aPaaS. To be a PaaS, according to Gartner definition above it has to have a set of middleware services. Like for example Stratos.