Dot Net Dunk

Wandering in the land of .NET
posts - 42, comments - 22, trackbacks - 187

My Links

News

Archives

Post Categories

Blog Roll

WSDL First and BizTalk

I've held off posting on the WSDL-first approach so far because I've been waiting for the tools to arrive to make my gripes go away. Well, I'm still waiting... and waiting...

In the BizTalk world, we already have a Service Oriented mindset. We communicate in terms of schema-defined documents; we offer up services not APIs. We want to be interoperable with as many people as possible. I don't care whether you're using Java, .NET or ARM assembler - if you can send me a soap message, I'll talk to you. The trouble is that the .NET world approaches web services from a very object-y view point. Just pop a [WebMethod] in your asmx page and let ASP.NET create you some WSDL describing your objects. Easy, right, for people who want to knock up a quick web service in code?

The trouble is this promotes a very code-first approach. This really sucks from a BizTalk developer's point of view. I already have my schemas. I know the shape of the messages I want to receive. Where's the support for the Schema- and WSDL-first approach? The "publish orchestration" wizard seems ropey - a colleague today ended up with unusable WSDL just because he'd used an xs:import in his schema. Besides, I don't want a "publish orchestration" wizard, I want a WSDL designer with "create BizTalk orchestration template" and "import BizTalk definitions" options.

How about BizTalk's support for consuming web services? If I add a reference to a Web Service, I want the types defined in that WSDL added as first-class schemas in my BizTalk solution, not hidden under MyWebReference\Reference1.xsd. I want support for promoting properties out of the web reference - just remembering them if I refresh the web reference would be nice. Even worse, if I already have those schemas included in my solution please don't create a duplicate copy of the schema - share the reference (.NET 2.0 has an enhancement to WSDL.exe that may support this, I believe).

For the record, I am very much in favour of WSDL first. I just think there's an awful lot of pain to get it working in anything but the most simple cases. Let's hope Microsoft's new Domain Specific Languages designers lead to some WSDL designers pronto. XML Spy looks nice, but it's damned expensive!

This hasn't been a very structured post, for which I apologise, but I'd love to hear from anyone else who has found any silver bullets for BizTalk and WSDL-first...

Print | posted on Tuesday, November 09, 2004 5:38 PM | Filed Under [ BizTalk Server C#/.NET Development ]

Feedback

Gravatar

# re: WSDL First and BizTalk

Hi Christian... Thanks for the links.

I've been following your series of articles... Very interesting... Impressed at how much you are stretching out the series ;-)

Keep on blogging ... if we make enough noise hopefully enough people will get the WSDL-first message :-) Hopefully I'll have some bench time in December and I'll get to have a play with all the latest WSDL-first tools.
11/16/2004 10:17 PM | Duncan Millard
Gravatar

# re: WSDL First and BizTalk

Totally agree – SOA is all about isolating and separating consumption of business services from the provision of those services though a commonly defined and accepted service contact.

As a solution architect, I want to follow Contact First service development (define data and message xsd schemes>create WSDL contact>provision server). However, the automated tool sets currently available do not fully support this approach. So the trade off is we either compromise on design principles and use available tool for productivity; or we manual plug the gaps between contact first artefacts and implementation.
9/21/2007 4:13 AM | John

Post Comment

Title  
Name  
Email
Url
Comment   
Please add 1 and 7 and type the answer here:

Powered by: