(Возврат на основную страницу)
Editorial
Стратегии развития платформ Microsoft сегодня
.NET все еще загадка, но картина начинает проясняться
Питер О'Келли (Peter O'Kelly)
В этой статье рассказывается о прогрессе Microsoft в разработке .NET и содержится прогноз, перейдет ли полностью линия продуктов Microsoft в 2004 г. на .NET.
В середине 2000 г. стратегия .NET корпорации Microsoft была представлена на радикально отличающемся от нынешнего рынке программных средств. А именно: мыльному пузырю Интернета еще только предстояло лопнуть, технологические достижения были неоправданно переоценены, предприятия агрессивно инвестировали деньги в непроверенные программные области, а общее мнение о Microsoft склонялось к тому, что этот производитель программного обеспечения уходит со сцены.
Ожидалось, что Java и обработка данных на базе Web вообще вытеснят Microsoft с множества его основных рынков. Линия продуктов Microsoft тогда выглядела несколько старомодно, она была близка предыдущему поколению обработки данных на базе персональных компьютеров, но на шаг отставала от тогда совсем еще новых реалий Интернета. Движение за открытые исходные коды также заставляло многих сомневаться в неприкрыто коммерческой модели программного бизнеса Microsoft, хотя экономический спад, впоследствии внесший свой вклад во взрывное распространение обработки данных с открытыми исходными кодами на предприятиях, еще не наступил.
Стратегия .NET создавалась как ответ на все эти угрозы, она позволяла Microsoft скачком обойти конкурентов в платформах, инструментальных средствах и приложениях, а также использовала многие из тех же самых ресурсов и принципов работы, составлявших основу обработки данных в Интернете. Создатели .NET внесли большой вклад в разработку открытых стандартов для интеграции на системном уровне и даже установили со стратегическими партнерами и учебными заведениями отношения, разрешавшие совместно (не открывая полностью коды всем желающим) использовать часть исходных кодов.
После выхода .NET реакция рынка, как правило, определялась рыночными перспективами, существовавшими до этого события. Сторонники Microsoft рассматривали .NET как смелый шаг вперед, правда, это сопровождалось опасениями насчет совместимости и миграции. Наоборот, конкуренты и противники Microsoft либо объявляли .NET отчаянным маркетинговым маневром, либо резко критиковали ее как неполную, слегка замаскированную копию платформы Java. Более подробно об исторической перспективе.NET написано в статье «How the .NET Strategy Stacks Up (Как обстоят дела у .NET)», опубликованной в первом выпуске (осень/зима 2001) журнала «WindowsServer System Magazine», называвшегося тогда «.NET Magazine».
До сих пор, четыре года спустя после ее выхода в свет, стратегия .NET представляет собой некоторую загадку. Она лежит в основе системной архитектуры и общего видения Microsoft, однако, с общей точки зрения рынка, это одна из наиболее часто искажаемых страниц истории Microsoft. Для сравнения Whidbey/Yukonи Longhorn с исходной стратегией .NET ниже приведен краткий исторический обзор .NET и отчет о ее статусе.
История .NET
Стратегия .NET корпорации Microsoft, первоначально называвшаяся кодовым именем Next Generation Windows Services — NGWS (Службы Windows Следующего Поколения), была представлена на форуме Microsoft Forum в июне 2000 г., а ее подробная презентация происходила на конференции PDC 2000 в июле 2000. И тогда и сегоднястратегия .NET лежит в основе Webслужб XML и применения управляемого кода в среде .NET Framework.
На рис. 1 представлен подробный проект .NET, показанный на конференции PDC 2000.
Первоначально стратегия .NET с точки зрения развития платформ фокусировалась на следующем:
· создании основанной на виртуальных машинах платформы .NET Framework, состоящей из Common Language Runtime и .NET Framework, которая была призвана изолировать разработчиков от различий в базовых аппаратных средствах и версиях Windows;
· интегрированном семействе серверов масштаба предприятия .NET Enterprise Servers;
· интеллектуальных клиентских платформах с Windows PC и другими интеллектуальными устройствами (где «интеллектуальный» означает наличие процессоров, запоминающих устройств и прочих средств, обеспечивающих локальное исполнение приложений), которые включали бы .NET Framework (с полной версией .NET Framework для персональных компьютеров и .NET Compact Framework для иныхустройств);
· создании фундамента для Webслужб XML, построенных в соответствии с возникавшими тогда стандартами, такими как SOAP.
В исходном проекте .NET единственным инструментальным средством был пакет Visual Studio .NET; ожидалось, что те разработчики, которые пользовались предыдущими версиями Visual Studio, перейдут на Visual Studio .NET. Пакет Visual Studio .NET вводил Windows Forms и Web Forms и требовал серьезных изменений от разработчиков, использующих инструментальные средства предыдущего поколения. До .NET у Microsoft было три заметно различавшихся модели программирования: модель MFC/ATL для разработчиковC/C++; более простая модель для быстрой разработки приложений на базе подхода COM, применявшаяся разработчиками на VB и ориентированная на сценарии модель ASP для Webразработчиков. По мере того как стала превалировать разработка приложений для Web и задействованным в проектах командам приходилось комбинировать все эти три модели, сложность и идиосинкразия применения этих моделей стали основной проблемой. Проект .NET вводил новую унифицированную модель программирования, в которой комбинация лучших свойствболее ранних моделей должна была создать всеобъемлющую среду с улучшенной безопасностью и управляемостью (конечно, этому сопутствовало решение вопросов миграции и переобучения разработчиков).
Исходный проект .NET не включал специфических деталей прикладных продуктов, хотя Microsoft ссылалась на проект под кодовым названием NetDocs, в котором разрабатывался новый универсальный пользовательский интерфейс. Он должен был со временем стать ключевой составной частью также нечетко определенного будущего продукта Office.NET. NetDocsпозднее превратился в XDocs и в итоге был выпущен как InfoPath.
Ключевой частью исходного проекта .NET были службы, при этом множество разнообразных блочных услуг (к примеру, идентификация, аутентификация и скрытое хранение) должно было предоставляться корпорацией Microsoft и сторонними поставщиками. Например, ожидалось, что паспорт будет расширен и полностью перейдет на платформу .NET.
Инструменты коммуникации и совместной работы не были в центре внимания на PDC 2000. В то время в центре стратегии совместной работы, предлагавшейся Microsoft, находился Microsoft Exchange. Он обеспечивал мгновенный обмен сообщениями, организацию конференций и поддержку некоторых видов приложений для совместной работы. Выпущенный в свет в начале 2001 Windows XP включал Windows Messenger для услуг мгновенной пересылки сообщений, включая тексты, аудио и видеоинформацию. Однако возможности передачи звука и изображения применялись нечасто, поскольку ими было трудно воспользоваться при наличии брандмауэров и устройств трансляции сетевых адресов (NAT).
Более подробно о подходе .NET
В общем, выпуск .NET представлял собой крайне амбициозную и разрушительную подвижку стратегии Microsoft. Периоды альфа и бета тестирования NET 1.0 продолжались примернодва года.
По мере того как в 2000 и 2001 гг. разработчики продолжали изучать и тестировать версии альфа и бета Visual Studio в .NET Framework, корпорация Microsoft выдвинула новую инициативу с первоначальным кодовым именем HailStorm, которая впоследствии вышла под маркой .NET My Services. В HailStorm проявилось смелое видение нового поколения персональных компьютеров. Они предоставляли пользователямгораздо больше возможностей управления всей представленной в цифровом виде информацией (документами, контрактами, избранным, фото и т. д.) с ненавязчивым использованием схемы XML. При этом услуги Web обеспечивали незаметную для пользователя связь и совместнуюработу, стирающую границы рабочей и личной областей.
На PDC 2001 было проведено несколько убедительных демонстраций HailStorm, построенных на мириадах служб Microsoft, включая и те, которые тогда назывались MSN Network, MSN Hotmail, MSN Messenger, MSN Mobile и MSN MoneyCentral.Первоначальными партнерами Microsoft по HailStorm были eBay, Expedia (тогда еще под управлением Microsoft), и другие лидеры в электронной коммерции.
К несчастью для Microsoft, вскоре успешное представление HailStorm обернулось маркетинговым провалом, поскольку Microsoft сочли не вполне идеальным поставщиком услуг обработки личной информации, такой как медицинские записи. Кроме того, тогда корпорацию яростно обвиняли в потенциальном нарушении вопросов конфиденциальности и управления, связанных с технологией интеллектуальных тэгов (smart tag), планировавшейся к применению в Office XP. Во многом HailStorm просто опережал свое время, и его тихонько низвели на значительно более мелкие роли в общей истории .NET, сначала передав на откуп сторонним поставщикам услуг, а затем по существу устранив вообще.
Конференция PDC 2001 происходила спустя два месяца после событий 11 сентября 2001 г. и в разгаре спада в индустрии ИТ, вызванного последствиями скандала с Интернетом. Эта обстановка радикально отличалась от той эйфории, которая царила в отрасли во время конференции PDC 2000. По существу, предприятия не намеревались немедленно начинать эксплуатировать .NET My Services, даже если бы эти продукты уже были доступны. Тем не менее HailStorm вместе с чересчур рьяным маркетингом и раскруткой марки .NET (к примеру, серверы .NET Enterprise Servers на самом деле не соответствовали .NET) выхолащивали значение.NET, что нанесло серьезный урон этой торговой марке.
Версии 1.0 продуктов .NET Framework и Visual Studio .NET вышли в свет в феврале 2002 г. С точки зрения платформ и инструментария Microsoft начала реализовывать представления PDC 2000. Как .NET Compact Framework, так и другие элементы общей стратегии .NET, объявленные на PDC 2000, появятся позднее с задержкой от нескольких месяцев до ряда лет.
Задержки не были катастрофической неудачей для Microsoft в основном изза существенных перемен в рыночных условиях и в требованиях заказчиков, произошедших между 2000 и 2002 гг. Бюджеты предприятий, выделяемые на информационные технологии, радикально урезались, что сказалось и на Microsoft, и конкурентах. Как ни парадоксально, это было на руку Microsoft, поскольку .NET еще не была полностью готова к выходу в свет. Начальные выпуски Visual Studio .NET и .NET Framework создавали прочную базу, но они были ограничены многими факторами, начиная с очень крутой кривой обучения и заканчивая большим объемом загружаемых файлов .NET Framework (более 20 Mб), необходимых для запуска приложений Windows Forms.
На практике подавляющее большинство ранних приложений .NET представляло собой Webприложения, написанные для тонких клиентов (браузеров) с использованием ASP.NET и ADO.NET, так как ASP.NET было намного совершеннее версий ASP, предшествовавших .NET. Намного меньше приложений Windows Forms было написано для интеллектуальных клиентов отчасти изза того, что интересы рынка фокусировались на Webприложениях, а также потому, что технические условия .NET Framework ограничивали рамки приложений, которые бы легко развертывались и управлялись. Предприятия хотели централизованно управлять и контролировать Webприложения и отказывались принимать возможности администрирования интеллектуальных клиентов.
В этот период Microsoft ввела глобальную архитектуру Global XML Architecture (GXA) в качестве широкой основы для XML и тесно сотрудничала с W3C и другими производителями в разработке того, что в последствии станет стандартами серии WS*. Был выпущен также первый набор усовершенствований Web Services Enhancements (WSE), предназначенных для Visual Studio .NET. Они позволяли разработчикам знакомиться с WS*, не дожидаясь полного обновления Visual Studio .NET. В то время Webслужбы были массированно дискредитированы и в большинстве находились на стадии пилотного тестирования, развертывалось лишь несколько широкомасштабных систем на базе Webслужб.
Итак, прогресс .NET в 2002 году в основном ограничился выходом Visual Studio .NET и приложений Web Forms на базе ASP.NET.
Состояние .NET в 2003–2004 гг.
.NET все еще является той лошадкой, на которую Microsoft делает практически все свои ставки. Несмотря на смятение и разногласия на рынке и благодаря существенному подъему рынка программного обеспечения базовое видение .NET и его определение почти не изменились с середины 2000 г. В широком смысле Microsoft определяет .NET как программное обеспечение, объединяющее людей, информацию, системы и устройства. Как и прежде, .NET подразумевает разработку приложений на следующей основе.
· Применение Webслужб, основанных на XML, для взаимодействия приложений (а зачастую и приложений для интрасетей), а также коммуникации на основе сообщений, то есть отвечающих подходу SOA и требованиям соответствующих стандартов. Хотя в .NET вошли инициативы WS* (многие из которых возглавлялись самой корпорацией Microsoft), не должно быть никаких сомнений в том, что .NET сейчас и всегда подразумевала службы Web.
· Управляемое исполнение кода в среде .NET Framework, которая в свою очередь состоит из Common Language Runtime (CLR, виртуальной машины .NET) и множества библиотек классов — широкой и глубокой коллекции компонентов и служб, удовлетворяющих потребности презентации, хранения и связи. В этих библиотеках инкапсулированы относящиеся к нижним уровням основы операционных систем, такие как потоки, графика и управление драйверами. Управляемый код более безопасен, так как он ориентирован на виртуальную машину, а не обращается напрямую к используемой операционной системе. Он также повышает производительность разработчиков, так как автоматически выполняются функции нижнего уровня, такие как управление оперативной памятью и уборка мусора. Кроме того, в одной и той же среде применяется множество языков программирования.
Часть истории .NET, относящаяся к виртуальным машинам, тесно переплетается с историей ее конкурента — платформы Java. Обе они построены на десятилетиях предшествовавших исследований и разработок виртуальных машин. Существует одно фундаментальное различие: Java проектировалась для работы на множестве платформ, но с поддержкой единственного языка программирования. .NET проектировалась для поддержки множества языков программирования на Windows (как в персональных компьютерах, так и на других машинах). Пользуясь терминологией служб Web, стратегия .NET поддерживала эти службы с момента своего зарождения в продуктах .NET Framework и Visual Studio .NET, а также во всех расширениях, которые Microsoft публиковала в промежутках между выходами основных версий этих продуктов.
Об использованной в этом обзоре среде можно сказать, что к настоящему времени .NET оказала влияние на платформы и инструментальные средства Microsoft. Если оценивать в ключевых терминах определения .NET, то есть учитывая наличие основанных на XML служб Web и управляемого кода в .NET Framework, то сегодняшнее семейство продуктов Microsoft находится приблизительно на полпути к полному внедрению .NET. Продукты Visual Studio .NET и .NET Framework, выпущенные в начале 2002 г., были первыми продуктами, полностью соответствующими .NET. Разработчики быстро ознакомились с возможностями .NET Framework, предоставляемыми для разработки услуг и приложений Web (ASP.NET), доступа к данным (ADO.NET) и построения приложений Windows (Windows Forms).
Другие продукты Microsoft перешли на идеологию .NET в течение прошлого года, включая Windows SharePoint Services и Office SharePoint Portal Server 2003, и еще несколько таких же событий должны произойти в 2004. Продукт .NET Framework теперь включается в поставки серверных и клиентских версий Windows (он вошел в Windows Server 2003 и в сервисный пакет для Windows XP). Однако к наиболее значимым составляющим текущей линии продуктов Microsoft, еще не полностью перешедшим на .NET, относятся Office, Exchange, SQL Server, и, что крайне важно, большая часть Windows API (Win32). Все они пока еще существенно базируются на предшествовавших идеологии .NET моделях COM и COM+, несмотря на то, что возможности взаимодействия в .NET намного сильнее. Хотя расписание выпуска продуктов изменилось со времен PDC 2000, важно понять, что стратегия .NETв отношении продуктов, инструментальных средств и приложений осталась в основном неизменной.
По контрасту с этим торговая марка .NET после PDC 2000 использовалась часто непоследовательно и двусмысленно. И теперь Microsoft приходится вычищать контекст, в котором эта марка применима. Самые большие проблемы с маркой .NET возникли по собственной вине. Маркетинговые усилия Microsoft были чрезмерно рьяными, и эту марку преждевременно задействовали в продуктах, которые либо не соответствовали полностью .NET, либо просто не существовали. К примеру, как показано на рис. 1, Microsoft создала новую торговую марку в виде зонтика серверов .NET Enterprise Servers для существующих серверных продуктов и порой ссылалась на будущий комплект Office.NET. Однако ни один из серверов .NETEnterprise Servers понастоящему не отвечал базовым определениям .NET, а Office.NET никогда не появлялся.
Microsoft также навредила марке .NET, ассоциировав ее с инициативой HailStorm. Видение HailStorm было новаторским, но попытка корпорации Microsoft реализовать его в виде продукта намного опережала потребности рынка. Кроме того, Microsoft поймали на серии совпадающих конспиративных предположений, касающихся ее намерений и позиции относительно конфиденциальности информации потребителя. То, что впоследствии эту инициативу назвали настоящим бедствием, конечно же, не помогло компании.
Помимо того маркетингового вреда, который Microsoft нанесла себе сама, и общих теорий конспирации, связанных с корпорацией Microsoft, надо отметить еще и возрастающую избыточность собственно марки .NET. Поскольку большинство продуктов Microsoft будет приведено в соответствие с идеологией .NET в ближайшие несколько лет, Microsoft не нуждается более в квалификаторе .NET для того, чтобы отличать свои продукты на базе .NET от продуктов предыдущего поколения.
Даже для исходного набора .NET Services марка была изменена; теперь он называется Connected Services от Microsoft и в настоящее время включает Microsoft Alerts, Passport, MSN Messenger Connect for Enterprises и MapPoint Web Service. У Microsoft имеется также программа логотипов .NET Connected для компаний, которые желают ассоциировать свои продукты с .NET. Неудивительно, что требования для получения сертификата логотипа .NET Connected включают построение управляемого кода в среде .NET Framework и производство или потребление услуг Web.
Сегодня сокращающийся список предложений Microsoft, все еще использующих марку .NET, включает Visual Studio .NET, Windows CE.NET и Microsoft .NET Passport. По прогнозам Burton Group данные продукты тоже потеряют эту марку в последующих основных версиях, потому что Microsoft сообщила, что планирует переопределить .NET, на это раз низводя эту марку до термина, означающего подмножество WinFX (интерфейс разработчика API в Longhorn) без ограничений на свободное распространение. Разумеется, следующая версия Visual Studio .NET под кодовым названием Whidbey будет выпущена как Visual Studio 2005 (без квалификатора .NET).
В любом случае проблемы и изменения в раскручивании корпорацией Microsoft торговой марки .NET не следует неправильно истолковывать как индикаторы того, что Microsoft колеблется в своей приверженности исходному видению .NET и стратегии развития продуктов. Стратегия .NET попрежнему будет важным термином при описании сообщества разработчиков, применяющих продукты Microsoft для создания приложений, отвечающих SOA, — просто .NET в будущем не будет использоваться в качестве суффикса в названиипродуктов.
В появившихся в 2003 платформах Microsoft обнародовала Windows Server System, состоящую из Windows Server 2003 и ряда серверов масштаба предприятия (уже без марки .NET), включая SQL Server, SharePoint, Exchange и другие. Windows Server 2003, давно ожидавшийся преемник Windows Server 2000 и серверный аналог клиентского Windows XP, содержит множество важных усовершенствований и расширений. Это был первый сервер Windows, в который вошла .NET Framework (новая версия 1.1).
На более высоком уровне в стеке Windows Server стоит вышедшая в октябре новая версия SharePoint. Она стала понастоящему соответствующим концепции .NET сервером для предприятий (хотя к тому времени марку .NET тихо убрали из названия Enterprise Server). Продукт Windows SharePoint Services (включаемый в Windows Server 2003)и его компаньон Office SharePoint Portal Server 2003 являются реальными приложениями .NET, в них среда .NET Framework расширена классами и службами, ориентированными на совместную работу. Еще одним важным индикатором для Windows Server System является то, что в SharePoint для хранения информации задействован исключительно SQL Server 2000, тогда как в более ранних выпусках SharePoint применялась смесь файловой системы Windows, SQL Server и разработанной Microsoft машины Jet (подсистемы хранения, используемой в Exchange).
2003 стал определяющим годом также для коммуникационных продуктов Microsoft и серверов, предназначенных для коллективного использования. Имевшаяся ранее в Exchange 2000 поддержка совместной работы была удалена и заменена возможностями, предоставляемыми новыми продуктами Office Live Communications Server (сервером SIP и SIMPLE), SharePoint и Office Live Meeting (первоначально выступавшим под маркой службы PlaceWare, за ними последует еще версия традиционного программного продукта для домашнего применения Live Meeting).
Среди клиентских платформ к нескольким версиям Windows Mobile была добавлена .NET Compact Framework, а обновление Windows XP добавило .NET Framework к основным платформам Windows для персональных компьютеров.
Набор инструментальных средств Microsoft был также усовершенствован и упрощен в 2003 г. В апреле 2003 г. увидел свет Visual Studio .NET 2003 (а исходная версия Visual Studio .NET, выпущенная 14 месяцами раньше, задним числом получила суффикс 2002). Основные усовершенствования Visual Studio .NET 2003 были направлены на повышение производительности разработки, а новые возможности упростили переход от приложений и технологий Microsoft, предшествовавших .NET, и облегчили взаимодействие с ними.
В 2003 Microsoft также инвестировала значительные ресурсы в образование для разработчиков и в обмен лучшими практическими решениями, включая широкий ассортимент публикаций с образцами и жизненными примерами, посвященных таким областям, как архитектурные модели и детальные руководства по взаимодействию с .NET/J2EE.
На пересечении приложений и инструментальных средств новый продукт Visual Studio Tools for Office позволяет разработчикам приложений обращаться с Office 2003, как с набором компонентов и служб из Visual Studio .NET, работать с управляемым кодом (возможность взаимодействия обеспечивается слоем, находящимся над СОМ, собственной архитектурой Office). Кроме того, он расширяет возможности .NET Framework и предоставляет пути отхода от ранних инструментальных средств Office Developer (VBA), которые плохо приспособлены к приложениям для Интернета. Среди приложений для бизнеса наиболее значительным вкладом MBS в 2003 году сталпродукт Microsoft CRM, который также частично базируется на .NET.
Подводя итоги, сформулируем, на чем сфокусирована линия программных продуктов Microsoft по состоянию на середину 2004 года.
· Платформы. Windows Server System реализует серверную платформу Windows, .NET Framework, а также слои высокого уровня в серверном стеке для управления базами данных (SQL Server), обменом сообщениями в рамках предприятия (Exchange), порталами (SharePoint), XMLориентированной интеграцией приложений предприятия (BizTalk Server и Host Integration Server) и многим другим. Windows XP — это первая клиентская платформа для персональных компьютеров, включающая специализированные версии Tablet PC и Media Center. Существуют также варианты Windows не для персональных компьютеров, а для мобильных устройств и встроенных компьютерных контекстов. Многие версии Windows теперь включают .NET Framework или .NET Compact Framework.
· Инструментальные средства. Visual Studio .NET является центром стратегии Microsoft по созданию инструментария для разработчиков, при этом ранние инструменты разработчика, от Access до предшествовавшего .NET Visual Basic, либо совсем устраняются, либо низводятся до незначительных ролей с той быстротой, которую выдержит рынок разработки. Visual Studio .NET пока не описывается как система (как Windows и Office), но, безусловно, является ею, предоставляя широкий, глубокий и расширяемый IDE.
· Приложения. Microsoft Office System представляет собой рабочую информационную среду Microsoft, и она позиционируется в большей степени как интегрированный набор специализированных редакторов и инструментальных средств (для визуализации данных и манипулирования ими, для обеспечения коммуникаций и совместной работы и для многого другого), чем как коллекция автономных приложений для повышения производительности. Семейство продуктов Microsoft Business Solutions претерпевает аналогичные метаморфозы, оно перестраивается заново на новой основе .NET Business Framework.
· Службы. Пока еще без систематической организации — но Microsoft предлагает «строительные блоки» для общественных служб идентификации и аутентификации (Passport), извещения и предупреждения, а также специализированные службы, такие как MapPoint для картографии и услуг, базирующихся на учете местоположения. К концу 2003 г. Microsoft сообщила о том, что Passport вырос настолько, чтобы обеспечивать 500 миллионов операций аутентификации в день с коэффициентом использования 99,8—99,9 для приблизительно 350 миллионов активных пользовательских учетных записей. Службы Microsoft в 2003 также расширялись, предлагая более досконально продуманные услуги на базе Web, такие как MSN, Microsoft Office Live Meeting и Microsoft Business Network. Совместно используя марки Live с Office Live Meeting и Office Live Communications Server, служба Xbox Live, которая предлагает игры в Internet в реальном времени с участием множества игроков и передачей речи по IP (VoIP), к концу 2003 г. выросла до 750 000 подписчиков.
Развивались также точки интеграции между линиями продуктов. К примеру, Office System 2003 г. позволяет делать следующее:
· естественным образом совмещать Windows SharePoint Services с новыми разделяемыми панелями документов и задач, а также с управляемыми сервером списками;
· включать во многие контексты средства оповещения о присутствии и коммуникационные средства реального времени, привязывая службы SIP и SIMPLE к Office Live Communications Server и общедоступной службе Passport;
· использоваться с помощью нового инструментального набора Visual Studio Tools for Office в качестве набора компонентов и служб Visual Studio;
· задействовать службы Web в разных контекстах, включая исследования, системную помощь и отчеты об ошибках;
· применяться в решениях Microsoft Business Network для обеспечения обработки XML и в качестве средства разработки приложений.
Office и другие продукты Microsoft также часто интегрируют в продукты и службы других компаний. Свежими примерами использования Office System являются контекстные связи с Salesforce.com и Amazon.com.
Прогноз для .NET на 2005 и ближайшие годы:назад к будущему .NET
Линия продуктов Microsoft по состоянию на середину 2004 приблизительно на 50 процентов отвечает .NET. Инструментальные средства Microsoft, среди которых доминирует Visual Studio .NET 2003, полностью перешли на .NET. Выпускаемые корпорацией платформы частично приведены в соответствие с .NET, причем во многие платформы входят .NET Framework и различные серверы, включая SharePoint и BizTalk Server 2004, которые теперь полностью основаны на .NET. Приложения Microsoft еще не полностью соответствуют .NET, хотя Office 2003 предлагает множество точек интеграции на базе .NET. Службы «строительных блоков», которые прогнозировались четыре года назад, когда .NET только появлялась, пока не полностью реализуют .NET, хотя налицо быстрыйпрогресс Microsoft с Passport и другими общедоступными службами.
Whidbey и Yukon являются следующими опорными вехами в истории развития .NET. Whidbey — это кодовое имя для будущих основных выпусков Visual Studio и .NET Framework, а Yukon — кодовое название SQL Server 2005.
DB Design & Warehousing
Открываем инструментарий Microsoft для настройки производительности
Использование методологии анализа задержек и очередей для повышенияпроизводительности SQL Server
Том Дэвидсон (Tom Davidson)
Настройка производительности SQL Server представляет собой большую и сложную задачу. Ключом к успешной настройке производительности служит разбиение этой задачи на несколько более мелких и простых задач. В принадлежащей Microsoft лаборатории по работе с клиентами SQL Server команда консультантов Customer Advisory Team использует информацию о задержках и очередях SQL Server как часть постоянно применяемой методологии — инструментария настройки производительности — для систематического анализа и разрешения возникающих у заказчиков проблем с производительностью SQL Server.
Мы периодически устанавливаем пользовательские приложения у себя в лаборатории, чтобы оценить качество проектирования приложения и баз данных, измерить производительность и дать рекомендации по повышению масштабируемости. Всего за одну неделю мы устанавливаем пользовательские приложения и базы данных, готовим конфигурацию для тестирования производительности и применяем методологию задержекиочередей для выявления узких мест. При этом часто обнаруживаются просчеты в архитектуре и в проектировании системы. Хотя эта методология не заменяет хорошего проектирования на физическом уровне, надлежащего индексирования и качественного написания кода SQL, она предоставляет возможность увидеть вероятные проблемные места производительности, связанные с управлением кэшем, многократным использованием планов исполнения, перекомпиляцией, управлением транзакциями и использованием ресурсов.
Методология задержекиочередей рисует детальную картину производительности приложения. SQL Server отслеживает статистику задержек, она включает более 50 различных причин их возникновения, которые называются типами задержек. С этими задержками пользовательское соединение может столкнуться при ожидании конкретного ресурса. Увидеть информацию о задержках пользовательских соединений можно в столбцах waittype и waittime системной таблицы sysprocesses базы данных master. SQL Server также агрегирует задержки по всем пользовательским соединениям, формируя профиль производительности для заданной нагрузки. Таким образом, типы задержек SQL Server идентифицируют и классифицируют испытываемые пользователем (или потоком) задержки с позиции пользователя или рабочей нагрузки приложения.
Счетчики Performance Monitor и другие источники информации предоставляют этой методологии измерения производительности сведения об очередях. Когда SQL Server выполняет оператор SQL для пользовательского соединения, он использует такие системные ресурсы, как оперативная память, подсистема ввода/вывода и процессор. Если запрос системного ресурса не может быть удовлетворен незамедлительно, подсистема управления ресурсами ставит этот запрос в очередь до тех пор, пока ресурс не станет доступным. В состав Performance Monitor входят счетчики, которые собирают сведения о пропускной способности этих системных ресурсов.
Чтобы извлечь полезную информацию из данных о величинах задержек и очередей, необходимо соотнести между собой типы задержек, показания счетчиков Performance Monitor и некоторые их соотношения. Это даст основание для вывода заключений о производительности и узких местах приложения. Вот как следует производить анализ информации, получаемой посредством типов задержек.
Планирование безопасности баз данных Microsoft SQL Server в масштабах предприятия
Если вы применяете базы данных Microsoft SQL Server для жизненно важных приложений предприятия, то поддерживаете нарастающую тенденцию. Преимущества Microsoft SQL Server на платформах Microsoft Windows NT и Windows 2000 по критерию цена/производительность стимулировали распространение SQL Server в качестве платформы для приложений класса предприятия.
Простая в применении и эффективная по стоимости платформа в конечном счете не облегчает решение проблем, возникающих при администрировании промышленных баз данных. По мере роста размеров баз данных и количества таких баз в промышленных приложениях важной задачей становится адекватная и эффективная их защита.
Собственные утилиты резервного копирования, распространяемые в составе Microsoft SQL Server, ориентированы на системы разработки или небольшие промышленные базы данных. Если ваши промышленные базы данных небольшого размера, скорее всего, это именно то что надо. Но если вы стали использовать базы данных SQL Server в интенсивно работающей промышленной среде с огромными объемами данных и транзакций, задача управления и сопровождения этих баз данных неожиданно становится более сложной.
Рассмотрим спектр проблем, которые могут потребовать решения от администратора баз данных, отвечающего за несколько больших промышленных баз.
· Пакетное задание испортило одну таблицу. Вам необходимо восстановить эту таблицу, пользуясь резервной копией. Применение собственных утилит SQL Server предоставляет вам единственную возможность — восстановить базу данных целиком. Для большой базы данных это может занять много времени, что приведет к дорогостоящему простою.
· Вам необходимо манипулировать объектами базы данных или перемещать их с сервера на сервер. Например, находящиеся на тестовой системе некоторые хранимые процедуры или триггеры готовы к использованию в промышленной системе, как и новая таблица. Если у таблицы имеется множество зависимостей, воссоздание ее в производственной системе может оказаться весьма трудоемким.
· Сбой диска повредил базу данных master. Вам необходимо быстро восстановиться, но прежде вам придется определить конфигурацию базы данных master, существовавшую до выхода из строя.
· Вы добавили три новых промышленных базы данных без привлечения дополнительных администраторов. Старший администратор собирается пойти в отпуск на следующей неделе, и вы беспокоитесь, сможете ли сами охватить все.
Ясно, что вам нужен более продуманный план обеспечения безопасности баз данных — такой, который учитывает не только сами данные, но и опыт администраторов, и применяемые ими процедуры. В этой статье описаны требования к такому плану. В ней также рассказывается, как новый продукт SQLBackTrack for Microsoft SQL Server совместно с BMC Software поможет вам внедрить всесторонний план, позволяющий обезопаситьжизненно важные данные от множества потенциальных проблем.
Other
Перемещение баз данных Tempdb и Master в SQL Server
Стивен Уоррен (Steven Warren)
Во многих случаях мне требовалось переместить базу данных и файлы журналов на другие диски для улучшения производительности. Когда для повышения производительности необходимо переместить типичную пользовательскую базу данных или разбить журналы на несколько частей, обычно для этого запускают sp_detach и sp_attach. Однако, когда приходится перемещать базы данных Master и Tempdb, применяются совершенно иные правила. В данной статье мы собираемся провести вас через процесс перемещения этих баз данных.
Перемещение базы данных Master
Бывали случаи, когда мне требовалось переместить файл журнала базы данных Master или саму базу данных на другой диск. Если вам когданибудь придется выполнять эти действия, следуйте приведенным правилам, чтобы успешно перенести базу данных master. Сначала щелкните правой кнопкой мыши по SQL Server в Enterprise Manager (EM) и выберите Properties. Затем щелкните по Startup Parameters, как показано на рис. 1. В окне появятся следующие параметры:
· d — полностью квалифицированный путь к файлу данных базы master;
· e — полностью квалифицированный путь к файлу журнала ошибок;
· l — полностью квалифицированный путь к журналу базы данных master.
Рис. 1
Теперь, если вы хотите перенести файлы, надо убрать текущую запись и создать новую с правильно указанным путем. К примеру, я собираюсь перенести базу данных Master в C:\test\. На этом шаге я удалю l [путь], высветив старый параметр и выбрав remove (рис. 2). Затем добавлю следующую запись (рис. 3), l C:\test\mastlog.ldf и дважды нажму OK. Теперь остановим SQL Server и перенесем mastlog.ldf на новое место.
 |
 |
|
| Рис. 2 | Рис. 3 | Рис. 4 |
Примечание: пожалуйста, убедитесь в том, что вы перемещаете mastlog.ldf в тот самый каталог, который указали в конфигурации параметров запуска. Если вы перенесете его в другое место, не указанное в параметрах запуска, то SQL Server не запустится.
Наконец, запустите SQL Server. Теперь вы успешно завершили перенос базы данных Master, как показано на рис. 4.
Перемещение Tempdb
Чтобы перенести базу данных tempdb, откройте анализатор запросов и запустите следующий запрос:
use master
go
Alter database tempdb modify file
Ã
(name = tempdev, filename = 'E:\Sqldata\tempdb.mdf')
go
Alter database tempdb modify file
Ã
(name = templog, filename = 'C:\Test\templog.ldf')
Go
В зависимости от того, куда вы собираетесьперенести Tempdb, вы задаете параметр filename=parameter. Я собираюсь перенести templog в c:\test, как в коде выше. После того как этот запрос будет выполнен, удалите старый файл после перезапуска SQL Server.
Перемещение базы данных MSDB
Для переноса баз данных MSDB и Model выполните следующие шаги. Вопервых, щелкните правой кнопкой по названию SQLServer и по свойствам. На закладке General выберите параметры запуска. Затем введите параметр T3608. Щелкните OK, остановите и перезапустите SQL Server. После перезапуска отсоедините базы данных и перенесите их в нужное место.
Итоги
Когда бы ни возникла необходимость в переносе файлов системных баз данных на другие диски изза того, что на диске осталось слишком мало места, следуйте этим простым процедурам. Это позволит вам эффективно и надежно перемещать файлы.
(Возврат на основную страницу)
