2

I need to develop a webservice which will be exposed to a java client over SOAP. We have a well defined schema in place which we use to communicate between both the systems. Now I need to expose an operation on my WCF contract which takes the Schema object and store it inside our DB.

I have followed the following for developing the webservice.

  • Host it over basichttp in wcf
  • Create an object model of the schema using xsd.exe
  • Take the schema as a parameter on the operation something like DoThis(SchemaObject schema)

Since this is going to be exposed in WCF, I have gone and modified the xsd tool generated object model. Our schema has mutiple level of nesting, and is a combination of 4 different schema linked together. The object graph generated by xsd tool has abstract classes, inheritence etc.

For this to work, I have gone and defined DataContract attrbute on everyclass and added the namespace to it, which was already there in the XmlTypeAttribute. Also I have added DataMemebers to each properties.

Some of the properties in the schema are arrays which was defined by the tool using xmlarrayitem attribute.

Now when I send a request using SOAP UI, the object is not getting deserialized as expected. Almost all the fields are coming as null, which has some sort of inheritence hierarchy. I have added KnownType attribute to the appropriate datacontracts, but still not working.

My question is:

  • Is this the right way to develop a webservice.

  • Is there a way to avoid putting the datacontract and data members and just work witht he serialization attributes added by the xsd tool?

  • Is it necessary to use datacontract attribute, will it not work with the xmlserialization attributes as it works inthe case xml deserialization?

Mike
  • 3,204
  • 8
  • 47
  • 74
  • There are two approaches to develop web service, write the wsdl and xsd then generate the classes / code based on it. Or vice-versa. Sometime to avoid compatibility issues with cross-platform client & server. I tend to write the data contract, service contract classes and run the service to generate the wsdl & schema. This ensures that the serializations are taken care of. Also if you have the wsdl and schema, did you try to generate the wcf service using svcutil? – Dilberted Aug 15 '12 at 01:07
  • I would check that you are sending all your properties in the correct order i.e. Either Alphabetically or in the specified order. http://stackoverflow.com/questions/10474838/not-all-parameters-in-wcf-data-contract-make-it-through-the-web-service-call/10475117#10475117 – SCB Aug 15 '12 at 01:40

2 Answers2

1

WCF supports two types of serialization - DataContractSerializer and XmlSerializer.

XSD.exe generates strong type entities with all necessary XmlSerializer attributes. You do not need to add any DataContract or DataMemeber attributes to work with generated classes in WCF.

See MSDN for more details - http://msdn.microsoft.com/en-us/library/ms733901.aspx

Be also very careful with your entities generated by xsd.exe. As you probably already seen WCF server will eat many serialization changes you can do in these files but that will be breaking change for clients because they relay on XSD.

If possible I would remain these auto-generated entities without changes to guarantee that interface is not broken. You may introduce separate DTO classes for using in Business Layer. You can implement inheritence hierarchy over there.

Bunch of Unit Tests can help if you feel that auto-generated classes need to be changed. These Test Cases should generate different data sets, serialize them into XML and check that XML over XSD.

Dmitry Harnitski
  • 5,838
  • 1
  • 28
  • 43
0

Technically, I don't see any particular flaw in the way you are implementing the service.

But from the architectural point of view it's too complicated for me. It's always easier to send 'flat' data-structures and hide complexity somewhere else. I would suggest the following steps

  1. Develop some special 'transport' scheme, maximally flattening it. It makes changes of the service easier when your model changes. And also it makes less painful to generate and cope with xsd.
  2. Code special transformators on both sides of the channel to translate normal model to 'flat' and then vice-versa.
Konstantin Chernov
  • 1,899
  • 2
  • 21
  • 37