Recently, I have been involved in connecting a Java webapp with a Document Management System (DMS).

Of course, the DMS comes with a Java API that is procedural and proprietary. Not very difficult to control, but still proprietary.

Little surprise, we decided to design an adapter that would - yes - adapt the webapp's technology agnostic document API to the DMS' proprietary API. Implementation was relatively simple, little tricky perhaps, and we ended up with 4 classes and 500 lines of code. Well, that's not much, but yet we have another 4 classes and 500 lines of code to maintain.

But there's help coming. Major vendors are currently defining the Content Management Integration Services (CMIS). CMIS are here to provide uniform access to document and content managent systems, even a REST-based. And this time, they seem to be a little bit more enthusiastic then they have been with the Java Content Repository API (JCR). Documentum, OpenText, IBM, Alfresco, and even Microsoft and SAP not only occupy seats in the OASIS CMIS Technical Comittee, but are already providing implementations on CMIS draft versions. And some TC members, such as our fellow out Documentum, Craig Randall, are also out in the blogsphere with news.

Well, I would not recommend to anybody to actually use the preliminary impelementations for real applications. And let's see first, how the glossy announcements will be materialized, and in front of which DMS/CMS/RMS we actually will find implementations of CMIS, expected sometimes next year. Only then we can say of how much nicer our lifes has become...

This blog is all about Web Oriented Software Architecture (WOA), also called Resource Oriented Architecture (ROA).

WOA is an architectural style that tackles the enterprises' information challenges of the 21st century with the concepts of the largest IT systems known to the mankind: the World Wide Web. WOA still focuses on client/server and services-delivery, but uses as the main abstraction the notion of the Resource.

In this blog, I try to discuss interesting aspects of WOA. Comments are warmly welcome. Please see also www.restfulness.info, the home of the prototypical Resource Oriented Enterprise (ROE). The site also explains the basic concepts of WOA.

Enjoy,
Juerg

There is little information out there about a good structure of an URI-based addressing scheme. That is surprising, because few concepts have such a high impact on a Resource Oriented Architecture like the structure of the URI.

Of course, there is the mother of all URI design papers, Berners-Lee’s “Cool URIs don’t change”. The central point it is conveying is (1) to actually design URIs carefully and (2) to design them in a manner that they remain stable the next 20, even 200 years. That’s easier said than done, of course, and Berners-Lee gives advice that the single most stable attribute of a document is probably its creation date. But even that is not always straightforward: for many enterprise documents, there is a creation date and logical date that differ. For instance, the creation date might be today, but the logical date might be yesterday because you traded those shares yesterday.

Talking about records, it is the archiving guys that probably have the longest experience with taxonomies and classification schemes. They differentiate three basic file plan structures:

• Functional: content is organized by activities. So, from board decisions to support calls, everything is classified into some specific functional class and subclass. Has the advantage that organizational changes can be ignored.
  
• 
  
• Organisational: exactly this happens with this structure. Everything is filed according to which department has produced it. Advantage is that the responsibility for the content is clearly defined.
  
• 
  
• Topic/content type: a certain information gets classified according to “its nature”, for instance policies, contracts, financial bookings, images, …

All three have the potential to deliver a stable structure, but all three also bear likelihood to change. Perhaps least the functional structure, even if technical progress has an impact on a company’s activities, it is still likely that it has a board of directors and a support department.

Certainly a bad idea is to include technology pointers, like: /oradb/orders/123. What if we change to some other database system than Oracle? If we don’t change the URI, we give users a wrong idea; if we change it, we make many hyperlinks invalid out there.

So, we really need to design URIs to avoid that infamous HTTP 404 code. But what if we have to change an URI for some reason? Well, HTTP provides us with status code 301 Moved Permanently, which let’s us indicate the new location. That at least makes the client redirect for now and all future requests to the new location. However, this requires that during the move of the content the server actually learns about the new location.

So, probably the best manner to get a long-lasting structure is to design it carefully and have a substantial exchange with the folks from the records management department.