WCF CollectionDataContract and DataMember attributes

We often use the WCF CollectionDataContract on a data contract so that the latter is generated as a collection (and not as an array) in the WCF Service proxy.

One day, I tried to define a data member inside a CollectionDataContract. Strangely, the data member was not generated in my proxy. It seemed that was not possible with WCF 3.0 (http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2413798&SiteID=1)

[CollectionDataContract(...)]
public class MyCollectionDataContract : List
{
...
[DataMember(..)]
public string MyDataMember
{
...
}
}

The MyDataMember was not generated in the MyCollectionDataContract in the proxy.

Localizing error messages in client applications in SOA

Localizing error messages in a client application in a Service Oriented Architecture (SOA) might be a difficult task especially if you don't have control on the available services. Technical or functional errors might be returned in the form of text to client applications. Now, if these applications take these raw error messages and display them to their users, we'll have a strong dependency on the language used by the services and the client applications.

Services in an SOA do not need to worry about presentation logic. Instead, they are here to solve technical or business problems. It is the responsibility of client applications to translate results/errors returned by these services before presenting them to their users.

Let's take the example of a french application using a web service which returns its error messages in english. It would not be very appropriate to display english messages to french users. To solve this problem, we could have translations of all possible error messages on the client side, which we will display according to the error returned by the web service.

Here we have another problem. While doing error handling, we often test some conditions/exceptions to determine whether or not, we have an error. Testing for long text strings representing errors is a bad idea as we will have a strong dependency on the service error naming convention. If for example, on the service side, we change a word in the error message, there will be a mismatch on the client side, and consequently, we will not display the correct translated message in the client application.

One possible solution could be a scenario where the service returns error codes to its clients. Each of these error codes would indicate one type of error. Of course, both the client and the service, must agree on the semantics of these. Using this solution and in case of errors, client applications will first search the error message corresponding to the received error code from a resource file before displaying them to their users.