Business
Object Workshop IIBusiness
Object Workshop IIComments:
Its admirers are expecting the OMG with its CORBA-styled clothes to rule the object standards world. Encouraged, the OMG demands CORBA-compliance in its RFPs, even as the bogeyman scaring the industry into support of the OMG - Microsoft - imposes its own COM/OLE standard. But COM uses the same cloth (also being based on interface-inheritance) so the OMG can continue to flaunt in the belief that they might still look grand together (Bridges are being built between them to reassure the more circumspect courtiers). Microsoft plays cooperative though not seriously: they may not have the same intellectual airs, but it is sales that count in the fashion world.
Ironically, the OMG even seems to admit to some problem. They urge us on their Web home page to "Get on the bus", but the bus in the graphic only has a front half! The rear half is missing, and that's where the engine should be in the Volkswagen bus portrayed. The undoubted demand exists, but where is the supply? Even the with-it decorations on their bus will not cover up the nakedness.
I have a normal limited mind, and I need simplicity in Information Technology. I was unimpressed by Microsoft's one-time sales spiel for their development library CD: "one hundred thousand pages of vital information for every developer!" No workable toolkit can be that heavy with detail. But the OMG's various documents indicate some yet more complicated monster in gestation …
Meanwhile, I have spent more than 30 years gradually developing a simple view of knowledge and its evolution, a practical view that can help people work and live together.
The result is a forthcoming new information architecture, presently called "MACK", the Metaset Architecture for Common Knowledge. MACK will in due course be put into the public domain as a proposed open standard, refinable and extensible - surely, with the market's help - towards a resounding ACK (the Architecture for Common Knowledge).
MACK is based on an astonishingly simple information-sharing picture which is radically more appropriate to the accepted needs than the OMG's OMA and Microsoft's COM, as well as all other system architectures of which I am aware but which are even further from industry-wide acceptance. Neither Java nor HTML have anything near comparably clear and comprehensive aims.
This paper is not yet a launch of MACK, nor of Metaset, the first realization of MACK. But considering the unreadiness of the whole OMG architectured toolset (I've no doubt that, d.v., MACK will easily beat them to it!), it's surely not too late for the OMG Titanic to contemplate a change of course, difficult though such moves always are.
Difficult indeed! And reminded once more by Medawar's Dictum (Theories are not displaced by facts, they are replaced by better theories) I do not expect you to be convinced of the technology until you can really see the alternative in action. But maybe, somewhere, based on the broader picture presented here, there will be some readiness to take what at this stage must seem to a newcomer like a gamble: together, we - and especially our users of all kinds - would get safely to port sooner, in conclusion of this commonly-agreed knowledge-modelling standards Odyssey.
As reported in this Workshop's Call for Participation, the X3H7 Object Information Management Technical Committee has neatly put their finger on a major immediate problem: "Interoperability of large grained objects existing in these environments was identified as a core activity in the standards process." Let us follow that lead and see where the present OMA might take us.
The background to this exploration is that there has been an insidious shift in the OMG's aims: the "generalized object model" of the OMA Guide of November 1990 (p 4-2) gave way in CORBA to a "classical object model" (see CORBA 1.1 p 18 or CORBA 2.0 p 1-2). The acceptance of a classical object model was clearly confirmed in the revised chapter on the Core Object Model of the 1995 Revision 3 of the OMA (section X.4.4 of document 95-03-22).
Whereas a generalized object model seems better suited to addressing high-granularity situations, a classical model insists that a message invoking an operation is sent to one object. That object then has to request further operations so that all collaborating objects can do their respective bits. That creates two major problems at least: the original client has to know which one service to invoke, and that poor object has to be very clever about things that aren't necessarily its business. For example:
Consider an almost universal business requirement: to be able to enter an order. We might try one classical object such as Order, with a large-grained structure as partly manifested in an eventual order document. Some EnterOrder operation might be declared on Order, which would invoke a method with its own requests on related business objects such as customers, products, pricing strategies and shipping schedules. Not too difficult so far. But entering an order must also take into account aspects such as UI style, user profile, organization structure and office plans - environmental perspectives which are largely orthogonal to the essence of an eventual order yet import a great variability of behaviour that must be catered for in the eventual order-entry workflow. (Let's leave aside for now the notorious scene of Modifications to Order, as well as all the BPR possibilities!)
Refinement through multiple inheritance from orthogonal supertypes does not address the issue, for, substitutability ruling (see the OMA Guide Revision 3 section X.4.4 again, but rather consider the Liskov Substitution Principle), an order-entry process is neither an order nor an environmental perspective.
The "context expression" in the CORBA operation invocation is intended to cater for such environmental factors. (Back to refinement through single inheritance…) But if an operation on mere Order were to try to take full account of orthogonal factors' potential variability it would quickly over-complicate a general-purpose Business Object's behaviour, as some combinatorial arithmetic would easily show. The simplicity and reconfigurability demanded of an application component would be lost. Meanwhile, orthogonality should be an opportunity not a problem…
Maybe some higher-granularity OrderEntry object, aggregating Order with all collaborating objects, could be conceived which could invoke the appropriate operations on the relevant objects? But either such an object would again be unmanageably complicated or there would in real life be an explosion of such larger granules in an attempt to compartmentalize the complexity.
Or else the diversity and dynamism of reality can merely be shoe-horned - as is currently the tendency - into an inflexible and oversimplifying application package.
No, to conceptualize such dynamic clusters of collaborating objects we require a more powerful yet general-purpose construct than for example aggregates or patterns or frameworks or templates. The OMG's Common Facilities RFP-4 (Common Business Objects and Business Object Facility) correctly prescribes no specific form for the specification and management of such coarser granules. But what kind of response can the OMG be expecting on the basis of a classical object model? Their shift - nay, drift! - is a definite retreat from adequate conceptual ambition.
Further unsatisfyingly resolved problems surface when one considers such real requirements as asynchronous inherited behaviour, dynamic schema evolution and smooth version migration. All are special cases of quite extensive and often multi-threaded object-collaboration whose systematic and flexible resolution should be favoured by a generalized object model.
In addition, information system penetration into the modern business offers us the ever-growing challenges of temporal database and the advanced transaction (Remember those Modifications to Order?). Such mine-fields lurk in both run-time and design-time domains (Remember those BPR opportunities?). Each is further complicated by their own integration as part of the ever more widely-recognized convergence between enterprise modeling, application development and workflow. See for example this observation from Unisys' response to the OMG's Repository Common Facility RFI: "A number of customers now view workflow as the driving technology that is used to control all business processes (one of which happens to be software development!) in an enterprise."
The time dimension and workflow conspire together to complicate yet further any supposed Business Object concept constrained by a classical object model. It becomes a rank impossibility. The OMG's chickens truly come home to roost, which might help explain their slow progress of late.
MACK, of course, addresses all such complex needs, and provides for them simply.
But is such ambition feasible? The real complexities cannot be escaped. Nonetheless it is easy to be ensnared by the artificial complications in present theory and practice. But how can one distinguish between real complexity and artificial complication? I have greatly relied on some guiding images.
With the benefit of MACK-based hindsight, one can see how both OMA/CORBA and COM/OLE are irretrievably misshapen by their common history: conventional procedural programming spawning RPC hence "interface inheritance", thoroughly confusing algorithm time and real time.
But what, then, are more appropriate and reliable threads of continuity between past and future?
Long before the OMG's bus, in fact in March 1990, the Metaset project's founding document sported a very comparable - and even more arrogant - title: "Ride The Mainstream!"
The slogan can be elaborated - and its arrogance self-critically yet confidently defended - in very fundamental and comprehensive ways. For The Mainstream's unifying theme is philosophical: history gives us very generally-applicable advice as to how to advance our knowledge. It is most catchily expressed as Einstein's Imperative: Make everything as simple as you can, but no simpler.
Thus MACK is designed to help people simplify complexity without unduly oversimplifying it. The Mainstream is the confluence of many interweaving currents of people making ever more diverse yet workable knowledge despite the infinite complexity of our given underlying reality.
That there is a confluence is underlined by ever-increasing integration of applications (and interdependence of all human activity). That there should be a greater confluence is implicit in the undisputed calls for better component reusability and product interoperability (and better cooperation between people everywhere). That there will indeed be a yet greater confluence to ride is indicated by the apparently infinite possibilities in that infinite yet evidently humanly-accessible complexity, which point compellingly at infinite humanly-meaningful opportunities in Creation.
The simplification imperative might even be presented as a fairly high common factor to all the most respected ethics. And indeed, let's start (as I explicitly did in 1966) with an appropriately historical yet ever-fresh image for that single imperative: we must steer between Scylla and Charybdis. That was Odysseus' challenge in Homer's Odyssey, centuries before the generally-recognized birth of western philosophy. (For the jargon-minded: Homer was the first european "post-modern"! See further under item (e) of the faq q 2 reply.)
Charybdis represents the terrifying and disorientating whirlpool of complexity. To escape it we have to "hug Scylla's rock". Scylla is the many-headed monster of oversimplification. We cannot avoid at least partial capture by her. We have to simplify, and occasional oversimplification - the stuff of tragedy, dramatic or everyday - is the price of the evolution of our products, our lifestyles, our very concepts and human knowledge itself.
But we must not overcomplicate either! Jumping to the end of the fascinatingly interpretable episode, we find Odysseus having to avoid stagnation on the figtree growing over Charybdis, which represents the bureaucracies and establishments which cannot make progress through the straits.
In the domain of Business Objects here are some interpretations of those who are stuck on the Charybdian figtree: suppliers of working but monolithic packages, guardians of legacy applications, enforcers of unduly elaborate standards. (Pin the label on the one you love to hate!)
The figtree is the most beguiling of the obstacles to a desirable future, for, growing over Charybdis as it does, it is rooted in real complexity and has grown luxuriantly in the evident wealth of possibilities implicit in complex reality. It is however the domain of artificial complication, with its High Priesthoods with positions of privilege to maintain.
How did Odysseus escape the Charybdian figtree? He rowed himself away with his hands, astride the mast and keel of his broken ship. The keel represents humanly-assimilable structure, while the mast - as that which holds the sails to catch the winds of progress - represents human freedom to create. Thus:
MACK is applied epistemology. It was designed to mirror the way we live our knowledge in a world of information system penetration, integration and wide-spread distribution, set against the background of the complexities of real life whose potential should uplift, not mire down.
Knowledge, once admitted to our minds, is abstract. It is only in that form that it is sharable and refinable. Any good abstract system is simple, with its basic concepts and inference rules easily manipulable like calculi. As Bertrand Russell put it, mathematics enables thinking without thought.
The application of an abstract system to a realworld situation aims to be a contextually-justified simplification of that reality. But it could be an oversimplification. However, we cannot even think without such abstraction. So we are in constant danger of succumbing at least partially to Scylla.
On the other hand, the application of an abstract system to new realworld domains, when successful, is readily recognized as creative, and in fact closely represents the essence of human creativity (cf. Arthur Koestler's The Act of Creation, Hutchinson 1964). It is the source of surprise and wonder, and underlies the creation of new wealth.
MACK in action will support that people-driven process as no non-fictional architecture has aimed to do before, as the first realization, Metaset, will show. Subsequent realizations by others will doubtless show it better, at least in niches.
Meta-systems - cf. the OMG's proposed Meta-Object Facility - enable reflectivity (a rudimentary self-consciousness?) in information systems. The simpler the architecture the easier and more extensive the practical reflectivity. Greater reflectivity gives more automatic manipulability, which, when related to human purposes, is more likely to be more relevantly stimulating.
MACK's simple and general-purpose nature gives Metaset a reflectivity far beyond that offered by any present architecture. Such reflectivity enables extensive self-manageability. Internally that means continuous self-monitoring and self-tuning of resource use, including garbage-collection, content-addressibility support, physical data representation and location-contiguity optimization, redundancy management and other memory and database grooming on the fly (What else is there? -- how about "appropriate forgetting"?). Externally, following a core strategy of maximization of coherence with consistency, it enables adaptable workflow on the basis of a continuous pressure to help people match supply with their expressed demands.
But is all that plausible? Well, that's the way Metaset is already booting itself. It is presently still below the elbow of the growth curve where an unconstrained self-booting process suddenly reflects the exponential, critical mass or take-off stage. But that delightful phase is taking ever clearer form, as are some of the constraints that will in due course give the curve its more natural sigmoid shape.
Reuse and interoperation need objective communication. The ability to communicate stimulates creativity. Common ground makes it relevant. Demand stimulates supply, but supply then shapes demand in a simplifying process. A product, when it represents an oversimplification of the ultimate democratic reality of demand, is - in a well-oiled market - soon replaced by a better theory (see Medawar's Dictum again, quoted above). The market is a philosophical instrument in the fullest sense, ever proposing and often validating new products as better simplifications of reality.
Knowledge is information that is lived. Ubiquitous computing will only meet the ever more expectant demand if it is congenial to its various users. Predictable systems are sterile. But unpredictable systems tend to be discomforting. Every kind of user should be automatically helped to find his or her own levels of comfort and challenge.
The behaviour of the future Personal Digital Assistant will not be dictatorial or Procrustean, forcing us into its own restricting and oversimplifying patterns. It will refresh, stimulate and enable us to exploit that infinite complexity. It will draw attention to possible constraints, and will thereby concentrate attention on new vistas, enlarging meaningful freedom.
MACK is based on yet another old faithful from The Mainstream: binary entity-relationships spun into a semantic web. Need that unduly invite oversimplification? No more so than alphabets or number systems unduly oversimplify the complex realities that we represent with their help!
MACK exploits the abstraction of all common knowledge. Too little appreciated, its explicit awareness can nonetheless be traced right back - e.g. in western philosophy - through Plato's image of the cave in his Republic, to Heraclitus' "You can't fall into the same river twice" paradox. We are freer than we usually think to explore and construct in the abstract domain. MACK's reflectivity multiplies the scope.
The test for validity is then the conventional "coherence and correspondence" one: Is there a workable correspondence between the coherent constructs of the abstract model and deemed points of contact with a deemed reality? (The latter concept is variously phrased in the literature with the help of such terms as "sense-data" or "perceptrons", or "measurements" in scientific contexts.)
In MACK, that key empirical process maps abstract constructs into deemed "realworld equivalents" or "REs". Those maps are part of an extensively generalized MVC(Model-View-Controller)-like concept which reflectively interprets the application metadata and constructs the user's interface with the abstract model. (Though it owes nothing more to Smalltalk than the MVC word used here!)
A fragment of an example: Once admitted, an instance of a type can easily be pursued throughout the abstract domain, including up and down multiple hierarchies of generalization and refinement, in a purely mechanical hence computerizable way. Views appropriate to the user's contexts are automatically selected or constructed - in a distributed ORB-like way where indicated - with the aim of inviting, promoting and enabling a step-by-step expansion of coherent user-verified and user-assimilable knowledge. A people-driven but truly philosophical tool.
MACK says "BOO!" to conventional Object Orientation: it is "Beyond OO", for it has absorbed OO's essence yet has no further need of fancy OO vocabulary: MACK is simply plain logic. Conventional OO terms are used here merely to relate to this audience.
The plain logic in the metadata - with its various constructs unique to MACK - is available to the reflective process. Thus (on the one hand) much conventional program or method coding is eliminated, in extensive reuse of standard common logic facilities in the abstract domain.
On the other hand, such visibility is in partial conflict with the precepts of classical encapsulation, with its usual "complexity-hiding" claims. Compared with MACK the latter are an oversimplification of application decomposition: objects are not islands, as the generalized object model reminds us.
There are however RE-methods, which do fully encapsulate realworld knowledge which is outside the abstract model. The rules here are much more strict than in conventional methods.
However, following those rules, those residual methods have a high degree of invariance with related semantic net topology changes. Moreover, their total number will increase merely logarithmically, while application volume will grow exponentially on account of the easy hence high reuse.
That confident prediction is consistent with the notion of real complexity and its abstract equivalent, interconnectedness, whose surely ever better sharable form supports the thesis of the unity of The Mainstream. (True, such greater sharability will - hopefully - partly result from this kind of propaganda! But then, that kind of supply-drivenness is quite natural in the market, and will come under ever better demand-side or democratic control...)
The application design process is also carried out in a market-like way, matching the claims of well-defined Products with the needs and constraints of the user community. Thus client-server information system design will generally be a matter of simple assembly: Metaset is guided by logical coherence and consistency criteria through available product and component metadata. It asks appropriate questions and mediates negotiation where necessary (the hard part!), gradually composing a tightly-bound application incorporating the thus established degree of common knowledge. Binding is intimately associated with the whole market scene, where suppliers make commitments to their customers. That in its turn creates the opportunity for highly-bound high-granularity application components to be code-generated for efficiency where it really counts. Such relative inflexibility will tend to have high user-legitimacy hence high specification-reliability.
MACK has a kind of equivalent to CORBA's IORs (Interoperable Object References), though it is an integral part of the whole message structure scene, which is radically different from CORBA's. As may be expected, message structure also rests solidly on the far-reaching and very practical notion of common knowledge. It benefits greatly from the MACK coherence and consistency strategies. Applying cleanly both to local messages and to IPC, it is integrated with all memory management, including virtual memory, persistence and recovery mechanisms. It forms a natural foundation for meeting distributed-system, mobile-agent and broker/trader needs.
In what way does MACK follow a "generalized object model" (in the regrettably defunct terms of OMA Release 1)?
The answer starts with the already widespread event-driven computational model (cf. for example Peter Wegner's OOPSLA '95 Tutorial Notes: Models and Paradigms of Interaction). MACK integrates it with its decomposition/composition approach, providing a basis for disentangling the thorough confusion of algorithm time with real time which I have already alleged exists in the whole "interface inheritance" concept of for example the OMG and Microsoft.
Thus MACK fully provides for the time component of data. Realworld "objects" tend to be not only qualitatively complex, but dynamic and fluid too. There are many hints of the time dimension in the increasingly recognized importance of workflow, which we kept on observing above.
MACK has a particularly tight integration between relatively timeless metadata (a feature greatly facilitating data consistency), and mechanisms for the transformation and evolution of our models of reality, that is, databases. Conventional objects make the clearest sense in the "naïve realtime" of implicitly synchronous views of data as pioneered by "on-line realtime" mainframes in a database world of "short transactions". But the time dimension demands views in relativistic realtime, fully recognizing the different timeframes of autonomous actors. MACK caters systematically, under semantic control, for their transformations and for the kinds and degrees of synchronicity required for meaningful and accurate interactions between actors in otherwise asynchronous timeframes.
That tight architectural integration, using the reflectivity of the MACK-informed abstract model of reality, enables Metaset's elegant "MVC-like" aspect, giving the truly time-embedded orchestration of method-invocations and user-interactions which characterizes a generalized model in action.
I introduced the market first as a philosophical phenomenon and then as a technological device. Of course it is commercial too. At launch Metaset will have an information-product developer/user market integrated with it, in support of the further bootstrapping by the multi-developer market of Metaset and other MACK-compliant products. It will seed an evolutionary growth process that will promote both supply and demand, thus kick-starting a synergy between them that will soon lead to the replacement of many present software technologies. (And continue to rely heavily on others!)
The boosted information-product market will do the same for the whole market. On the supply-side, the Civil Society phenomenon will rise to a higher quantum level of accuracy and diversity throughout the political economy. From the demand-side, more convenient and congenial hence fuller democratic involvement will ensure a more representative supply. Riding The Mainstream, every consumer/citizen will genuinely supply. The medium will be the message as never before.
Business
Object Workshop II