Jan Schreuder on .Net

.Net code samples, experiences, observations

View my professional profile on LinkedIn

Recent Posts

Tags

News

  • Inappropriate comments will be deleted at my discretion.

    The information and code samples in this weblog is provided "AS IS" without warranty of any kind, either expressed or implied, including but not limited to the merchantability and/or fitness for a particular purpose.

Community

Email Notifications

Tool suppliers

Tools

General

Microsoft

Favorite blogs

Archives

TechEd - Proven Practices for Implementing Services

What promised to be a session where proven practices for implementing services would be presented, turned out to be more of a session about the impact of migrating from ASMX webservices to WCF webservices.

Migrating ASMX to WCF is not that difficult. It is possible to keep the ASMX service operational while adding WCF specific attributes to the code. This allows you to test both versions and make sure that your WCF version works the same as your ASMX code. When you're done, simply remove the ASMX stuff (such as [WebMethod]) and you have a WCF service.

The presenters (Beat Schwegler, Architect and Don Smith, Service Factory product Manager) demonstrated how easy implementing a webservice is when using the Service Factory. A lot of the infrastructure for a service is generated automatically. So most of what you need to do is implementing the interfaces and business logic. The demo proved this by building a webservice to do some simple math in less than 10 minutes. The service factory for ASMX is already available, the one for WCF will be made available mid-December.

The Loosy-Goosy problem was explained including a way to get rid of it. Loosy-Goosy is the effect where the soapmessage that reaches your webservice does not contain all the arguments for your webmethod. In general, the method will not fail but simply return a result you do not expect. Consider the following method: public int Add(int a, int b). When the soap method does not include a value for a or b, you will not get an error when you call the method. You will just get a result. You can solve this by changing it to the following: public nullable<int> Add(nullable<int> a, nullable<int> b).

A better option to pass data to a service is to use Request and Response messages. All methods then have one argument, the response message, and all return a response message. These messages can be stored, logged, validated and re-used. Which is not possible with method arguments.

Comments

Dennis van der Stelt said:

For the soap thingy, these are called DataContracts where you can specifiy what's required (mandatory) and what not. Check out the following piece of code. [DataContract(Name="ShoppingCart")] public class ShoppingCart {     [DataMember(IsRequired=true)]     Customer customer;       [DataMember(Name="ItemsInCart")]     int? items;        } int? I prefer over nullable :)
# November 9, 2006 4:24 AM
Leave a Comment

(required) 

(required) 

(optional)

(required) 


Please add 1 and 4 and type the answer here: