1. Introduction - view from the end-user's side
2. View from the vendor's side
4. User Documentation
5. Programming Guide
7. Frequently asked questions (FAQs)
How can we deliver applications as services, over the Internet, and get PC-like functionality, where each user can mix-and-match applications as if they are on a PC?
(Note: The question does not refer to pure user-interface issues that are addressed by AJAX!)
Domicel is a virtual personal Internet domain. It gives the end user the look-and-feel of working on a PC – without the PC! Applications are provided as on-line services, in an object-oriented paradigm. The aggregate of a user's objects (think: icons) from all applications, hosted anywhere in the world, is their Domicel – there is no one place in which a Domicel's objects reside, no bottlenecks, and no central point of failure.
The Domicel architecture provides for the features of both the PC and the World Wide Web, for example World Wide Web-style links, and PC-style icons. Most of all, Domicel enables the end-user to mix-and-match applications, ad-hoc, just as is done on a PC – but with any application in the world!
Domicel is the Infinite PC.
Joe User opens his browser, surfs to the website of his Domicel Service Provider (DSP) and logs in. He sees a desktop very similar to the desktop of a PC - icons that can be "run" by double-clicking, or dragged-and-dropped on other icons to initiate an activity. Icons also contain links to other icons - they can be "opened" to view the icons to which they link.
Joe wants to buy a wide-screen TV on-line. He would like to find all the vendors that sell them, so he double-clicks on the icon called "Search". Since he hasn't searched for a wide-screen TV before, it doesn't appear as a choice in the drop-down menu. He pushes the button marked "Find a Service", and up comes a new window, into which he types, "wide-screen tv". He gets a list of services which can be described, approximately, by these terms - the topmost service is an exact match: "Wide-screen TV". He chooses it, and it drops into his Search window: Joe wants to search for Domicels that contain objects (icons) which support the "Wide-screen TV" service.
Joe finds dozens of wide-screen TVs, sold by many different vendors (each vendor selling its wares on its own Domicel). He doesn't know what to do - it's too much information to process. So he decides to make a spreadsheet. Joe double-clicks on his spreadsheet icon and an empty spreadsheet opens up. He then selects all the wide-screen TV icons (returned by the search), and drags them into the new spreadsheet. Instantly, a spreadsheet is created - a row for each TV, and a column for each of the TV's attributes: size, color, make, vendor, price, etc. - plus a column for the object itself. Joe looks down the rows of TVs. He deletes some that he knows he doesn't want (wrong size, wrong color...) but the rest look too expensive.
So Joe writes a formula which puts the lowest-price TV (i.e. the object which represents it) in a cell that he labels "Lowest TV".But this is no ordinary spreadsheet! It doesn't copy any of the values appear in its cells - instead it links to the original attributes - meaning, that whenever a value changes, the spreadsheet is recalculated in real time. As a result, the "Lowest TV" cell of the spreadsheet is always up-to-date.
Joe then double-clicks on his "Buy-bot". A "buy-bot" is a service provided by Joe's bank which will automatically buy something when a condition is satisfied. Joe drags the "Lowest TV" cell to the buy-bot and types, "Price < $100.00", meaning: buy this item when its prices drops to less than 100 dollars.
Why can't this be done without Domicel?
1. There's no way to ensure security across multiple applications on the Web.
2. There's no way to dynamically integrate applications on the Web.
3. All solutions up till now involved some kind of centralization, which either customers or vendors disliked.
How does Domicel do it? See the Architecture section.
Nowadays, almost every vendor wants to sell its products or services on-line. If not that, it wants to buy products and services on-line. And it wants these activities to be fully integrated with its computer systems. This is the problem of application integration - but exponentially worse, for it involves not only its own systems, but the systems of a potentially infinite number of other firms.
The Domicel architecture solves both of these problems: It gives the end-user a way to involve multiple entities in a single transaction (see the Introduction: the end user involves his bank, his spreadsheet provider, and multiple TV vendors in a single transaction), and it gives vendors a way to integrate their systems ad-hoc.
Let's first take the case of "simple" in-house application integration. A firm buys several applications from different providers, among them, let's say, a Customer Relationship Management (CRM) system and a Human Resources Management (HRM) system. Now it wants to integrate them, so that it can implement business rules like: "When I fire a salesmen I want to reassign his clients" - the firing would be done in the HRM system, while the reassignment of customers is done in the CRM system. Real businesses have many, many such rules: the money spent on application integration is about as much as what's spent on the applications themselves!
The problem is even worse than the numbers indicate: most firms are not in the software business - their areas of expertise are elsewhere. They might be the best at making cars, shoes, or hamburgers, but they're not the best at writing software. Yet, they need the best possible computer systems - their competitiveness depends on it! The solution to this problem is not to buy software. The Internet makes it possible to buy services instead: All software problems reside with the experts - the suppliers - and the service is delivered over the Web. But if this path is chosen, how do you integrate services from multiple suppliers? Basically, you can't. The best you can do is get the supplier to provide an Internet interface and do the integration yourself - but then you've outsourced only the easiest problem! Buying applications is much easier than integrating them.
The Domicel architecture makes it very easy to write applications that can be integrated ad-hoc. In other words, most of the work of integration is done by the suppliers, what's left can be done by non-programmers. How might we implement, using Domicel, the business rule:"When I fire a salesmen I want to reassign his clients"?
1. The CRM and HRM services are provided by Domicels (physically located in the suppliers' servers), delivered over the Web.
2. The HRM application provides an icon labeled "Things to do when an employee of this type is fired"
3. The CRM application provides an icon labeled "Reassign salesman's customers"
4. An officer of the firm drags the HRM icon, and drops it on the CRM icon, implementing the business rule.
As you can see, this is the same solution the end-user employed, applied to application integration.
How does Domicel do it? The secret is two numbers: the Domicel ID and the Host ID. Every Domicel user (whether a person or entity) has a unique Domicel ID. Every Domicel (service) supplier has a unique Host ID. Every object created by a Domicel Server (an add-on to a web server) has both a Domicel ID and a Host ID. That's it!
Well, it gets quite a bit more complicated than that, but that is the basis of all that follows. From the point of view of the user, every object with their Domicel ID belongs in their Domicel - this is what gives a PC-like illusion, even though there is no one place anywhere in the world where the Domicel resides: each object resides on its supplier's server.
Each supplier maintains a Host that creates objects for each of its customers. Let's say the supplier is an appliance vendor. It would probably create an object for each item in stock in its own Domicel (i.e. with its own Domicel ID) - there's no need for every customer to have their own copy. But each customer would certainly want their own shopping cart, their own billing objects, etc. This means simply creating objects with the Domicel ID of each customer. Each customer that's interested in the service would keep a link to the root of their account in the supplier's Host, thus accessing their objects.
The one point of centralization is the Domicel Service Provider (DSP). However, it is important to note that the DSP can be different for each user, and the user can change DSPs at will. The sole purpose of the DSP is to provide login services to the end user. However, as with ISPs, this is a natural place to provide certain basic services, which the customer might want, such as Account Management, Access Management, and the Desktop service.
The rest is plumbing, but it gets quite complicated. For more see the Detail Design document.
Currently, the Domicel system is far from being ready for prime time. Nevertheless, you can get a Domicel, and use the primitive applications provided. For detailed documentation of each application, see the Application Documentation document.
Instructions, ideas and downloads for building Domicel applications can be found in the Programming Guide.
You will notice that you have two objects called "Blog" and "Import Posts". The "Blog" object is meant to be the top-level object of your blog. The "Import Posts" object is for importing posts into your blog. The "Import Posts" object takes either the URL or the straight text of an XML document containing the posts to import. See here for an example of one such document.
By right-clicking on "My InterBlog Domicel" (or any object in this Host) you can create objects which will function together to provide simple blog functionality. The following demonstrates a suite of such objects already in existence in David Boxenhorn's Domicel.
For a description of the template format, see Creating Query Templates.
For the answers to frequently asked questions see the FAQs document. This document is expected to grow and change as more questions come in.