Hedging Your Bets with Web Technologies
Since the emergence of the Web, application technologies that leverage the Web have undergone two distinct incarnations, and are poised for a third. First, applications leveraged the Web to exchange documents using the http and ftp protocols. Now with the maturity of XML and Web Services, the web can support collaborative, computational applications. And soon, web technologies will mature so that the promise envisioned by Tim Berners-Lee, of a semantically-aware web that supports distributed/evolving knowledge and collaborative sense-making based on that knowledge, will become robust enough for use in business applications. The work discussed in this talk is biased with the following assumptions: 1) our business applications must minimize technological risk, and so use technologies that are reasonably mature, 2) the technologies associated with the “Computational Web,” i.e., XML and Web Services have begun to mature over the last couple of years, unlike the technologies needed for the Semantic Web, and 3) our applications being designed and built today will still be valuable when the Semantic Web truly emerges.
Over the last few months, the FMT team has been deeply investigating current and emerging web technologies as part of our OpenMail program. Specifically, our work about investigating how we might leverage standard interfaces to create an automated provisioning process and so enable mailing systems to dynamically change as carrier products are introduced is very much influenced by web technologies. Based on our investigations and our need to provide robust prototypes in limited time, we have developed an application framework architecture that allows us to move forward with computationally-based web technologies, but that supports enriching our prototypes with semantic behavior through a technology migration path that localizes the disruption of changing web technologies on existing applications.
Our application framework architecture is composed of three levels, as shown at the above. The bottom layer, i.e., information design, enables the application developer to use the best available web technology for describing the information provided in a document repository. As web technologies evolve and mature, the information can be recast from one technology to another. The ease of this transformation depends on the foresight of the information architect. For example, we have developed an XML schema for representing mailing system capabilities that captures the notions of class structures used in the comparable W3C Delivery Context standard, defined in OWL. By doing this, when/should the underlying technology move to OWL, we have a one-to-one mapping between XML types and potential OWL classes, and so can more likely automate the conversion of information descriptions.
The middle layer consists of APIs and technology-dependent implementations. The APIs are derived from the W3C Device Description Repository (DDR) standard, though generalized and extended for our application framework. First, we recognized that the DDR API was a very general access API, and did not rely on a specific formalization (schema) of the information. Second, we understood that the DDR API relied heavily on three notions: Aspects, Entities, and Properties, while explicitly providing methods for only the properties. (Details of the notions are beyond the scope of this talk.) We added APIs that would enable applications to access instances of all three notions. Finally, we provided a means for the XML Schema designer to describe which parts of the XML structure related to aspects, which to entities, and which to properties.
The top layer, i.e., the Application Layer, uses the Information Access API when parsing instance documents. Should the team determine that it is time to migrate to semantic web technology, the application code is isolated. The applications use upgraded description documents by “linking” in the Information Access implementations for the selected web technologies. Currently, the FMT team is investigating this architecture across two core OpenMail interfaces, the Mailing System Capabilities interface and the Rates Description interface. As we move forward, we expect to refine the architecture and learn more about transforming information from one Web technology (XML Schema) to the next (OWL), and so vet our approach with solid experience.
