Behavior of BizTalk WCF Publishing Wizard When Creating Multiple Operations or Services at Once

So what happens when you create a few operations or services during a single instance of the BizTalk WCF Service Publishing wizard?  What types of web service projects and BizTalk messaging configurations get produced?  I was messing around with this the other day, and thought I’d quickly show the output.  Maybe this is common knowledge, but I hadn’t tried all these scenarios before.

Let’s assume you have a schema to use for the wizard, and a BizTalk application to hold the generated ports.  In this first scenario, I’m creating two operations for the single service.  I started out the wizard by saying that I wanted my receive locations (notice that “locations” is plural here) in a particular BizTalk application.

2010.10.22.wizard01

I then decided to build a service from existing schemas instead of an orchestration.  I’ve created two one-way service operations on the root service.

2010.10.22.wizard02

I accept the rest of the wizard’s default values and complete this wizard instance.   The first thing that I end up with is a web service application in IIS that contains a single service file.

2010.10.22.wizard03

When I browse that service, I can clearly see in its metadata that there are two operations available for consumption.

2010.10.22.wizard05

On the BizTalk side, the application has a single new receive port and a single receive location that points to my web service.

2010.10.22.wizard04

In my next run through the wizard, I’ve once again selected to have a metadata endpoint enabled and to put my receive locations in a particular BizTalk application.  I’ve also chosen to build my services from schemas.  In this case, I’ve created two services, each with a single one-way operation underneath.

2010.10.22.wizard06

With all the other default values selected (but using a different output service location), I completed the wizard.  As you’d probably expect, my generated web service application now has two services within it.

2010.10.22.wizard07

The generated BizTalk output surprised me slightly.  What I ended up with where a distinct receive port and receive location for each service.  I was expecting to have a single receive port with two locations.  I could see why they’d have to be different if the exchange pattern (two-way vs. one-way) was different for the services, but both of my services are one-way, and could theoretically live fine in the same receive port.

2010.10.22.wizard08

I can only guess that the reason for doing this is because folks could use the single wizard instance to build completely unrelated services while trying to save the time of opening a new wizard for each new service.

To be thorough, let’s compare this against a multi-operation orchestration-generated service.  I’ve built an orchestration that has two (public) receive ports.

2010.10.22.wizard09

After deploying this and starting the BizTalk WCF Service Publishing Wizard again, I chose to build a service from an orchestration.  Here I get a different interface and both of my public ports are shown.  I’ve NOT selected the “merge ports into a single service” option for this pass through the wizard.

2010.10.22.wizard10

With the wizard complete, I confirmed that I have a web service application with two services, and a BizTalk application containing two receive ports, each with a single receive location.

In my last pass through the wizard, I’ve again chosen to build a service from an orchestration and chose to merge my selected ports.    I have to change my orchestration itself before I proceed since my orchestration used the default Operation_1 operation name for each port and I get an error from the wizard saying that I cannot merge the operation because of the name collision.  After dealing with that unpleasantness, I completed the wizard instance with my ports merged.

What did I get?  I have a single service in my IIS web application.  and a single receive port with a single receive location in my BizTalk application.

The wizard works consistently whether you are building services from schemas or orchestrations.   It’d be great if you had a choice to merge ports from a BizTalk messaging sense in addition to the orchestration sense, but such is life.

Do any of you use the wizard to build up a whole set of services at once, or do you typically fly through it for each individual service?

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.

7 thoughts

  1. My curiosity is, does it support RESTful services instead of just the SOAP ones? I’ve always been intrigued by BizTalk but never had the chance to work with it before.

  2. I usually use the wizard to build up a whole set of services at once so I end up with a single *.svc file. Usually the people building the clients prefer this so they can generate their proxy classes in one shot.

    Speaking of which, does 2010 save off your wizard choices so you can quickly walk through it again in the future? For example, if you want to leave in place what you’ve got and just add another service?

      1. You can’t just run the BtsWcfServicePublishingWizard from the Visual Studio Command Prompt like below? It does forget the namespace, but remembers everything else.
        BtsWcfServicePublishingWizard.exe -WcfServiceDescription=\WcfServiceDescription.xml

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.