(Возврат на основную страницу)
Editorial
Понимание стратегий платформы Microsoft
Место Whidbey/Yukon и Longhorn в мире .NET Framework
Питер О’Келли (Peter O'Kelly)
Сегодня шлюзы компании Microsoft широко открыты, и в прошлом году на нас хлынул поток новых выпусков продуктов и стратегий. Кроме того, на октябрьской конференции профессиональных разработчиков (PDC, Professional Developers Conference) 2003 года, были раскрыты детали стратегии следующих двух волн платформ и инструментов компании.
В целях планирования деятельности предприятий сферы ИТ важно правильно оценить эти волны продуктов не только в более широком контексте полного развития платформы приложения, но также относительно стратегии .NET компании Microsoft, поскольку эти волны являются более значимыми, чем традиционные обновления продуктов.
Первая из двух волн будущих продуктов Microsoft ожидается в течение первой половины 2005 года и включает инициативы под кодовыми названиями Whidbey и Yukon. Whidbey представляет собой версию 2.0 .NET Framework и существенно обновленный выпуск Visual Studio (Visual Studio 2005). Yukon является значительным обновлением SQL Server (SQL Server 2005). Выпуск Whidbey/Yukon и других продуктов Microsoft, запланированный на 2004 и 2005 годы, проясняет общую стратегию .NET компании Microsoft и улучшает положение Microsoft в завершающейся эволюции ландшафта рынка платформ приложений.
Вторая волна сфокусирована на Longhorn, кодовом имени для следующего значимого семейства программных продуктов Microsoft (выпуск которого запланирован после волны Whidbey/Yukon), и начнется с реализации заметно улучшенной клиентской операционной системы Windows. Временные оценки выпуска Longhorn существенно разнятся, хотя сама Microsoft намечает его на 2006 год. Сегодня представляется довольно бессмысленным рассуждать о точном времени выхода Longhorn, поскольку разработка проекта находится на стадии альфа-версии, и этот вопрос прояснится только в следующем году.
Longhorn в некотором роде парадоксален. Он представляет собой вершину стратегии платформы .NET компании Microsoft (открытой в середине 2000) и новое, широкое, глубоко интегрированное основание для будущих программных продуктов и решений Microsoft. Longhorn можно рассматривать как последовательный эволюционный шаг по отношению к Windows XP, но также в качестве впечатляющего достижения с точки зрения инструментальной и пользовательской концептуальных моделей и основных возможностей платформы. Продвижение на рынке и потребление Longhorn будет трудно прогнозировать до тех пор, пока Microsoft не раскроет также детальных планов относительно Office 12 и Green (кодовое имя для выпусков Office System и Microsoft Business Solution), что было бы оптимальным для полноты использования и, таким образом, увеличило спрос на Longhorn.
При оценке двух следующих волн продуктов Microsoft нужно учитывать, что Microsoft не одинока в своей стратегии совершенствовать семейства продуктов, использующих открытые стандарты для взаимодействия и интеграции системного уровня, наряду с напористой нацеленностью на тесно интегрированный и запатентованный набор платформ, инструментов, приложений и служб для установления конкурентных разграничений.
Рассматриваем волны продуктов в контексте
Эта статья является первой из серии, посвященной тенденциям и анализу, которая поможет рассмотреть в контексте текущие и будущие волны продуктов Microsoft. Остаток статьи представляет собой исследование общих тенденций рынка программного обеспечения и применим как к Microsoft, так и к ее главным соперникам, таким как IBM, BEA, Oracle и Sun. Следующая статья серии еще раз возвратит нас к стратегии .NET компании Microsoft и даст оценку продуктов 2003—2004 годов этой компании относительно общих тенденций рынка и философии .NET компании Microsoft. Третья статья будет сфокусирована на достижениях Whidbey и Yukon, а четвертая рассмотрит Longhorn относительно каркаса приложений, введенного ранее в этой серии.
Чтобы начать анализ тенденций рынка программного обеспечения, влияющих на Microsoft и ее соперников, будет полезным распределить эти тенденции по категориям и рассмотреть их примере платформ, инструментов, приложений и служб.
Размышляем над тенденциями платформы
Наиболее значимой тенденцией платформы является усиление направленности на обеспечение всесторонней безопасности и управляемости каркасов (framework) приложений. И хотя, возможно, это не самая волнующая тенденция для разработчиков приложений, все же она является главным бизнес-приоритетом и влияет на каждый аспект пакета платформы приложений. Безопасность и управляемость, в значительной степени оставлявшиеся на усмотрение разработчика и настраиваемые вручную, теперь все в большей мере основаны на самом каркасе, управляются с помощью политик, автоматизированы и вводятся в действие принудительно и автоматически.
Стремление к улучшению безопасности и управляемости приложений, наряду с насущной необходимостью улучшения продуктивности разработчиков и гибкости приложений, привело к значительному сдвигу в сторону виртуализации. Одной из форм виртуализации является переход к новому рабочему циклу платформы приложений, основанному на архитектурах виртуальной машины и обширных интегрированных каркасов классов (class framework). Главными примерами могут служить платформы Java и .NET компании Microsoft. Обе они основаны на использовании управляемого (managed) кода — программ, нацеленных на виртуальные машины, а не на базовую аппаратную архитектуру, и создающих основу для гораздо большей безопасности и более мощных приложений.
Необходимость поддержки существующих приложений, не подрывающих безопасности и управляемости каркасов приложений уровня платформы, достигается с помощью другой формы виртуализации, в которой старые операционные системы запускаются в виртуальных «песочницах» (sandbox) поверх современных платформ. Хотя этот тип виртуализации пока используется нечасто, считается, что он будет быстро распространяться, по мере того значительно меняя посылки и критерии принятия решений о том, что для поставщиков программного обеспечения означает практическую независимость от платформы.
Наступление сетевой платформы приложений, чему способствовал сдвиг к философии архитектуры, ориентированной на поставку служб (SOA, service-oriented architecture) для развития приложений, является другой тенденцией, приводящей к глубоким изменениям платформы. По мере усиления единодушия рынка в том, что архитектуры распределенных объектов (такие как CORBA, RMI, DCOM и .NET Remoting) не отвечают интеграции системного уровня (между приложениями), основанной на использовании Интернет-технологий, SOA быстро становится выбором по умолчанию для системной интеграции. Этому способствует, в частности, принятие в масштабах индустрии стандартов Web-служб (широко упоминаемых как WS-*, что является условным обозначением для бессчетных стандартов этих служб, вводимых для защищенной, надежной, транзактной передачи сообщений между несколькими конечными точками).
Другой важной тенденцией для платформы является то, что границы между операционными системами и специализированными серверами для управления базами данных, обмена сообщениями на предприятии, порталов/презентаций, совместной работы и других запросов быстро размываются. По мере того, как все больше служб добавляется в новые платформы (к виртуальным машинам и операционным системам), а SOA-архитектура модернизирует и упрощает системную интеграцию, традиционные категории продуктов для систем управления базами данных (СУБД), мониторов обработки транзакций и промежуточного программного обеспечения, ориентированного на обработку сообщений (MOM, message-oriented middleware), среди прочих, сближаются и объединяются.
Требования заказчиков и приверженность производителей индустриальным стандартам также управляют стремительным развитием платформы и приводят к впечатляющим улучшениям в этой сфере и упрощению взаимодействия системного уровня между приложением/производителем/платформой/программируемой моделью. Происходит консолидация рынков платформ, инструментов и приложений для создания большего количества сильносвязанных (tightly coupled) приложений и некоторого развития стандартизации (например, аспектов Java-платформы и .NET). Однако реальностью современного рынка является то, что оптимизация сильносвязанного приложения приводит к привязке к платформе определенного производителя, и это верно для .NET, Java и LAMP (платформы с открытым исходным кодом, состоящей из Linux, Apache, MySQL и PHP/Perl/Python).
В течение последних лет также не ослабевало развитие платформы на стороне клиента с основанными на браузере приложениями, ставшими теперь нормой как для Интернет-приложений, так и для внутрисетевых приложений. Приложения и инструменты, разработанные для использования всей мощи интеллектуальных клиентских устройств, по-прежнему существуют, и Microsoft Office и IBM Lotus Notes являются ярким тому примером: большинство коллективов предприятий сегодня делят свое время между приложениями на основе браузера и «более мощными», такими как Microsoft Outlook или IBM Lotus Notes. В настоящее время эта волна Web-приложений является всеобъемлющей, растущий акцент на эффективный опыт пользователей и оптимальное усиление возможностей интеллектуальных клиентских устройств управляют изменениями в клиентских платформах. В контекстах многих приложений общепринятый (HTML и JavaScript) опыт Web-пользователей является достаточным, но далеким от идеального. Изменения в информационном управлении и презентационных шаблонах также приводят к сдвигу от основанных на браузере к интеллектуальным, оптимизированным для клиентов приложениям и инструментам. Примерами этого сдвига может служить стремительный рост клиентов RSS aggregator (заменяющий традиционный просмотр Web-сайтов), без труда персонализируемые клиенты портала и многозадачные совместные рабочие среды (например, WebEx, Microsoft Office Live Meeting и Groove).
Обдумываем тенденции инструментов
Ведущие интегрированные среды разработки, включая продукты от Borland, IBM, Microsoft, Oracle и других производителей, вместе с инициативами сообщества открытых исходных кодов, таких как Eclipse.org, предоставляют широкий и глубокий, тесно интегрированный набор инструментов, которые могут быть использованы для создания приложений в диапазоне от простых, управляющих базами данных форм до сложных системных потребностей программирования.
Хотя специализированные инструменты по-прежнему сохраняют свою важность в некоторых контекстах, и предпочтения разработчиков всегда являются ключевым соображением (например, если вы желаете, можно продолжать использовать Emacs или vi), современные ведущие инструменты сфокусированы на интегрированных инструментальных средах и быстро расширяются, включая инструменты для управляемого моделью проектирования и реализации, направляемой политикой. Разработчики все в большей мере работают на более высоких уровнях абстракции, что позволяет им, например, заменять друг друга при работе с документами, БД и объектно-ориентированными программными интерфейсами приложения (API, application programming interface).
Оцениваем тенденции приложений
Платформы и инструменты развиваются более стремительно, чем приложения (что вполне разумно, поскольку приложения создаются с помощью инструментов и запускаются на платформах), но области приложений также претерпевают существенные изменения. Обычно в состав платформ включаются инструменты и службы, классифицируемые от служб начального уровня, таких как идентификация и аутентификация, до больше ориентированных на пользовательские инструменты возможностей по совместной работе и взаимодействию, позволяющих разработчикам приложений больше сконцентрироваться на бизнес-процессах и меньше — на инфраструктуре системного уровня.
В категориях приложений предприятия, таких как ERP, CRM и SFA, сдвиг к составным каркасам приложений, основанным на SOA, управляется спросом на эти приложения, которые могут быть использованы в качестве коллекций компонентов и служб. Специализированные приложения, которые нельзя с легкостью применить в контекстах других приложений, гораздо менее полезны для разработчиков, работающих с современными интегрированными средами разработки и нацеленными на новые клиентские и серверные платформы.
Кроме того, волна Web-приложений также безвозвратно изменила само значение термина приложение. Если раньше существовали ясные границы между приложениями, документами и мультимедиа (например, интерактивные графические устройства и потоковое аудио и видео), современные приложения все чаще бесшовно объединяют взаимодействие, документы и медиа и более сфокусированы на пользовательских задачах/сценариях, чем отдельных, ориентированных на определенные функции, областях применений.
Раньше в оценку круга возможных пользователей приложений входили сотрудники или близкие бизнес-партнеры, и довольно часто компания разработчиков могла собраться в кафетерии компании. Теперь же любой подключенный к Интернету и оснащенный браузером пользователь в любом месте земного шара является претендентом на использование приложения. Эти пользователи нацелены на осуществление целенаправленной деятельности (исследовательской, коммерческой, коммуникационной и т. д.), и они не хотят быть обремененными посторонними, связанными с приложением концепциями или заниматься разрушительным смещением контекста приложения.
Исследуем тенденции служб
В настоящее время SOA- и Web-службы являются господствующей тенденцией. Несмотря на то, что в последние несколько лет от активной рекламы на рынке этого программного обеспечения, порою можно было оглохнуть, а соотношение рекламной шумихи к реальности зачастую приводило в уныние, налицо стремительный прогресс в индустрии. В частности, это происходит благодаря направленному на стандарты сотрудничеству ведущих производителей, работающих над созданием стека стандартов Web-служб.
Платформы, инструменты и приложения во все возрастающей мере сосредотачиваются вокруг SOA, и как общественные, так и частные «скрытые» службы претерпевают расширение для достижения следующего уровня эволюции приложений. И хотя прогресс в общественных службах идентификации, аутентификации, транзакций и другого контекста не всегда проходил гладко, существуют достаточные основания для оптимизма. Даже, несмотря на то, что для разработчиков приложений не является простым или привычным использовать инфраструктуру служб, это избавляет их от проявлений индивидуальных особенностей и путаницы междоменной организации сетей и службы вместе с платформами, инструментами и приложениями, требующими их более полного использования, развиваются все более быстрыми темпами.
Стремительный рост ориентированных на службы приложений высокого уровня поддерживается также такими поставщиками служб приложений, как salesforce.com, призывающей к рассмотрению согласованного определения приложений масштаба предприятия и ориентированных на сотрудничество предложений служб от производителей, включающих такие компании, как Microsoft, Raindance и WebEx.
Другие тенденции приложений, влияющих на платформы
Существует множество других важных тенденций, рассмотрение которых выходит за рамки этой статьи. Вот краткий перечень некоторых из них:
Макроэкономика и Закон Мура (Moore). Большая часть предприятий значительно сократила разработку приложений за последние несколько лет, сосредоточившись главным образом на возможностях, предполагающих снижение затрат и растущую управляемость приложения. С наступлением последнего глобального макроэкономического улучшения, предприятия снова начали инвестировать в сферу ИТ и, зачастую, выделяемые средства по сравнению с предыдущей инвестиционной волной являются более значительными; закон Мура не прекращает своего действия в ходе экономического спада.
Сближение понятий корпоративного/потребительского и вычислительного/коммуникационного. Все более непродуктивным становится делать различие между рабочим и личным вычислительным/коммуникационным контекстами, что дает «зеленый свет» организационному образу действий, дистанционному присутствию, взрывному росту коммерческого Интернета и домашних широкополосных сетей, а также росту беспроводных высокоскоростных служб передачи данных.
Открытые для всех стандарты и исходные коды. Сотрудничество и политика в сфере индустриальных стандартов могут послужить основой для нового развлекательного телесериала. Некоторые, например, могли предсказывать, что IBM и Microsoft откажутся от сотрудничества в области стандартов, но сегодня стало нормой видеть BEA, IBM, Microsoft, Oracle, Sun и другие соперничающие компании с энтузиазмом ставящими свою подпись под очередным утверждением стандарта, что приводит к чрезвычайно быстрому созданию стандартов для Web-служб и других областей.
Средний уровень ИТ-рынка уступчив и легко поддается движению. Приложения уровня предприятий не разрабатываются только для огромных организаций, и небольшие и средние организации теперь зачастую обгоняют большие в выпуске платформ, приложений и инструментов.
Непрерывное смещение в сторону решений. Многие организации более не заинтересованы в программных продуктах, предпочитая искать решения (зачастую включающие в себя аппаратные, программные и разработочные/интеграционные службы), которые направляют свои бизнес-приоритеты, особо не учитывая лежащие в основе платформы, приложения и инструменты. Результат заключается в мощном сдвиге в сторону поставщиков решений. Если Accenture или EDS, например, предпочитают основывать свой CRM-бизнес на CRM-приложении определенного поставщика, то влияние на общий пользовательский спрос может оказаться значительным.
Microsoft среди новых рыночных реалий
Недавние изменения на рынке программных продуктов в платформах, инструментах и службах оказались глубоко трансформационными, вынуждая всех поставщиков программного обеспечения стремительно развивать линии своих продуктов и стратегии. Эта статья лишь обозначила главные тенденции, которые в равной мере можно применить к Microsoft и к ее ключевым соперникам. В следующей статье этой серии мы рассмотрим, насколько Microsoft учитывает новые рыночные реалии в семействах своих продуктов 2003—2004 года.
Programming
Хранение больших таблиц поиска в наборах данных
Общий объем исходников к этой статье почти 3 Мб. Т.е. он не влезает ни на какую дискету. Поэтому те из наших уважаемых подписчиков, кто получает исходники вместе с журналом получат проект клиентского приложения, исходные тексты для создания таблиц. Сами БД, наполненные информацией мы выкладываем на сайт, так что вы сможете взять их отсюда. Итак: 200408_jennings-client.rar - это клиент и схема БД, 200408_jennings_databases.rar - это сама база, точнее две базы с журналами.
Роджер Дженнингс (Roger Jennings)
Сохранение наборов данных (DataSet) с информацией для поиска в виде локальных XML-файлов позволяет пользователям отключенных от БД портативных компьютеров и Pocket PC оперативно выполнять поиск и обновление наборов данных.
В силу того, что пример, находящийся на сопровождающей статью дискете, включает сами базы данных объемом более 10 Мб, ужать их до размера дискеты не представляется возможным. Мы помещаем на дискету полный набор скриптов, достаточных для создания баз данных (Customer.sql и Product.sql). Сами базы с наполнением можно будет скачать с нашего сайта, там, где обычно размещаются исходники к номерам. Для удобства мы разделим архивы на две части: клиент и собственно БД, чтобы вам не пришлось заново качать клиента, который и так есть на дискете.
Вам потребуется следующий технологический набор инструментов: VB.NET, SQL Server 2000, XML, Visual Studio .NET 2003.
Правильной практикой при создании объектов DataSet (далее — наборов данных) является минимизация числа записей, возвращаемых объектами SqlDataAdapter. Это верно и для приложений VS.NET, чьи пользователи имеют прямые сетевые подключения к исходным БД. Однако, это рекомендация не применима к редко подключающимся к БД мобильным пользователям, вынужденным искать записи и редактировать данные, находясь в офисах заказчиков, на насосных станциях трубопровода, на танкерах рейдовых причалов или в других удаленных местах. Обновления и добавления данных, сделанные в отключенном режиме, должны быть сохранены между перезагрузками устройства и выживать в результате конфликтов обновлений, возникающих при конкурентной модификации данных.
Одним из подходов является настройка репликации слиянием (merge replication) с Microsoft SQL Server Desktop Engine (MSDE) 2000 на портативных компьютерах или SQL Server CE на Pocket PC. Альтернативным методом будет сохранение больших наборов справочной информации данных (такой как спецификации продуктов, записи заказчиков, даты последних заказов), а также незавершенных обновлений и добавлений в виде локальных XML-файлов. В этой статье я опишу преимущества и недостатки сохранения, загрузки и обновления поддерживаемых локально наборов данных, размер которых варьируется в диапазоне от 250 Кб до более чем 20 Мб. Вы сможете провести свои собственные тесты с проектом OCETestClient VB.NET (для компании OakLeaf Consumer Electronics (OCE)), находящимся на сопровождающей журнал дискете. Он генерирует потребление ресурсов и показатели производительности, которые я буду обсуждать позднее.
Кэширование справочных данных или операций ввода/редактирования заказов является обычным требованием для часто отключаемых клиентских приложений. В большинстве случаев пользователи загружают начальный набор информации каталога и обновляют эти данные периодически, когда подключаются к БД через виртуальную частную сеть. Пользователи без подключения по локальной сети или через виртуальную частную сеть могут использовать простую хранимую процедуру SQLXML 3.0, реализованную в виде Web-службы, возвращающую отдельные наборы данных для категорий продуктов и элементов заказа или вложенные наборы данных с таблицами категорий и элементов. Шифрование SSL/TLS (Secure Sockets Layer/Transport Layer Security) защищает конфиденциальную информацию, получаемую с помощью прямого подключения клиента к Web-службе через Интернет. В качестве альтернативы можно использовать Web Service Extensions 1.0 или более позднюю версию для шифрования возвращаемых сообщений по протоколу SOAP (Simple Object Access Protocol).
Other
Описание поддержки памяти большой емкости
Одной из наиболее важных и слабее всего понимаемых административных задач является необходимость управления памятью, применяемой для операционной системы (далее ОС) и приложений. Этот раздел расскажет о различных типах настройки памяти ОС и о практических рекомендациях по их использованию.
Эта статья не претендует на роль полного курса по диспетчеру памяти (memory manager) ОС. В значительной степени этот краткий обзор был разработан для того, чтобы дать читателю достаточное понимание диспетчера памяти, призванное помочь разобраться в различных доступных техниках настройки памяти и тех последствиях, к которым может привести их использование.
Существует несколько доступных типов настройки памяти и каждый из них имеет свои достоинства, недостатки и особенности применения.Однако прежде чем перейти к различным типам настройки памяти, я собираюсь кратко пройтись по диспетчеру памяти ОС. Это поможет понять, когда, как и почему должны применяться различные типы настройки памяти.
Работа диспетчера памяти
С момента появления ОС Windows NT 3.1, Windows NT 4.0 и их преемников (включая Windows 2000 и Windows Server 2003, которые будут упоминаться в этой статье просто как Windows) были 32-битными ОС до тех пор пока не появилась 64-битная версии Windows Server 2003. Возможно, вы думаете: «Все это просто замечательно, ну и что?» На это «ну и что» отвечает тот факт, что количество памяти ОС, к которой можно обращаться напрямую, зависит от того, сколько бит поддерживает ОС. 32-битные версии Windows способны адресовать 232 байтов новой памяти или 4294967296 байтов. Чтобы сделать эту цифру более простой для восприятия, будем говорить, что Windows может адресовать 4 Гб памяти. Очевидным следствием является то, что, чем больше бит поддерживает ваша ОС, тем большую емкость памяти вы сможете адресовать. Так 64-битная ОС способна адресовать 264 байтов памяти (что составляет 18,446,744,073,709,551,616 байт — поистине гигантское число). Из этих рассуждений вы можете сделать вывод, что 32-битные версии Windows могут адресовать только 4 Гб реальной памяти, но это не является непреодолимым пределом, за что стоит благодарить творческий подход и небольшую «ловкость рук».
Однако до того, как вы, взволнованные этой статьей, начнете писать приложения, требующие 4 Гб памяти только для своей загрузки, я хотел бы упомянуть о нескольких основных правилах использования всей этой емкости памяти. Windows использует довольно известный подход, называемый разделением памяти (memory split). Согласно ему, по умолчанию ядро может использовать до 2 Гб памяти в своем собственном изолированном пространстве памяти и каждое приложение может задействовать до 2 Гб памяти в своем собственном частном адресном пространстве
(Возврат на основную страницу)