ROE — what is it?

restfulness.info

Home of the Resource Oriented Enterprise

Introduction

ROE — what is it?

If a user requires information out of different information silos, the IT industry offers us a multitude of concepts and technologies to do so. Enterprise Application Integration, adapters, transformers, portlets, EJBs, message oriented middleware, transaction monitors, web services, proprietary APIs, to name a few, all try to support you in that as best as they can. One common denominator is that they are all procedural - and miss out an important concept: the support for an overall addressing scheme. Besides the need of converting a call to a specific protocol, the client also needs to know where the data actually resides. Consequently, crowds of developers deal with tons of infrastructure code instead of doing work that brings real value to the business.

Compare this with the WWW. For instance, the URI

www.mybank.com/private_customers/mortgage.html

denotes the HTML page - or better the Resource - that describes the mortgage offering of MyBank for private customers - on a worldwide basis. An addressing scheme, based on the notions of the URI and the Domain Name System (DNS), takes you right away to the desired information fragment. You don't need to bother about protocol conversions nor which middleware to call exactly - by typing .html at the end of the URI, the server knows you would like some HTML representation of that Resource.

Help! Users want information — silos offer data and services

The addressing scheme helps us overcome an old dilemma in enterprise architecture, too. That the user, in ROE called the Information Requester, often thinks and works in different categories than IT systems offer the information. Again, we have delopped many approaches to overcome this, some more successful than others, but they typically involve different technologies that developers need to deal with and involve many software layers that slow down roundtrip times.

The Resource Oriented Enterprise overcomes this by introducing Information Request specific taxonomies, which are business driven and de-couple the requester's view of information from the structure of the silos. Consider the following overview:

Let's assume the Information Requester is a bank employee, dealing with private customers. Such a customer relation is a fairly complex information object, consisting of personal data such as name and address, of products he bought such as accounts and mortgages, and along this we find quite a number of documents such as contracts and administrative records. Well possible, that this data resides in 4 or more silos. Traditionally, the user would do some call to a mainframe system to see the personal data, another system to view details of accounts, yet another for the mortgage, and uses the viewer of the document management system to read documents, and so on...

In a Resource Oriented Enterpise, he would be able to use a uniform naming scheme to access any of these information through the browser, e.g.

/privateCustomers/12345

... points to the Resource that returns the overview of the customer relation, that is personal static data, links to accounts, financial products and documents belonging to the relation with ID 12345

/privateCustomers/12345/accounts/A1

... yields details about account A1 of customer 12345, whereas

/privateCustomers/12345/accounts/A1/docs/balanceReports/2009/01

... is the URI of the monthly balance sheet for January 2009 of account A1.

The Resource is the central focus point in such an architecture, thus the name Resource Oriented Enterprise. It is the target of Information Requester's URIs, it replies with the desired representation of the resource, perhaps HTML, but perhaps PDF this time? It points to other information fragments by linking to other resources. Or, it calls a propriatary adapter to call on information residing in some silo. For more details, see the article on Resources.

Think of a cloud — at its best!

"I can do that with my enterprise portal, too!" I hear some voices out there. Certainly. But you are integrating on a portal level, by adding additional portlets to your portal (a CRM portlet, an account one, a DMS one...), i.e. opening several point-to-point connections with very limited re-use potential, that is, limited to other portal users, instead of extending your enterprise's addressing scheme.

Imagine, the information requester also needs to know if that private customer is an attorney in some business customer relation. Worse, this information is located in another system, perhaps even belonging to some different division of MyBank. In a Resource Oriented Enterprise, we could access that attorney information by simply linking our resource /privateCustomers/12345 to

/corporateCustomers/09876/attorneys/att2

The Resource Oriented Enterprise thinks in terms of a cloud. Certainly not that offered by some computer giants who offer brute force disc space and computer power for your data and services, but as a container for a smart and constantly changing space of taxonomies and resources. Only these REST concepts bring real value - and flexibility - to this cloud and it's users, the Information Requesters, who represent the ROE's business.

Silos ARE important

The reader might get the impression that the Resource Oriented Enterprise considers Silos as a bad thing per-se. No.

Silos are an essential part of the SW architecture. There is an unbelievable amount of company knowledge and wisdom in each of them. There are the 800-pound gorillas among them like SAP or mainframe systems offering thousands of mission critical transactions; highly specialized archiving systems for records management; document management systems containing office docs, BI systems, search engines, mail systems, you name it... Besides that, they decide about the Qualiity of Service.

But what the ROE asks for, they must further open themselves. Not primarely in a technical sense, but by offering better abstractions of their information content. In the Resource Oriented Enterprise, this is clearly achived by integrating them into the URI-based addressing scheme.

Conclusion

The Resource Oriented Enterprise integrates its many information sources, or silos, by means of the World Wide Web. The communication infrastructure is as far as possible based on pure HTTP, the information exchange between server and client is based on hypertext formats such as HTML or XML formats. They represent Resources, who keep data and links.

Even more important is the business aspect. The notion of the URI allows us to build an addressing scheme that potentially can point to everything, from very small to huge, from information to real things. This allows us to build up taxonomies that offer the information requester an information structure according to his indiviual perspective, not as the silos offer them. Thus, the taxonomies are designed according to business needs, and can be adapted dynamically to new situations.