For many years, Glue42 Desktop has been available as a single end-to-end platform comprising all of the services likely to be required for a large scale mission-critical environments. To address market demand, we have today announced that these services can now be deployed and consumed independently from the rest of the stack – via glue42 or open APIs. Now, and for the first time, enterprise-class services such as advanced window management, directory management, notifications and interop can be accessed by organisations who have already made an investment in their own or 3rd party containers.

The purpose of this blog is to explain the history of how we got here and how we see the future direction of the market.

In the beginning…

…there was simple ‘interop’ that supported client-side integration of desktop applications. These were typically in-house developments and may have only supported one or two application technology stacks. As the number of browser based applications increased, ‘Containers’ were developed that offered rudimentary data exchange between web applications and the ability to access native operating system functions. Electron is perhaps the most widely deployed example of this – and one that Glue42 endorses.

Over time, wrappers were built on top of these containers to provide a broader range of services including data streaming, sticky-windows and data dictionaries. For organisations who have adopted one of these wrappers, this is where things stop, and that may be ok if you only ever need to integrate simple web applications with a simple UI.

If, however, you want to deliver a streamlined user experience across the application types shown below, plus directory services, configuration management, search, notifications and advanced window management (etc) – then you are on your own. Add to that the need to support multi-screen, multi-machine and users within and beyond your firewall at scale, then that’s a whole different matter.

Glue42 supported technologies

Historically, many organisations have sought to build these capabilities in-house – but just like basic-interop they are too costly to maintain and don’t offer the competitive advantage that they once did. To embrace a commercial solution, such as Glue42, would certainly satisfy these needs – but some organisations want to use open standards to avoid lock-in for those things that will eventually become commodities. Fair-enough.

Enter FDC3, Hadouken, FINOS and Openfin.

Glue42 has been a keen supporter of open standards for 5+ years, our role with the Symphony Foundation and OpenMama is evidence of that. The next step in our journey is to open up our platform to allow specific services to be deployed on top or alongside other containers or wrappers. As a reminder, these are the high-level services that Glue42 provides:

All are currently accessed via Glue42’s own APIs – across the following language bindings: JavaScript (browser, container and NodeJS), Java, .NET and COM.

From today, the diagram now looks like this:

Glue42 Services

You will notice that the services are still accessible via Glue42 APIs – but in some cases, where the appropriate standards exist, we have exposed our enterprise-class capabilities via open API as well. This means that organisations who perhaps already use their own in-house container or a wrapper like OpenFin can quickly augment their existing environments with robust, full-function, production tested implementations.

Bottom line

If you already have an interop capability that meets your needs – then great; keep it. If your interop is not up to the job or too costly to maintain, then consider Glue42 Interop. In both cases, you can now deploy the higher-order services, avoid lock-in via open standard APIs and avoid the build cost that would otherwise have been incurred.