Структура .Net Framework
| СТАТЬЯ | 18.10.02 |
Влад Боркус
Статья была опубликована в PCWeek.ru
Впервые об инициативе Microsoft под “неброским” названием .Net мы услышали в начале июня этого года — одновременно с оглашением известного решения американского судьи Джексона, поставившего под сомнение будущее этой корпорации. Однако борьба Microsoft в суде и судьба ее технологий — разные вещи, а инициатива .Net, без сомнения, повлияет на жизнь миллионов людей, создающих программное обеспечение для платформ Windows. Как это часто бывает с производителями высокотехнологической продукции, Microsoft использовала маркетинговый термин .Net для обозначения сразу множества наборов решений, не очень-то похожих друг на друга: сервиса аутентификации Passport.Net, следующих версий операционной системы (Windows.Net) и офисного пакета (Office. Net), портала для малого бизнеса bCentral.Net и многого-многого другого. Вообще, теперь представители Microsoft получили возможность на вопрос: “А какие продукты вы производите?” кратко отвечать: “Производим семейство ПО .Net”.
Структура .Net Framework
Для разработчика интересны три компонента этого необъятного семейства: линейка серверного ПО, комплект технологий для создания Web-сервисов (т. е. услуг, оказываемых Web-сервером по HTTP-запросу из разного рода клиентских программ) и среда для построения приложений .Net Framework.
По замыслу Microsoft, в них содержится все необходимое для создания прикладного ПО, корпоративных информационных систем и Web-решений. Более того, разработку этих решений можно будет вести унифицированным образом для “разных платформ”, под коими понимаются различные варианты платформы Windows, популяция которых, как известно, с каждым годом становится все многочисленнее.
Семейство серверного ПО .Net Enterprise Server состоит из компонентов, составляющих основу инфраструктуры КИС. Большая часть входящих в него продуктов обсуждается в прессе уже более года, и к тому же многие их них детально рассмотрены в обзорах Тестового центра eWeek (см. www.pcweek.ru, № 39). Поэтому я не буду подробно останавливаться на каждом, а лишь перечислю главные продукты данного семейства.
Самым новым среди них является BizTalk Server 2000 — набор ПО, призванного исполнить роль “клея” при интеграции приложений, входящих в информационные системы компаний. Он состоит из двух основных механизмов — Orchestration Engine, ответственного за координацию исполнения бизнес-процессов, затрагивающих различные серверные компоненты (COM-объекты, Microsoft Message Queuing — MSMQ, Web-сервисы и т. п.), и Messaging Engine, обеспечивающего пересылку и преобразование XML-документов, а также из ряда приложений для конфигурации и настройки.
Другие пакеты — это новые версии известных решений Microsoft: СУБД SQL Server 2000, почтовая система Exchange Server 2000, набор технологий для построения узлов электронной коммерции Commerce Server 2000, брандмауэр и сервер кэширования Web-страниц Internet Security and Acceleration Server 2000.
Кроме того, под новым “флагом” выпускаются: Host Integration Server 2000, представляющий из себя набор ПО для взаимодействия с унаследованными платформами (терминалами 3270, 5270, мониторами транзакций CICS и т. п.); Mobile Information 2001 Server, ответственный за взаимодействие с мобильными устройствами; и Application Center 2000 — комплект программ для конфигурирования, мониторинга и управления серверами, входящими в кластеры, управляемыми ПО балансировки нагрузки Microsoft Network Load Balancing и Component Load Balancing.
Наиболее важное свойство серверной части .Net — относительная доступность. Все основные ее компоненты существуют по крайней мере в виде бета-версий и появятся в коммерческом варианте в конце этого — начале следующего года.
| SOAP-запрос и.. |
| Content-Type: text/xml; charset=”utf-8” Content-Length: 300 SOAPAction: <SOAP-ENV:Envelope xmlns:SOAP-ENV = “http://schemas.xmlsoap.org/soap/envelope/” SOAP-ENV:encodingStyle = “http://schemas.xmlsoap.org/soap/encoding”> <Body> <GetValue xmlns:m=”<A HREF="http://www.aaa.ru/bbb">www.aaa.ru/bbb</A>”> <Input>12345</Input> </m:GetValue> </SOAP-ENV:Body> </SOAP-ENV:Envelope> ..SOAP-ответ HTTP/1.1 200 OK Content-Type: text/xml; charset=”utf-8” Content-Length |
Второй блок инициативы .Net целиком опирается на технологию SOAP (Simple Object Access Protocol) — “протокол простого доступа к объектам”, который, как пошутил Дэвид Чапел*, не является протоколом, не слишком-то прост, а также имеет весьма опосредованное отношение к объектам. Данная технология определяет способ вызова удаленных процедур и функций при помощи XML-сообщений.
SOAP работает с любыми платформами, любыми языками программирования и не требует использования объектной модели. Все происходит примерно так: программа, желающая исполнить какую-либо процедуру на удаленном сервере, посылает ему XML-документ, содержащий информацию об имени вызываемой функции и значениях ее параметров, а затем получает другой XML-документ, содержащий результат работы этого удаленного метода. В качестве транспортного механизма для обмена этими сообщениями используется протокол HTTP или система управления очередями MSMQ.
Microsoft собирается дополнить SOAP двумя новыми технологиями: SOAP Contract Language (SCL) и DISCO. Первая позволяет описывать на XML интерфейсы Web-служб, а вторая определяет формат документов и алгоритм (т. е. последовательность HTTP-запросов/ответов) получения информации в виде SCL-текста об имеющихся на сервере службах и их характеристиках. Вместе они позволяют удаленному приложению опросить сервер и узнать, какие, собственно, функции он может исполнять и как с ними нужно работать.
Есть еще и третье решение: WSDL (Web-services Description Language). Это — XML-формат для описания сетевых сервисов как набора базовых точек (портов), обменивающихся документо- или процедурно-ориентированными сообщениями. Иначе говоря, WSDL описывает сервис как некий “черный ящик”, в который приходят документы одного типа, а уходят другого.
В отличие от SOAP, который можно использовать уже сейчас (с сайта Microsoft можно скачать SOAP Toolkit) и который проходит стандартизацию в консорциуме W3C, дата появления других технологий неясна — пока они существуют только в виде предварительной спецификации.
Microsoft — мастер подхватывать чужие идеи, использовать их в своих продуктах и становиться лидером. Так было с оконным графическим интерфейсом, офисными пакетами и т. п. Фундаментальные идеи, заложенные в этих решениях, были реализованы задолго до появления на свет продуктов редмондского гиганта, а результат (в виде распределения долей рынка) вам хорошо известен. И когда слышишь о .Net Framework, опять возникает ощущение дежавю: где-то мы это уже видели. Источником вдохновения Microsoft на этот раз оказалась платформа Java компании Sun Microsystems. На самом деле отличия конечно же есть, и связаны они главным образом с тем, что .Net будет поддерживать не один, а множество языков программирования. Ну и, естественно, только одно семейство ОС — Windows.
Структурно .Net Framework состоит из трех базовых компонентов: среды исполнения Common Language Runtime (CLR), библиотеки стандартных классов и набора технологий ASP+ для построения Web-ориентированных приложений.
CLR — основной компонент .Net Framework, в функции которого входит поддержка исполнения .Net-приложений. Дело в том, что подобные приложения будут поставляться не в виде “родного” для целевой платформы кода, а в виде байт-кода, написанного на специальном языке Microsoft Intermediate Language (MSIL). Программы или их компоненты, скомпилированные в этот код, да и сам код Microsoft называет “управляемыми” (managed).
Структура сборки
Однако, в отличие от платформы Java, в CLR не будет интерпретатора. Его место займет JIT-компилятор, транслирующий каждый метод с MSIL в “родной” код непосредственно перед тем, как запустить его исполнение. Предусмотрен также вариант, когда вся программа перед запуском транслируется целиком.
CLR содержит механизмы управления событиями, сборки мусора, проверки безопасности кода, средства отладки и профилирования. Она также обеспечивает поддержку многопоточности и вызова удаленных процедур (используется специальный протокол .Net, протокол SOAP или возможности DCOM/COM). Приведенный список до боли похож на перечень задач виртуальной машины Java (Java Virtual Machine, JVM), и это понятно: придумать что-то кардинально новое в этой области сложно. Все базовые идеи были высказаны лет тридцать-сорок назад.
Составляющие .Net-программ, к числу которых относятся динамически связываемые библиотеки (DLL), исполняемые (EXE) модули, вспомогательные файлы данных, будут собираться в пакеты совершенно нового типа — так называемые “сборки” (assembly). В каждой сборке будет присутствовать манифест-файл и другие метаданные, описывающие ее содержание. Инсталляция такого пакета производится простым копированием его в нужный каталог (очень все это смахивает на Jar-файлы в Java).
Assembly определяет пространство имен для содержащихся в ней классов, тем самым ликвидируя проблемы, связанные с установкой на компьютеры DLL разных версий, принадлежащих различным приложениям или их модификациям.
В .Net предусмотрены два типа сборок — частные (private) и общедоступные (shared). Частные сборки используются только одним приложением, именуются обычной текстовой строкой (скажем, “DLL1”), и контроль за их версиями целиком возлагается на автора программы.
Общедоступные же сборки могут использоваться разными приложениями, а именуются они специальным (в терминологии Microsoft — “сильным”) именем, состоящим из текстовой строки и открытого ключа издателя. Это имя уникально, так как уникален открытый ключ. В этом случае контроль за версиями пакетов CLR берет на себя.
Поэтому на одной и той же машине могут находиться разные версии одной и той же сборки. Более того, одним системным процессом подобные версии могут использоваться одновременно. Однако разработчикам все равно придется быть очень внимательными — к примеру, не допускать ситуации, чтобы две DLL разных версий записывали данные в один файл, но в разных форматах.
Кроме решения проблем DLL, сборки позволят повысить безопасность работы приложений, поскольку они будут исполняться в своеобразных “песочницах”. Администраторы смогут детально определять, что имеет право делать та или иная сборка, основываясь на таких характеристиках, как ее имя, имя издателя, сайт или зона безопасности, с которых она загружена, ее URL и т. п. Например, сборке можно запретить запись и считывание файлов с какого-то каталога, доступ к переменным среды, системному реестру, использование ГИП или каких-то его отдельных компонентов (скажем, диалога открытия файлов).
Вообще, все управляемые приложения исполняются в специальных “доменах” (application domain), ограничивающих доступ к памяти, гарантирующих изоляцию ошибок и безопасность исполнения кода. При этом одно приложение может иметь несколько доменов.
Согласно утверждению документации Microsoft, при использовании доменов ресурсы тратятся более экономно, нежели при использовании механизма процессов ОС.
CLR решает еще одну фундаментальную задачу, упомянутую выше, — определяет общий для всех языков программирования набор типов данных и механизм наследования классов. Естественно, речь идет лишь о тех языках, которые совместимы с .Net.
| Пример программы на C#: интерфейс и класс |
| public interface ICalc { int add( int x, int y ); int substr( int x, int y ); } public class CalcTool: ICalc { public int add( int x, int y ) public int substr( int x, int y ) |
В Visual Studio.Net будут поддерживаться четыре языка: Visual Basic.Net, C# (читается как “сишарп”), Си++ и Jscript. Бросается в глаза отсутствие Java (здесь комментарии не требуются) и пакета InterDev (его возможности будут доступны в каждом из инструментов, но об этом — чуть позже). Другие вендоры обещают обеспечить поддержку Perl, Python, Кобола, Паскаля, Оберона, Смоллтока и т. п.
Все эти языки получат в наследство от CLR одинаковую семантику (аналогичную той, что имеет сейчас Java), но будут различаться синтаксисом. Скажем, C# будет представлять из себя язык с семантикой CLR и синтаксисом Си. При этом в нем не будет таких привычных для Си вещей, как препроцессор и include-файлы.
Единство семантики .Net-языков означает, что все они будут объектно-ориентированными (ОО), обладать средствами организации многопоточных вычислений, управления исключительными ситуациями, встроенной поддержкой интерфейсов, свойств, событий и т. п.
Важно, что производный “управляемый” класс может наследовать свойства от класса написанного на совершенно ином языке программирования. К примеру, родительским классом C#-класса может служить класс написанный на VB. Единственное ограничение здесь такое же, как в Javа, — наследование допускается только от одного “родителя”. Как и в Java, число реализуемых в классе интерфейсов может быть любым.
Среди прочих, полноценным ОО-языком станет и Visual Basic: в нем появятся механизм наследования с возможностью переопределения методов в производных классах, семантика для “реализации” интерфейсов, механизм исключительных ситуаций — и все другие возможности, перечисленные выше. Это и хорошо, и плохо: VB станет мощнее, но разработчикам придется больше времени тратить на технические детали программирования. Компенсирует ли экономия от введения новшеств увеличение затрат на борьбу с этими деталями — вопрос, остающийся открытым.
Однозначно положительным моментом является унификация всех разновидностей VB. В частности, VBScript перестанет существовать как отдельная технология: VB будет единым.
Что касается Си++, то в нем появятся специальные расширения для создания “управляемых” приложений, в том числе ключевые слова __gc (этот префикс перед определением класса означает, что он является “управляемым”), __interface, __event, __property. Visual C++ останется единственным инструментом разработки в Visual Studio, сохраняющим возможность генерировать “родной” код. У программистов будет также возможность “смешивать” в рамках одного приложения управляемые классы, компилируемые в MSIL, и обычные Си++-классы, компилируемые в “родной” код.
Однако несмотря на то, что Си++ сохраняется, Microsoft будет подталкивать программистов к переходу на новый язык C#, а Си++ применять лишь для создания серверных приложений, требующих повышенной производительности, таких, как СУБД.
Тем, кто знаком с Java Development Kit, не покажется странным идея Microsoft создать новую иерархическую библиотеку системных классов. Аналогия между двумя разработками прослеживается и в деталях.
В пространстве имен System определяются все основные типы данных, такие, как Object, Int16, Int32, Uint32, Uint64, Single, Double, Decimal, Boolean, Byte, Char, String, Array, Class, Interface и пр.
Другие пространства имен включают:
Из системных стоит отметить еще две библиотеки — System.Reflection, позволяющую исследовать метаданные сборок и узнавать свойства находящихся в них методов и классов, и System.Runtime, содержащую классы для взаимодействия с COM (подбиблиотека InteropService), сериализации управляемых компонентов (подбиблиотека Seiralization), а также для доступа к объектам в других процессах и на других машинах (подбиблиотека Remoting).
В .Net по-новому организован доступ к данным. Эту задачу решает технология ADO+ (библиотека System.Data.ADO), обеспечивающая интерфейс для доступа к “управляемым провайдерам данных”. Подобные провайдеры, в свою очередь, могут быть “родными” для СУБД (Microsoft уже выпустила SDK для их создания и провайдеры для SQL Server) или работать через OLE DB, а стало быть, и ODBC. Поставляется также провайдер для доступа из ADO+ и старой технологии доступа к БД — ADO.
ASP+: Работа Web-приложения
Другим новшеством в ADO+ является новая структура DataSet, замещающая RecordSet из ADO. Она обладает рядом полезных свойств.
В частности, DataSet “отсоединена от СУБД”, т. е. кэширует результаты ответа на запрос к СУБД. Она содержит также не только данные, полученные в ходе текущего запроса, но и данные, которые могут быть получены при других, близких запросах. Помимо этого DataSet способна одновременно хранить данные из разных источников, в частности более одной таблицы и/или XML-документа. И наконец, она поддерживает механизм сохранения своего состояния, сериализуя его в формате XML.
Если ранее для построения Web-приложений на платформе Microsoft использовались технологии ASP (Active Server Pages), то теперь им на смену приходит ASP+.
Приложения ASP+ состоят из двух типов объектов: тех, что генерируют HTML-интерфейс (они аналогичны обычным ASP-страницам и помещаются в файлы с расширением aspx) и тех, которые выполняют исключительно служебные задачи (их расширение — asmx). Объекты последнего типа могут быть использованы для построения Web-сервисов.
Для создания всех объектов можно использовать любой из языков .Net, хотя по умолчанию применяется VB. Заметим, что .Net допускает разделение описания класса и использующей его HTML-страницы. Например, в ней можно написать: что означает, что тело класса MyClass находится в файле class1.cs.
Кроме файлов указанных типов приложение ASP+ может включать сборки, конфигурационные файлы и т. п. Все данные и объекты приложения должны находиться в одном каталоге, при этом инсталляция осуществляется простым копированием файлов — не требуется ни внесения изменений в реестр, ни перезапуска Web-сервера.
Исполняются приложения ASP+ также более надежно, чем программы ASP. Во-первых, для каждого из них создается специальный виртуальный домен. Во-вторых, имеется возможность сохранять их состояние в специальном хранилище.
Благодаря этому процесс может продолжить работу с того места, где его застал сбой Internet Information Server (IIS) или даже аппаратный сбой, если сервер входит в кластер. Более того, подобный механизм упрощает балансировку нагрузки, так как состояние процесса доступно всем машинам серверной фермы.
ASP+: Работа Web-сервиса
В качестве хранилища состояний может выступать либо один из компьютеров фермы, размещающий данные о процессах в своем ОЗУ, либо выделенная машина с SQL Server. Напомню, что в рамках обычной технологии ASP состояние процесса доступно только на одном компьютере и теряется при сбое.
Для создания приложений ASP+ используется библиотека System.Web, содержащая классы для Web-аутентификации, получения информации о Web-сервисах, доступа к Web-сервисам посредством протокола SOAP, а также построения Web-интерфейсов.
Для решения последней задачи применяется библиотека System.Web.UI, содержащая набор базовых элементов Web-ГИП. Разработчики смогут конструировать Web-интерфейсы, просто перетаскивая компоненты с палитры на разрабатываемую форму.
Подобные элементы управления способны определять в процессе исполнения их на IIS-сервере, с каким браузером им предстоит работать и генерировать соответствующий HTML-код. Например, они могут сформировать страницу в формате HTML 3.2 для простых браузеров, функционирующих на мобильных устройствах или DHTML-код для Internet Explorer. Кроме того, эти элементы могут автоматически сохранять на сервере введенные в них пользовательские данные. При повторном отображении элемента (например, после сбоя и восстановления сессии) данные пересылаются обратно в браузер пользователя.
Что касается Web-сервисов, то реализующий их код помещается в файлы с расширением asmx. Создать их очень просто: достаточно определить в классе public-метод с атрибутом Web Method, и сервис будет доступен через протокол SOAP или команды GET и POST протокола HTTP.
В заключение стоит сказать и о нескольких других свойствах ASP+. Так, в .Net встроены средства кэширования запросов. Скажем, если ASP+-страница содержит директиву , то результат её обработки будет помещен в кэш на 30 секунд. Если содержимое страниц меняется не очень часто, то это повышает производительность работы системы.
Одним из главных препятствий на пути .Net станут накладываемые ею ограничения на использование старых технологий. Код старых приложений нелегко будет перенести в .Net — для этого потребуется не просто их перекомпиляция, а коренная переделка.
Мало того что ушли в прошлое милые сердцу программиста на Visual Basic операторы Set и Let, список передаваемых в VB-подпрограммы параметров придется заключать в круглые скобки, не будут поддерживаться присваиваемые по умолчанию значения свойств, а аргументы (по умолчанию) будут передаваться по значению. К тому же изменился API.
С другой стороны, Microsoft сделала многое, чтобы смягчить проблему перехода. Так, инсталляция ASP+ не нарушит работы обычных ASP-страниц, а совместимость с унаследованными приложениями будет поддерживаться на уровне COM: к этим компонентам можно обращаться из любых .Net-приложений и даже создавать управляемые классы, наследующие свойства этих объектов. Вызов .Net-компонентов из COM-объектов также будет поддерживаться.
Вообще говоря, с появлением .Net Framework технология COM никуда не исчезнет и даже получит дальнейшее развитие в Windows.Net (см. полемику Microsoft с Gartner Group на www. Microsoft.com/net), но все современные сложности работы с ней (включая взаимодействие с системным реестром) будут маскироваться.
По оценке экспертов, под .Net действительно необходимо переделать всего лишь около 2% имеющихся приложений. Однако в ближайшее пятилетие все новые корпоративные разработки для Windows будут идти на основе этой технологии.
Стимулы к переходу на .Net огромны. Даже той части описанного выше набора технологических решений, которая была реализована в Java, достаточно, чтобы к этой кардинально новой платформе Sun потянулись миллионы разработчиков. Ясно, что потенциал технологии, дающей то же самое, но без кардинальной смены привычных языков программирования, инструментов разработки и платформы, просто колоссален.
И все же в заключение хотелось бы подлить ложку дегтя. Microsoft заманивает решениями, появление которых произойдет в отдаленном будущем — ведь из всех компонентов .Net Framework существует пока только .Net Framework SDK, да и то в виде версии Technical Preview. Microsoft обещает выпустить эту технологию в ближайшие годы, но следует учитывать ее большой опыт в части задержки выпуска своих продуктов. Java же существует уже сейчас.
В мире бизнеса важно не то, кто высказал идею, а то, кто сделал все правильно и вовремя. Хотя что такое “правильно” и когда наступает это “вовремя”, обычно выясняется только задним числом.
* Дэвид Чапел (David Chappel) — один из ведущих независимых экспертов по технологиям Microsft. Глава консалтинговой компании Chappel & Associates. В сентябре московское представительство Microsoft организовало семинар для разработчиков, на котором он прочитал многочасовую лекцию на тему Windows DNA и .Net. Материалы этой лекции использованы в данной статье.
За дополнительной информацией обращайтесь в компанию Interface Ltd.
| INTERFACE Ltd. |
| ||||
