GotDotNet.Ru: основная лента

Ну вот наконец добрался до второго поста :)

Много чего произошло за это время, но я понял для себя главное: нужно всегда двигаться вперед. Не нужно плыть против течения, нужно поменять направление течения, тогда двигаться к поставленной цели станет заметно легче.

Самыми значимыми для меня событиями за этот год стали созданные вебкасты на TechDays.ru по теме ReportingServices 2008

http://www.techdays.ru/videos/2228.html

http://www.techdays.ru/videos/1354.html

и вообще, я решил делать вебкасты, мне очень это нравится - делится тем что знаеш, пусть это и не так много, но уверен - кому-то обязательно пригодится. Кроме этого, за последний год я стал MCTS, MCPD и MCTIP :) Особенно активным был месяц декабрь 2009, т.к. удалось сдать по акции 5 экзаменов бесплатно. Кризис - надо экономить.

Следующий вебкаст, которым сейчас занимаюсь, будет не технологическим - он будет как раз посвящен вопросу сертификации, мне кажется тема будет интересная, т.к. есть что рассказать, за прошедший год я хорошо прокачал себе скил сдачи сертификационных тестов. Сейчас готовлюсь к сертификации по SQL Server BI, даже на курсы ходил по MSAS. В общем сертификация дело серьезное, и подходить к ней надо во всеоружии.

Часть 3: WSDL и document/literal

Итак, WSDL описывает веб-сервис, а WSDL binding описывает, каким образом сервис взаимодействует с протоколом SOAP, т.е. по каким правилам формируются SOAP сообщения. WSDL SOAP binding может соответствовать Remote Procedure Call (RPC) или document стилю. К этому еще добавляются encoded или literal свойства сериализации. Итого получаем четыре возможных варианта (на самом деле пять, т.к. еще есть document/literal wrapped), которые определяют каким образом WSDL binding "преобразовывается" в SOAP сообщение.

Document : <soap:Body> содержит один или несколько дочерних элементов (частей), <soap:Body> содержит те элементы, относительно которых договорились (знают) отправитель и получатель, т.е. других специальных указаний нет.
RPC: RPC подразумевает, что <soap:Body> содержит элемент с именем метода или удаленных процедур, которые будут вызываться. В свою очередь, этот элемент содержит элемент для каждого параметра процедуры/метода.

Endcoded: сериализация выполняется в соответствии со спецификацией SOAP. Правила указывают, каким образом должны быть сериализованы объекты, массивы и т.п.

Literal: сериализация данных выполняется в соответствии со некой схемой (например, W3C XML Schema).

Давайте посмотрим на примеры, чтобы на практике понять различия.

RPC/encoded

<soap:envelope> 
   <soap:body> 
      <myMethod> 
         <x xsi:type="xsd:int">5</x> 
         <y xsi:type="xsd:float">5.0</y> 
      </myMethod> 
   </soap:body> 
</soap:envelope> 

RPC/literal

<soap:envelope> 
   <soap:body> 
      <myMethod> 
         <x>5</x> 
         <y>5.0</y> 
      </myMethod> 
   </soap:body> 
</soap:envelope> 

Document/encoded
Исключаем, т.к. не поддерживается WS-I спецификацией.

Document/literal

<soap:envelope> 
   <soap:body> 
      <Element1>5</Element1> 
      <Element2>5.0</Element2> 
   </soap:body> 
</soap:envelope>

Document/literal wrapped

<soap:envelope> 
   <soap:body> 
      <myMethod> 
         <x>5</x> 
         <y>5.0</y> 
      </myMethod> 
   </soap:body> 
</soap:envelope>

По умолчанию WCF использует document/literal wraped представление, тогда как другие платформы могут использовать, например, rpc/literal. Для конечных клиентов и прокси все преобразования должны быть прозрачны, т.е. SOAP ответ ответы/запросы должны генерировать автоматически в соответствии с тем типом, который объявлен в WSDL сервиса. Но, к сожалению, так бывает не всегда и иногда возникают ошибки, связанные с тем, что та или иная платформа по умолчанию использует другой тип, а не тот, что объявлен в WSDL стороннего сервиса. Что можно сделать в такой ситуации? Например, указать WCF использовать RPC/encoded (и в очередной раз мы будем использовать XmlSerializer):

[OperationContract]  
[XmlSerializerFormat(Style = OperationFormatStyle.Rpc, Use = OperationFormatUse.Encoded)]  
string RPCEncoded(int value)  

11го Февраля пройдет очередная встреча Петерубргской группы Alt.Net, посвященная проблемам версионирования и миграции баз данных.

18я встреча группы пройдет в черверг, 11го Февраля в 19:00.
Встреча группы пройдет в Университете Путей Сообщения по адресу:
— Аудитория 9-013, Набережная реки Фонтанки 115 (карта).

Программа

9:00 – 21:00 — Миграция и управление версионностью баз данных, Александр Попов [MVP ASP.NET] и Алексей Садомов

Версионирование баз данных

• Теория вопроса (briefly)
• Версионирование в командной разработке
• dbuilder app (MetaCommunication)

Обзор приложений для миграции баз данных в .Net

• Tarantino + RedGate SQL Compare
• Migrator.Net
• SubSonic

Зарегистрироваться на встречу

Занимаясь продвижением анализатора Viva64 (из состава PVS-Studio) мы часто комментируем ключ /Wp64 из Microsoft Visual C++. Кто не в курсе, напомню, что этот ключ появился в Visual Studio 2003 и предназначался для подготовки миграции приложений на 64-битные системы. В Visual Studio 2008 ключ /Wp64 считается устаревшим, поскольку надо уже давно компилировать 64-битные приложения, а не готовиться к этому. То есть компиляция в 64-битном режиме выявляет все те же самые ошибки и недостатки кода, что выявлял ключ /Wp64 при сборке 32-битного приложения. Причем при компиляции 64-битного кода это делается гораздо более полно и точно.

Но помимо сказанного, у ключа /Wp64 есть еще один недостаток, который путает программистов, которые не знакомы с ним. Это касается проблемы разбора кода, содержащего некоторые шаблоны. Рассмотрим пример.

Евгений Рыжков

Одной из новых фич SQL Server 2008 была поддержка иерархических структур данных. Эти структуры можно использовать для хранения информации об организационной структуре предприятия, структуре форума, топологии сети, и другой иерархической информации. В этой статье я хочу кассказать про то, как можно работать с этой новой структурой данных в SQL Server.

Для компиляции и использования исходного кода вам потребуются Visual Studio 2008 и SQL Server 2008.

В ходе последнего визита в Нижний Новгород мне удалось побеседовать с Ниной Гоновой, магистранткой Нижегородского государственного университета, стажировавшейся в ETH в Цюрихе в бывшей научной группе профессора Никлауса Вирта, создателя языка Паскаль. Мы говорим про язык Зоннон, одно из последних языковых изобретений группы Вирта, для которого существует неплохая реализация, встраивающаяся в Visual Studio, про концепцию активных объектов и возможности научных вычислений. Также Нина рассказывает про жизнь в Цюрихе и про то, как попасть на стажировку в ETH. Кстати, само интервью записывалось на территории лаборатории высокопроизводительных вычислений ННГУ, на фоне компьютерного кластера!
Видео на YouTube: часть 1, часть 2, часть 3. RSS-лента подкаста тут.