UPDATE: I have since moved these articles to my own blog and they can be found here.
I just posted another article for TopXML.com as part of my series on BizTalk + WCF. This post covers the various ways to expose WCF services and endpoints out of BizTalk itself.
Topics include: exposing one-way services, working with services exposed via schemas or orchestrations, handling exceptions, generating MEX endpoints, hosting the WS-Http adapter in-process, using simple type service parameters, and using multi-part messages.
Technorati Tags: BizTalk, WCF
Author: Richard Seroter
Richard Seroter is Director of Developer Relations and Outbound Product Management at Google Cloud. He’s also an instructor at Pluralsight, a frequent public speaker, the author of multiple books on software design and development, and a former InfoQ.com editor plus former 12-time Microsoft MVP for cloud. As Director of Developer Relations and Outbound Product Management, Richard leads an organization of Google Cloud developer advocates, engineers, platform builders, and outbound product managers that help customers find success in their cloud journey. Richard maintains a regularly updated blog on topics of architecture and solution design and can be found on Twitter as @rseroter.
View all posts by Richard Seroter
Absolutely fantastic. Exactly the sort of information I was looking for.
Great stuff. It was really helpful.
We were trying to inprocess hosting for ws http binding.
We are not able to generate the contract and we get the ‘scheme already exists’ as you have rightly pointed out.
Can you please guide about How do we create stub WCF service using the BizTalk WCF Service Publishing Wizard? Any help is appreciated. Thanks
To add to the above question when we generated the stub hosted in IIS the cs file had only the data contract and did not have port specific methods. Were we missing something?
I cover this extensively in the book, so pick that up 😉
What you might want to do is take your in-process hosted receive location, add a metadata behavior, and set the externalmetadatalocation attribute to an externally defined WSDL of your own making. This way you can define the messages and opereations that you want to associate to the in-proc receive location.
It might take a few minutes to drum up the WSDL file, but it’s more flexible in the long run.
Thanks for your reply. I will definitely take your book.
Excellent article with well detailed examples.