As Chris noted in his post, I gave a presentation about using SnapLogic for REST integration at the Oracle REST Symposium back on July 29th.
This was an interesting audience. The group was both very technical, and well versed in the issues of enterprise integration and API’s , so I was able to get into the internals of SnapLogic somewhat more that I typically would. (The slides from the talk are on our wiki for reference.)
Whatever technology stack is used, the core issues of integration don’t change. Dealing with integration opens up significant complexity because of the permutation of interface protocols, data formats, application semantics. In short, integration is dealing with distributed systems, and distributed systems are hard. There are three main abstractions in use for distributed systems:
- Remote Procedure Calls (RPC)
- Representational State Transfer (REST)
- Message Queuing
Everyone in the audience had experience with 1 or more of these models (and I believe everyone had RPC experience.) This wasn’t the appropriate forum to discuss the relative merits of the alternative approaches; others are already doing that.  Instead, the general outline of my talk was based on simply describing how we map REST to the integration problem, and minimize complexity in the process.
I went through a SnapLogic overview, and then we took a look at building a mashup-style application using SnapLogic and Google Mashup Editor.
The ‘business scenario’ for for the example was quite straightforward. It was based on a simple problem – For body shops considering purchasing a vehicle at auction, is repairing a damaged car worthwhile ?
There are two data sources. The first is a publicly available list of crashed cars available at auction, including information about the damage, and pictures of the vehicles. This data set is available as an XML feed from WebLogic Portal.
The second data set is a ‘prorietary’ reference data set from a local database, containing information about book value and scrap value. We used SnapLogic to expose this as a feed so it could be used in a mashup.
The processing logic was straightforward; join these two on year / make /model, and enable the bidder to decide if the repair is profitable. We built the processing logic in SnapLogic, and exposed the end result as an Atom feed suitable for consumption by Google Mahsup editor.
I chose this example because it describes a pattern we commonly see – enriching a proprietary data set by adding information from another public data set. We see this pattern in both mashup scenarios, as well as application to application scenarios.
Overall, the symposium was interesting, especially to hear others relate their experiences. REST is often interpreted as being all about URL’s, and I believe this event increased awareness of the deeper issues in REST architecture.
It’s also easy to understand the momentum RPC style interfaces have in the enterprise landscape. A number of standards have become ‘checklist’ requirements on customer shopping lists, where the customer may not even understand the implications of what they are requesting. As a vendor, it’s hard to push an alternative when license revenue is on the line. And on the server development side, it’s easy to expose RPC versions of internal API’s with minimal effort. All of this momentum combines to slow down adoption of alternatives, despite the proven long term benefits of taking an alternative approach.
This was a great event, and I’m glad Peter organized it. There are definitely some REST practitioners at Oracle, and given the recent REST initiatives by Microsoft (Astoria) and IBM (Info 2.0 / sMash), as well as the shift to cloud computing, we might see some interesting new approaches from the towers in
|||Refer to Steve Vinoski’s recent Internet Computing articles for a primer.|