Monish Nagisetty's Space

Building connectivity on-premise, in the cloud and beyond

BizTalk WSE Web Service Publishing Wizard woes

BizTalk provides a great way to expose orchestrations to the outside world through web services.  In fact, the SDK provides the BizTalk Web Service Publishing Wizard which generates web service code and even the IIS virtual directory.  If you are using WSE 2.0 as one of your adapters then you can use the BizTalk WSE Web Publishing Wizard.  The following article is very helpful in walking through all the steps required to create a web service with WSE:  Walkthrough for BizTalk Adapter for Web Services Enhancements 2.0

So it may be apparent that workflows can easily be exposed through web services to third parties as long as you follow proper contract first design (more on this later).

My recent contention with the WSE WS Publishing Wizard is that it creates a copy of all the schema definitions and places them in a xsd folder underneath the web service project directory.  I have some serious problems with this because it inhibits the developer from simplyfying deployment.  In other words, every time I make any changes to the BizTalk schemas I have to deploy the schemas to the BizTalk database and also rerun the WS Publishing Wizard.  Why does the xsd folder need to exist anyways? Upon some researching, I found out that the xsd folder and the schemas need to exist in order to generate proper WSDL with all the schema information.  Otherwise the WSDL will just contain part type definitions and your web service subscribers will not be able to generate useful proxy classes.

So why can’t the web service dynamically load the deployed schema assembly? Not sure, Microsoft needs to improve this in BizTalk 2006.  So I decided to use the Reflector for .NET to investigate the Microsoft.BizTalk.Wse assembly and see why the BizTalk team created such a strong binding between the xsd files and WSDL generation.  Turns out that the Microsoft.BizTalk.Wse.WseTransport.WsdlHelper class contains the method AddSchema(ServiceDescription, BizTalkPartTypeAttribute, String) : Boolean with implementation to read the xsd files and embed them in the WSDL.

The following line of code assembles the filename to look for within the xsd folder:
string text1 = attribute.TypeName + “, ” + attribute.AssemblyName +”.xsd”;

The attribute information above is carried in from the BizTalkPartTypeAttribute in the web service code.

For example the following attribute declaration:

[WebMethod()]
public void DoTaxCalculation([BizTalkPartTypeAttribute(TypeName=”XYZCompany.BTServer.SalesTax”, Assembly=”XYZCompany.BTServer”] SoapEnvelope request) {}

results in the WsdlHelper class to look for the following xsd file:
XYZCompany.BTServer.SalesTax, XYZCompany.BTServer.xsd

So far I have not found a workaround for this.  Post here if you find something.

Advertisements

July 5, 2005 - Posted by | BizTalk, Web Services | ,

No comments yet.

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: