The real problem is to get people to come up with a model of the problems and to make this model available to the machine at runtime using a standard markup language. Developments like the 'deployment descriptors' in Enterprise Java Beans and the massive amount of meta-information generated and used in Component Broker are only a first glance at things to come.Īfter working several years with meta-information driven systems I came to the conclusion that it is not so much the technology that is missing or hard to understand.

The idea here is that repositories used to be some kind of add-on for change impact analysis they are now necessary at runtime just to keep the system going and in a valid state. While with previous programming paradigms (see below 'Old style static programs' these aspect were kept quite separate of each other, distributed system make the borders fuzzy and require a new look at their relations. to find out about the consequences of a certain object/server being unavailable.Īnother assumption targets the new relations between programming model, build process, runtime system and system management. Not only the business related functions need meta-information - the machine needs a reflective view of itself, e.g. Large CORBA systems are either meta-information driven or they won’t survive the need for constant changes. We also see the current trend to more and more meta-information to continue, especially in distributed environments using static typed languages. And no matter how good the prototyping or development environments are, a large bank could not survive with this model. It needs to have higher abstractions, otherwise every change in the business use would end up needing a new processing machine. (PLOPD 3)Īnd there is also the believe of the 'machine' working on a higher abstraction level than the usual use case based business analysis. the bureaucracy pattern can be used to implement a system that ensures structural and semantic validity during constant changes from outside. Typical examples for this approach are Applets or the Coins project. The difference to regular OO concepts lies in the fact that behavior and information are dynamically associated and can therefor be combined in ever new ways. It turns out that OO is an excellent approach to handle information. Just as I can use a book to derive articles from it, to search for topics in it and maybe even use it to level my table with it, I cannot foresee all the contexts a piece of information might be used in.ĭoes this mean that object orientation with its tight coupling of data and behavior is wrong? Not at all.

Representation of information needs to be separate from behavior to enable processing of this information in different contexts. The sturctures and relations expressed in this –ever growing and changing- hyperdocument are handled by a generic hypermedia engine with specialized behavior attached to it.īehind all this is the believe that even with object technology being used, the concept of information is still valid and that not everything is usefully represented as a behavioral object.

Structure, addressing, linking and schedules are what a generic hypermedia system provides and those are also the features needed to form a repository.įollowing this approach the repository content for a bank is seen as a hyperdocument. The most radical approach used in this document is the decision to consider a repository to be some kind of Hypermedia system. The following is a collection of - some might say religious - statements on what the current state of affairs is, what a repository nowadays has to provide and on which technology it should be based.

Simplemind other languages