alphaspirit - Fotolia
Enterprises face many challenges deriving benefits from SOA architectures, such as service reuse. One of the key reasons has been the complexities underlying exposing enterprise services to new applications. With SOA, in theory services are generically reused. However in practice, there typically ends up being a lot of hardwired direct part-to-part integrations, according to Steven Willmott, CEO of 3Scale.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
At the same time, the API economy has started to explode by allowing enterprises to leverage existing services using straightforward RESTful interfaces. "APIs are everywhere," said Paolo Malinverno, research vice president for Gartner. "Any software that uses the cloud uses APIs. Companies are starting to leverage APIs for integration and also to allow agility for new applications. Any application purely within the enterprise can take advantage of the trends as well."
APIs versus SOA
SOA is an architecture and a way of structuring an application that goes through the partitioning of functional units that can be called from wherever, said Malinverno. SOA has been done with Web services protocols and people associate SOA with Web services, but SOA is an architecture and Web services are an API style.
Paolo Malinvernoresearch vice president, Gartner
"People in general don't want to talk about SOA," Malinverno explained. "They think it is passé and did not work. But SOA as an architecture is alive and kicking." Web services are just one way of doing SOA. APIs do have a slightly different connection than the old systems way of doing SOA internally, but architecturally they are more or less the same.
Malinverno added, "In IT, people build careers on technologies. The younger people don't want to hear about Web services. They want to hear about REST." REST, however, also limits the complexity of interactions. API management tools could help bridge this gap in the short run.
The main reason REST is so successful is because it is simple to use. Web developers can go to a portal, receive an API key and start testing it. The procedure with Web services is much longer and more complicated, said Malinverno.
The need for RESTful complexity
In the long run, REST could prove limiting as enterprises try to add complexity to API interaction. "REST enables simple interactions like create, read, update and delete," Malinverno said. "When you have more complex interaction, then you have events. You need to have event handlers that look at the event and then decide what to do."
Organizations will find a way to implement these more complex interactions, but REST and JSON will show their limits. "There is no hope that Web services will get there either because most of the standardization on Web services has finished," Malinverno argued. "There is more to do, but people have moved on. We will have to find some other protocol."
New considerations for business logic
With this in mind, a key feature to consider with API management tools is the ability to define business logic on top of the platform, noted Malinverno. Today, business logic is tied into business process partitions, into the logic of applications, or in the cloud in a SaaS package. REST will have to have a way to express at least some of this logic and support it.
Malinverno expects the API phenomenon to grow wider before it gets deeper. Developers now have a need for simple interactions, but in three years there will be a need for something more complex. REST still does the job, and does it well. Most of the growth of mobile and things on the Internet will be based on REST.
There are still a lot of applications that have business logic wired into them. For example, the vast majority of SAP installations have customized logic wired in. Changing the business logic for the future is one of the main problems with current B2B applications. Also, sometimes the logic does not depend on the business process. It depends on what was programmed five years ago.
Standardizing the interface
"People have been building APIs for 15 years," said Andrew Leigh, vice president of products at Jitterbit. "Now we come up with a term like 'API management.' People are trying to think through what it takes to build a high-quality API."
SOA was focused on the internal connections of the enterprise, but it turned out to be more complex and challenging than enterprises thought. The issue with SOA was that it was more of a methodology than a discipline. "When we looked at what APIs mean to SOA, we always looked inwards," Leigh said. "People built APIs in every crazy way. We had SOAP and Web services but the way people implemented them was fundamentally different than when the cloud came through."
The widespread success of cloud-based enterprises like Salesforce, NetSuite and Workday demonstrate the importance of a standardized approach to building and deploying APIs. Enterprises need to consider factors like security and how throttle exposes APIs to different consumers. "The problem we see is how do people take the enterprise data behind the firewall and expose it in a safe and secure manner outside the firewall," Leigh said.
Supporting the API tier
Full-featured API gateways, which have built-in transformation and orchestration capabilities, are adopted rapidly to provide a management and governance tier in addition to addressing lightweight integration. Sachin Agarwal, vice president of product marketing at SOA Software, said, "We see API tiers being either layered on top of existing integration tools like ESBs oriPaaS, or increasingly even being directly layered on top of the applications themselves."
The layering needs to be done with an appropriate infrastructure that respects the enterprises governance, risk and compliance needs. Agarwal said, exposure of APIs requires publication, documentation, security, monitoring, analytics and governance. These are capabilities offered by API management tools and are increasingly being layered on top of enterprise-class APIs.
Due to these capabilities, API management tools are being used as part of integration infrastructure. In some integration use cases where customers need lightweight orchestration and transformation, the API management tier provides a low-cost replacement alternative to traditional heavyweight ESBs that rely on proprietary adaptors.
API management is breaking down barriers between data locked within on-premises systems and making it available for new infrastructure and applications that are being increasingly hosted in the cloud, said Agarwal. With the fine-grained control, monitoring and analytics provided by API management platforms, customers have the ability to analyze usage and find out which services are being called the most often and further fine-tune either their business models or infrastructure.
Opening new enterprise adoption patterns
Agarwal sees four different enterprise adoption patterns emerging as enterprises re-architect and prepare for their digital transformation.
Balancing growth with control
Most SOA is predicated in a controlled environment in the enterprise or across trusted partners. "A lot of the problems you have to solve, like governance, you solve with SOA," Willmott said. "The shift for enterprise architects is thinking about how to put together apps that use those services."
When the enterprise publishes out a set of resources to a much larger audience, these developers will do things that were not predicted. Willmott noted, "It seems like a trivial change, but it is important. You need different levels of identity and trust."
For example, the city of New York is leveraging the 3Scale API management platform to build mobile applications for its citizens. The platform allows them to expose data in a structured way so that third parties can build applications that leverage these services. This makes it easy for people to find new ways for building applications in a way that does not incur development costs for the city. "People can get what they want, and the city does not have to pay a dime for it," said Willmott.
About the author:
George Lawton is a journalist based near San Francisco. Over the last 15 years, he's written more than 2,000 articles on computers, communications, business and other topics. Find out more at glawton.com.
Learn about the role of REST in legacy modernization