Bus Design
Connector:
Registers obects and attrbutes/facets.
Field and method facets.
local/remote facets for generation?
Both static and dynamic facets.
connects objects along facets.
for replicated dynamic facets, generates a single replica id for all objects connected to the facet.
All kinds of lookups.
object_to_replica (object)
replica_to_object (host name/context name).
....
Introspector:
Figures out facets of an object.
Like Beans, but must support in addition the concepts of:
static vs dynamic facets.
source vs destination methods.
Uses reflection for field facets.
Instantiator:
Probably want bus to instantiate objects also. In Cb's virtual machine
or in a separate Java machine. Also local vs remote CB virtual machine.
This would help provide a convenient UI.
Generator:
Allows generators to register.
Given a missing end point, generates that point.
Takes parameters of generation.
Reference Models:
These define certain sets of composable objects and associated facts.
Parent/Child Model.
Parent has dynamic children (method/field) facet.
Child has single/multiple parents.
Child can be connected to parent.
Now can have hierarchical naming ala Sync for
hashtables, records, sequences etc.
We can also have recursive register where root of connected tree can ask for all
its descendents to be registered.
This model can be composed with other models
Observable/Observable Model
Bean/Listener Model.
Same as O/O except that Observer/Observable have certain structures rather
than particular classes or interfaces.
Observable/Observer/controller model
Munson model.
Submodel of O/O model.
Model/View Model
or Abstraction/Interactor Model.
Submodel of O/O or B/L model.
One or more observers happen to be user-interface views.
Protocol remains the same, so perhaps this may not
really be interesting.
But we can probably make use of the fact that views are
rendering models.
Maybe considered supermodel of Client/Display Server Model
and other models below.
Model/Version/View/InCoupler/OutCoupler/CC Model
Submodel of O/O/C and M/V model.
Client/Display Server model.
Display server like view.
Client like Model.
Client can be connected to multiple servers,
which are named.
Multiple clients can be connected to same instance of display server.
(Actually that should be true of views also.)
Display server works for multiple types of clients.
Well defined 2-way protocol between client and display-server.
Client initiates connection.
(View to Model communication not defined by M/V).
Essentially defines X Client/X Server and
Client/Collaborative Display Server Model
Same as above except that Display Server
allow multiple users to interact with a client
Client is collaboration unaware. Thinks there is single stream of
communication.
Centralized Client/Collaborative Display Server Model
Client is centralized.
Replicated Client/Collaborative Display Server Model
Client is replicated whenever a new user joins.
Pseudo-server based models.
Subclass of above models.
Log Model.
Adds a log module to above model.
JCE Model?
Not sure how AWT works.
Replicated Client/Colab Display Server Model.
Bean/Adapter/Editor Model
Subclass of M/V model which is sublcass of B/L model.
Uses Bean structure.
Defines a 2-way protocol between editor and bean.
Generators.
Using these reference nodels we can build generators.
Adapter/Editor generators.
X Pseudo Server generator.
In-Out Coupler/Concurrency Controller generator.
Log generator.
Bus User-Interface.
Have a bus window.
Shows currently registered objects.
clicking on object generates static connections.
clicking again on an object genberates dynamic connections for
that user.
See how XTV, spreadsheet etc can be launched.