Web Services, Serialization and Interfaces

Hi,

I'm writing a Web Service layer. I would like to use interfaces to pass data in and out, this will allow the server and client to have different implementations and allow for example the DBA to change the database structure and server implementation without the client apps needing to change their implementation, but.... XmlSerializer can't serialize interfaces...

I don't want to have the same implementation on server and client, and using interfaces seems to be the "correct" way of doing this.

Has anyone encountered a solution to this problem I understand the reasoning behind XmlSerializer not being able to do this, but I can't understand why it shouldn't!

Any help would be greatly appreciated...

Kev

Answer this question

Web Services, Serialization and Interfaces

Guilherme Cestarolli Seleguim
Kev, I don't think interfaces are the "correct" way of doing this..... why .... because interfaces describes the behavior of the classes that implement it.

And here you should not have (or should not need) "behavior" description but "data" or information description.... right this is one of the tennets of SOA: "contracts"

So, data or information description is usually called metadata, and nowadays the most common flavor of metadata is expressed in XML.... so if you put it all together and also consider that web services also use xml.... you can conclude that when using web services the implementation of the data contracts is independant and you can do it differently in the client and server as far as both client and server implementations uses the same contract.

The idea is very similar to interfaces, so this causes confusion many times.... but as I said, interfaces describes behavior and metadata describes information or data.

Visual Studio makes this "independency" not so straightforward as it generates the proxies for you implementing your client-side classes.... but even there you can see that the implementation can vary.... for example, if you return a List<string> from the web service... this will be translated as string[] in the client-side proxy.... do you see ... different implementation of the same... a collection of strings.

So as Visual Studio modifies this, you can do the same with your client or server side classes as far as you keep the same xml contract in both places.

If you're interested on how to customize Visual Studio proxy generation I can help you too.... just let me know.

Hope it helps

Rgds

Rodrigo
CodeSweatAndBeers
IMHOIn two seperate business Web Services I have written, I have abandon serialization for some of the reasons mentioned. Most importantly if a service changes all clients have to recompile due to serialization. I always enjoy it when other developers come to me after a change to the service and thank me for making them do unnecessary update work, not related to their goals, when I tweak the web service many times during development...its priceless. <g>

One of the goals of serialization is that the consumer data request is verified not to send in invalid information...but balanced by the problem mentioned above. I find that verification after the initial development quickly loses its luster as the web service changes for new needs. A quick check to see if an Xml document validates against a schema can do the same work.

I disonnect the consumers by simply requiring raw Xml as input and output and providing an Xml Schema to go by. That way if the busines layer behind the service is changed to tweak incoming data for future needs, old consumers, who probably don't need to be updated are not affected. Its transparent.

This way the client is disconnected from the business layer and any major changes done to the BL. That way I can support backwards compatibility easier.

Just my opinion...I could be wrong.
Web Services, Serialization and Interfaces

Answer this question