Prime Radiant Replication
The Prime Radiant is just another NS application, able to be be regenerated or rejuvenated, and distinguishing the four dimensions of evolvability: the model, the skeleton, the utilities, and the craftings. However, as the Prime Radiant is regenerating itself, one has to be careful in this process of self-replication.
Extending the Run-Time Model
As in any application, the model can be extended. In the case of Projections, one could for instance add an attribute to the DataProjection data element, or introduce an additional data element DataTransferProjection to represent projections consisting of value objects that are suitable for data transfer in distributed applications. As such a DataTransferProjection is clearly confined to the context of a data element, we also define it as a DataChild of the DataElement data element.
Now, we simply expand or regenerate our Prime Radiant in the same technology settings it is currently deployed on our computer, and build it. As the simultaneous deployment of different replications of the Prime Radiant is currently not supported, unlike regular NS applications, we still have to perform an explicit
copy of the
primeRadiant.ear archive from the
apps directory to the
deploy directory in the application server
BASE. A simple restart of the Prime Radiant, not even necessary if you feel comfortable with a hot deployment, suffices to present us a brand new Prime Radiant with an extended metamodel.
It will often be desirable to develop some additional custom user interface code to support the extension of the model. In the case of a new DataTransferProjection data element, simply defining it as a DataChild of DataElement, will give us appropriate access in the Components screen of the Prime Radiant user interface.
Extending the Transfer Objects
In order to enable the import and export of the model extensions, the client code of elementsio and nsx-prime need have access to the newly extended versions of the shared and proxy layer archives of the elements component:
elements-proxy.jar. These archives have been created, and copied to the
BASE directory of the Prime Radiant deploy base, during the build of the Prime Radiant.
For run-time operations, They need to be made available to the elementsio and nsx-prime repositories by putting them, with the appropriate version number, in the root of the
nsx-prime repository. For compiling code extensions in elementsio, we
Now, we are able to extend the aggregate classes of elementsio to support the model extensions. We therefore create the class n.d.elements.model.DataTransferProjectionAggregate and implement the class n.d.elements.model.DataTransferProjectionAggregateBuilder in the elementsio repository. Of course, these aggregate objects need to be embedded in and passed through the n.d.elements.model.DataElementAggregate, using the n.d.elements.model.DataElementAggregateBuilder. We should not forget to retrieve the agent n.d.elements.DataTransferProjectionAgent of the new element in the n.d.elements.context.Context.
Supporting the Import & Export
We need to support the extended metamodel in the XML import and export as well. Therefore, we need to implement an importer class n.d.elements.importer.DataProjectionXmlImporter, and an exporter class n.d.elements.export.DataProjectionXmlExporter (TBD). These classes need to be activated in the n.d.elements.importer.DataElementXmlImporter and n.d.elements.import.DataElementXmlExporter as well.
Providing Access to Expanders
Then, we are able to pass these model extensions through nsx-prime to the expanders. For the data transfer projections, we need to implement a class n.d.elements.ModelFromTransferProjectionClient (TBD) of the nsx-prime repository to create an instance of the descriptor class n.d.descriptor.TransferProjectionDescriptor of the expanders repository. These descriptors need to be inserted into the data element descriptor n.d.descriptor.DataDescriptor by the n.d.elements.ModelFromDataElementClient of the nsx-prime repository, retrieving and passing the n.d.elements.model.DataTransferProjection classes.
The ModelToTransferProjectionClient does not need to be implemented, as the ModelTo classes were only necessary in the past to import the old descriptor files, which were read by the expanders classes into the Prime Radiant.