Interoperability - Interface, Middleware, and Database

These could be contributions to a panel or workshop on interoperability or a separate 45-minute presentation.

There are three major areas where open-source CMS developers can design for interoperability - the web-based client front end, the implementation framework at the web application server, and the database back end. We will start with the underlying database model or schema and work forward to the user experience.

Open Database Model. It is well known that most organizations take little advantage of standard reference designs for database schemas, preferring to reinvent their own wheel. (See The Data Model Resource Book/CD set by Len Silverston, Kent Graziano, and William H. Inmon.) Software developers are no exception, with each development team deciding on their own field names for standard data like givenName and familyName, and few developers employing optimal relational database designs (fourth normal form, etc.). Just as object-oriented design facilitates code re-use, adopting a standard database schema will facilitate data re-use and especially remote data retrieval via web services.

The parallel to XML Ontologies and XML Schemas is obvious. A good relational database schema should have its own namespaces. Suppose an organization wanted to integrate best-of-breed blogs, wikis, news portals, and a powerful CMS into a single institutional database. Each of these programs will have its unique data structures for users, and they may use different databases. A good open database design will have a database abstraction layer, so you can choose PostgreSQL or MySQL, etc. A better design would use standard names for users, emails, etc. and standard field names for content objects and RDF triples. This would be a contribution to the shared authentication problem. We will propose an action plan and a schema to be placed in the public domain under a Creative Commons license at http://www.opendatabasemodel.com.

"Loosely-Coupled" Middleware. A CMS is a web server application written under some framework, whether a general one like .NET, JavaONE, or one specialized to CMS like Zope or Midgard. Interoperability looks toward multiple such applications running on the same or distributed servers, communicating via web services. Thus the membership/signup application common to many CM systems could be written in a separate, loosely-coupled program. This program would need only share the database model, and ideally common elements of the UI.

Server pages (ASP, JSP, PHP, etc.) are like tiny server applications. Using HTTP requests, they can provide RESTful web services to one another, locally or remotely, and expose methods and data (generally stored in the open database). Large multiple server page aplications have a unique degree of horizontal (functional) scalability. While their scripting languages suffer in speed compared to server applications coded in lower-level languages, they are more versatile and may be more robust. A development team interested in a specific narrow application (personal information management or scheduling) could write code with minimal impact on existing loosely-coupled applications, yet reuse common data like users information, settings, and permissions. Developer teams with very different expertise could more easily collaborate.

Even large monolithic applications (e.g., a web-based mail program, CRM, a fund-raising manager, or an e-commerce application) can run simultaneously on the web server and share the same "loose coupling" to the open database and interface. This means programs written in diverse languages could cooperate to provide the overall functionality. The server host need only support multiple languages simultaneously (e.g., C++, Java, Perl, PHP, and Python) and the programs need only observe appropriate APIs for the database and the client interface.

User Interface. The Apple Macintosh taught us the value of common UI elements. The learning curve for the second and third app in the same interface is much easier if consistent navigation elements are used - similar names, similar positions, etc.

Every CMS has its unique approach to administering common tasks. But as the community of users comes to expect the same functions, we can expect dominant controls to emerge and hope for some convergence in terminology, especially among open-source developers. The Blogger API exerted standardizing influence on blogger clinet UIs. Similarly the common names and namespaces of an Open Database Model could exert a pressure for convergence in the UI.

Now that most CM systems have WYSIWYG editing interfaces (both HTML and XML), can we expect even more UI convergence? CMS template design and editing tools might be easier to use if they created standardized template information structures. Content elements need some standardized ways to describe source material, whether from web service RSS feeds, files, or the database. Tagging tools (both semantic and style tagging) might be much easier to use if the industry could decide on common ontologies (like Dublin Core) - with identical naming in XML, the database, and the interface.

Perhaps the greatest benefit of such interoperability will not be for developers, but for the CMS consultants and users who will find they can move more easily from system to system to provide the very best service for their customers.

Here is an early OSCOM look at the question "Is interop a bunch of crap?"

Here is a recent look at the same question.

Bob Doyle
skyBuilders.com
bobdoyle@skybuilders.com