Arnon Rotem-Gal-Oz has written an excellent article for InfoQ: Bridging the gap between BI & SOA. This very much resembles the conclusions we came to in one of my last projects — essentially, we arrived at a model where each service interface included three (optional) facets:
- the “transactional” request/reply interface
- an interface to get at pure data
- an event interface, i.e. one that pushes data out instead of providing it for retrieval
(This architecture was based on SOAP/WS-* services; in a REST variant, the three facets essentially become one.)
Working on a rather large scale ROA/SOA implementaton project, we also have identified the need for “pushing data out of services”, primarily to propage state changes from service/resources to trigger subsequent processes, since this keeps our processes small and separated (like in an EDA approach), without the need to specify each and every interaction or information need explicitly.
So, i find the idea of “in a REST variant, the three facets become one” quite interesting, especially with regards to the last bullet point. Could you explain this a little more extensivly, especially how one does get the “pushing data out” aspect by “simply” utilizing REST?