XML в MS SQL Server 2000 и технологиях доступа к данным

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

Кроме того, эта работа ведется чаще всего в гетерогенных средах, где перемешаны и Windows, и Linux, и Solaris, и FreeBSD, и много чего еще. Во-первых, представление как запроса, так и его результатов в виде XML существенно упрощает передачу данных через межсетевые экраны. Понятно, например, что передать recordset как COM-объект через брандмауэр скорее всего не удастся, потому что ни один администратор в здравом уме не откроет порты для произвольных RPC-вызовов снаружи. Издавна придумывались лазейки и средства: вспомните, например, Remote Data Service (RDS), появившуюся еще в составе ADO 1.5 во второй половине 1997 г. (а ее предшественник Advanced Data Connector - ADC - и того раньше). Она позволила-таки маршалировать recordset'ы через HTTP и DCOM, хотя и не скажу, что это было тривиально. Сериализация объекта в XML решает эту задачу легко. Во-вторых, XML и HTTP, являясь де юре и де факто общепринятыми стандартами, упрощают взаимодействие между базами данных различных производителей, на какой бы платформе и ОС они ни стояли. Причем, даже не только между базами данных, но и напрямую с серверами электронной коммерции и бизнес-интеграции. Например, с Commerce Server, BizTalk Server и др. Причем не только с серверами промежуточного слоя, но и вообще между гетерогенными приложениями, поскольку SOAP легко решает извечную задачу мостования между СОМ и CORBA. Впрочем, о SQL Server как о веб-сервисе мы еще поговорим. В-третьих, преимущество поддержки XML в СУБД состоит в том, что на компьютер конечного пользователя или приложения, работающего с базой данных, не требуется устанавливать никакой клиентской части, специфичной для данной СУБД, т.к. все, что ему нужно, - это стандартные протоколы и форматы Интернета, априори поддерживаемые практически всеми современными платформами.

Итак, работа через Интернет, взаимодействие в гетерогенных средах и поддержка тонких мобильных клиентов - вот основные практические плюсы, которые получает СУБД, если умеет общаться на языке XML.

Кроме того, XML представляет собой одно из наиболее заманчивых направлений эволюции СУБД. Допустим на минуту, что наряду с реляционным механизмом в SQL Server появился встроенный XMLный движок, так что тип данных XML является для него теперь родным. Представим также, что SQL Server является полноценным .NET-сервером, т.е. программировать на стороне сервера можно не только на Т-SQL, но и на любом CLR-языке. Тогда любой класс .NET Framework можно не только выразить при помощи XML, но и хранить и обрабатывать средствами SQL Server. Что означает, ни много, ни мало, что из чистой РСУБД, каковой он является на данный момент, SQL Server плавно превращается в объектную. А это означает, в свою очередь, что все многообразие не реляционных структур и хранилищ, представленных нынче в семействе Windows (WebStore, файловая система, Active Directory и т.д.) элегантно сводится к единой системе обработки и хранения. Поскольку пока еще рано предметно говорить о функциональности MS SQL Server "Yukon", все это, естественно, мои личные фантазии. Делать будущее гораздо интереснее, чем о нем гадать. Давайте вернемся к тому, что мы имеем в плане поддержки XML на сегодня.

Второй вопрос: о чем конкретно будет говориться в этом материале. Как SQL Server, так и XML - вещи, достаточно необъятные. Я поставил себя на место прикладного разработчика, который, наслушавшись про XML, решил, наконец, попробовать его в своем клиент-серверном приложении. В принципе, вся необходимая информация для этого есть, но она разбросана: Books-On-Line к SQL Server, хелпы к SQLXML 3.0, безбрежная MSDN Library, наша и зарубежная программерская периодика, дискуссии на разработческих сайтах и т.д. Я просто попытался превратить разрозненные куски в более или менее целостное повествование, выкидывая то, что мне никогда не пригождалось на практике, и останавливаясь на тех вещах, которые на самом деле нужны, но в документации описаны недостаточно подробно. В процессе копания случалось наступать на грабли, которые самому обойти не получалось. Тогда я обращался за помощью к интернациональному сообществу разработчиков Microsoft и сейчас хотел бы сказать спасибо товарищам Ramakrishna Pamulapati, Matt Neerincx, Kyoko Shikamata и Dion Houston, чьи советы мне здорово помогли. Таким образом, несмотря на то, что добавленная мной стоимость ограничивается компиляцией различных источников, сведением мыслей воедино и расстановкой акцентов, я считаю написание данного материала оправданным. Надеюсь, что он будет способствовать увеличению читательских знаний и умений, а не только энтропии Вселенной.

И еще пара соглашений. Я не собираюсь публиковать этот текст в бумажных средствах массовой информации, поэтому не будем заранее планировать объем и пытаться выполнить пятилетку за два дня и угадать мелодию с одной ноты. Считаем, что объем ограничен моим и вашим временем и терпением. По этой же причине я сначала буду следить за техническим содержанием, а уже потом за чистотой языка и стиля. При самом уважительном отношении к русскому языку, я не считаю криминалом использовать сленг и жаргонизмы в профессиональной беседе, каковой является наше с вами общение. Они позволяют более точно и быстро донести смысл.