(Возврат на основную страницу)

Содержание номера за Июль 2006 год

Предсказания будущего? Не верьте ни единому слову!

Хотелось ли вам когда­нибудь вернуть время назад, чтобы пересмотреть уверенные предсказания экспертов, которые сбылись и не подтвердились?

Недавно я решил начать большую уборку моего чулана в офисе. Там я обычно храню неие сокровища, которыми, как я думаю, могу заинтересоваться снова, но обычно это не происходит. Итак, беспорядок становился все больше и больше, и в итоге пришлось разбираться во всем этом хламе и избавляться от некоторой его части.

Когда я начал уборку, я заметил множество интересных вещей, на которые раньше не обращал внимания, — например, книги IBM из эпохи DB2 V2 (обычно здесь я говорю про мэйнфреймы). Также там было несколько древних руководств по VSAM и IBM Repository, а также множество книг с конференций. Если вы следите за конференциями, то знаете, что сейчас на них больше не выдают печатные материалы, — значит, это «книги» начала 90­х гг. (с IDUG, конференции DB2 Tech Conference, Gartner Symposium и даже с Database and Client/Server World). Я собираюсь хранить эти реликвии как память о прошедших днях, но, думаю, придется убрать их на чердак.

Продолжая своих «раскопки», я нашел некоторые старые журналы, а также научные отчеты от групп аналитиков. Это оказалось забавным. По мере прочтения некоторой части этих материалов я все больше и больше понимал, что никогда не стоит доверять прогнозистам — даже профессионалам. Чтение этой литературы в то время могло помочь вам быть современными, но руководствоваться в своих планах журналами и научными отчетами неблагоразумно. Почему? Я расскажу об этом.

Вы угадали, я собираюсь подчеркнуть некоторые «прогнозы», которые были неверными. Однако я не буду относить их к какой­либо определенной публикации или группе аналитиков, поскольку хочу избежать дискуссий в сети. Достаточно сказать, что все они взяты из уважаемых источников. Перечислю некоторые из моих любимых.

•     Аналитика­эксперт, 1996 г., комментарии о рынке РСУБД: «Из общей картины рынка можно выделить Informix как серьезного лидера… Большая доля Oracle на рынке и его финансовые ресурсы должны компенсировать технические проблемы… Ни один другой поставщик РСУБД не может составить правдоподобную конкуренцию этим двум компаниям». (Oн не забыл IBM, но как минимум не внес в двойку лидеров Sybase. — К. М.)

•     Группа аналитиков, 1995 г., о сигнально­ориентированном промежуточном программном обеспечении (Message Oriented Middleware, MOM): «Наша группа верит, что явные проблемы взаимодействия могут стать, а могут не стать проблемами пользователей в зависимости от того, насколько важны на этой ранней стадии высокая гарантия автоматической доставки сообщений, безопасность и управ­ление трафиком». (Хм, что мне сейчас делать с таким мудрым советом? Я могу его игнорировать или не игнорировать. — К. М.)

•     Финансовый аналитик, 1997 г., о проблеме Y2K: «Только 6 процентов никак не рассматривали эту проблему (Y2K)». (Вот пример, где в соответствии с этими данными мы можем сказать, что почти все справятся с этой проблемой и нам не нужно будет строить бункеры в Вайоминге в случае чрезвычайной ситуации в мире. — К. М.)

•     Журнал, 1997 г., о будущем PC: «Ваш PC станет устрой­ством, не предъявляющим тех требований, которые предъявляют сегодняшние PC». (Разумеется, материнская плата в моем основном PC не просто сгорела, потребовав покупки нового компьютера, а затем полной переустановки. И моя мама не звонит мне, потому что ее CD­привод больше не работает и она не может найти ничего, что она скачивает. Да, сейчас это все так просто. — К. М.)

На этом я собираюсь закончить. Но по мере уборки моего чулана я могу опубликовать что­нибудь новенькое.

Задания SQL Agent: прыжки назад и вперед

Пока большинство из нас усердно трудилось над довольно неприятной проблемой по переводу часов и других связанных с временем устройств с летнего времени на зимнее (чтобы сэкономить за счет использования дневного времени), Рон Тэлмейдж приотстал и сделал ряд потрясающих открытий, относящихся к SQL Agent. Любопытно? Читайте дальше.

Включенные в расписание задания SQL Agent могут проявить себя совершенно непредвиденно при переходе с летнего на зимнее время и наоборот. Если время в вашем сервере баз данных переводится автоматически и у вас имеются задания SQL Agent, дата и время выполнения которых приходится на добавляемый час при переходе на зимнее время или на пропускаемый час при переходе на летнее время, вас ждет сюрприз! На самом деле вы обнаружите, что подобное поведение имеет место всегда, когда время сервера переносится на час вперед или назад. Рассмотрим оба случая по очереди, а затем сформулируем выводы для планирования расписаний выполнения заданий.

Организация индексов в SQL Server 2005

SQL Server 2005 представляет новую парадигму для команд языка определения данных (data­definition language, DDL). Все объекты будут создаваться с помощью команды CREATE, удаляться с помощью команды DROP и изменяться посредством команды ALTER. В SQL Server 2005 не будет отдельных хранимых процедур для изменения одного из свойств объекта, таких как sp_defaultdb в SQL Server 2000 и 7.0, которая изменяет базу данных пользователя по умолчанию, или специальных команд, таких как sp_addtype. В SQL Server 2000 движение к такой парадигме началось с включения в функциональность команды ALTER DATABASE возможности изменения всех свойств базы данных и менее активного использования команды sp_dboption.

Некоторые действия, которые в более ранних релизах требовали выполнения через DBCC, в SQL Server 2005 будут осуществляться с помощью команд ALTER. До SQL Server 2000 DBCC было сокращением от DataBase Consistency Checker, и доступные в первых нескольких версиях SQL Server опции DBCC, такие как DBCC CHECKDB и DBCC CHECKTABLE, действительно выполняли серию проверок целостности. Но по мере развития продукта совершенствовалась и DBCC, и разработчики в Microsoft начали расширять функциональность и без того уже перегруженной DBCC, так что проверка целостности базы данных неожиданно стала лишь малой частью этой функциональности. В SQL Server 2000 Books Online (BOL) окончательно было приведено новое значение для DBCC — DataBase Console Command (полный список опций DBCC можно найти в документации).

Некоторые опции DBCC в SQL Server 2000 запрашивают информацию, некоторые производят изменения. Две команды DBCC из SQL Server 2000 и более ранних версий работают с индексами: DBCC SHOWCONTIG показывает фрагментацию индекса, и DBCC INDEXDEFRAG уменьшает фрагментацию, модифицируя страницы, используемые индексом. В SQL Server 2005 команда ALTER INDEX заменяет DBCC INDEXDEFRAG. Заменой DBCC SHOWCONTIG является новый динамический объект управления sys.dm_db_index_physical_stats().

Команда разработчиков Microsoft давно хотела найти альтернативу SHOWCONTIG. Среди причин этого был тот факт, что результаты команды DBCC сложно отфильтровать, равно как и получить нужную информацию. Вы могли использовать INSERT EXEC для сохранения результата DBCC SHOWCONTIG в таблице, но вам приходилось сначала создавать таблицу отдельной командой, и только после сохранения данных в новой структуре вы могли их отфильтровать. В SQL Server 2005 можно получить информацию о фрагментации с помощью функции sys.dm_db _index_physical_stats(). Если вы запросите все столб­цы, которые возвращает функция, то получите намного больше информации, чем выводилось командой DBCC SHOWCONTIG. Но из­за возврата данных через табличную функцию (table­valued function, TVF) вы можете ограничить результаты необходимыми вам столбцами или записями.

Как взломать SQL Server

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

Я верю, что лучший способ справиться с потенциальными рисками в области безопасности — выставить их напоказ, поэтому данный подход может вас шокировать. С моей точки зрения, рассказать о потенциальных рисках — значит уравнять в шансах хороших и плохих ребят. Несмотря на название этой серии статей, я вовсе не собираюсь учить плохих ребят взламывать SQL Server (они и так знают, как это делать), вместо этого я хочу рассказать хорошим ребятам (то есть вам), что на уме у плохих ребят и что мы можем предпринять для своей защиты.

SQL Server 2000 — это устойчивая СУБД, которая предоставляет великолепную производительность и исключительную легкость в использовании по разумной цене. К сожалению, все это может обернуться проблемами с безопасностью, ведь то, что просто применять, так же просто использовать неправильно или с дурными намерениями. Как профессиональный администратор баз данных, вы, вероятно, знакомы с большинством уязвимостей, которые я буду здесь обсуждать, а Microsoft, похоже, прилагает немало сил, чтобы нас о них предупредить и, где возможно, закрыть бреши. Все это так, но администраторам все еще приходится потрудиться, чтобы обеспечить безопасность своих серверов с SQL Server.

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

Ресурсы

• Портал по безопасности Microsoft’s SQL Server — http://www.microsoft.com/sql/technologies/secu­ri­ty/default.mspx.

• Web­трансляция Джайриша Чэндерса (Girish Chander) от 8 декабря 2004 г., посвященная улучшениям в безопасности SQL Server 2005, — www.microsoft.com/events/ webcasts/ondemand.mspx.

• Схема средств безопасности SQL Server 2005 — www.microsoft.com/sql/2005/productinfo/secu­rity­features_2.asp.

• Безопасность и аутентификация MSDE — http://support.microsoft.com/Default.aspx?kbid=325022.

• Web­сайт Microsoft по безопасности для разработчиков — http://msdn.microsoft.com/security.

1 Как рекомендует Microsoft в KB 313418, следует заблокировать порт 1433 на вашем шлюзе в Интернете и настроить SQL Server так, чтобы он слушал другой порт, а если это невозможно, включить фильтрацию входа/выхода, чтобы предотвратить использование этого порта с дурными намерениями. — Прим. ред.

2 К счастью, Microsoft закрыла дыры в SQL Ser­ver 2005, и одним из результатов этого стала более безопасная работа SQL Agent, о чем вы можете прочитать по адресу: www.microsoft.com/tech­net/prodtechnol/sql/2005/evaluate/news­qlagent.mspx. — Прим. ред.

Табл. 1. Приблизительное время взлома слабого пароля, состоящего только из символов алфавита

Табл. 2. Приблизительное время взлома улучшенного пароля

Четыре сценария с рисками

Очевидно, что надо обладать техническим мастерством в SQL Server и T­SQL, чтобы быть хорошим администратором баз данных. Но это еще не все. Необходимо также понимать бизнес­процессы, которые поддерживают ваши серверы. А еще требуется соблюдать эмоциональную дистанцию, чтобы суметь узнать о состоянии дел, оценить возможности и мыслить в терминах минимизации риска. В этой статье показано несколько сценариев из реальной жизни, которые иллюстрируют эти положения.

Как администратор баз данных, вы должны знать администрирование SQL Server вдоль и поперек. Ожидается также, что вы окажетесь весьма полезны при проектировании БД. Но иногда и этого недостаточно. В большинстве случаев администраторы баз данных знают, когда ситуация балансирует на грани срыва — возможно, в результате таких очевидных причин, как плохо спланированные процедуры формирования резервных копий, или более тонких, например бездумного принятия существующего положения дел. В этой статье я обобщила несколько основанных на реальных событиях сценариев, иллюстрирующих процесс, которому необходимо следовать, чтобы оценить и минимизировать риск.

Сценарий 1:
единственный администратор в городе

Сколько раз вам приходилось принимать участие в проектах, где множество людей разрабатывают клиентские приложения, и которые поддерживает всего один администратор баз данных — вы? Разумное зерно такого подхода состоит в том, что клиентская часть — это то, что видит заказчик. Именно поэтому туда и направляется основная масса ресурсов. На одинокого администратора взирают (часто с жалостью и презрением) как на несчастного, которому выпала утомительная задача заниматься серверной частью, несмотря на риск, обусловленный наличием этой единственной точки отказа. Так каковы же варианты, и, что важнее, каковы риски?

Первый вариант состоит в том, чтобы ничего не предпринимать, сохранять статус кво и стараться все выдержать. Почему такое решение неправильно? Будучи единственным администратором в проекте, вы отвечаете за архитектуру баз данных, построение хранимых процедур, резервное копирование и восстановление, прогнозирование и разрешение проблем производительности и за документирование всего вышеперечисленного. К тому же в свободное время вы можете поддерживать и другие приложения. Очень велика вероятность того, что вскоре каждый из разработчиков клиентских частей начнет обращаться к вам за хранимыми процедурами, поддерживающими его или ее часть кода. Скорее всего, разработчики станут сами кодировать собственные хранимые процедуры, заставляя вас редактировать их. Известно, что работа над серверной частью требует других навыков и умений, чем разработки клиентских частей. Немногие способны выполнять и то и другое. Вы даже можете заметить, что редактирование отнимает у вас больше времени, чем собственноручное создание кода. Незавершенная работа накапливается, раздражение нарастает с обеих сторон, и команда начинает искать обходные пути.

Если в качестве администратора именно вы управляете внедрением хранимых процедур, что остается делать разгневанному разработчику? Обращения к базе данных из строки кода на короткое время решают проблему, так ведь? Но проблема состоит в том, что эти кратковременные решения живут своей жизнью. Как только пользователи начнут работать с системой, им понадобятся изменения — пара пустяков, если все применяют одни и те же хранимые процедуры, и настоящий кошмар, если нет. Теперь решение оставить единственного администратора ради максимального увеличения числа разработчиков клиентских частей или экономии денег уже не кажется таким уж мудрым. Еще большей проблемой это станет, если администратор вдруг заболеет или уйдет.

Второй вариант состоит в том, чтобы нанять второго администратора для выполнения задач по проекту, оставив вам выполнение ежедневных работ. Разумеется, вы будете поддерживать это приложение, когда оно будет внедрено в производство. Помимо того, что такое решение наносит очевидный моральный ущерб, на самом деле оно не решает проблему, а просто перемещает узкое место с вас на нового сотрудника.

Третий вариант состоит в том, чтобы нанять второго администратора и разделить задачи на первичные и фоновые, поручив их решение обоим администраторам. В то время как у каждого из вас будут свои первичные задачи для выполнения, вы должны будете выступать как резерв другого. В случае болезни или ухода одного из сотрудников работа будет продолжена с минимальными нарушениями, пока не будут сформированы новые планы. Дополнительным преимуществом является то, что у вас появится партнер, с которым можно будет обсудить идеи. А поскольку две головы лучше, чем одна, проект только выиграет. С моей точки зрения, это предпочтительное решение. Оно позволит проекту двигаться дальше мерным шагом, при этом риски будут минимальны.

Я стараюсь в достаточной степени подчеркнуть, насколько важно резервирование в этой области. Тем из вас, кого мои доводы не убедили, напомню, что Майк Йокка, администратор и соавтор этой публикации, погиб в аварии на снегоходе в расцвете лет. Подобное может случиться с каждым, и надо быть готовым к этому.

Сценарий 2:
кризис в середине проекта

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

Первый вариант заключался в том, чтобы оставить все как есть. База данных уже была спроектирована, кодирование шло полным ходом, и время на переделку проекта было упущено. Несомненно, производительность приложения станет меньше, чем могла бы, но она все же будет выше, чем при работе приложения с базой DB2. В будущем вносить изменения в приложение будет сложнее, но ведь пользователи привыкли к задержкам.

Второй вариант включал отступление на шаг назад, фиксацию проекта, отмену большого объема работ по разработке клиентской части и после этого возобновление движения вперед. Также требовалось объяснить высшему руководству, зачем все это делается, и призвать их набраться решимости до дня сдачи проекта. Простое решение? На самом деле да. Для меня единственной жизнеспособной альтернативой было начать все заново. Причины такого преобразования в первую очередь включали предоставление пользователям лучших позиций для конкуренции на рынке и повышение общей производительности системы. Руководство поддержало мои рекомендации пройти заново стадию проектирования базы данных, и эта переделка была выполнена в рекордные сроки — причем в ней участвовали и разработчики клиентской части. В результате объем кода клиентской части уменьшился, хранимые процедуры стали компактными и приложение все выполняло с лету. Единственной жалобой пользователей было: «Слишком быстро работает». Ну, с этим можно жить.

Сценарий 3:
следуя правилам

Планирование действий в случае отказа является обязательной частью разработки всех критически важных приложений. Но оно будет хорошим настолько, насколько тщательно оно продумано и сколько усилий в него вложено. Бывают времена, когда эта задача становится самой приоритетной из всех, а в другие моменты ее можно отложить. В данном сценарии план восстановления после аварии был разработан и аккуратно тестировался каждый год. Однако представьте себе, что ежегодное тестирование восстановления после аварии запланировано на октябрь, а перевод приложения на SQL Server 2000 — на ноябрь. Чтобы сделать все еще интереснее, представьте, что приложение является пакетом производителя и сопровождение его прежней версии закончится, как только будет внедрена новая. Будете ли вы менять свое расписание для тестирования восстановления или нет?

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

Второй вариант состоит в переделке расписания тестирования восстановления с учетом грядущего обновления версии программного обеспечения, однако ресурсы уже забронированы и будут выделены, даже если тесты будут отложены или отменены. Если вы подумаете о том, почему тестирование восстановления занимает первое место, то ответ ясен. Рекомендую пересмотреть план тестирования и изменить его, чтобы привести в соответствие с выходом новой версии. А затем можете выполнить его в качестве последнего шага плана внедрения. Вероятнее всего, у вас уже будет все необходимое и ресурсы будут меньше, чем в случае планирования отдельного тестирования.

Сценарий 4:
порядок в

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

Первый вариант предполагает передачу всей поддержки внешним производителям. Имеется 24­часовая горячая линия, и производитель готов предоставить дополнительный персонал, необходимый для разрешения пожарных ситуаций, внедрения нового программного обеспечения и тестирования восстановления после аварий. Звучит прекрасно, но первый предупредительный звонок прозвучит, когда вы поймете, что это те же самые люди, которые оказывают 24­часовую поддержку и другим компаниям. Если у другого клиента авария произойдет одновременно с вами, решение ваших проблем может задержаться. Более того, перед теми, кто поставляет внешние ресурсы, стоят те же трудности, которые в первую очередь побудили вас прибегнуть к этому. Назову некоторые из них: возможность привлечь компетентных специалистов, необходимость быть в курсе новейших разработок на рынке и новых технологий, их соб­ственное стремление снизить расходы и максимизировать прибыль. Если ключевое для вас контактное лицо покинет производителя в критический момент вашего бизнес­плана, это окажет влияние на вас и вы не сможете проконсультироваться с ним, если он начнет работать на конкурента. А что случится, если ваш поставщик поддержки обанкротится? Условия контракта, гарантирующие непрерывность обслуживания, возможно, не будут стоить бумаги, на которой они записаны.

Второй вариант состоит в том, чтобы привлекать внешние ресурсы для первичной поддержки, но назначить для работы с ними внутреннюю команду, что будет гарантировать непрерывность отношений. Эта команда будет также контролировать действия по­ставщика внешних ресурсов, проверять выполнение им плана и оценивать качество предоставляемого персонала. Когда производитель выполняет ключевые задачи, такие как тестирование восстановления после аварии или обновление версии программного обеспечения, очень важно, чтобы вы или кто­то внутри вашей компании был знаком со всеми необходимыми шагами. Как я упоминала в первом варианте, производитель может исчезнуть через год, но ведь вам не хотелось бы стать косвенной причиной риска, которому подвергнется ваш бизнес.

Не стоит забывать также о проблеме конфиденциальности. Могут существовать причины не оглашать заранее ваши планы, такие как слияние или приобретение. Внутренняя составляющая команды поддержки сможет гарантировать, что никакие принимаемые ими решения не воспрепятствуют вашим планам, — не раскрывая ключевой информации. Хотя такой вариант может потребовать более высоких расходов, я отдаю предпочтение ему.

Заключение

Управление рисками составляет большую часть вашей работы по проектированию высокопроизводительных баз данных и обновлению приложений. Мне случалось работать и руководителем, и менеджером проектов. Помню плакат, который увидела на одном из семинаров по безопасности: «Выдающийся руководитель — тот, кто использует свои выдающиеся суждения, чтобы не пришлось применять его выдающиеся умения». То же самое можно сказать и о разработке и сопровождении программного обеспечения. Заблаговременное планирование позволяет избежать появления приводящих нас в трепет кризисных ситуаций. Задавать себе вопрос «А могли ли мы предвидеть, что все это случится?», после того как «все это» произойдет, — это совсем не то, чего каждый из нас желает. Так оценивайте риски заблаговременно! Аналогичным образом затраты времени на разработку хорошего проекта позволят избежать проблем с производительностью в будущем. Хорошо продуманная стратегия рисков способна предотвратить кризис, который может разрушить бизнес. Стремитесь включить оценку рисков в процесс мышления — и в описание заданий.

Простое создание Web­служб и их клиентских частей

Хотя SQL Server 2000 Web Services Toolkit существует уже давно, первоначально многие организации его игнорировали. Теперь, когда и Web­службы, и среда .NET распространены гораздо шире, настало время изучить (а может быть, и поддержать!) эту технологию.

Web­службы уже довольно давно стали «горячей» темой, однако SQL Server 2000 Web Services Toolkit остается малоизученным средством быстрого создания Web­служб. Хотя этот инструментарий позволяет очень быстро создать Web­службу на базе хранимой процедуры SQL Server или определяемой пользователем функции (UDF) совсем без использования кода, все же несколько строк потребуется написать, чтобы создать клиентское приложение для этой Web­службы. Более того, один из самых простых способов по­строения клиентской части состоит в использовании среды .NET Framework. По мере того как организации развертывают .NET Framework на все большем числе компьютеров, интерес к инструментарию SQL Server 2000 Web Services Toolkit может возрасти. Демонстрация объектов SQL Server через Web­службы особенно важна, потому что она позволяет использовать базы данных SQL Server в большем количестве контекстов. В основном, в организациях Web­службы создают больше путей использования имеющихся у них баз данных SQL Server. В этой статье рассказывается, как построить клиентскую часть для Web­службы на базе хранимой процедуры базы данных SQL Server и как создать клиентскую форму Windows средствами VB.NET.

Быстрый обзор Web­служб

Web­службы позволяют осуществлять вызовы удаленных процедур на одном компьютере с другого компьютера. Web­служба может показывать объекты SQL Server как Web­методы, которые действуют во многом аналогично обычным методам объектной модели. Когда с одного компьютера инициируется Web­метод на другом компьютере, первый удаленным образом инициирует эту процедуру (или Web­метод). Web­службы используют протокол SOAP (Simple Object Access Protocol) в качестве формата для передачи содержимого между рассматриваемой парой компьютеров. В то время как Web­службы можно применять для обмена между двумя приложениями на одном компьютере, намного интереснее случай, когда через SOAP взаимодействуют компьютеры, на одном из которых установлен SQL Server, а другой работает под управлением отличной от Windows операционной системы.

Инструментарий SQL Server 2000 Web Services Toolkit реализует Web­службы в промежуточном слое между клиентским приложением Web­службы и базой данных SQL Server. Компоненты Web­служб существуют в виртуальном каталоге для служб Microsoft Internet Information Services (IIS), Web­сервера Microsoft. Инструментарий SQL Server 2000 Web Services Toolkit предоставляет управляющую консоль Microsoft для создания и настройки Web­служб.

Полезные ссылки

• Scott Swigart «SQLXML Managed Classes» —http://msdn.microsoft.com/library/ default.asp?url=/library/en­us/Dnsql2k/html/sqlxml_intromanagedclasses.asp?frame=true.

• Drew Minkin «Inside the SQLXML Virtual Directory Structure» — http://msdn.microsoft.com/ library/default.asp?url=/library/en­us/Dnsql2k/html/ sql_insidevirtdirstruct.asp?frame=true.

• 321460 FIX: Patch Available for Script Injection with XML Tag and Unchecked Buffer in SQLXML ISAPI Extension Vulnerabilities.

• 320833 FIX: Script Injection with XML Tag and Unchecked Buffer in SQLXML ISAPI Extension Vulnerabilities.

• 321858 FIX: MDAC: Patch Available for Script Injection with XML Tag and Unchecked Buffer in SQLXML ISAPI Extension Vulnerabilities.

• 324669 WebCast: Programming ADO SQLXML to Execute SQLXML Queries. Related: 323920 PRB: Run­Time Error When You Use SQLXML 2.0 with ADO to Execute an Updategram.

• 324786 WebCast: Microsoft SQL Server 2000: How to Create and Consume Web Services Using SQLXML 3.0.

• 321911 MS02­030: SQLXML Security Updates.

• 810784 PRB: Error Message «HTTP Error 404 ­ File or directory not found» Occurs When You Access SQL Server 2000 with HTTP.

• 316866 HOW TO: Import XML into SQL Server with the XML Bulk Load Component. Related: 316361 PRB: SQLXMLBulkLoad Error Message 80046000: «The System Cannot Find The Path Specified» and 316371 PRB: SQLXMLBulkLoad Error Message 80040E14: «File Could Not Be Opened» or «File Does Not Exist».1(SQLXML 3.0 SP2 доступна на узле www.microsoft.com/down­loads/ details.aspx?FamilyId=4C8033A9­CF10­4E22­8004 477098A407AC&displaylang=en)

(Возврат на основную страницу)