To say that I have issues with Service Oriented Architecture for IT infrastructure would be understatement. It is not that I do not like the idea of it, I just do not like the way people tend to implement it. But before I get ahead of myself lets make sure we are all clear on what service oriented architecture actually is.

What is SOA and whats wrong with the current implementations

Service oriented architecture is the idea that instead of building giant monolithic applications you build smaller pieces that can be accessed as a service using an API. You then use those pieces to stitch together your lager application. In theory this is better because the next application you build can then make use of the same services you already have in place. This allows code re-use and in theory makes time to deploy faster because you no longer are building everything from the ground up.

Now don’t get me wrong, SOA as it is described is great and should be the base of any modern IT strategy, but there are some fundamental problems with the way SOA is being done.

Problem 1:

The whole point of SOA is to allow small application parts (I will call them fragments) to communicate with one another easily and quickly. However in most IT departments there is no standardization of communication between fragments. Which means some applications may have a rest API, some may have a soap API, some may use old school sockets, and the list could keep going. What is worst is even if several applications use a rest API the parameters and inputs are all different. This means that for each service you application needs to connect to custom, code has to be written for the connection. Sometimes it might even be easier to just build the service natively removing any benefit of SOA altogether.

Problem 2:

Not only do you have many different ways to communicate with many different services, but on top of that you have many ways to authorize to these services. Few companies actually have a universal single sign on for there back end services. This means that if your application uses 5 services, you most likely will have 5 authorization systems and 5 sets of credentials. This means you have to handle the authorization hand shake independently for each service. What makes matters worse is I can almost guarantee that all 5 authorization services will use different standards complicating the matter even more for you.

Problem 3:

There is no standard return pattern. Like problem 1, some data will be returned to your application using JSON, some with XML, some with plain text, some as a CSV. If there is no standard that means you must implement your own parser within your application for nearly each connection.

When you think about problem 1, 2, and 3 most would realize that the amount of code they will have to write will erode the benefits of SOA. What is nice is that all three of these problems can be fixed, and fixing them is actually easy and does not require re-writing any of your existing services. Lets talk about the Service Bridge.

Service Bridge, the Answer to poorly implemented SOA

You can think of the service bridge as the gate keeper to all of your existing and future services. It is a single application that has a standard way of formatting a request, authorizing access, and responding to a request. It essentially acts as a consistent piece of middleware that takes the complexity out of communicating with different services, because the Service Bridge itself handles that complexity for you.

Another benefit of making a services standard and consistent is that now your developers can create standard libraries for the different application frameworks used in the organization. Now I am sure some of you who are reading this have your doubts about a standard communication protocol that can handle all types of requests.

The Standard of Communication

I am sure many of you have heard of JSON. For those that have not it is essentially a way to store data in a key value format. I argue that all communication no matter the system could be translated and sent via JSON. So I am suggesting a standard format that looks something like this:

{"Authentification":{...}, "Payload":{...}, "ServiceName":"...", "ReturnFormat":"..."}

The first thing to realize is your service bridge will act as your single sign on. The value you have in the ServiceName field will determine what type of authentication the service bridge will have to reach out to (and that will determine the format of your Authentication content). The ServiceName will also dictate what format the system is expecting the payload to be in.

Now we have not touched on the ReturnFormat field yet. This field dictates whether the request is synchronous or asynchronous. There will be some services out there or some application out there that cannot handle an asynchronous communication. If that is the case a value of synchronous will tell the service bridge to keep the connection open as it completes the request. By default though I would suggest that the service bridge operate in asynchronous mode, and its return should look something like this:

{"status":"queued", "id":"j123hg"}

Where ID is a unique identifier of the job that was submitted. The application can then poll the service bridge with the Job ID, until the job completes and the result is returned, once again in JSON.

Wrapping Up

So to wrap up this post I want to re-iterate the points I made above. SOA is a good idea but inconsistent implementation of the API and authorization protocols make things much harder then they should be. By defining a standard way of communicating with all services and centralizing authorization we can fix this issue. However it is not cost effective nor a good use of everyones time to re-build all of your existing services so instead I suggest we use the concept of a service bridge to act as middle ware enabling all of your old services to follow your new consistent protocol, while also giving you a place to build all of your new services.

In part 2, we will look at how to build a Service Bridge on Heroku, and then in Part 3, we will connect the service bridge to a few applications including Salesforce, Postgres, and maybe an external application. Finally in part 4, I will show you how easy it is to build an application using services from the service bridge.