Sharing structured data

XML Magazine

Subscribe to XML Magazine: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get XML Magazine: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


XML Authors: Mamoon Yunus, Progress Blog, XebiaLabs Blog, Mat Rider, Sematext Blog

Related Topics: Software AG at SOA World, Intel XML, XML Magazine

Blog Feed Post

API Management for a Digital World | @CloudExpo #DevOps #Microservices

Ever since the dawn of the Internet, people have struggled with how to get one computer to talk to another

The rise of the modern API

Ever since the dawn of the Internet, people have struggled with how to get one computer to talk to another. Early business systems had no provision for such interactions. They were entirely closed— worlds unto themselves.

As enterprises set up early networks, the question of how to get applications to interact with each other became a pressing business concern, and led to the introduction of Remote Procedure Calls (RPCs). A client computer might directly interact with the program running on a server or host by calling procedures (or subroutines, methods, etc.) over the network.

As long as every host system had its own proprietary architecture, operating system and programming environments, however, such RPCs were rarely practical. As those systems matured, a level of standardization became more commonplace, and the Application Programming Interface (API) was born.

Early APIs exposed RPC interactions, and the fact that we were able to define a software interface allowed us to abstract the underlying code—thus simplifying the software on the client side and providing some measure of flexibility.

Flexibility, however, is a relative term. For many years, virtually any change in the code on the server required a commensurate update on each client—a problem we now call tight coupling. Companies were able to live with tightly coupled client/server applications. After all, they had little choice.

That is, until the Internet came along.

Thanks to simple protocols like HTTP and HTML, browser interactions with web servers were loosely coupled. Any browser worked with any Web page on any Web server and wouldn’t break when someone updated the page—more or less.

But what about application-to-application integration? How do we make those interactions as loosely coupled as the Web?

The answer: Web services. Take the suddenly popular eXtensible Markup Language (XML) as a basis, combine it with the hard-won lessons of interface publication and discovery from the Common Object Request Broker Architecture (CORBA®), and hammer out standard protocols for contracting software interfaces—now called services—and the formats of the messages they exchange.

Oh, and don’t forget publication and discovery of the services, which require more than an XML-based standard. We actually need architecture. And lo, Service-Oriented Architecture (SOA) was born, like a phoenix from the flames of CORBA.

The service contracts that defined Web services provided looser coupling as compared to the earlier generation of client/server APIs but required traditional middleware in order to support the data transformation and content-based routing at a scale that enterprises required to implement SOA in practice.

These Enterprise Service Buses (ESBs) were an important part of the early SOA story to be sure. But the combination of ESBs and Web services proved difficult to implement in practice—and with the advent of cloud computing, this first-generation SOA story became ripe for further innovation.

Today, the principles of SOA have become a part of the fabric of enterprise distributed computing, and by navigating the gauntlet of Web services, we have reinvented the API for today’s cloud and mobile-centric world.

Read the entire white paper (registration required).

Copyright © Intellyx LLC. Software AG is an Intellyx client. Intellyx retains full editorial control over the content of this paper.

More Stories By Jason Bloomberg

Jason Bloomberg is the leading expert on architecting agility for the enterprise. As president of Intellyx, Mr. Bloomberg brings his years of thought leadership in the areas of Cloud Computing, Enterprise Architecture, and Service-Oriented Architecture to a global clientele of business executives, architects, software vendors, and Cloud service providers looking to achieve technology-enabled business agility across their organizations and for their customers. His latest book, The Agile Architecture Revolution (John Wiley & Sons, 2013), sets the stage for Mr. Bloomberg’s groundbreaking Agile Architecture vision.

Mr. Bloomberg is perhaps best known for his twelve years at ZapThink, where he created and delivered the Licensed ZapThink Architect (LZA) SOA course and associated credential, certifying over 1,700 professionals worldwide. He is one of the original Managing Partners of ZapThink LLC, the leading SOA advisory and analysis firm, which was acquired by Dovel Technologies in 2011. He now runs the successor to the LZA program, the Bloomberg Agile Architecture Course, around the world.

Mr. Bloomberg is a frequent conference speaker and prolific writer. He has published over 500 articles, spoken at over 300 conferences, Webinars, and other events, and has been quoted in the press over 1,400 times as the leading expert on agile approaches to architecture in the enterprise.

Mr. Bloomberg’s previous book, Service Orient or Be Doomed! How Service Orientation Will Change Your Business (John Wiley & Sons, 2006, coauthored with Ron Schmelzer), is recognized as the leading business book on Service Orientation. He also co-authored the books XML and Web Services Unleashed (SAMS Publishing, 2002), and Web Page Scripting Techniques (Hayden Books, 1996).

Prior to ZapThink, Mr. Bloomberg built a diverse background in eBusiness technology management and industry analysis, including serving as a senior analyst in IDC’s eBusiness Advisory group, as well as holding eBusiness management positions at USWeb/CKS (later marchFIRST) and WaveBend Solutions (now Hitachi Consulting).