CONNECTION PROFILES
For too many years now, systems developers and users have faced the rapid proliferation of many random endpoints trying to connect to other endpoints in the absence of any meaningful context. The PADI platform’s magic lies in how it achieves its connections among diverse equipment and systems. Its designers set as their goal the Shangri-la of integration—connecting anything to anything, no matter what or where a given “thing” was. This goal came out of Budiardjo’s long work in the device integration field, where he spent many years designing specialized drivers and one-off middleware for project-specific issues. As anyone who has done this type of work knows, the solutions to these difficult challenges are not immediately reusable in other contexts, and the engineering also tends to be brittle and break under the slightest stress—for example, a single URL changing.
To be successful, integration platforms need to go to a much deeper, more abstracted level. The mechanism that its creators came up with—Connection Profiles—are not defined for specific projects, but rather for specific use cases—for example, to connect a certain type of client to a certain type of server for a specific purpose. This is done in a way that allows that Connection Profile to be used for any instance where a client and server of the same specifications are being connected.
Connection Profiles itemize the characteristics of a “client” (for example, a device) or a “server” (for example, a data repository). (Note, however, that “client” and “server” are terms used largely for convenience. Any entity utilizing Connection Profiles could function as a client and a server simultaneously.) Connection Profiles have unique names, just like internet domains, and there is a registrar of Connection Profiles to ensure that they retain the necessary clarity.
Finally, integration platforms need to maintain a connection instance over the course of its lifetime. Anyone with real-world experience integrating internet-connected devices will immediately recognize the importance of this statement. Things in any system change over time—URLs get modified, software gets updated, something physical gets broken or replaced, and so on. With Connection Profiles, the connection becomes dynamic. The server tells the platform that X or Y has changed, the platform tells all clients, and within moments the connection is up and running again—with minimal downtime and no human intervention. You can swap pieces of equipment or modify the software, and the connections will continue to work.
In the world before Connection Profiles, you’d decide on a project-by-project basis that this needs to talk to that, and you’d begin a very involved and expensive development cycle involving engineers in a room writing specifications, deciding what protocols or standards to use, and then getting custom code written. Then you’d have to install it, with people from both sides of the equation present, and pray that for the life-cycle of that equipment (often decades), the integration would continue to function.
Many consultants make a lot of money doing this type of integration work, and Padi—with its open-source and extensible Connection Profiles—is a disruptive technology in their world. Instead of specifying a project-specific specification, you create a Connection Profile instance that says, in essence, “I want to connect a train-ticketing system with an energy management system.” Any necessary development becomes part of a product-development process, not a project-development process, and all development is reusable and can be made available again and again. At installation time, the systems are connected with minimal if any configuration, such configurations being project-specific information.
(This essay continues. Fill out the form below to download our full whitepaper on PADI and Connection Profiles.)