Using existing types in Data Contract?

Topics: Service Factory Modeling Edition Forum
May 31, 2009 at 7:45 PM

Hello, please orient me. I'm just starting with WSSF.

I got the point where WSSF is a tool to 'design and generate' the elements of a Web Service solution that maps to clr-based web services.

And I see that its generally one-way from the WS abstraction model to the implementation models.

But if I would like to include some existing components and get the integration features of WSSF and its contrib components, am I going against the flow of the tool?

For example, I have to implement a Sync Framework web service following the (poorly named) 'n-tier' model. That framework uses some pre-defined dll's, classes, and its own generated service contract and client proxy class.

I would like to reference at least the sync framework classes used in the service contract generated by the sync framework in a Data Contract or Message Contract in the WSSF designer, but I don't see how this can or might be done.

When defining a Message Contract, I am only able to 'Add New Data Contract Message Part' or 'Add New Primitive Type Message Part'.

I can also reference some parts of an XSD.

However if I could reference an existing type from an existing library DLL as a Message Part, life would be good.

The benefit to me would be that I could create a web service that aggregated the Sync Framework web service or at least its components, but also enabled me to add the security and other robustness features I need.

Any technical insight or general advice would be appreciated.



Jun 1, 2009 at 11:17 AM

Hi Kimball,

If I got your point, you basically want to use your generated entity classes in the WSSF models (mostly in DataContract). Id this is your scenario, then I would like to suggest if possible to keep your business classes decoupled from your published contracts (Service and Data contracts). This is a desing recommendation despite of some cases where you can go further and reference an XSD or with some hints do the same from within you DataContracts.

There quite a lot of links out there that illustrate this scenario and also Don talk about this here:

More info searching with "WCF Contract Design Guidelines" and business entities.




Jun 1, 2009 at 3:54 PM
Edited Jun 1, 2009 at 4:01 PM

Thanks for responding, Hernan.

Well, you're certainly talking about the same kinds of topics I've been researching to find an answer to my question.

But what I would like to do is to use the designer to create a service contract identical to the one shown below.

I'd like to do this so that I have a WSSF solution with all its peices organized properly so that I can add other services to it as time goes on.

The interface shown and its contract attributes is the one generated by the Sync Services for ADO.NET LocalDataCache component.

The issue is that it references classes as input and output parameters to the Operations which exist in the Microsoft.Synchronization.Data.dll.

Your answer indicates to me that my question leads nowhere since the purpose of the designer is to create business entities, and not to utilize existing framework classes.

Therefore should I not be simply moving the Client and Server projects that are generated by the Sync Services wizards into the Solution generated by WSSF and then working on them there in a manual fashion?

At least I could have everything together with the other services I am creating using the designer as intended?

[ServiceContractAttribute()] public interface IVLMCDataCache1SyncContract 


[OperationContract()] SyncContext ApplyChanges(SyncGroupMetadata groupMetadata, DataSet dataSet, SyncSession  syncSession); OperationContract()] SyncContext GetChanges(SyncGroupMetadata groupMetadata, SyncSession syncSession); OperationContract()] SyncSchema GetSchema(Collection<string> tableNames, SyncSession syncSession); OperationContract()] SyncServerInfo GetServerInfo(SyncSession syncSession);







Jun 1, 2009 at 6:47 PM
Edited Jun 1, 2009 at 6:54 PM


I your case, I would take the option of generating your SC that references a DC with all your operation paramteters as DC properties and have a "Translator" strategy at the implementation project that translates between DC and your business entities (in this case SyncSession, and all the other external types). This way you don't need to resolve external types in your models and you decouple your contracts from your business data types.

To illustrate:

OperationContract()] SyncContextData ApplyChanges(SyncChangesData data)

where SyncContextData is a DataContract that contains your context data (defined in your model) and the same for SyncChangesData.

 Then you may create a Translator in your implementation project that maps yout DC types into your external types and back so you can call your business actions with your external types and convert back to DC types your results (in case of Request/Response operations).

More on translators here: Exercise 8 in the Hands on lab for Building a Service.

Jun 1, 2009 at 7:01 PM


Well OK then!

That's very helpful.

Thanks very much,