Resource Services: A True SOA Method for Enterprise Data Access
Saturday, October 6th, 2007SOA brings many promises to the Enterprise. Chief among these is the ability for IT to respond to ever-shifting business needs. In the current SOA landscape the answers to accessing Enterprise data are the same as they were pre-SOA; namely: SOAP, WS-*, proprietary APIs, etc… Time and experience have told us that these technologies do not in fact really free Enterprise data. This is not a new or hidden concept, yet the technology landscape (driven by SOA), is not changing to adopt to this reality.Right now there are legions of Enterprise IT developers that are either writing custom code to consume complex non-standard Web Services APIs or they themselves are writing their own complex non-standard Web Services APIs. Meanwhile, we are in the midst of a revolution in the human-web. Concepts such as mash-ups, Web 2.0, etc…, are transforming the web into a user-driven, world-wide, application platform. This is a world in which users can mesh and extend data in ways that the shepherds of these data could never have imagined. All of this is possible because the human-web is simple: HTTP, URIs, and (X)HTML documents.
In the computer-web, especially in the Enterprise, there is no unified way to access data. Every data access service, web or not, has its own proprietary access mechanism. Or at best one of thousands of competing “standards” are used. This prevents the computer-web from experiencing the revolution that the human-web is undergoing. The development of novel, user-driven applications and IT’s ability to respond to inevitable business shifts is greatly hampered as a result. The good news is that the tools for solving these problems are already here: HTTP, URI, XML and they are already ubiquitous. Also we already have a set of design criteria (REST) that help usher in this new age of true SOA data access. We can now make the data accessible to users; give developers a unified interface to operate on the data; give Business Analysts common (canonical) representations of the data; and more. Finally, we can leverage all of the lessons learnt (scalability, reliability, security, etc…) by the human-web.
I propose that we call these SOA data access services Resource Services. Resource, since that is a fundamental concept in REST; and Service, well because they are to be services, web services in particular.
As an example, imagine letting a Google Search Appliance loose on a set of corporate data exposed as Resource Services. The resulting index could cross all data silos and harness the power of the Google search algorithms to give (the appropriate) users a wealth of information about their data. Clearly this raises all sorts of security and governance concerns, but that is a topic for another day. This is just a simple example, the key is that we can not possibly think up all the ways that this data might be harnessed, if it were easily accessible via a standard mechanism. It is time to stop imagining this brave new world and to start enabling it.

