From the aspect type, a full „bean-like” interface source can be generated, and so this instance will be returned on request. The type restrictions can fully apply here. Behind the interface, a generated mapper code exists that can 1: using the generated constants it can call the generic data access/message sending
Messages: messageID is mandatory; additional parameter type optional; if present, providing a message entity with that aspect is required. Question: id is globally unique OR I can use the same id for multiple entry points with different type parameter?
From the user perspective, the message ID identifies the required service – and that is independent of the actual parameter; and anyways, practically ANY instance can be thrown on that message if it contains the required aspect. On the other hand, the message processor should be different for the different content, because the incoming parameter data has to be handled differently, though there were shared codes for the actual function.
Result: there can be multiple incoming parameter declarations for the same message IDs. The caller may send any of those parameters to the same service – actually the caller does not see the entity, only the aspect with the required type. The message processor can also be declared with the same interface…
So: the proxy implements both interfaces: provide a bean-like typed access to the local data; the referred linked entities (DATA), and the functions that can be called (SERVICE). On the service side, the user code has to implement the SERVICE interface, and has access to the wrapped DATA instance, handled by the framework.
The proxy object itself is an “aspect” instance, with direct access into the access implementation code, that is the actual executor of the proxy wrapping calls (local, no more dispatching). The same applies to the message service interface: that is linked to the dispatcher implementation. This instance is also passed to the working code; it can send message to itself through the proxy object… There is a third component: the actual data area containing the instance data? NO: that is the entity instance that contains a “map” of aspect references connected to data content.
Preliminary idea - The dispatcher contains a tree: implementation / type / loaded business logic class. The lowest level is a Method ID. This ID is returned back to the caller in a map when resolving the message IDs; on actual calls these IDs are referred to, and the actual methods are called after the proper administration. REMEMBER: this dispatcher is STATIC, able only to resolve the known type calls. Another level is responsible for loading new implementation packages, and yet another for parallel thread management. Perhaps additional aspects of the same entity… There is one problem: different implementations can coexist for the same type. The aspect statically refers to the type, but the instance (inside the Entity) may refer to other implementations. So when calling the method, two separate levels are required: the Entity for the actual implementation, and the aspect with the actual type. In this way, the Entity contains ONE ref ID to the implementation, and the Aspect knows the type IDs for the actual message identifier on the type level. Both IDs are required for calling an actual method. This looks good.
The other side does not look this complex: the memory management seems to be clear. The aspect knows its required fields. It passes to the memory manager that returns the offset for each member, and a reference in its config area. When creating an instance, this reference is used, the memory is allocated, and a block ID is returned. On data access, this block ID and the offset is required, the memory content is copied out or loaded into the memory manager area. NO direct access is allowed in the mem manager area. Here we have the locking issue, and also the configuration change features which are other aspects of the memory manager. By default it is only able to serve those instances that it already knows. The initialization is a bi-directional communication between the mem manager and the aspect instance.
