Metadata Handling in BizTalk Server 2010 AppFabric Connect for Services

Microsoft just announced the new BizTalk Server 2010 AppFabric Connect for Services which is a set of tools used to expose BizTalk services to the cloud.  Specifically, you can expose BizTalk endpoints and LOB adapter endpoints to the Azure Service Bus.

The blog post linked to above has a good overview, but seemed to leave out a lot of details.  So, I downloaded, installed and walked through some scenarios and thought I’d share some findings.  Specifically, I want to show how service metadata for BizTalk endpoints is exposed to cloud consumers. This has been a tricky thing up until now since AppFabric endpoints don’t respect the WCF metadataBehavior so you couldn’t just expose BizTalk receive location metadata without some slight of hand.  I’ve shown previously how you could just handcraft a WSDL and use it in the port and with Azure clients, but that’s a suboptimal solution.

First off, I built a simple schema that I will expose as a web service.

Next up, I started the BizTalk WCF Service Publishing Wizard and noticed the new wording that came with installing the BizTalk Server 2010 Feature Pack.

Interesting.  Next up, I’m asked about creating my on-premises service endpoint and optionally, a receive location and a new on-premise metadata exchange point.

On the next wizard page, I’m able to optionally choose to extend this service to the Azure AppFabric cloud.

After this, I choose whether to expose an orchestration or schemas as a web service.  I chose to expose schemas as a service (i.e., build a service from scratch vs. using orchestration ports and messages to auto-produce a service).

As you can see, I have a one-way service to publish order messages.  Following this screen is the same “choose an on-premises location” page where you set the IIS directory for the new service.

After this wizard page is a new one where you set up a Service Bus endpoint.  You pick which Service Bus binding that you want and apply your own service namespace.  You can then choose to enable both a discovery behavior and a metadata exchange behavior.

Finally, we apply our Service Bus credentials for listening to the cloud.  Notice that I force authentication for the service endpoint itself, but not the metadata retrieval.

After the wizard is done, what I expected to see was a set of receive locations.  However, the only receive location that I have is the one using the on-premises WCF binding.

What the what?  I expected to see a receive location that used the Service Bus binding.  So what happened to all those configuration values I just set?  If you open up the WCF service created in IIS, you can see a whole host of Service Bus configuration settings.   First, we see that there are now three service endpoints.  The three service endpoints below include an on-premises MEX endpoint, a RelayEndpoint that binds to the cloud, and a MEX endpoint that binds to the cloud.

That’s a pretty smart way to go.  Instead of trying to hack up the receive location, Microsoft instead beefed up the proxy services to do all the cloud binding.

I can use IIS 7.5 autostart to make sure that my cloud binding occurs as soon as the service starts (vs. waiting for the first invocation).  Once my receive location and service are started, I can hit my local service, and, see my service is also in my cloud registry.

If I drill into my service, I can also see my primary service and my MEX endpoint.

 

When I click the primary service name in the Azure AppFabric registry, I get an HTTP 401 (unauthorized) error which makes sense since we have a client authentication requirement on this service. 

If I click the MEX endpoint, I get a weird error.  I seem to recall that you can’t retrieve a MEX WSDL over HTTP.  Or maybe I’m crazy.  But, to test that my MEX endpoint really works, I plugged the MEX URL into an Add Service Reference window in Visual Studio.NET, and sure enough, it pulls back the metadata for my BizTalk-exposed service.

All that said, this looks really promising.  Seems like a smart decision to stay away from the receive location and move cloud configuration to the WCF service where it belongs.