The new metadata generation is one of the areas that present significant differences between the .NET 3.0 and BizTalk adapter frameworks. In a previous post I covered some of those differences from a conceptual standpoint. Ultimately, those differences are reflected in the tools available for developers for generating metadata at design time. If not, they are not relevant aren’t they?
In the current family of BizTalk Server adapters (like SAP or SQL) it is a common approach the use design time wizards to generate the metadata associated with a LOB application or technology. That metadata is generated by the adapter in the form of a WSDL definition. Adapter builders need to implement the interfaces for building and generating the WSDL. The wizards are just a mechanism used for collecting the parameters required for accessing the meta-information. In this case the only point of contact between the Adapter Framework and the adapter itself is the interface by which the framework requests the WSDL and the adapter kicks off the wizard, collects the info and generates the WSDL.
The fact that .NET 3.0 adapters are implemented as WCF bindings together with the new interfaces for Searching and Resolving metadata makes possible to unify the user experience for the metadata generation process. In other words; having built in mechanisms for querying, resolving and searching metadata makes possible to use the same set of wizards to generate the metadata.
Currently, there are two main approaches a BizTalk developer can use to generating design time metadata: the .NET Adapter Metadata wizard and the WCF-Custom adapter wizard. The first one gives the developer a lot of options for searching and resolving metadata and leverages of all the features of the .NET 3.0 adapter framework built on top of the WS-MetadataExchange WCF implementation. However the WCF-custom interface offers developers more control at the WCF level. Notice that the final output from both interfaces is going to be the same.
In order to generate metadata using the WCF-custom adapter wizard you first need to register your adapter binding in the Visual Studio configuration file.
<system.serviceModel> <client> <endpoint name="ssb" address="My base Url…" contract="IMetadataExchange" binding="ssbBinding" /> </client> </system.serviceModel> |
After that, the WCF-custom adapter wizard will show the adapter binding. Clicking Get will send a WS-MetadataExchange request to the adapter. All the required parameters for the operation are passed as part of the url.
Figure 1: WCF-Custom adapter metadata wizard
If you required a complex set of parameters in order to generate the url the Service Adapter Wizard will be more appropriated.
Figure 2: .NET 3.0 Adapter metadata wizard
Bottom line, both wizards will output the same WSDL. The adapter metadata wizard gives you a lot of more options in terms of performing extra operations against the metadata like: Removing or modifying operation definitions etc. At the end, somehow Microsoft has to keep the rule of giving the developers multiple options for achieving the same goal.