Blogs

EDI to API – The evolution of systems integration, Part 1

Written by Coforge-Salesforce BU | Dec 13, 2016 6:30:00 PM

What is EAI? What is SOA? What is SCA, BPEL and ESB? Are all of these Web services? What is an API?

Being a systems integration architect, I often hear these questions from clients, sales team and developers. I think the best way to understand what these acronyms represent, is to picture each one as a milestone on the evolutionary road to today’s systems integration.

As Plato rightly said, “Necessity is the mother of invention.” The journey to today’s Service Oriented Architecture (SOA) started in the early 70’s with Electronic Data Interchange (EDI). EDI was a way of exchanging vast quantities of digital data and information across enterprises. It was developed to address data exchange problems for a limited number of business areas.

Moving on, here are the notable milestones for later decades in the history of SOA:

  • The 80’s – the era of inter-process communication
  • Early 90’s – the era of distributed computing
  • Late 90’s – the battle of the standards for application integration
  • New Millennium – a common agreement on Web service standards
  • Recent Past – ESB and API-based integration


The 80’s – The era of Inter-Process Communication (IPC)

Inter Process Communication enabled communications between systems or network level applications within the system. UNIX lovers treated network operations as remote system calls, terming it Remote Procedure Call (RPC). The first implementation to gain popularity was Sun’s RPC (ONC RPC), which was used as the basis for the Network File System (NFS) protocol. On the other side, the Windows community came up with Component Object Model (COM) and Dynamic Data Exchange (DDE) that allowed sending and receiving messages called “conversations” between applications.

These set the trend in network level communications like TCP/IP (Transmission Control Protocol/Internet Protocol), LAN (Local Area Network) and inter-application messaging like OLE (Object Linking and Embedding), but all still contained within the vendor’s own boundaries of technology and ideology.

Early 90’s – The ideology of distributed computing

The early 90’s saw the curtain rise on a new stage of distributed computing. It elevated the concept above the system or application level to a service level. A service can be anything from a file transfer, to an operation on a systems resource, like a printer. The two major technology communities competed with their distributed programming models; RMI (Remote Method Invocation) from Java, and DCOM (Distributed Component Object Model) from Microsoft. RMI used JRMP (Java Remote Method Protocol) and DCOM used Microsoft RPC (MS RPC) which were obviously developed on top of their predecessors RPC and COM.

This way of requesting and executing remotely opened the door to EI (Enterprise Integration) with service as the common interface, but still dependent upon vendor specific operating systems, transport protocols, programming languages and message formats.

Late 90’s – the battle of the API (Application Programming Interface)

With better distributed computing, and more applications being integrated, there was an increased need for a common enterprise application integration standard.

During this period, more trading partners replaced non-Internet transaction methods with the Internet for external company communications. The IETF (Internet Engineering Task Force) released a revised EDI specification which separated the electronic document format (data) from its transmission method (protocol).

Whilst EDI was being adopted by the enterprise, IT giants were fighting to push their integration methodologies onto the market to win the race for the industry standard. Microsoft continued with DCOM and other big players like IBM, BEA, Oracle and Sun picked another initiative, CORBA (Common Object Request Broker Architecture). CORBA’s objective was to garner agreement for a common communication protocol, an intermediary language for service operations, but at the same time allow vendor and platform specific implementation at runtime:

  • IDL (Interface Definition Language) defined the service interface.
  • General Inter-ORB Protocol, the abstract protocol for ORB.
  • RMI over IIOP (RMI-IIOP), the most popular CORBA implementation.
  • Revised Java RMI replaced JRMP with IIOP (Internet Inter-ORB Protocol) to support the CORBA architecture.


These components of distributed computing with EDI were termed EAI (Enterprise Application Integration). EAI implementations were successful on a stack of tools specific to a vendor or programming language, but failed to address cross platform, heterogeneous, real-time application integration.

Drawbacks to EAI

  • Enterprise forced to align internal process to fit the EDI standard used to communicate with third parties.
  • Enterprise locked into expensive vendor-specific implementations.
  • Integration depends on platform specific transport protocol.
  • Operating system and programming language dependencies increase the cost of maintenance.

Enterprise integration took an interesting turn towards end of 1990’s when the W3C (World Wide Web Consortium) released the XML (Extensible Markup Language) specification, and Microsoft convinced key IT player IBM, to adopt its Simple Object Access Protocol (SOAP).

If you would like to find out more about how Systems Integration could help you make the most out of your current infrastructure while enabling you to open your digital horizons, do give us a call at +44 (0)203 475 7980 or email us at Salesforce@coforge.com

Other useful links:

EDI to API – The evolution of systems integration, Part 2

Coforge Systems Integration

API Recipes with MuleSoft Anypoint Platform