Does anybody have any innovate ways to document your customized IDL-XML mapping parameters. I could create yet another document that noone looks at…
We are exposing Natural modules through EntireX and my clients are complaining about the cryptic SOAP actions (8-character NATURAL subprogram names). Instead of XMDUOSN they’d prefer UpdateOrderStatus, etc. I understand how to alias the name, but my concern is how to document this so a future programmer can generate the same mapping that I did originally.
Between programmers having different defaults in Workbench and ideas about naming conventions and suppression, I invision a real mess in the near future.
I think this is good example where a best practice will help you to address this problem. The Web Service related artifacts (IDL, IDL properties, SOAP/XML Mapping file, and WSDL) should be stored in a central repository. As a start you can use CVS, but I think that a Services Repository would be the best approach to solve this problem. The services repository should allow you not only to store all the artifacts, but additional information such as documentation, comments and metadata related to the Web Services as well.
This will allow the developers to go to one location to find the latest artifacts related to the Web Service they are working with. They can check everything out as needed, which potentially will include steps how to maintain the IDL file and what should remain unchanged.
Once the developers is done with their maintenance of the Web Service, then can then check the artifacts back into the repository, thus creating new versions, etc.
Software AG is doing work on such a Services Repository right now. It is called the IMR or Integration Metadata Repository. In the current version it provides a WebDAV interface, with versioning, etc. Plus it allows you to publish the Web Services via the UDDI interface. The next release which is slated for early next year should provide a number of important features and improvements. The plan is to have the products that create and consume Web Services integrated with the IMR. You can expect to see and hear more about this in the near future.