XML Types in WSSF: ME Data Contracts

Topics: Service Factory Modeling Edition Forum
Feb 22, 2008 at 9:15 PM
Edited Feb 22, 2008 at 9:20 PM
As described in XML and ADO.NET Types in Data Contracts, WCF has several ways to include XML directly in a data contract. I have several existing web services that operate on XML passed as XmlElement or XmlDocument types, and operated upon using the same types. The schemas for these XML documents are complex, and use attributes extensively.

In converting these services to use WCF, I'd like to maintain the existing schemas, and much of the existing code. This means that I'll need to continue to operate upon XML.

Unfortunately, I don't see a way to do that in either the Data Contract Designer nor the Service Contract Designer. I'm new to WSSF, so, am I missing something?

The same question applies to DataSet, DataTable and others that implement IXmlSerializable.
Developer
Feb 25, 2008 at 10:41 AM
Did you try using XML Message elements (instead of Message) in your Service Contract models? That way you can point your messages to types defined in your schemas or existing WSDL files. These shapes are intended for contract-first scenarios where you can reuse your contract types defined in your shcemas.
Feb 25, 2008 at 12:06 PM


charlyfriend wrote:
Did you try using XML Message elements (instead of Message) in your Service Contract models? That way you can point your messages to types defined in your schemas or existing WSDL files. These shapes are intended for contract-first scenarios where you can reuse your contract types defined in your shcemas.


Thanks, I tried that before starting this discussion. It doesn't work with arbitrary schemas - only those that are compatible with the DataContractSerializer. I don't want to have to use the XmlSerializer either. In fact, I don't want any serialization here - I want to operate on the raw XML of this part of the message. WCF has that capability; I wanted to know if that capability was exposed through the WSSF: ME.
Developer
Feb 25, 2008 at 1:20 PM
I'm not sure if I got your point. When you say "operate on the raw XML" Do you mean passing an XmlDocument or something like that? Or just using the XML API in WCF? For the latter you won't find that in WSSF unless you change the tt files (part of the code-gen stuff) and add your required XML logic there.
Feb 25, 2008 at 2:54 PM
I was specifically referring to XML and ADO.NET Types in Data Contracts in the MSDN library. In particular, I'm thinking about a web service that needs to accept or return a complex XML document that validates against some predefined schema. It looks like WCF, like ASMX, has the ability for a web method to accept a parameter of type XmlElement or to return XmlElement. I wanted to know if this capability was exposed in WSSF: ME.

Is there a page that describes features of WCF that are deliberately not addressed by WSSF or by WSSF: ME?
Developer
Feb 25, 2008 at 3:53 PM
You may find some comments regarding that in the know issues pages (to be updated soon) and perhaps in the docs included with the factory.
Now regarding the DataMembers types that you can define in the models, WSSF suports only Primitive types and other DCs references or collections of primitives. If you want to expose other kind of types (built in in the framework or custom ones) you can manually edit the model file opening with an XML Editor (from VS) and update the Type attribute of the appropiate DC element.
Feb 25, 2008 at 8:02 PM

charlyfriend wrote:
Now regarding the DataMembers types that you can define in the models, WSSF suports only Primitive types and other DCs references or collections of primitives.
Is this meant to be a fundamental design decision for WSSF? Are you saying that, if we decide to use WSSF, that we will never be able to use the features of WCF that use other types? Is the use of these other types not a best practice for some reason?

If you want to expose other kind of types (built in in the framework or custom ones) you can manually edit the model file opening with an XML Editor (from VS) and update the Type attribute of the appropiate DC element.


Manually editing the model doesn't sound very maintainable.