Remembering the Future

For each class of resources identified, we can create a set of documents (messages) that go in to and come out of the resources to perform business functions. We then further analyze the messages in terms of their overall effect on resources. Some messages will simply inquire about the state of a resource ("get outstanding invoices" message to a customer resource for example). Others will update the resource ("Add new machine" message to an assembly line resource for example.). Still others will delete the resource ("clear all" message to a shopping basket resource for example).

We then map these message classes onto an application protocol - HTTP. Essentially, this gives us standard plumbing - a standard interface -supported by all resources for the exchange of messages.

This encapsulation of complexity behind a simple message exchange pattern layered on top of a standard application protocol, makes it easy for developers to use business resources in their applications. Moreover, it allows the developers of the business resources to add extra message types as business needs change. By following some simple design rules[2], existing resources can be made forward compatible with this sort of change so that nothing breaks as the system evolves. Moreover, the loose coupling implied by the message exchange approach allows developers to use intermediating resources to gracefully "broker" complex modifications over time to minimize system changes.

Now doesn't that sound just great? I think so. Why is it a distortion of reality? Well, it is a distortion of reality because systems are not currently - by and large - architected this way. I suspect that will change though. Somewhere in the terminological soup of web services, REST, SOA, SOI, SOBA, ESB, MOM and Indigo, a new conceptualization of "business object" is taking shape and will incorporates at least some of the ideas presented here.

Topics: REST | Architecture