Note: I am NOT talking about VSS, PVCS, etc.
Was curious if anyone had any input on devising a strategy for versioning the code. Below is a fictious example. I am not positive how the elements will interact exactly, just curious about creating versions of the code.
Documents are created based on the current business rules. A team would create documents that would be version 1.0 and the date it should be processed, then dropped in a queue/drop box. Down the road, documents are created with version 2.0 and the date they should be processed, then dropped in a queue/drop box… Version 1.0 and 2.0 are similar, but have different business rules and will handle the documents slightly differently. In the future, the versions could theoritically be infinite.
Additionally, the document receivers (WSDLS/XSDs) could change per version, either adding to or subtracting from the data being passed in. We would also likely need to version these as well.
A service would run to get all the documents with the current date, then based on the version that is requested, process the document with that version of the code. There could potentially be versioning for not only the top level services, but also the child services as well. We could theoritically have released 25 versions of the code when there is still a version 1.0 that needs to be processed.
Since creating a seperate set of packages for each version would eventually load 100s of packages on the server, this isn’t an ideal solution.
Anyone have any thoughts on some potential strategies to do this?
Best approach I’ve found with this is to build in version information in the header of your canonical document formats. That way you can use a dispatcher type architecture to re-route the documents to the correct code.
TN will also work quite well if it is used as the entry point into your system. The TN Document type will be defined to identify document X by looking at the document type field in the header AND the version number in the header. That way you don’t necessarily need a new package for each “version”, that part can be up to you.
You might find a multi-dispatcher type of approach would work too, you do your initial dispatch and then along the way you might do further dispatching based on the version number?
Hope that gives you some ideas,
Nathan
Thanks Nathan. I had considered using the canonical, but since we are doing A2A transactions vs. B2B transactions, the canonical model doesn’t fit as well as it would in a B2B setting. Basically our canonical would have to include around 1000 elements, that would seriously hurt performance.
TN was considered briefly, but since the inbound calls are typically web services, that doesn’t make sense.
We have made some general recommendations that I wanted to share…
-Web services are versioned, along with each top level service. If a client calls WSDL version 1, it follows version 1 path through the code.
-Code is developed as a true SOA, where the top level service (web service) handles the calls to the lower level service. The lower level elements will not have children, or only children that would do things such as formatting, etc.
-For new versions, the old services are called unless a change is required, in which case a new service is created and called for only the new version.
-There could be dynamic elements involved in the calling of services, or using wM Modeler, but that will make the code a little less readable.