Ok, not a really easy way of doing this but it is possible? I have been told absolutly this must be done without using virtual machines. It does not matter how difficult it is, does not matter how complex the changes to compoinent names or changes to orchestrations, I MUST find a way to support four environments on a single machine without using virtual machines. Any idea?
Perhaps even more details.
We have a WebSphere Application Server running our primary application. This WAS is configured to talk to a queue manager running on UNIX. This queue manager (IBM WebSphere MQ) can handle request/reply where the application send request, saves MsgId and reads the proper response via the Correl Id. If this was all there was too it, I would be fine. But there are two other interfaces where the application on the WAS cannot know if the response is thiers. One process sends request but since there is not a user waiting at a web screen, the sending process ignores any responses, it leave another application to sit there read ANY message that shows and processes it. Since our INT and QT WAS applications are currently being fed by a single BizTalk instance, any response of this type can be read by either. So if the Integration people initiate a request, the QA environment may read the response and process it even though they did not generate it.
If I had two BizTalk instances, running on two computers or in two virtual machines, each could load the exact same code, talk to two different queue managers. So INT and QT are isolated and when one sends a request, it will go o different BizTalk servers which are configured to talk to their queue manager only. We would have a INT WAS, INT queue manager, and INT BizTalk server. We would have a QT WAS, QT queue manager, and a QT BizTalk server.
But we have only one BizTalk server and can only run one BizTalk server, no tricks like virtual machines due to license issues. So if I could find a say to deploy our code multiple times on the same server, I could configure each instance to talk to a different queue manager as if they were on different servers. It would be like loading Application A and Application B which is done all the time but in this case, A and B have the same orchestrations, same schema, same assemblies, etc.
Initally I tried the following.
Use BizTalkApplicationServer as the default Host Instance. I did a regular deplay and it worked. I then created a second Host Instance, set this up as the default and tried a deploy with no changes. Unfortunatly, the send ports are not associated with a particular Host Instance, receive locations are tied to a Host Instance but send ports are not. Also the various assembles are not associated with a specific Host Instance. So when the second deploy is attempted, I get error messages about assemblies already deployed and the deploy fails.
Now I am trying to alter the assembly names and just the assembly names. I hope this will allow the assembles, containing the same stuff but with different names to coexist in the mysterious common area that is not part of the Host Instance. I have run into a few errors that I am trying to resolve. Unfortunatly I believe this will also prove to be a dead end.
I suspect I will have to treat every single step of the configuration path as a different application just as if I were to load a BizTalk application from Company A and a different BizTalk application from Company B. I am afraid this will require renaming most if not all components, make changes to Orchestrations that reference these componetns, and who knows what other changes. So after the Integration testers complete thier tests, I would have to rename everything, make extensive changes to various orchestrations and custom pipelines and then recompile what is basically an entirely different applicaiton. Kinda defeats the purpose of Integration testing if the QT testers get different code. Not to mention Customer Testing and Production each getting a "different" application.
Figure this is as confusing as my other attempts, hope it kept you entertained at least.