I recently had to do some work on a BizTalk application being developed on our project. Because of my experiences with the WSE adapter one of the tasks i needed to do was to configure all of the WSE stuff for this application. I came across the problem below.
Problem
I wanted to publish an orchestration as a web service using the WSE adapter web publishing wizard. The orchestration used .net messages as opposed to ones based on a schema. When i generated the web service the service was untyped, accepting and returning an XmlElement as parameters. This was not great as i wanted the web service to be strongly typed.
My requirements in terms of WSE were that i needed to secure the call to the web service, i did not need to do anything to the WSE stuff within BizTalk.
Work Around
As i say i did not have time to solve this properly (hopefully a future post will cover this) but i did manage to implement a cunning work around. I took the following steps:
1. Use the standard Web Service Publishing Wizard to generate the web services.
2. Setup the BizTalk port with the Soap Adapter
3. Copy as part of my build process a new config file (containing wse settings) and a WSE policy file to the web services directory
After this i needed to implement the policy to be able to call the web services.
Why Does This Work?
This works because the WSE dll is in the GAC and the new config file tells the web services to implement the policy. The only downside to this (an assumption, i have not looked into more detail yet) is that and WSE context properties would not be passed into BizTalk along with the message.
Conclusion
Ok so this is a hack, and i plan to do a POC to work out why this didnt work the way you would expect, but the key point here is that being pragmatic and creative (aka hacking) solved this problem in a slightly different way to allow us to still deliver this particular BizTalk application to the test teams on time.