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

In last weeks’ blog I looked at the milestones in systems integration from EDI in the 1970s to the distributed computing architectures of the late 1990s, now we’ll move onto the New Millennium and the following:

Developments in the New Millennium were boosted by Extensible Markup Language (XML) and Simple Object Access Protocol (SOAP). XML with schema definitions was a set of guidelines providing data formats in simple text. This made the creation and exchange of custom data structures possible. SOAP, based on XML, was transport protocol neutral, and language independent, and so opened the door for enterprise service integration using Web services:

• WSDL (Web Service Description Language) an XML-based service description language - used to define message structures, service operations, and communication protocol - emerged as replacement to the CORBA (Common Object Request Broker Architecture) IDL (Interface Definition Language).
• SOAP, an XML-based communication protocol and a better alternative to the GIOP (General Inter-ORB Protocol) used by CORBA.
• UDDI (Universal Description, Discovery and Integration), repository service definitions used to dynamically discover and invoke Web services. Again this was XML-based, enabling CORBA interface and implementation registries.
• (BPEL) Business Process Execution Language, an XML-based language which orchestrates multiple Web services for business integration.

Both Web services and BPEL were widely adopted by the IT and business community, and replaced the 90’s EAI (Enterprise Application Integration) stack.

Over a period of time it became apparent that BPEL was an overhead in application integration. And systems integration architectures in the early 2000s were still subject to vendor lock-in and not always enabled by web services. 

The recent past – ESB and API based integration 

The Java Business Integration (JBI) specification is a common standard for Java-based applications, and is used to address the BPEL overhead. JBI defined an architectural pattern called Enterprise Service Bus (ESB), an application abstraction layer used to mediate between the integration components, via WSDL (Web Services Description Language) to describe the functionality offered by a Web service, and Message Oriented Middleware (MOM) like JMS (Java Message Service) or WMQ (WebSphere MQ).

Two major companies, IBM and BEA (WebLogic) were not part of the JBI specification and have followed other integration paths for Java applications.

Most of the key players in systems integration - TIBCO, BEA, Oracle and IBM - follow a composite application model called Service Component Architecture (SCA). SCA is not an alternative to ESB, rather it is a way of combining different kinds of implementations, either involving mediation through ESB or a simple BPEL orchestration of abstract WSDL interfaces.

• IBM WebSphere Process Server uses connector interfaces as abstract contracts with BPEL to wire the process flow. As does Oracle, with JCAPS (Java Composite Application Platform Suite), a standards-based Enterprise Service Bus.
• Oracle Service Bus uses XML modelling under Spring, an application framework and version control container for Java as a component wiring tool.

Similar to EAI, the way of running services through WSDL and the various ways of composite application development combined, is called Service Oriented Architecture (SOA). SOA is widely adopted for both inter and intra systems integration, but the industry began to encounter issues with XML and SOAP that impacted application performance.

ServiceMix and Mule are two notable ESB implementations that delivered critical areas of improvement. The benefits:

• Application integration is an event driven flow rather than central hub of orchestrated operations.
• Direct mapping of data fields should be possible between the same data type objects. Marshalling and un-marshalling with an intermediary XML format is not always necessary.
• SOAP/WSDL based services can be replaced with the lighter weight REST/RAML (REpresentational State Transfer/RESTful API Modelling Language) approach to communications that uses less bandwidth
• Java Script Object Notation (JSON) is a light weight and UI friendly data format with no overhead like the marshalling or un-marshalling of XML.
• REpresentation State Transfer (REST) API mean communication and service operations are based on proven HTTP protocol, supporting both JSON and XML.
• RESTful API Modeling Language (RAML) – A YAML-based (human-readable data serialization language) implementation used to describe the RESTful API implementation. It’s like WSDL to a Web service that enables the service provider to build application interfaces in a standard way.
• MuleSoft is known for its strengths in API design and integration.

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, then give us a call or email us at Salesforce@coforge.com

Other useful links:

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

Coforge Systems Integration

API Recipes with MuleSoft Anypoint Platform