Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Миграция на .Net. Подготовка приложений

Годфри Бейкер

Новые возможности, предлагаемые платформой .Net фирмы Microsoft, кажутся привлекательными. Но годится ли она для ваших приложений? Ниже приводится набор простых критериев, которые помогут вам оценить вашу готовность к миграции.

Стратегию .Net фирмы Microsoft принято рассматривать как новый этап в разработке распределенных приложений. Ее преимущества с точки зрения Web-проектирования очевидны. Это ускорение разработки, сокращение объема программирования и повышение стабильности работы приложений. Но что же необходимо сделать для перевода приложения на новую платформу? Готово ли ваше приложение перенестись в .Net?

Чтобы получить представление о том, легко ли (или трудно) обновлять ваше приложение, начните с оценки качества исполнения проекта. Плохо структурированная или неполная документация свидетельствуют о явно непродуманной разработке и низком качестве приложения. Другими тревожными признаками являются "забытые" устаревшие тексты программ и SQL-сценарии, обилие "закомментированных" кусков исходного кода, бессвязные комментарии.

Само по себе небрежное оформление программного кода не препятствует миграции, но оно служит первым предупреждением о возможных проблемах. Перенос на платформу .Net обладающего серьезными дефектами кода без устранения его основных недостатков может потребовать незапланированных (и потому нефинансируемых) усилий по его переработке. Программный код готового к переносу в .Net (.Net-ready) приложения, как правило, должен быть хорошо структурирован и документирован.

Оценив качество исполнения проекта разработайте четкую стратегию переноса приложения в среду .Net. Определитесь с тем, как вы намерены достичь интероперабельности, например, перенесете ли вы в среду .Net один или несколько уровней приложения (как, например, при переходе от ASP к ASP.Net), либо определенный функциональный блок, охватывающий все уровни.

Правильный выбор стратегии интероперабельности является ключевым моментом в интеграции различных уровней приложения и обеспечении возможности более широкой системной интеграции. Эта стратегия должна определять, например, следует ли переходить от компонентов COM к управляемым объектам .Net или ограничиться интероперабельностью самих компонентов COM.

Архитектура

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

С целью оптимизации работы с БД в трехуровневой системе для доступа к данным должны использоваться хранимые процедуры, а не SQL-коды, встраиваемые в страницы ASP (Active Server Page). Кроме того, хранимые процедуры облегчают сопровождение, поскольку позволяют модифицировать SQL-запросы и таблицы, не затрагивая код приложения.

В настоящих трехуровневых системах бизнес-логика инкапсулирована в объекты COM. Это позволяет переложить выполнение приложения на процессор транзакций, что является основным методом масштабирования приложений Microsoft с интенсивным трафиком. При этом учтите, что протоколы раннего связывания платформы .Net дополнительно повышают производительность по сравнению с текущей реализацией механизма ASP/COM.

Далее определите, совместим ли язык программирования исходной реализации приложения со средой CLR (Common Language Runtime) платформы .Net. На момент написания этой статьи выбор языков ограничивался C#, C++ и Visual Basic (VB).

Если использовать мост Java-COM или Web-службы, то Java-приложения могут быть перенесены на платформу .Net без переписывания их на CLR-совместимый язык. Однако динамические библиотечные COM-модули, сгенерированные из Java-кода, возможно, будет трудно отлаживать, кроме того, среда в целом становится сложнее. Не менее сложен и альтернативный путь - изменение языка программирования в ходе миграции, так как при переходе на другой язык, несомненно, потребуются архитектурные изменения. Поэтому, в отсутствии серьезных причин для миграции, перенос Java-приложений в среду .Net будет, вероятно, не самой лучшей затеей.

Уровень представления

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

На практике все разработчики слишком часто встраивали код HTML, обеспечивающий элементы интерфейса, внутрь ASP-процедур. Это неизбежно приводит к проблемам с последующим сопровождением, поскольку усложняет понимание структуры генерируемого клиентского кода. Платформа .Net заставляет придерживаться хорошей практики программирования, запрещая процедуры, генерирующие HTML-код. Вместо них используются заказные управляющие Web-элементы, которые скрывают все сложности языка HTML и открывают приложению доступ только к своим свойствам и событиям.

Составьте также список всех глобально доступных процедур. Поскольку ASP.Net поддерживает объектно-ориентированную архитектуру, вам придется поместить все глобальные процедуры в глобальные классы в соответствии с используемой в .Net моделью распределения кода, именуемой "code-behind". Страницы code-behind представляют собой заранее скомпилированные модули, написанные на любом из CLR-совместимых языков программирования. Скомпилированные в страницы code-behind глобальные классы становятся доступными всему приложению. Затем, если структура включаемых файлов не нормализована, вы можете обнаружить, что имена и функциональные возможности некоторых из них дублируются. Будет лучше переписать все дублирующиеся функции в виде методов в файлах code-behind.

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

Прикладной уровень и уровень данных

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

Последние являют собой одно из важнейших преимуществ платформы .Net. Эти готовые компоненты снижают избыточность кода и реализуют соответствующие функциональные возможности посредством простых в использовании объектов. Переход на платформу .Net приведет, скорее всего, к замене заказных ASP-страниц и прикладного кода на новые управляющие элементы. Осуществить эту работу значительно проще в том случае, если логика приложения, код уровня представления и SQL-процедуры для работы с БД легко идентифицируются и четко разделяются.

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

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

Принципиальным нововведеним, появившемся в VB.Net, стал механизм обработки исключительных ситуаций try/catch, знакомый пишущим на языке Java программистам. Конструкция on error по-прежнему поддерживается в VB.Net, но современная практика программирования требует перехода к новым структурированным механизмам обработки ошибок. Поэтому необходимо детальное понимание как текущих, так и будущих потребностей приложений в части обработки ошибок.

Если перевод приложения в среду .Net не затрагивает БД как таковую, то появление технологии ADO.Net влияет на доступ к БД и соответствующим объектам. Хотя технология ADO.Net предоставляет много новых функциональных возможностей, в том числе связывание данных, решение модифицировать ваше приложение с целью использования этих возможностей может отразиться на производительности и должно быть тщательно продумано. Альтернативная стратегия предполагает применение хранимых процедур, инкапсулированных в COM-объекты, для доступа к БД, используя для этого классическую технологию ADO.

Готовность к миграции

Любой ИТ-проект преследует обычно три цели: уложиться в сроки, не выйти за рамки бюджета, удовлетворить требования по функциональным возможностям. Оценка текущей реализации приложения и проектирование новых функциональных возможностей позволит вам обеспечить относительно безболезненный и быстрый переход на новую платформу.

Начните с анализа программного кода и документации. Помните, что миграция повлияет на все файлы, а не только на те, к которым обычно осуществляется доступ. Убедитесь, что система сопровождается должным образом и ее уровни четко разделены. И, конечно, действуйте по заранее намеченному плану.

Хорошо изучив свою систему, вы наверняка сможете ответить, написан ли весь код уровня представления на одном и том же языке программирования, а код прикладного уровня - на CLR-совместимом языке. Если на оба вопроса вы ответили "да", то поставьте себе высшую оценку за языковую совместимость. Если ваше приложение написано на языке Java или на каком-нибудь другом не совместимом с CLR языке, то отложите карандаш и закройте журнал: вы определенно не ".Net-ready". Кроме того, вы должны определить, является ли ваш уровень представления лишь "тонким слоем" с небольшим объемом собственной логики или же SQL-код непосредственно встроен в ASP-шаблоны.

Поставьте себе высший балл и в том случае, если ваши бизнес-правила и хранимые процедуры инкапсулированы в COM-объекты. Сейчас ваше приложение уже является масштабируемым и четко разделено на уровни, а благодаря интероперабельности доступ к вашим COM-объектам (и вашим данным) будет возможен практически без модификации приложения.

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





  
3 '2003
СОДЕРЖАНИЕ

бизнес

• Siemens ICN представляет NGN-решения

• Интеграция кредитной и авансовой систем расчетов с абонентами

инфраструктура

• В стремлении к идеалу

• Такие привлекательные радиосистемы типа "точка—точка"

• Тестируем 5-ГГц беспроводные мосты

информационные системы

• Если вам что-то нужно — просто спросите

• Миграция на .Net. Подготовка приложений

• Избегайте "страусов"!

• Руководство по выживанию с помощью ИТ

кабельные системы

• Проверьте ваши знания в области тестирования кабельных систем

• Активные медиазоны

сети связи

• Что надо знать операторам об IP DSLAM

новые продукты

• "Конгресс" — новая система аудиоконференц-связи компании "Телрос"


• Калейдоскоп



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх