[This article originally written by Pablo La Greca.]
Long ago, enterprise companies started using software to manage information across the enterprise. As the number of systems within the enterprise grew, the need to synchronize all these isolated systems emerged. From this came the need to find a solution allowing system-to-system communication, and the easiest approach for this was point-to-point integration. Soon, enterprises found themselves with several systems interconnected via point-to-point integration, resulting in a maintenance nightmare. Rather than being unified, each system had it’s own communication protocol – some were file based, others were databases, and if we were lucky, some of them used web services.
The mess began to look something like this:
Point-to-point integrations were typically done with little or no documentation. With numerous systems and poor documentation, it was hard to keep track of which system was doing what. Moreover, it became difficult to reuse integrations. As a result, users started creating duplicate behavior within different systems, further increasing the complexity.
The software world realized that it was impractical to continue working like that; there needed to be a better way to organize interconnected systems.
What is SOA?
We can define service oriented architecture (SOA) as an architectural pattern. Some of its main pillars are:
Services must be reusable
Service must have a service contract
Services can be easily discovered
Services can be composed into other services.
When designing systems with these pillars in mind, it becomes easy to build applications that provide reusable services. Having an easy way of discovering those services and a clear interface to communicate with them promotes reusability of software components and allows the creation of systems that provide more concrete services by composing services from other systems.
You can argue that we still have the point-to-point nightmare depicted in the “spaghetti” picture above. That is where the last pillar comes in: Service location transparency.
Service location transparency means that the client of a certain service must be agnostic of it’s physical location. Most of the time, this is accomplished by using a service bus that decouples the service location from the service consumer.
What are APIs?
Application Programming Interfaces (APIs) have been around for quite some time, yet their popularity has recently skyrocketed. Whenever you use a third party library within your application you are using an API, whether it’s correctly defined or not, to communicate to it. APIs by definition are source code based specifications intended to be used as interfaces by software components to communicate with each other.
Why is everybody talking about APIs?
IT has evolved in a way that has given APIs another meaning. Generally, when the term “API” is brought up, the first thing that comes to mind are those of publicly available APIs like Twitter or Twilio – and there’s a good reason for it.
In the last 10 years the number of APIs has grown dramatically. Company applications are not isolated anymore, but rather, we see SaaS applications connecting to other SaaS applications. You can see this everyday. Whenever you visit a new site and it allows you to log in using your Google account, there’s communication going on between the site application and the Google API to authenticate you.
How do SOA and APIs play together?
API expansion required a “simple” way to create APIs. “Simple” in a way that allows any type of client to rapidly develop a consumer of that API providing faster time to value. Therefore, APIs share the following SOA pillars:
Services must be reusable – APIs are defined to be public so they can be reused by other applications.
Services must have a service contract – This is a must since it’s an API.
Services can be easily discovered – Most APIs have good documentation with lot of examples.
Services can be composed into other services – Companies such as ark.com provide an API that behind the scenes is composing services provided by other APIs.
When defining reusable services within a SOA-initiative-driven company, one must take into consideration who the service consumers are and how to manage them. For instance, a single service consumer may try to invoke a service thousands of times per second. Managing this service access is called SOA governance and requires managing permissions for which consumers can access which services and defining SLAs, which may involve policies such as throttling service access.
With APIs, it’s pretty much the same, but at a much larger scale. There are public APIs and different kinds of consumers for that API such as partners and developers. Managing all these is called API Management and is similar to the concept of SOA governance. An example of an API management tool is MuleSoft’s Anypoint API Manager.
APIs can be seen as a means to a SOA implementation. Companies will continue to push for the pillars of SOA but the set of technologies used is going to match the ones that are emerging from the API world. One clear example is the shift that’s happening from SOAP to REST.
For the past year, we have seen the same evolution that happened within the enterprise now happening at a broader level between companies. APIs will keep increasing exponentially in number, and that evolution will be accompanied by a new breed to technologies focused on simplifying the exposing and consuming of APIs.
See what MuleSoft is up to in the API space by visiting our Anypoint Platform for APIs page. Or, take a look at our entire Anypoint Platform, consisting of solutions for APIs, SOA, and SaaS. Don’t forget to follow us on Twitter @MuleSoft!