About MagmaForwardingProxys
Last updated at 10:11 pm UTC on 12 December 2005
A single Magma repository permits collaboration of a large, centralized domain model. While there is still no easy way to selectively replicate objects from other repositories it is possible to save a "bookmark" to any object in another repository. This bookmark offers high transparency by way of a forwarding proxy (MagmaForwardingProxy). Provoked with a message, this proxy "bookmark" will automatically connect to the other repository, establish a connection, retrieve the object, forward the message and give back the response. The result is then cached so that future sends will be quick and the remote repositories model may be traversed from there.
If the other repository cannot be connected, a MagmaOfflineObject will be returned. This object is just a temporary dead-end placeholder for the result once the other repository is able to be connected. When your network situation changes, send #retry to the MagmaOfflineObject and the original message will be sent to the forwarding-proxy. This time, a connection will be made and the offline-object will "become" the result of the having sent the message.
Natural domain partitioning
This features also facilitates domain partitioning.
How to create the proxy
Creating a bookmark to a foreign object is a snap:
someObject asMagmaForwardingProxy
Magma is able to find the session someObject belongs to and gives you back a MagmaForwardingProxy that you then attach somewhere to your domain model. This is the "bridge" from your repository to the other. You may, for the most part, treat the proxy as the actual object, it will create a session and ensure a connection to its originating repository, then cache the actual object and forward the message.
Offline portions of the distributed domain model
When a forwarding-proxy is agitated with a message but a connection cannot be made, the message will answer a MagmaOfflineObject. This is a stand-in for the result of the message send which can be represented in a UI framework such as Maui to indicate to the user that the object is currently unavailable. Later, after their network situation changes, they may press a button, #retry, to retry the message send. If it succeeds, all MagmaOfflineObjects originated from this proxy will be sent the message they were unable to send before. The desired UI effect is that the object will suddenly "populate" with the valid data.
See it in action
All of this is demonstrated by the method, MagmaTestCase>>#testAutoConnectingForwardingProxy.
What if repositories move?
The user must maintain their MagmaLocations by simply commiting a change to them (ip and port). Since these MagmaLocation objects are shared, a particular location should only need to be updated in one place when a repository moves.
The foundation for peer-to-peer model sharing
These new fowarding proxy's are the foundation for maintaining your own personal objects while simultaneously sharing them with others. You may run your own MagmaSession in the same image as your MagmaServerConsole and the server will see you as just another client.
Exceptional circumstances
If an object is de-referenced from the main root, it will continue to be accessible from its ForwardingProxy's as long as the file is not compressed with MagmaCompressor. After that time, however, it will no longer be available and a MagmaInvalidOid will be signaled.