Application Programming Interface. If you're a developer you are in the habit of consuming a healthy diet of these. They are the handles to functionality that you didn't have to write yourself, but get to leverage and control in order to produce your app. APIs started out as low level libraries, maybe a C lib and a .h file, then progressed to fancier packaging as object oriented components like CORBA (remember that?), COM, and EJB. All these were great ways to enhance the productivity of a development team so that they could stay more focused on a solution and less time on re-engineering common functions. These were like lego blocks that a developer would splay out onto their desks in the form of API manuals and reference books, or fill their browser bookmarks with reference links. Awesome stuff, but I've always wanted bigger lego blocks.
Pulling the viewpoint up a few degrees, the software solutions (and I say solutions instead of applications on purpose) of today almost never involve a single system. A solution is a system of systems. In the mid-nineties I was writing custom manufacturing control systems. Some of the data I needed was in an ERP system, some in a CRM system, lots of it in the financial system, and yet more dribbled around in almost a dozen other point-solutions that solved very specific problems. The integration point was - you guessed it - the databases. I don't think I need to describe the fragile horror that this resulted in. At the time I remember thinking that the Holy Grail of software development might be when entire systems could communicate to each other through a well defined API, just like my cherished COM and EJB components did. The difference would be the semantic level on which the systems interacted. I could buy an off-the-shelf COM library in 1997 that helped me control devices through a serial port: it had operations like sendString and setBaudRate. But what I wanted was an API for the financial system so I could say billCustomer. And when would I want to do this? I'd want to do it from within the workflow of the shipping system.I don't simply want to query and control the systems remotely, I also want hooks into their internal processes, including scheduling my own processes.
So to summarize, what you'd like from a system API is:
- Query and Control from an external system through a commonly available transport
- Facilities to add logic within the system's internal processes
- Facilities to schedule a unique workflow within the system
Modern applications have really caught on to #1. As apps move to the cloud, the importance of integration through the cloud is taking center stage, with HTTP based APIs like SOAP and REST leading the charge, but something is still missing. It's great that we can write apps that query our CRM data and update it remotely and in an automated fashion, but I also want to get my hooks into the CRM system itself, so that I can control yet another system as part of a workflow. The development community at large hasn't quite gripped the Holy Grail just yet, but we're a long way ahead of just linking in libs and configuring DCOM components.
With the Axeda Platform, we've been working hard to hit all three of these important system API styles. We have
- Web Service APIs, available as SOAP and REST services
- ExpressionRules to orchestrate data processing and Custom Objects to code advanced logic with a full-blown scripting language
- RuleTimers to schedule ExpressionRules and Custom Objects
- BONUS: Implement your own Web Service with Scripto
All without hacking a database or recompiling custom versions of modules. In the cloud. What makes this especially fun is that you can scour your internal, Enterprise, or publicly available cloud-based APIs and find cool connections between these systems. Check out sites like Programmable Web for inspiration.
Once you've signed up for an account on the Axeda Developer Connection you'll have access to the Axeda Platform. Let your creative spirit shine and let us know how you've been mashing up data with the Axeda Platform on our forums! Send a Twitter message when your asset reports something. Use Twilio to have your asset call you when there's a problem. Send your asset data to Google Fusion Tables for analytics. Man, you can have tons of fun!
I'm looking forward to it!