|
|
  |
Главная страница / Архитектура отрасли ЗАГЛЯДЫВАЯ В БУДУЩЕЕТехнологии разработки приложений (Продолжение. Начало см. в № 5/2002) Продолжаем публикацию прогнозов, составленных специалистами PricewaterhouseCoopers Technology Centre. Эти данные могут быть полезны всем, кто связан с разработкой или использованием программного обеспечения (ПО), а также с электронным бизнесом. C 2002 по 2004 год развитие программного обеспечения (ПО) будет идти не только в направлении расширения функциональных возможностей; немалую роль здесь должны играть также факторы, по своей природе являющиеся скорее технологическими. Такие факторы могут быть связаны, в частности, с операциями, которые исполняются «внутри» приложения «прозрачно», то есть незаметно для пользователя. Между функциональными и техническими требованиями существует очень тесная связь. Например, функциональным требованием по предоставлению услуг мобильным пользователям обуславливается техническое требование обеспечить поддержку клиентских устройств различных типов. Допустим, если нужно, чтобы приложение работало за пределами предприятия (функциональное требование), значит, оно должно «уметь» обрабатывать, хранить данные и обмениваться ими в среде XML (техническое требование). В настоящее время весьма широко распространена архитектура EAI (Enterprise Application Integration), основанная на использовании ПО промежуточного слоя (middleware), которое служит для организации взаимодействия между прикладными программными продуктами. Однако многие предприятия начинают или планируют переход на другую архитектуру, состоящую в том, что приложения разбиваются на небольшие блоки с ограниченной функциональностью — компоненты. Такое компонентное ПО легче интегрировать, чем пакеты программ, поскольку упомянутые компоненты содержат стандартизованные интерфейсы. Наконец, третья архитектура, основанная на Web-сервисах, расширяет возможности компонентного ПО, допуская использование некоторых компонентов в качестве коммерческих служб, найти которые можно с помощью общедоступных каталогов. ПО, созданное с применением последнего подхода, пока находится в стадии экспериментального исследования, однако уже есть компании, которые хотели бы на его основе строить свои инфраструктуры. Каждая из перечисленных архитектур подразумевает определенный набор решений, которые организации должны принять в качестве основы инфраструктуры используемого ПО, причем возможные варианты выбора меняются при переходе от одной архитектуры к другой. Например, при приобретении пакетных приложений перед компанией стоит вопрос, выбрать ли ей интегрированный комплект продуктов от одного поставщика или набор отдельных оптимальных приложений разных производителей и связать их через EAI middleware. В случае компонентного ПО значимость такого выбора снижается, поскольку стандартизованные интерфейсы облегчают процедуру комбинирования компонентов различных поставщиков. Здесь важно выбрать основу для построения компонентнокомпании Sun Microsystems и Microsoft.Net. Интеграция приложений Пожалуй, интеграция приложений составляет наибольшую техническую проблему при развертывании и последующем использовании ИТ. В большинстве организаций хранится пухлый портфель различных приложений, полученных от разных поставщиков или разработанных собственными силами. Как правило, эти приложения плохо приспособлены для взаимного обмена информацией, так что события, происходящие в одном из них, не могут инициировать действия в других. Однако существуют вполне доступные способы интеграции приложений, наиболее простой из которых связан с ситуацией, когда периодически возникает необходимость экспортировать информацию из некой базы данных в некий файл. Такая база данных может содержать сведения о продуктах компании, а периодически обращающееся к ней приложение может представлять собой on-line-каталог, используемый электронной системой сбыта или сервером электронной коммерции. Но бывает и более сложная интеграция. Средний уровень сложности обусловлен ситуацией, когда нужно, чтобы одно приложение производило поиск данных, циркулирующих в другом. Примером здесь может служить сервер для коммерции, осуществляющий запрос в соответствующую информационную систему по поводу отправки товара клиенту. В более сложных случаях приложение должно обладать способностью запросить разрешение на некоторые действия в других приложениях, после чего дождаться завершения операции и на основе полученной реакции предпринять соответствующее действие. Такой функцией обладает система CRM, которая запрашивает у поставщиков информацию о доступности различных деталей перед корректировкой производственного плана. На выполнение подобной транзакции может уйти от нескольких минут до нескольких часов. Во второй половине 1990-х годов были разработаны специализированные продукты архитектуры EIA промежуточного слоя, обладающие расширенными возможностями по интеграции приложений. Эти продукты позволили добавить такие функции, как передача данных между приложениями с помощью ПО промежуточного слоя, ориентированного на сообщения и вызов удаленной процедуры, и обеспечение целостности транзакции с использованием мониторов их обработки. Помимо базовой функции интеграции данных ПО промежуточного слоя EAI поддерживает интеграцию приложений и автоматизацию бизнес-процессов. При этом применяются брокеры сообщений, которые осуществляют динамическую маршрутизацию сообщений на основе их контента и преобразуют представление данных между различными приложениями. Путем автоматизации эти функции распространяются на многофазные процессы контроля и управления, включая те, которые требуют вмешательства оператора, например для санкционирования транзакции, по продолжительности превышающей установленный порог. До сих пор шла речь об интеграции целых приложений или их наборов. Фактически спрос на наборы приложений определяется тем, насколько высока степень интеграции между составляющими их функции разными поставщиками. Но к интеграции есть и другой подход, основанный на формировании приложения из компонентов меньшей функциональности. Компонентный подход Истоки компонентного подхода к разработке ПО лежат в объектно- ориентированном программировании, которое, в свою очередь, реализует модульный принцип, упрощающий как саму разработку, так и последующее сопровождение программных продуктов. При этом удается обойтись без повторного написания отдельных кодов, поскольку сформированные библиотеки объектов могут служить в качестве строительных блоков для многих приложений. Компонентный подход к разработке ПО подобен модульному. Отличие состоит в том, что основное внимание здесь уделяется не возможности повторного использования и модульности исходного программного кода, а единообразию принципов разработки исполняемых программных кодов. В результате авторы ПО получают возможность конструировать приложения, «собирая» программу из уже созданных компонентов, а не программируя их заново. Для этого существуют три основные компонентные модели: • DNA (Distributed Network Architecture) Microsoft; • OMA (Object Management Architecture) OMG; • J2EE (Java 2 Enterprise Edition) Sun. Как известно, технология компонентной разработки ПО получила широкое распространение в первой половине прошлого десятилетия, однако поставщики системного ПО стали реализовать компонентные архитектуры в своих программных платформах только в конце 90-х годов (в данном случае речь идет о спецификациях EJB – Enterprise JavaBeans компании Sun и Microsoft Transaction Server, которые появились в 1997-м). Продажей программных компонентов до конца прошлого века занималось лишь несколько компаний (исключение составляли некоторые специализированные области, например, связанные с разработкой GUI). В последние годы ситуация изменилась, что было обусловлено, в частности, возросшей популярностью серверов приложений, представляющих собой среду, в которой исполняются программные компоненты. Это заставило разработчиков приложений обратиться к компонентному подходу, который обеспечивает исполнение их продуктов на серверах приложений от других поставщиков. На сегодняшний день на компонентную основу переведено большинство «коробочных» приложений, включая ERP-системы, либо ведется интенсивная работа по такому переводу. В результате у покупателей таких продуктов появляется возможность модульного развертывания приложений и облегчается последующая их модернизация, поскольку она будет касаться только необходимого компонента, не затрагивая всего модуля целиком. Первоначально эти компоненты, как правило, разрабатывались по фирменной технологии поставщика. Однако благодаря тому, что поставщики предприняли определенные усилия по поддержке в своих продуктах нескольких компонентных архитектур, у пользователей появилась возможность строить свои собственные наборы приложений, комбинируя различные компоненты. В то же врены на одной и той же компонентной архитектуре, гарантируется только обмен сообщениями между компонентами. При этом нет никаких гарантий в том, что будет осуществляться обмен содержательной информацией на уровне бизнес-процессов, поскольку здесь возможна различная интерпретация данных. В таких ситуациях следует использовать ПО промежуточного слова EAI, которое и производит преобразование данных. Значение этой проблемы снижается по мере распространения технологии XML, предусматривающей самоописание данных. Архитектура MDA Архитектура MDA (Model Driven Architecture) появилась в развитие языка UML (Unified Modeling Language) организации OMG (Object Management Group). Она представляет собой новый подход к созданию ПО, который призван в течение предстоящего десятилетия внести революционные изменения в процесс разработки и проектирования ПО. Применение этой технологии позволит организациям строить модели приложений и автоматически преобразовывать их в ПО, которое можно будет исполнять в различных средах. Такой принцип существенно упростит саму процедуру разработки. В связи с тем что MDA предоставляет возможности «замкнутого проектирования» (round-trip engineering), изменения программного кода могут быть использованы для модификации моделей приложения, относящихся к высоким уровням, и автоматической синхронизации модели и ПО. Главная страница / Архитектура отрасли |