Your “server-side” class won’t be “made available” to the client, really.
What happens is this: based on the data contract, the client will create a new separate class from the XML schema of the service. It cannot use the server-side class per se!
It will re-create a new class from the XML schema definition, but that schema doesn’t contain any of the .NET specific things like visibility or access modifiers – it’s just a XML schema, after all. The client-side class will be created in such a way that it has the same “footprint” on the wire – e.g. it serializes into the same XML format, basically.
You cannot “transport” .NET specific know-how about the class through a standard SOAP-based service – after all, all you’re passing around are serialized messages – no classes!
Check the “Four tenets of SOA” (defined by Don Box of Microsoft):
- Boundaries are explicit
- Services are autonomous
- Services share schema and contract, not class
- Compability is based upon policy
See point #3 – services share schema and contract, not class – you only ever share the interface and XML schema for the data contract – that’s all – no .NET classes.