Oliver Sims' is regarded as the father of today's business object movement, in large part due to the success of his book, "Business Objects; Delivering Cooperative Objects for Client/Server". Yet, despite the attention given business objects today, much of his insight is apparently going unnoticed.
This paper contrasts attributes of the current popular view of distributed object systems, with Sims' vision.
Many people, when first learning about business objects, initially see the benefit of encapsulating related business functionality and data within a single object from the analysis model. This is not a difficult conceptual leap to make as it doesn't, by itself, disrupt our established mental model of an architecture. We can simply imagine applications on a client machine, invoking methods on objects on a server, and presenting them to a user.
Unfortunately, this is not the view presented by Sims.
In Sims' view, on the desktop are containers (forms and folders), not applications, and there's a large difference between the two, especially in human-machine interface design.
Sims, appropriately enough, starts "Business Objects" with a discussion about the "usability bottleneck" introduced by placing monolithic applications in front of users. This bottleneck is created by introducing a discontinuity between the world of the user - the atom world - and the world of the computer - the bit world. The IBM CUA (Common User Access) OOUI specification was an attempt to bridge the gap between the bit and atom worlds by allowing real-world objects to present themselves on the desktop.
But, as with any new technology, the majority of adopters did not understand how to make proper use of it. And that is where we stand today; icons in folders on desktops representing odd chunks of software called 'applications', where we'd find all of the functionality and data that we'd fine in our real-world objects, but fused together so that our real-world objects are unidentifiable.
Sims suggests that desktops present the business objects as objects in their OOUI. For example, instead of seeing an icon/object on the desktop representing "Order Management Application", the user would see the business objects from the "Order Management" domain right on their desktop.
Sims preaches a stronger form of decoupling than is capable by the use of static interface mechanisms such as OMG IDL. He suggests that business objects should have minimal compile time knowledge of one another so that maximum flexibility could be achieved by their use and composition. In his own implementation of his vision, Newi, he uses so-called semantic data streams (SDS). By marking up data on-the-wire to a common vocabulary, coupling between objects was deferred to that vocabulary, and away from the implementation of the components that use it. In other words, the coupling between two objects exists solely in their agreement to use a common vocabulary.
In effect, Sims' notion of a SDS is a step in the move towards natural language communications that are typically seen in agent systems.
In one respect, Business Objects, as defined by Sims, are a special type of agent. Specifically, they are agents without their own thread of control. Though nothing in Sims' description of his CBOs precludes a business object containing a thread of control, it is apparent that they are mostly, if not entirely, reactive objects, not active/proactive.
A large part of Sims' vision that hasn't been paid any attention in today's business object frameworks is inter-object communication. Sims proposes the use of semantic data streams, SDSs, in place of IDL, A business object must still publish a list of methods it supports, but the required parameters are not part of that published information. Instead, an implicit SDS is the only parameter passed to every method; a "self-describing unbounded sequence of anys".
It is interesting to compare this form of communication with that of agent systems. Inter-agent communications such as the Knowledge Interchange Format (KIF; http://www.cs.umbc.edu/agents/kse/kif) go one step further by removing the need altogether for methods and using knowledge contained within the message in induce a response in a target agent or agents. So while Sims wasn't quite suggesting this, he wasn't far off.
It is also interesting to note the parallels with the current next wave in markup languages being proposed by the W3C, the Extensible Markup Language (XML; http://www.w3.org/xml). XML allows documents to contain a definition of their contents, but without the rigidity of a predicate calculus like KIF, or the bulk of SGML. XML may represent the next step in the unification of the web with objects - if the participants can decide on who is to contain whom.
In another respect, agents are a special case of business objects. The concept of a CBO, as a software analog of some real world entity, provides agent systems with a form. Instead of the ambiguous term "agent" that provides no insight into what shape this software object must take, the driving philosophy of business objects tells us that our agents should strive to take their shape from a domain model. For example, if the domain is one of personal communication and information management, then we might expect to see "Personal Agents" proxying for us - their real-world counterparts - on the Internet. Personal agents, of course, have received scattered attention in the media in recent years.
OO frameworks are incomplete software systems. The functionality which can be assumed, from the analysis model, to be static is hard-wired into the framework. That functionality which is not static can be plugged into the framework using so-called "hot spots", thereby completing the system and producing an executable model of the domain.
OO frameworks have been successfully constructed for some years, but have typically focused on fringe applications such as graphical user interfaces. In more recent years, much interest has been expressed about "domain frameworks" for high level business functionality such as accounting, telco billing, human resource management, etc. This is indeed an admiral and ambitious goal, but still, after utilizing the framework to construct an application, what remains is only an application. It is not itself a component, and therefore not composable with other components.
In the land of business objects, the business objects themselves are at the top of the component food chain. There is no single piece of software "larger" than a business object. In this land, domain frameworks, as currently defined, are too big. So, in place of one large framework, we create a set of cooperative business objects, where each object derives directly from the analysis model of that domain. The flexibility that would normally be built into the domain framework would find itself dispersed between the business objects.
Therefore, not only are business objects built from a framework, they can (and should, if they're competing to be reused) also be frameworks.
The continuity afforded by objects on the network, objects on the desktop, and those same objects in the real-world of the users, is an enticing vision, and should provide a scaleable means for the efficient management of the increasing amount of information we find at our fingertips.
Unfortunately, moving to this vision is difficult as it requires a thorough rewiring of our mental models regarding how software is developed and deployed. Distributed objects, specifically business objects, are not about building a better application. They are about replacing the application as the predominant means of delivering value to customers.