Относительно XmlSerializer() и говорить-то особенно больше нечего. Он отлично будет (де)сериализовать ваши данные через XML, и, если вы еще разберетесь с атрибутами из System.Xml.Serialization, то можно будет сказать, что you are embraced the XML as data interchnage format. (Нельзя не заметить, что WebServices internally rely on the Xmlserializer to do object-to-SOAP transformations) Словом, MBV - marshal-by-value, в ваших руках. Ну, а что осталось для MBR?
Во-первых, понятно, что как бы ни сериализировать RPC-подобные вызовы для MBR, этим нельзя ограничиться. Кто-то должен эти вызовы передавать, принимать, направлять и т.д. и т.п. Добро пожаловать в .NET Remoting. Я хочу сказать, что SoapFormatter, BinaryFormatter and friends разрабатывались для .NET Remoting (о чем свидетельствует и то, что все они находятся в одном namespace - System.Runtime.Remoting) и без .NET Remoting понять их совершенно невозможно.
Теперь по сути. Начать с того, что SOAP specification определяет 4 разных типа документов, которыми занимается SOAP:
1). "document-style" message (section 5). Этот тип наиболее близок к XML-serialized messages. Сейчас мы заниматься им не будем.
2). Faults (section 4) - очень интересная и важная тема, особенно в контексте BizTalk. Но и этим типом мы займемся не сегодня.
3). Requests for method invocations and 4). their responses (section 7). Вот именно этим типом, который и решает вопросы MBR, мы и займемся сегодня. А еще точнее - его взаимодействием с .NET Remoting infrastructure.
Но, прежде всего, я хотел бы сказать пару слов о версиях SOAP. На сегодняшний день его рабочая версия - 1.1. Именно она поддеживается .NET Framework 1.0 и 1.1. Версия SOAP 1.2 пока является W3C Recommendation и, по всей видимости, будет поддеживаться .NET Framework 2.0. (Например, классы Soap12FaultCodes, SoapFaultSubcode). Пока я не собираюсь рассматривать версию 1.2.