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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
“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.
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.
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.
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.
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!
Related posts:
No comments:
Post a Comment