The UltraHigh Reuse project is a thoughtful approach to problem solving in general. It is a free-source project.

In our view, UHR is Jini and bean-scripting taken to a higher level of abstraction. UHR may benefit from some of Jini's approaches in the short term. In the long run, we suspect Jini will be reduced to merely an application of UHR. This is because Jini has some nice concepts, but it's still domain-specific -- whereas UHR is domain independent. Jack Harich, the project lead, has focused on problem solving in general -- while Sun has focused on network devices in particular. The main parallels between the two are:

Jack also claims his "Param" abstraction is better than Java's "bean spec". The following definitions and notes were collected from Jack's writings:

Container: user partitions the system into Containers.

relationship: user establishes relationships between Containers.

Part: user selects and drops "smart" Parts into Containers; automagically hook themselves up to the system. Parts typically communicate through their Container via Messages.

Part Shop: place where ready-for-use Parts and pre-built groups of Parts (plugpoint frameworks, role patterns, etc.) are kept.

Param: parameter (property?) of Part expressed as "declarative knowledge" (DK); is a Datatron containing parameters for part initialization.

Containers are just another type of Part. A system is just the "root" Container. Systems are built from subsystems (i.e, nested Containers are used to build systems). A Container can optionally have a custom class and custom parameters, in addition to the mediator-style parameters that create and set relationships for the Parts in a Container.

The Part Shop is where the user or developer goes looking for Parts to use in a system. It can provide empty apps, Containers, Parts, groups of parts, systems, and assistance. It has a huge number of Parts in stock, so it has query and search abilities. It knows which Parts have worked well, where they are deployed, which are not used anywhere, which are under construction, which work well together, etc. It is constantly improving this knowledge by monitoring or exploring systems and remembering all check_outs and check_ins. It also asks users about their satisfaction with Parts and the Part Shop's services, stores this info, and uses these Surveys to improve itself with developer assistance as needed. Like all elements, the Part Shop itself is built of Parts.

Parts are organized in a layered architecture with base Parts at the bottom and app specific one at the top, with additional layers such as domain and service in between. Enterprises can organize their Parts by describing their preferred organization to the Part Shop, which is then enforced when Parts are assembled from other Parts or collaborated with via Messages.

System Tree: a hierarchy of Containers and Parts.

System Mediator: initializes the system and handles Part creation, findability, and destruction; later becomes the Microkernel (BA system engine).

Message: Parts receive and send Messages which contain event type and properties. The properties can be primitives, Strings, or "riders" such as Datatrons or mobiles. (Any Part can be a rider???)

Datatron: application-neutral data structure. A small number of types can handle all Part needs. These are expected to be trees, row/column, rows and streams. They can be nested. In all cases the leaf is a primitive or String. The purpose of a Datatron is to travel somewhere with data and allow that data to be easily accessed.

A Part knows of no other Parts. They remain a mystery which it can only query about -- not about the Parts, but about the capabilities (services) available. Queries and other data getting is done via "acquire" Messages.

The Part Shop can send and receive datatrons such as policy changes, state changes, part replacements, and alerts to deployed parts, stock parts, deployed systems, or particular users.

Some special Parts can communicate beyond their Container:

• Sensor: Part which can receive input
• Emitter: Part which can send output
• Mobile Part: Part which can travel beyond its Container to other Containers, regardless of the Part's or Container's location, as well as send and receive messages to/from Containers. A Mobile Part may leave a proxy behind to foward messages after it departs.

autohookup: consists of establishing relationships and finding property values based on Needs and other types of initialization. (If Parts have problems doing this, they report what properties and relationships need setting to the user, who can then remove the Part, alter the system, or alter the Part to fix the problems.)

Provider Service: aka Trader, Naming or Registry; given a need, the Provider can find a Part to fill that Need.

Need: (Rule?) a type of Param; expresses the "logical service needed" information. For example, a Part may need a storage part that can count rows for users in the admin database. The Need would have: Role = Storage, Function = CountRows, Area = Admin, Entity = SystemUser. This would be enough for the Provider Service to find a Part implementing the Storage interface that could handle the need, assuming the Part had already been registered.

Parts are added to Containers by Part Shop check_out and removed from Containers by check_in. This is done manually by users or dynamically by Parts (i.e, systems can dynamically grow or shrink).

Autohookup, aka autoconfiguration, would be like building a house with the materials doing most of the work. You would mark out the footing, throw some "smart" Concrete at it, and it would dig the slab and footing, mix itself, find the rebar and put that in, and pour itself. Then you would mark where the doors are, throw some "smart" Sill Plates at the slab, and they would cut themselves to length and attach themselves. Later when a room was ready for finishing off, you would throw in some "smart" Flooring (oak tongue and groove) and it would cut and lay itself.

Parameter Editor: a visual tree of typed parameters: "look and choose". Each Param Container node is a Param type, such as Need, and has default member nodes that appear when the Param Container is added. Additional members are added via selection. Each member shows allowable values and validates changes. (Since Param types are similar to XML DTDs, there may be editors and other subsystems on the market as XML matures which we can use and not have to build our own. Of course, we need to change the param text format to XML to do this.)

configures: user or system configures the hookup and behavior of Parts; dynamic aspect is useful for fine tuning and evolving system behavior.

default: preconfigured value of a property of a Part.

inspects: user inspects a Part to see its properties, their defaults, and what other Parts or Containers it collaborates with.

navigates: user navigates through the system by drilling down into Containers and returning (zoom and unzoom).

Filter: a Filter allows user to hide/show certain types of Parts and relationships.

Evolver: wizard that steers user through changes; caters to the user by remembering preferences, habits, skill level, changes made.

Part Picker: works with Evolver to allow picking out needed Parts. Start simple with tree, move up to query, search, user favorite Parts list, etc.

part_order: add ability to order Parts. This will unify project management and address customer's needs better.

Part Inventory: create several hundred useful Parts and some sample systems. All Parts must tell how to use themselves.

Containers can be configured to various patterns, such as Layered Architecture or Services Architecture. For example a Container serving as a layer would configure its Provider to first check other Parts in the Container, and then those Parts in the lower layer. If services were available then the Container would configure its Provider to next check the services Container.

Parts normally contain no references to another Part, making replacement and reuse possible. Parts doing high speed work need references and may be referenced. (This will be resolved by use of state transfer for references and replacement notification or another mechanism for "be referenced".)

Parts can be replaced anytime by asking a Container to replace an old Part with a new one. Since all Parts communicate only with Messages, this involves transferring old Part state to the new Part and then routing Messages to and from the new Part. This will require "morph" support from Parts for state transfer.

All uses of a Part in a system can be replaced by sending an agent through the system's Containers. The agent can do a three phase replacement: beginReplace(), commitReplace() or abortReplace(). This handles Parts that need to be "paused" during replacement, such as servers, open files, windows, etc.

Custom Part: can be manufactured on the spot or ordered. Users are notified when orders arrive. (Notification could go to a Monitor; e.g, project manager or a developer in a project.)

Empty Part: given state and policies, it responds to input by reasoning, changing its state, and emitting output as necessary. Optimization is needed for Empty Parts to avoid a system built from them being too slow. This is done by part_manufacturing. Goal is to eliminate need for any custom coding by producing behavior of any type from DK. This and Generated Parts will herald the end of hand coding.

part_manufacturing: add ability to generate DK from meta DK to produce a Part. Add code generation, see below. Add ability to assemble group of appropriate Parts, as a Container, for use in a Container, or as a skeleton system.

Generated Part: Part Shop can generate and compile Parts from DK and other Parts. This is useful for high speed work, behavior that is hard to express with parameter-driven Parts, or needs for Parts that don't exist. A key threshold to look for here is when generated Parts start generating Parts.

Policy Part: created by Part Shop per needs; a subtle mechanism: Its mission is to decide things. It is not a view, not persistent, not a task. It is used for reference by these other types of Parts to decide what to do in a centralized manner. This allows the designer to *isolate all business rules*. At first, the Policy Part does it with code. Eventually, it will do it with Configurable Logic. (It is a deliberate bridge from the "Reusable Parts" stage to the "Dynamic Logic" stage. Once we figure a few things out, Policy Parts will probably be replaced by yet-to-be-discovered types of Parts -- or possibly by all Parts.)

Logic Engine: driven by Policy Part's input.

Part Builders: driven by Logic Engine output.

Learning Part: driven by various.

Knowledge Part: driven by Learning Part's output.

Last modified: 5/26/99