Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Introducing Contract First : Page 5

Many publications and blogs consider Web services to be the silver bullet because they are so easy to implement in .NET and interoperate with disconnected systems. But are people really using Web services the way they should be used?


advertisement
Creating Client Code
For the sake of a complete overview of the sample scenario in this article, it will help to also take a look at the Windows Forms client application. All in all things look quite similar on the client compared to the Web service itself. The same class files get generated except that you now have a WebServiceProxy instead of a WebService type, but this is an obvious difference. Likewise, you can easily write code that has a sample call to your Web service on the other side. The following snippet shows how to create a message-oriented call to the service's GetMemberData operation.

DotnetUserGroup svc = new DotnetUserGroup(); svc.Url = "http://localhost/WSCFWalkthroughService/" + "WebService.asmx"; GetMemberDataRequest req = new GetMemberDataRequest("42"); GetMemberDataResponse result = svc.GetMemberData(req); propertyGrid1.SelectedObject = result.MemberInfo;

 
Figure 11: Sample Windows Forms consumer application with data binding.
Did you notice the last line? The result data object is directly bound to a Windows Forms PropertyGrid control (see Figure 11)—you didn't have to manually hack anything. This is possible because WSCF offers all the necessary attribute glue for it if you enable the appropriate code generation option.

Another interesting point to discuss about the client is the ability to get read-only access to the SOAP request and response messages. It's not a big deal and there are few people who will ever need it, but I've heard of customers who complained that this feature was missing in the original .NET Framework implementation.

Now you're done with your application scenario. You've modeled your data and your messages to exchange with XSD. Afterwards you took WSCF's WSDL Wizard to hammer down the service interface contract. The tool abstracts from the nitty-gritty details of WSDL and aids in creating an interoperable WSDL. Finally, you provided the respective developers with the necessary metadata and they could get along with WSCF's code generation feature to create code from the XSDs and the WSDL—in a much more enhanced fashion than it is currently available in the .NET Framework SDK and Visual Studio .NET.

Refine the Contract
But honestly, there is never just one shot. You never make everything just right the first time. Therefore it is indispensable to provide a round-tripping functionality for WSDL interface descriptions. Just imagine you've forgotten to add an operation for enumerating all registered members. This means that you need to add the ListAllMembers
 
Figure 12: Editing an existing WSDL and revisiting the Web service interface.
operation to the interface. And surely you want to leverage the WSDL Wizard one more time. When you right-click the WSDL file you'll see another entry called "Edit WSDL Interface Description..." (see Figure 12). The wizard starts and pre-populates the pages with the metadata from the WSDL. From now on you can change about anything you like, including adding and removing operations and changing the mapping of operations and message types. It remains to say that WSCF does not support any style of WSDL out there in the wild, but rather can just handle WSDL descriptions that follow the same rules as those WSDL files generated by the wizard itself. That's it: a complete contract-first design and development lifecycle.

Wrap-Up
What did you think about Web services as described by this article? Sure, this is just one valid point of view. You can still think and act in an RPC-fashioned manner, no problem. But when you are serious about interoperability and integration, I think you should at least take a look at contract-first design and development when it comes to Web services.

We are heading slowly towards maturing the Web services specs and features. Microsoft's Indigo run time and programming model will provide us with some very rich and powerful features for building distributed systems, especially those that focus on the Web services world. With contract-first-based ideas you're also well placed for the near future. Indigo has the concept of a data, message, and interface contract. These concepts should by now be quite familiar to you. So the future is bright, start to use it now.

This article was written with a beta version of WSCF 0.5; however, the final version should be available for download by the time you read this article. If you have any questions, problems or suggestions regarding contract-first design and development, please do not hesitate to contact me.



Christian Weyeris co-founder of thinktecture, a company that helps software architects and developers to build projects with .NET and distributed applications technologies. He is a recognized XML, Web services, and service-orientation expert. As a Microsoft MVP for Solution Architecture and one of the few independent Microsoft Regional Directors, he has made a name for himself in the developers and architects community. He has worked for many years with Microsoft technologies like COM/DCOM, COM+ and .NET. Christian has spoken at many well-known developer conferences and forums worldwide and is a published author, editor, and writer of numerous articles for various German and international technical magazines. Visit his Weblog to find out more about Web services and service-oriented integration and programming, not just on the .NET platform.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date