Business Object Components?

Erik Persson

Department of Computer Science

Lund Institute of Technology

Lund University

Box 118

S-221 00 Lund

Sweden

Erik.Persson@cs.lth.se

Abstract: Although the term business objects is notoriously polysemous, most authors making use of it seem to assume that business objects, apart from being ob­jects in the ob­ject-oriented sense, should also be re­usable, “plug-and-play” com­­po­nents. How­ever, the starting-point of the vision of ob­ject-orien­ta­tion is fun­damentally dif­ferent from that of soft­ware com­po­­nents, and objects and com­ponents cannot, as is often taken for granted, be fitted together without con­sider­able difficulties. To be more pre­­cise, these two programming paradigms clash in the con­cept of im­ple­men­­­ta­tion in­­heritance, which, while being funda­men­tal to most strains of ob­ject-oriented programming, viciously under­mines the plug-and-play com­posa­bi­l­ity required by software com­po­nentry, owing to a set of issues commonly, albeit somewhat ineptly, re­ferred to as “the fragile base class problem”. Below, having outlined what class fragility is, I will try to show how it af­fects business objects and how three impor­tant can­di­date plat­forms for the im­ple­mentation of busi­ness objects, viz. Newi, Java, and COM+, fare with re­­fe­ren­ce to it. Here­upon will follow a brief description of en­cap­su­lated pro­gram­ming, which is a novel style of programming attempting to har­mon­ise ob­ject-orienta­tion and soft­ware com­po­nentry on the basis of en­cap­su­lated in­herit­ance. This re­formed in­heritance mecha­nism, de­­­signed so as to eschew all kinds of class fragility, forms the basis of a new basic building block of software, the cap­sule, which in effect will assimilate the ob­ject and com­­po­nent con­cepts. Finally, I will also dis­­cuss how en­­cap­su­lated pro­gramming can be brought to bear on the three afore­­­mentioned candidates for a business objects plat­form.

Keywords: business objects, software components, encapsulated programming

1           Introduction

Business objects are often held to be, as it were, the ultimate software compo­nents, potentially pro­vid­ing for very high levels of reuse and software agility. For such business objects to become viable, various obstacles, will, however, have to be ove­r­come, of which a very serious one, viz. class fragility, provides the topic of this study.

The idea that the assembly of prefabricated parts or com­­po­nents, forming the basis of the in­dustrial pro­duc­tion of com­puter hardware and most other artefacts, can be taken advantage of also in the production of soft­ware was broached in Douglas Mc­­Ilroy’s famous invited address Mass Pro­duced Soft­ware Com­­po­nents, de­livered at the NATO con­­fer­ence on soft­­ware engi­neer­ing in Garmisch in 1968.[1] The basis of such soft­ware com­ponentry is the machine metaphor, a con­ception of a computer pro­gram­me as a machine-like contrivance built from parts, making en­cap­­­­­sulation and reuse the key­stones of software construction. In con­trast, ob­­­­ject-orienta­tion, originating slight­ly earlier with the SIMU­LA 67 language, rests on a world meta­­­­phor, which arises na­turally in the do­­main of soft­ware simu­la­­tions targeted by the SI­MU­LA lan­guage.[2] The allure of object-ori­ented soft­ware ­– including business objects – largely con­­sists in its em­­bodi­ment of a men­­tal mo­del of a set of real-world or imaginat­ive en­ti­ties that renders an ob­­­ject-oriented pro­gram­­me akin to a “micro­­­cosm” of message-ex­­chang­­ing ob­jects. In an oddly Platonic vein, the dynamically chang­ing, ‘material world’ of objects inside an exe­cuting object-oriented programme mirrors the unchanging, hier­archical­­ly structured, ‘ideational world’ of classes sculpted by a pro­gram­mer demi­urge. In sum, the lodestar of object-orien­ta­tion is hier­archical mo­delling, that of soft­ware com­­po­nentry the en­cap­­­­­su­la­tion of parts. Can these two fundamentally different outlooks be re­conciled?

In the 80s, as the interest in object-orientation, soft­ware com­po­nentry, and soft­ware reuse started to grow rapidly, Brad Cox made the in­genious and in­triguing at­tempt to amal­gamate the com­po­nent and ob­ject con­cepts through his notion of Soft­­ware-ICs.[3] These were binary packaged Objective-C ob­­jects, possess­­ing many of the dyna­mic pro­­­­­­­per­ties now wide­­ly held to be necessary for com­po­nents. The sup­port for im­ple­men­tation in­heritance implied by the object-oriented paradigm, however, gave rise to a number of “fragility” pro­blems that tend to seriously undermine the com­ponent idea. Through clever design, Cox attempted to counter the problems, although he was not able to re­solve all the issues involved.

Since the early 90s, the suitability of objects as com­po­nents has become in­creas­ing­ly contentious. In particular, weighty criticism has been levelled at im­ple­mentation in­­­herit­ance, the bedrock of ob­­­­ject-orien­ta­tion, but also the source of the fragility pro­blems. For example, Cuno Pfister, the chairman of Oberon micro­­systems, strikingly declares, “It may well turn out that im­ple­men­tation in­­herit­ance is the GOTO state­­ment of the nineties”.[4] Additionally, various problems pertaining to ob­ject-oriented frame­works seem to be de­rivable from imple­men­ta­­tion in­herit­ance.[5] ‘The fragile base class problem’ caused the de­signers of Micro­­soft’s Com­po­nent Ob­ject Model (COM), the as yet most success­­­­ful com­po­nent infra­struc­ture, to abandon im­ple­men­ta­tion in­herit­ance alto­­­gether. Rival com­po­­nent techno­­­logies, such as Open­­Doc and Java­Beans, have re­­tained full sup­port for im­­ple­men­tation in­herit­ance and the object-oriented approach, there­by, how­ever, also re­tain­ing the liability to the class fragility pro­blems. Pace the many advocates of such ‘traditional’ object-orientation, the swiftly rising star of component-oriented pro­gramming, as advocated in e.g. Szyperski’s sug­­ge­sti­ve­­ly named book Com­­po­nent Soft­­­­ware. Beyond Ob­ject-Oriented Pro­­gram­ming[6], seems to be beaming in the direction taken by the designers of COM.

Below, I will briefly adumbrate what class fragility is and why it is harmful to the business objects vision. I will then suggest how object-orientation and soft­ware com­po­nentry can be reconciled through encapsulated programming, a novel pro­gram­ming style that attempts to correct the deficiencies of the object-oriented in­herit­ance mechanism.[7] I will also discuss how the adoption of this programming style would affect classical Newi-style business objects as well as business objects im­ple­mented as COM components or as Java language objects, such as JavaBeans.

2           Class Fragility and Business Objects

In­heritance is widely held to be the dif­ferentia specifica of ob­ject-orienta­tion[8], but has become increas­ing­ly debated, as it clearly is also the source of mis­­cellaneous pro­blems.[9] According to Wegner and others, inheritance is es­sen­tial­ly a mecha­nism for the “in­cre­men­­tal modi­fica­tion” of a super­class by a sub­class[10], mak­ing poss­ible the pro­­­gram­ming style called pro­gram­ming-by-difference.[11] Be­­sides in­herit­ance, poly­­mor­­ph­ism is generally con­sidered essential to ob­ject-ori­ented pro­gram­ming.[12] Where poly­mor­phism is supported, values and vari­ables may be of more than a single type, where­as the ant­onym mono­­mor­phism implies that any value or variable in a pro­­gram­me may be of one and only one type. In ob­ject-oriented pro­­gram­­­ming, poly­morphism is yoked closely together with in­herit­ance, insofar as object references usually are poly­­morphic and re­­fer to objects that may be either of the type of the ob­ject re­fer­ence or of any sub­type of this particular type. In some pro­gram­­ming lan­guages that sup­port dy­namic typing, such as Small­talk or Ob­­jective-C, ob­ject re­ferences may hold re­ferences to any type of ob­­ject. When poly­morphism is taken ad­vant­age of, method re­­so­lution will happen at run-time by means of dy­na­­­mic or late bind­ing.

There are two distinct variants of inheritance, inter­face in­herit­ance (or subtyping) and im­ple­men­ta­tion inheritance (or sub­class­ing). The former term denotes the in­herit­ance of type (i.e. inter­face or protocol), the latter the in­herit­­ance of behaviour and state (i.e. implementation). Where­­as the virtuousness of interface inheritance is not very contro­­versial[13], imple­men­tation in­­heritance has ever and anon been decried as un­in­terest­ing[14] or po­ten­tially male­ficent[15]. Techno­logies such as COM and CORBA di­rect­ly sup­­port only interface in­heritance, where­­as most ob­ject-oriented pro­gram­ming lan­guages merge interface and im­ple­menta­tion in­heritance into one con­cept. An im­­por­tant ex­­cep­tion is Java, which of­fers a clear separa­tion of the two in­heritance types. In C++, interface in­­heritance may be simu­lated through public in­heritance of an ab­stract class, which has only pure virtual func­tion members, whilst pure im­­­ple­men­­­­ta­tion in­heritance may be simulated with private in­herit­­ance.[16]

Inheritance is sometimes said to “break encap­sula­tion”, be­cause it makes super­classes expose im­­­­­­ple­men­ta­tion details to their subclasses.[17] In this context, it is note­worthy that, in general, a class exposes two interfaces that usually inter­sect: the client inter­­face in­tended for ‘or­di­nary’ run-time usage and the specialisa­tion inter­face in­tended for subclassing.[18] In many object-oriented lan­guages, such as C++ and Java, it is poss­ible to restrict access to methods and instance data by the use of access modi­fiers. In C++ and Java, the methods and data of the client interface are declared pub­lic, those of the specia­lisation interface pro­tected, and im­ple­men­ta­tion details, which are to be accessible through neither inter­face, private. In both these lan­guages, mem­bers of the client interface will always be part of the specia­lisa­tion interface as well.

Whereas strict observance of the principles of infor­ma­tion hiding and data ab­strac­tion will mitigate the problem of en­cap­su­lation break[19], it will still at times be ne­cess­ary to have access to the source code of a superclass in order to be able to im­ple­ment a subclass cor­rect­ly. In par­ti­cular, this may be the case when a superclass method is over­­ridden by a method in a sub­class or when a sub­­class de­fines a method that will be recursively called from the super­class.[20] The cause of this need is that a sub­class – in contrast to an ordinary client – will share the important variable self (also known as this) with its super­­class. In­herit­ance-based reuse is at times re­ferred to as white-box re­use, because source code access is re­quired for the specia­­lisa­tion of the reused code. This need for source code access is evidently a serious obstacle on the road to markets for plug-and-play software com­ponents or business objects. For software componentry, ex­­tensi­bility mecha­­nisms sup­­porting black-box reuse, such as aggrega­tion, are, hence, frequent­ly claimed to be superior to white-box mecha­nisms.

2.1         “The Fragile Base Class Problem”

The locution “the fragile base class problem” emerged within Microsoft during the de­sign and de­ve­lop­ment of COM. Strictly speaking, this term seems in­appropriate, since, what is “broken” and thus “fragile”, will in most cases be a subclass rather than a base class, although the under­lying causes of the fragility often lie with a base class. Some authors use the term also for scenarios, where neither a base class, nor a sub­­class, but a client of a class is what “breaks”. In my con­­tention, the term “the fragile base class problem” is mis­­­leading and should be abandoned. Instead, I suggest class fragility as an overriding term for all fragility problems that per­tain­ to the use of classes; these can be further subdivided into subclass fragility and client fragility.[21]

Moreover, the term “the fragile base class pro­blem” is made to refer to different pheno­mena by different authors. Most­ly, the concept is understood as re­ferring to pro­­blems that occur when base class im­ple­me­ntations evolve in­de­pen­dent­ly of their sub­classes, and this will also be the sense used here.[22] There are two dis­tinct varieties of the problem, viz. syn­tac­tic and se­mantic fragility.[23] Since it will not be possible to explore these problems, which are both quite in­tric­ate and quite technical in nature, in de­tail here, we will focus on their con­sequences for components and business objects.

2.2         Syntactic Fragility

Source code references to external func­­tions and data (i.e. func­­tions and data de­fined out­side the current source code file) are tra­di­tionally re­solved at “link time” through static link­ing by a linker. However, in GUI en­viron­­­­ments, such as Windows and OS/2, run-time or dy­na­­mic linking to Dy­na­mic Link Lib­raries (DLLs) has caught the wind.[24] At the cost of an extra memory in­­­direction for each external re­ference, dy­na­mic linking makes it possible to upgrade a DLL with­out having to re-com­­pile and re-link all applications that make use of it, pro­vided that the functions and the data re­ferred to by these are not re­moved, renamed, or their types/signatures changed in the new DLL. This is a major benefit, mak­ing it easy to dis­tri­bute fixes and up­grades of binaries shared by a large number of pro­gram­mes without breaking them. For one thing, the Windows API is distributed as a set of DLLs. Un­for­tu­nately, such flexibility is only possible when procedure-ori­ented lan­­guages, such as C, are used; when ob­ject-oriented lan­guages are relied upon, the syntactic fragile class problem will stand in the way.

Syntactic fragility will make it necessary to re­com­­pile un­­modified subclasses and clients, whenever changes in the inter­face of a base class have been made, lest the sub­classes should “break” during exe­cution. Recompila­tion will be ne­cess­ary even upon apparently very harmless changes to the inter­face of the base class, such as a simple re­order­ing of its members. The problems derive from the way virtual methods and in­­­stance data are organised in tables and referenced by tabular offsets in the compiled and linked bina­ries of ob­ject-oriented pro­gram­mes. Un­for­tunately, the layout and size of these tables, which need to be known at com­pile-time, will tend to be affected by any modi­fication to the class interface, however slight.

Syntactic fragility causes two problems, re­com­pi­la­tion ava­lanches and the break­down of release-to-release binary com­pati­bility. Re­com­pi­la­tion ava­lanches tend to af­­fect pro­­grammer productivity very ad­versely, as appli­cations grow large and com­pi­la­tion- and link-time­s become increasingly protracted. In com­piled object-oriented lan­­­guages, this is ex­acerbated by the across-the-board use of file in­clusion directives and file time stamps to deter­mine which code needs re­com­pila­tion. In C++ and some other lan­­guages, the problem is primarily restricted to class inter­face changes by a clear­-cut se­paration of the class inter­­face from its imple­men­tation through header files, although some im­ple­men­­ta­tion de­tails ex­­posed by the inter­face of a class, such as in-line function mem­bers, may oc­ca­sionally add to the fragi­lity.[25] Languages that do not keep interface and im­ple­­men­ta­tion apart in dif­ferent files will be more vulner­able to syn­tactic fragi­l­ity, as not only interface changes, but any changes to the im­ple­­men­ta­tion part of a class will trigger the recom­pilation of sub­classes and clients.

The breakdown of release-to-release binary com­pati­bility af­fects system reliability ad­versely, inasmuch as the intro­duc­tion of a new version of an ob­ject-oriented DLL will possibly in­­validate all applica­tions that rely on this DLL, as the offsets used to address data and virtual func­tion members as well as the table sizes and layouts pre­sumed by any existing subclasses may no longer be correct. This obviously is a major obstacle for plug-and-play soft­ware componentry and business objects.

Various attempts to dispel syntactic class fragility have been made. Some of these, such as the run-time method dispatch of Smalltalk-80, Brad Cox’ Software-ICs[26], or IBM’s SOM (System Object Model)[27], only provide partial solutions and in doing so incur a more or less serious performance penalty to boot.

In the Java Virtual Machine (JVM), syntactic fragility is avoided by suspending 1) name re­so­lu­tion to link time (which happens either at load-time or at run-time) and 2) the deter­mi­na­tion of the storage layout of ob­jects to run-time.[28] Un­for­tu­nate­ly, the con­sider­able load-time/run-time per­form­ance penalty implied by this approach will have to be paid afresh every time a Java pro­­gramme is exe­­cuted and will grow con­sider­ably worse with code size and code com­plexity.[29] The success of Java is largely a con­sequence of the security benefits of the virtual machine approach for the – not very performance-critical – browser-based execution of code snippets down­loaded over the Internet. On the other hand, if the JVM approach is abandoned for com­pi­la­tion to native code, as is often sug­gested when the per­­­­form­ance problems of Java are de­bated or performance-critical application areas, such as web server or embedded systems programming, are considered, syn­tactic fragility will ne­cessarily re­appear.

Microsoft’s COM (Compo­nent Object Model) eschews syn­tactic fragility through the convention that published COM inter­­faces must be im­­mut­­able.[30] Finally, Newi’s co­operative business ob­­jects[31], which rely on semantic messaging for intercom­munica­tion, are not liable to syn­­­­tactic fragility at all, since dispatch is made dyna­­mi­cal­ly at message-time in a message loop. Although this kind of semantic messag­ing is much slower than ordinary method calls, the granularity of Newi’s busi­ness objects will en­sure that inter-object messaging will be comparatively rare, primarily hap­pen­ing due to direct user inter­­action.[32] Notably, both COM and Newi introduce a “layered” programming model, where inter-com­po­nent calls differ significantly from intra-com­po­nent calls. This two-layered approach allows both these technologies to pro­­­vide language inde­pen­­dence through the definition of a binary interface at the upper component/business object echelon.

2.3         Semantic Fragility

Semantic fragility is much more elusive in nature than its syntactic sibling, as it arises from evo­lu­tionary changes not to the interface of a class, but to its im­ple­mentation. It may show up, when­ever a new version of a base class, from which sub­classes have been derived through im­­­plementa­tion in­­­herit­ance, is introduced, pro­vided the base class makes a – direct or in­di­rect – poly­morphic self-re­cursive down-call. Since every poly­morphic self-call may po­ten­tially be resolved into a down-call, we can just as well say that the problem is latently overhanging in any class that makes at least one poly­morphic self-call. In addition, it may show up upon revision of a base class, the in­stance data of which are directly accessed from a sub­class. Mikhajlov and Se­ke­rinski, who have investi­gated this pro­­blem at length, dis­cern five dis­tinct cases of it, some of which are quite in­­volved.[33]

These cases will not need to be retold here; the bottom line is that whenever a base class is revised, any (unmodified) code taking advantage of the base class through subclassing may unexpectedly start to malfunction, although care has been taken to en­sure that the modifications in the base class will be entirely behaviour-preserving.[34] This will cause a breakdown of release-to-release semantic com­pati­bility and will compel subclass programmers to get access to and analyse the source code of base classes. Just like the lack of release-to-release binary com­pati­bility, this will of course seriously undermine the software componentry and business objects visions.

Since implementation inheritance is a crucial feature of object-oriented languages and these languages eo ipso are liable to semantic fragility, the problem has attracted con­siderable attention by researchers. Two kinds of countermeasures against se­mantic fragility that have been suggested are:

·     to “discipline” implementation inheritance by the establish­ment of a set of “rules”

·     to abandon implementation inheritance alto­gether

The former avenue, which has been dealt with in a number of research papers, seems to lead up to awkward and byzantine schemes that will force pro­­­­­gram­­mers to per­form complex analyses of the source code inter­de­pen­­dencies of methods, method group­­ings, self calls, etc.[35] Further­more, these schemes presume that the subclass pro­­gram­mer has access to the source code of super­­classes, which will be highly unde­sir­able in com­­po­nent/business objects scenarios. The latter avenue of forgoing imple­men­tation in­heritance altogether – taken, for instance, in Microsoft’s COM – will raise the hackles of many ad­vocates of ob­ject-orientation accustomed to the reliance on inheritance as a handy ex­tensi­bility mechanism.

3           Encapsulated Programming and Business Objects

Elsewhere, we have suggested that the clash of ob­ject-orienta­tion and com­­­­­­­po­nent-orienta­tion can be resolved through en­cap­sulated pro­­­gram­­­ming, a new programming style designed so as to be im­pervious to all kinds of class fragility, while still re­tain­ing sup­port for a restricted, “dis­ciplined” form of im­ple­men­tation in­herit­ance.[36] En­cap­­su­lated programming is based on two basic mandates:

·     Firstly, syntactic fragility is to be eschewed in one way or the other, be it through a semantic messaging mechanism as in Newi, an interface immutability con­vention as in COM, or the postponement to load-time/run-time of name lookup and of the computation of object layout as in JVM.[37]

·     Secondly, semantic fragility is to be addressed through the espousal of en­­­cap­su­lated in­­­herit­ance, which modi­­fies im­­ple­men­ta­tion in­herit­ance by banning poly­morphic self-re­­cursive down-calls and direct access to superclass data.[38]

In our terminology, an object that avoids syntactic fragility and sup­ports en­cap­sulated inheritance is called a capsule. Since, in our view at least, class fragility must be overcome, if the visions of software compo­nents and business objects are not to remain on the drawing-board, capsules should provide a suitable shape for the im­ple­mentation of components and business objects.

We will now try to clarify how encapsulated pro­gram­ming will affect business ob­jects, using Newi-style business objects, Java objects, and COM components as examples. We have chosen to look at Java and COM because of their current im­portance on the market overt, whereas Newi will be con­sidered both because of its historical impact on the business object com­mun­ity through the writings of Oliver Sims, “the father of busi­ness objects”, and because of its principal im­port­­ance.

3.1         Newi-style business objects

Newi’s semantic messaging mecha­nism effectively immunised Newi classes against syn­tactic fragility, although, by virtue of its support for im­ple­mentation in­herit­ance and poly­morphic self-re­­cursive down-calls, its objects were amenable to se­man­tic fragility. However, this was some­what mitigated by the fact that sub­classes and clients did not have direct access to super­class data. Thus, by removing the possi­bility of sending messages to self (but, of course, not to super!) from the Newi infra­struc­­ture, Newi could easily have been made to support encapsulated inheri­tance and the en­capsulated programming para­digm.

3.2         Java and JavaBeans

Java code executed in the Java Vir­tual Ma­chine is not liable to syntactic fragility, although the virtual machine approach may imply a significant performance penalty. This can be countered through dy­na­mic linking and com­pi­l­ing with cach­ing, which is a scheme that re­fines the JVM approach by cach­ing the linked and verified byte­codes – as well as any snip­pets of binary code re­sult­ing from dynamic com­pilation – in a cached image that, after a version control, can be taken advantage of on sub­sequent exe­­cu­tion of the code.[39] This approach will, I believe, reduce the performance pe­­nalty of the virtual machine approach considerably and still steer clear of syntactic fragility.

In order to avoid semantic fragility, the Java inheritance mechanism needs an over­haul so as to provide support for encapsulated in­heritance. Two minor measures will suf­fice: Firstly, all data members should be made private; thus, one should not be al­lo­wed to use the access modifiers protected and public on data members. Secondly, poly­­morphic self-calls of methods that are neither final, nor private should be dis­al­lowed. As the Java designers will not be likely to accept such bold reformation of their language, one may instead choose to use these rules as guidelines for the de­sign of Java or JavaBeans classes intended as reusable components or business objects.

In this context, it should be noted that encapsulated pro­gramming clashes with the workings of white-box frameworks, which tend to make heavy use of polymorphic down calls in accordance with the so-called Hollywood principle (don’t call us, we call you). Although certainly controversial, giving up the current frame­work reliance of the ob­ject-oriented approach appears to us a both necessary and highly bene­ficial step. In our experience, the chief cause for the low productivity and steep learn­ing curves of object-oriented pro­grammers as compared to developers that work with com­­po­­nent-based RAD tools stems from the reliance on appli­cation frame­works, which have an extremely high surface area[40] and thus are very dif­ficult to master and use. Application frameworks also violate funda­mental prin­ciples of soft­ware engineer­­ing, such as en­cap­sulation, infor­ma­tion hiding, and the mi­ni­misation of cross-module coupling, and, thus, tend to breed code complexity, undermine main­taina­bility, and create dangerously tight couplings between appli­cation code and frame­­works.[41]

The Java approach is, however, highly framework-oriented, and the thickets of frame­works surrounding the Java language tend to grow increasingly dense every day. For the Java programmer, it will not be a realistic option to dispense with all these frameworks. He can, however, use a two-layer strategy to mitigate the problems by abiding by the prin­ciples of encapsulated pro­gram­ming in Java and JavaBeans classes in­tended as re­usable components or business objects, while still taking ad­vantage of the Java frame­works internally in these.

3.3         COM

COM is already immune both to syntactic and to se­man­tic fragility, but lacks sup­port for implementation inheritance. It seems that COM would gain much by getting support for a simple-to-use extension mechanism, such as encapsulated in­herit­ance, since the extension mechanisms presently available to the COM programmer, dele­ga­tion and aggregation, tend to be both un­wieldy and difficult to use correctly.[42]

4           Conclusions

If business objects are to be objects in the object-oriented sense and also capable of being used as plug-and-play com­po­nents, the problems of class fragility caused by the flawed in­herit­ance mechanism of today’s ob­ject-oriented approach must be addressed. We have argued that the fragility problems can be ex­punged through the adoption of en­cap­su­lated pro­gramming and outlined how techno­logies such as Newi, Java, and COM can be modified so as to adhere to this style.

Business objects, being software representations of the things and entities of ‘the real world’, will need to be much more large-grained and flexible than the ordinary objects of object-oriented programming. Although the Newi product now seems to have faded out of sight in the hands of SSA, I believe that Newi-style, large-granular, directly user-mani­pul­able com­­po­­nents interoperating through se­mantic messaging as envisioned by Oliver Sims in his first book[43] still hold great promise as the proper shape for busi­ness ob­jects, in particular if modified according to the lines suggested above. For one thing, various on-going de­ve­lop­ments, such as the rise of XML and SOAP and the possibly im­mi­nent arrival of 3-D user interfaces, may make for a better apprecia­tion of this vision of busi­ness objects. By re­liance not on proprietary niche-technology, but on the rapidly matur­ing COM+, Java, or CORBA techno­logy com­­pages as infra­structural under­pin­nings, such business ob­jects should be able to gain in attractiveness in the market­­place. In the Panopeus project, of which this essay is a spin-off, I am cur­rent­ly in the pro­cess of de­­ve­lop­ing and ex­­ploring the agenda of realistic com­puting on the basis of this kind of large-grained business objects, semantic messaging, 3‑D user interface techno­logy, and en­cap­sulated programming.[44]

5           Acknowledgements

This research has been supported by Crafoordska stiftelsen and Helge Ax:son John­sons stiftelse.

6           References

[Berr95]