views:

138

answers:

3

We are trying to come up with an architecture approach for designing an application where front end runs as a browser based xaml app.

this app contacts services on the web server that are built using wcf, the wcf services host domain model that uses nhibernate for persistence (so it is hibernate aware by using interfaces for lists and sets and such)

i understand that when using soap web services, only schema are shared and not types, but we would like to share types since types would have methods, business logic etc ..

and since both ends of communication are in our control, we don't really need to use soap, but for all clarity and debugging, security and general peace of mind, SOAP is desired.

wondering what if this is an approach people use, and if there are any frameworks out there that enable/guide/ease the task of converting proxies back to their original types..

or if there are any other approaches possible.

A: 

You CANNOT share types (e.g. classes) in a true SOA world - because in the end, what it really comes down to is everything is serialized into a XML stream and sent across the wire. Also - one end could be .NET and the other end PHP or Java - now I don't think your Java client will understand and be able to execute .NET methods on your object.

SOA is a different beast than "object remoting" - it just doesn't lend itself to actually remoting objects across the wire - it sends XML messages across - that's all it can do. It can send data back and forth, but not code.

If in your scenario you do control both ends of the conversation, of course what is available to you is the ability to package all your business objects into a shared assembly (or several), and then physically share those assemblies between your server and client. In this case, you could serialize an object "Customer" on the server, send the XML message across, and on the client side, deserialize it into a "Customer" again. But be aware : all you're sending across is the state of Customer - the values in its fields and properties. You're not really sending the code across - that just happens to be available on both ends of the wire.

What a lot of folks do in this case is extracting the information of interest from the actual "Customer" object into a "Data-Transfer Object" often called "CustomerDTO", by using e.g. something like AutoMapper in order to make it easier, and then they create a new Customer instance on the other end of the wire and copy the data back from the DTO into the "real" object.

Marc

marc_s
+1  A: 

Marc is correct that you cannot share types in an SOA architecture. In fact, in SOA, it is undesirable.

But you've decided you don't need SOA, so you can share types if you like. Just click the "Advanced" button when you use "Add Service Reference", and choose the set of types you want shared between the client and service.

Of course, this does bind your client and service tightly together, and loses other benefits of SOA, but it's no worse than if you were using COM.

John Saunders
A: 

There is an easy way to share types between client and service, just by adding reference to shared type assembly to your client BEFORE adding the service reference.

You can find the detailed scenario and sample project there:

http://blog.walteralmeida.com/2010/08/wcf-tips-and-tricks-share-types-between-server-and-client.html

Walter Almeida