WOA: The Missing Link
Since the last time I wrote something about WOA, I have spent some more time researching this topic. (Though I still have not had a chance to sit down and build something.) Two articles in particular, “How to GET a Cup of Coffee” and “HATEOAS – The Confusing Bit from REST” do an excellent job of explaining what HATEOAS is and how workflow is handled in a RESTful fashion as opposed to how things are typically done with SOAP or POX. I find the idea of using standard HTTP infrastructure and features to handle the sending and receiving of data, and placing the next steps of the workflow process in the data to be absolutely brilliant. This gives us routing and workflow (aka. orchestration) which are arguably the two most important features of any integration implementation.
With that said, there are some additional integration concepts that I need to translate into a WOA/REST world before I would be comfortable selling this idea to a client.
- Discovery – If I am the new kid on the development team, how do I find out what REST services are already available on the network? How do I find out what their data contracts are? This could be something as simple as a web or wiki page, but I would like to know if there are any automated ways of discovering services and their data contracts.
- Transformation – Each service is going to expect data in a certain format. If I am getting data from another source, say, a packaged application how to I convert the data from the packaged application’s format into the format expected by the service? Without an intermediary handling the data, transformation will need to occur on the client. I can envision this being a part of a REST framework so the client will not be forced into implementing custom transformation logic.
- BAM - Most traditional integration platforms have a method of gathering data as messages are being processed for reporting purposes. How do I monitor business activity using REST? Maybe this is where enterprise mashups come into play. Instead of collecting data with an intermediary, each service will collect it’s own data and provide a query interface for retrieval. These different query interfaces could then be used to extract and combine the data into meaningful reports.
- Legacy Systems – Many existing legacy systems do not have support for RESTful communication. How do you incorporate a legacy system or application into a RESTful workflow? I figure this is where the developer will need to create a service either by writing code or leveraging an EAI tool to create a REST interface to the legacy system.
These are a few of the issues that need to be resolved before I can consider using WOA/REST for a real integration project. In order to find answers to these questions, I will need to build something so I can see what works. As I continue to work through these issues I will try and record more of my thoughts here.
October 5th, 2009 at 8:58 am
[...] area where I am dabbling a bit myself. I am very interested in seeing how they approach some of the issues I have blogged about recently. My only concern is that they will attempt to build specifications [...]