We were recently asked by a GuardIEn customer whether they could use our XOS (External Object Support) add-on to manage the generated WSDL/XSL files so that as they promoted a change through the life-cycle, these files could be 'migrated' to the next environment along with the object migration of the procedure steps.
Whilst this would have been possible, it raised an interesting point about whether generated code should be copied between environments or re-generated from the model in the next environment,
I don't think it is a good idea to copy the generated source code from an uncontrolled environment like the first development model. The reason for this is that the state of the model and in particular the synchronisation between the model and the generated code is difficult to establish. This is especially true for code generated from the toolset, since it could be generated without uploading the changes to the encyclopaedia, or the model could be changed without re-generating the code.
At IET we recommend that the Gen objects are migrated to the next environment's model(s) as part of a controlled 'system update'. When using GuardIEn, the automated impact analysis will ensure that all of the code affected by the migrated objects is regenerated and installed. Generating direct from the encyclopaedia ensures that the model and generated code are synchronised.
A further complication arises because the web service definition can contain interfaces to multiple procedure steps. The wsdl and xsl files are tied to the import and export views for the procedure step and need to be regenerated when the procedure step's interface changes. What happens if you have a web service for multiple procedure steps, change the interface to two or more of them and then only migrate one of the changed procedure steps to the next environment? If you copy the entire web service, the result is that interface definitions in the web service do not match the view structure for the procedure steps in the next environment.
It therefore seemed a bad idea to copy the generated wsdl/xsl files from the toolset and the same principle of re-generating code from a stable model should be adopted. The problem though was that the web service generation feature of CA Gen was only available from Gen Studio and not the encyclopaedia generation.
In consultation with the customer, we decided that the best approach would be to develop a new web service generation feature in GuardIEn so that the web services could be properly managed via re-generation from the model as part of a GuardIEn system update. This new feature is now available in the latest service packs released yesterday.