Integration

Integration has become a prevailing requirement to function within any environment for which information technology is used. The internet became infused in our daily lives within a relatively short space of time. The practice of integration is and will have similar exponential momentum in our technology world.

This is demonstrated in its evolutionary history. Early on, the number of computers and who used them were limited to governments, scientific organisations, tertiary organisations and very large corporates. These were the only organisations that could afford to build and or maintain these clunky contrivances.

By the late 1970’s, the landscape had rapidly changed as software was available for CAD, Word Processing, Graphics, Spreadsheets; along with new programming languages released on an annual basis. Computer networks like Wozniak’s Blue Box and Bob Metcalfe’s Ethernet were in existence, including the first microcomputers. However, it was only in the 1980’s that computer networks started evolving with MILNET, Novell Netware, TCP/IP and in the late 1980’s with the big World Wide Web, lifting of restrictions on Email and HTML; which made SMTP, POP3 and IMAP the standard. By this time computer graphics had also evolved with formats like JPEG and GIF.

It became possible for more people to have a personal computer at home that could be connected to the rest of the world with ease.

This huge outpouring of programming languages, networks, protocols, character encodings, networks etc. produced an ever-increasing communication gap. It became very clear that a solution to plug this gap, was required.

This is especially true with task and data management as systems perform specific functions effectively BUT with little or no holistic view of task progress or data across systems.

Each system has information relevant to that system and its function. These are often not easily shared due to:

• Different protocols.
• Different development languages.
• Different data storage mechanisms.
• Security concerns.
• Lack of knowledge between system domains.
• Pricey integration solutions were simply difficult to justify.

It became necessary to effect solutions and once again this is demonstrated through the evolution of integration endeavours and hence technologies like the ones mentioned below became popular:

• CORBA (Common Object Request Broker Architecture) one of the very early protocols designed to facilitate the communication of systems that are deployed on diverse platforms.
• RMI (Remote Method Invocation) system allows an object running in one Java virtual machine to invoke methods on an object running in another Java virtual machine.
• JMS (Java Message Service) for sending messages between two or more clients.
• SOAP (Simple Object Access Protocol) is a protocol specification for exchanging structured information in the implementation of web services in computer networks.

These and similar technologies, were severely criticised for being too heavyweight and process intensive however, the upside to this was:

• TCP/IP became an extremely popular and widely understood method of data transfer.
• HTTP became prevalent with existing programming languages like Java, DotNet, Ruby, Python, PHP and C++; and new programming languages like Google Go and Apple Swift. This meant that all these programming languages had a protocol they could all understand (not to mention having much quicker release and integration cycles due to technology such as SOAP).

The combination of the aforementioned, paved the way for REST (Representational State Transfer). REST came about in the early 2000’s and it took a few years to gain traction with developers.

REST was another great evolution in the HTTP world, nonetheless it still had a few limitations when faced with constraints like:

• It remained bulky due to constraints related primarily due to HTTP payload.
• The expense of performing SSL/TLS handshakes on each request.
• The statelessness of REST.

These obstacles could be overcome by scaling and optimization however, “super-performance” from the hardware, remained elusive. WebSockets offered a solution.

WebSockets have been a significant breakthrough in terms of performance, without relinquishing the security of HTTPS protocol; and by making use of both REST and WebSockets, one can create a high-performance integration point that allows for external systems to communicate fast, effectively and securely (even transmitting binary in full-duplex).

 

Please see the Blog from Arun Gupta (REST vs WebSocket);

http://blog.arungupta.me/rest-vs-websocket-comparison-benchmarks/

 

This is enhanced by the external integration through API’s. The large software vendors and SAAS providers have an API that allows integration with their platform, which facilitates software communication in harmony.

This is demonstrated in the Fluid BPM diagram below.

 

The challenge remains with internal integration as it is not possible to control the behaviour of systems AS information is received or sent from the application itself. HTTP WebHooks commonly utilised by Software as a Service (SAAS) organisations provide, event driven call-backs of limited real-time data, thus the restrictions of the scope of the WebHook remain a hindrance by simply acting as an informer … it cannot affect behaviour within an application.

 

Although the limitation of a single programming language remains with internal integration, having such functionality available is rare in the software space (mostly though plugins such as Microsoft Office Suite Plug-Ins).

 

This is demonstrated by the screenshot below in the Fluid BPM environment, which shows that JAVA is being used as internal integration.

 

External and internal integration have made it possible for more developers being able to access more systems than ever before, BUT we still need said developers to learn and fully understand the REST API and the programming language of the platform; before integration can be effected.

So, for integration to move to the next level, it is clear that the programming languages have to become irrelevant.

Fluid BPM achieved this by utilising an “external runner” which they have developed that allows executing tasks on any platform utilising any programming language without the need for a REST API.

Developers are therefore, left to continue in their “native” programming language and to focus on their domain knowledge. This means that the

1. Development language is irrelevant.
2. REST API is transparent.

This is demonstrated below.

 

For more information, please contact us at:

Jason Bruwer jason@koekiebox.com

Francesca Sammarchi francesca@koekiebox.com