Прошли те времена, когда программисты для создания приложений легко обходились одной-двумя любимыми технологиями, а связь приложений в рамках информационных систем осуществлялась просто и без затей — через SQL-сервер баз данных. Этот сервер и управлял ресурсами, и обеспечивал связь с клиентским компьютером, и ведал транзакциями. Времена изменились. Появилось множество программных продуктов, позволяющих быстро и красиво создавать клиентские приложения, управлять ресурсами серверов, потоками, безопасностью и транзакциями. Более того, все эти задачи теперь могут решаться одновременно, в режиме тесного взаимодействия друг с другом. Речь идет о новых мощных технологических направлениях — в первую очередь, CORBA, J2EE и DOT-NET. В этой книге рассматривается широкий круг новых технологий на уровне, достаточном для написания собственных программ. Наибольшее внимание уделяется связям между технологиями и вопросам их совместного использования. Книга предназначена для опытных пользователей и программистов.
Содержание
Введение
Почему мы написали эту книгу
О чем рассказано в книге
О чем в книге не рассказано
Вопросы обеспечения безопасности
Технология .NET
Web-сервисы
Коннекторы Java
От издательства
Глава 1. Три основные технологии построения современных распределенных систем
1.1. Технология CORBA OMG
1.1.1. Pro и contra стандартов
1.1.2. Философия CORBA и политика OMG
1.1.3. Область ответственности CORBA
1.2. Технология J2EE Sun
1.2.1. Семейка Java
1.2.2. Область применения J2EE
1.3. Технология .NET
1.3.1. Краткий обзор технологии .NET
1.3.2. BizTalk, или Как легко интегрировать приложения
1.4. Сравнение CORBA, J2EE и .NET
1.4.1. Сравнение идеологических подходов
1.4.2. Сравнение с точки зрения применения
1.4.3. Взаимное влияние
1.5. Заключение
Глава 2. CORBA и RMI
2.1. Некоторые элементы CORBA
2.1.1. IDL
2.1.2. CORBA-объекты и серванты
2.1.3. Отображение IDL на языки программирования
2.1.4. Объектные адаптеры
2.1.5. GIOP и IIOP
2.1.6. Механизм выполнения удаленных вызовов
2.1.7. Сервис имен
2.1.8. Транзакции и сервис транзакций
2.1.9. Пример приложения
2.2. Некоторые элементы RMI
2.2.1. Основные элементы и понятия RMI
2.2.2. Последовательность действий при создании приложений
2.2.3. Механизм выполнения удаленных вызовов
2.2.4. Механизм передачи аргументов
2.2.5. Пример приложения
2.3. Стандарт RMI/IIOP
2.3.1. Основные требования
2.3.2. Использование RMI/IIOP
2.4. Заключение
Глава 3. Java Naming and Directory Interface (JNDI)
3.1. Служба имен
3.1.1. Атомарное имя (atomic name)
3.1.2. Составное имя (compound name)
3.1.3. Сопоставление имени и объекта (binding)
3.1.4. Разрешение имени (resolving)
3.1.5. Контекст (context)
3.1.6. Начальный контекст (initial context) и фабрика контекстов
3.1.7. Система имен (naming system) и пространство имен (namespace)
3.1.8. Композитное имя (composite name)
3.2. Основные интерфейсы и классы службы имен
3.2.1. Интерфейс Name
3.2.2. Класс NameClassPair
3.2.3. Класс Binding
3.2.4. Интерфейс NamingEnumerartion
3.2.5. Класс NamingException
3.2.6. Интерфейс Context
3.2.7. Класс InitialContext
3.3. Настройка JNDI
3.3.1. Переменная java.naming.factory.initial
3.3.2. Переменная java.naming.provider.url
3.3.3. Параметры среды контекста
3.3.4. Файлы ресурсов JNDI
3.4. Naming Service CORBA
3.4.1. Основные понятия Naming Service CORBA
3.4.2. Основные интерфейсы Naming Service CORBA
3.4.3. Получение начального контекста
3.4.4. Пример использования Naming Service CORBA
3.5. Заключение
Глава 4. Java DataBase Connectivity (JDBC)
4.1. Принципы построения JDBC и основные интерфейсы
4.2. Типы данных JDBC
4.3. Драйверы JDBC
4.4. Драйверы и соединения в JDBC
4.4.1. Класс DriverManager
4.4.2. Интерфейс DataSource
4.4.3. Соединения JDBC
4.5. Транзакции JDBC
4.6. Интерфейсы Statement, PreparedStatement и CallableStatement
4.6.1. Statement
4.6.2. PreparedStatement
4.6.3. CallableStatement
4.7. Интерфейс ResultSet
4.8. Информация о метаданных
4.9. Работа с запросами (Query)
4.10. Работа с хранимыми процедурами (StoredProc)
4.11. Заключение
Глава 5. Сервис транзакций OMG OTS
5.1. Транзакции в распределенных системах
5.2. Модель распределенных транзакций X/Open DTP
5.3. Структура и основные понятия OTS
5.3.1. Основные понятия OTS
5.3.2. Обычные и вложенные транзакции
5.3.3. Последовательность действий при выполнении транзакций
5.4. Основные интерфейсы OTS
5.4.1. Структуры данных OTS
5.4.2. Исключения OTS
5.4.3. Интерфейс TransactionalObject
5.4.4. Интерфейс Current
5.4.5. Интерфейс Control
5.4.6. Интерфейс Terminator
5.4.7. Интерфейс Coordinator
5.4.8. Интерфейс Resource
5.4.9. Интерфейс TransactionFactory
5.4.10. Интерфейс Synchronization
5.5. Режимы выполнения транзакций
5.5.1. Управление контекстом транзакции
5.5.2. Распространение контекста транзакции
5.5.3. Сочетания различных режимов
5.5.4. Пример использования
5.6. Checked behavior
5.7. Обработка ошибок
5.7.1. Сбой инициатора/терминатора транзакции
5.7.2. Сбой менеджера ресурсов
5.7.3. Сбой менеджера транзакций
5.8. Interpositioning
5.9. Взаимодействие с базами данных
5.9.1. ITS Session Manager
5.9.2. ITS XA Resource Director
5.10. Заключение
Глава 6. JTS и JTA
6.1. JTS, JTA и OMG OTS
6.2. Основные интерфейсы JTA
6.2.1. Интерфейс UserTransaction
6.2.2. Интерфейс TransactionManager
6.2.3. Интерфейс Transaction
6.2.4. Интерфейс XAResource
6.3. Интеграция с JNDI
6.4. Примеры использования
6.4.1. Использование интерфейса UserTransaction
6.4.2. Использование интерфейсов JTS
6.5. JTA и соединения с БД
6.6. Заключение
Глава 7. Использование XML
7.1. Основные понятия и структура XML-документа
7.1.1. Структура и виды XML-документов
7.1.2. Основные элементы XML-документа
7.1.3. Описание структуры документа с помощью DTD
7.1.4. Использование пространств имен
7.1.5. Описание структуры документа с помощью XML Schema
7.2. Анализ XML-документа
7.2.1. Document Object Model (DOM)
7.2.2. Simple API for XML (SAX)
7.2.3. Java API for XML Processing (JAXP)
7.3. Использование XSL
7.3.1. Запись в файл DOM-модели документа
7.3.2. XPath
7.3.3. XSLT и таблицы стилей
7.3.4. Применение XSLT
7.4. Заключение
Глава 8. Сервисы сообщений
8.1. Передача сообщений в CORBA
8.1.1. Структура Messaging Service CORBA
8.1.2. Типы вызовов в CORBA
8.1.3. Модели асинхронных вызовов
8.1.4. AMI-вызовы
8.1.5. TII-вызовы
8.1.6. Операция unchecked_narrow
8.1.7. Примеры выполнения асинхронных вызовов
8.1.8. Служба сообщений и модель транзакций
8.1.9. Маршрутизаторы
8.1.10. Передача сообщений через Интернет
8.1.11. Качество сервиса (Quality Of Service)
8.1.12. Управление политиками
8.1.13. Качество сервиса сообщений
8.1.14. Воспроизведение политик сервиса сообщений
8.2. Java Messaging Service (JMS)
8.2.1. Основные элементы и понятия модели JMS
8.2.2. Структура сообщений в JMS
8.2.3. Основные интерфейсы JMS
8.2.4. Обеспечение надежности
8.2.5. Взаимодействие JMS с серверами приложений
8.2.6. Примеры создания клиентского приложения
8.3. Заключение
Глава 9. Enterprise JavaBeans (EJB)
9.1. Структура и используемые технологии
9.2. Основные понятия EJB
9.2.1. Сервер EJB
9.2.2. Контейнер EJB
9.2.3. Компонент EJB
9.2.4. Классы и интерфейсы EJB-компонента
9.2.5. Дескриптор развертывания (deployment descriptor)
9.2.6. Вспомогательные интерфейсные объекты
9.2.7. Установка компонента в контейнер EJB
9.2.8. Роли в технологии EJB и процесс создания приложений
9.2.9. Виды и атрибуты транзакций в EJB
9.3. Session stateless EJB-компонент
9.3.1. Удаленный home-интерфейс
9.3.2. Локальный home-интерфейс
9.3.3. Удаленный component-интерфейс
9.3.4. Локальный component-интерфейс
9.3.5. Класс компонента
9.3.6. Stateless session-компоненты и транзакции
9.3.7. Дескриптор развертывания
9.3.8. Объект SessionContext
9.3.9. Цикл жизни компонента
9.4. Session stateful EJB-компонент
9.4.1. Активизация и деактивизация компонента
9.4.2. Home-интерфейсы
9.4.3. Component-интерфейсы
9.4.4. Класс компонента
9.4.5. Stateful session-компоненты и транзакции. Интерфейс SessionSynchronization
9.4.6. Режим Bean-Managed Transactions (BMT)
9.4.7. Environment-параметры (properties) компонента
9.4.8. Связи между компонентами
9.4.9. Цикл жизни компонента
9.4.10. Использование объекта javax.ejb.Handle
9.4.11. Stateful-компоненты и потоки (threads)
9.4.12. Stateful-компоненты и методы remove
9.4.13. Состояние компонента
9.5. Entity EJB-компонент
9.5.1. Режимы управления сохранением состояния entity-компонента
9.5.2. Home-интерфейс
9.5.3. Find-методы home-интерфейсов
9.5.4. Home-методы home-интерфейсов
9.5.5. Component-интерфейсы
9.5.6. PrimaryKey-класс компонента
9.5.7. Select-методы
9.5.8. Класс entity-компонента
9.5.9. Дескриптор развертывания entity-компонента
9.5.10. Объект EntityContext
9.5.11. Entity-компоненты и транзакции
9.5.12. Цикл жизни entity-компонента
9.5.13. Связи между entity-компонентами в режиме CMP
9.5.14. Язык Query Language
9.6. Message-Driven EJB-компонент
9.6.1. Используемые интерфейсы
9.6.2. Класс компонента
9.6.3. MDB-компонент и транзакции
9.6.4. Дескриптор развертывания
9.6.5. Интерфейс MessageDrivenContext
9.6.6. Цикл жизни
9.6.7. Пример создания MDB-компонента
9.7. Заключение
Глава 10. Приложения J2EE
10.1. Структура серверных приложений J2EE
10.1.1. JAR-модуль
10.1.2. WAR-модуль
10.1.3. EAR-модуль
10.2. Структура клиентских приложений J2EE
10.3. CORBA-клиенты для серверных приложений J2EE
10.4. Заключение
Глава 11. Компонентная модель CORBA (CCM)
11.1. CORBA и компоненты
11.2. Структура модели
11.3. Этапы создания компонентных программных систем
11.3.1. Анализ и проектирование
11.3.2. Описание компонентов
11.3.3. Реализация компонентов
11.3.4. Упаковка компонентов в пакеты
11.3.5. Сборка системы
11.3.6. Развертывание и инсталляция
11.3.7. Активизация экземпляров компонентов
11.4. Основы компонентной модели
11.4.1. Что такое компонент в CCM
11.4.2. Home-интерфейсы компонента
11.4.3. Первичный ключ
11.4.4. Операции home-интерфейсов компонентов
11.5. Системные сервисы
11.5.1. Транзакции
11.5.2. Безопасность
11.5.3. События
11.5.4. Хранение
11.6. Категории компонентов
11.7. Модели использования компонентов
11.7.1. Среда реализации компонентов
11.7.2. Композиция
11.7.3. CIDL
11.7.4. Фацетные ссылки компонента
11.8. Реализация компонента
11.8.1. Программная модель контейнера
11.8.2. Внутренние интерфейсы, общие для всех типов компонентов
11.8.3. Интерфейсы для компонентов типа session
11.8.4. Интерфейсы для entity-компонентов
11.8.5. Интерфейсы расширенных компонентов
11.8.6. Серванты
11.9. Программная модель клиента
11.9.1. Компонентные клиенты
11.9.2. Некомпонентные клиенты
11.9.3. Порты
11.9.4. Модель событий
11.10. Метаданные для компонентной модели
11.11. Расширения IDL
11.11.1. Локальные объекты
11.11.2. Импорт
11.11.3. Объявление идентичности в репозитарии
11.12. Взаимодействие между компонентами CORBA и EJB
11.13. Подготовка компонентов к работе
11.13.1. Упаковка компонентов
11.13.2. Развертывание компонентов
11.14. Заключение
Глава 12. Web-приложения
12.1. Основные понятия
12.2. Что такое Web-приложения
12.3. Дескриптор развертывания Web-приложений
12.4. Реализации Web-контейнеров
12.5. Заключение
Глава 13. Сервлеты
13.1. Что такое сервлет
13.2. Контейнер сервлета
13.3. Объявление сервлета
13.4. Жизненный цикл сервлета
13.5. Контекст сервлета
13.6. Сценарий обработки запроса сервлетом
13.7. Запрос (Request)
13.8. Отклик (Response)
13.9. Сессии
13.10. Cookie
13.11. Основные интерфейсы
13.12. Основные пакеты
13.13. Безопасность
13.14. Поддержка различных языков
13.15. Фильтрация
13.16. Сравнение сервлетов с другими Интернет-технологиями
13.17. Поддержка событий и сохранение данных
13.18. Сервлет и EJB
13.19. Заключение
Глава 14. Java Server Pages (JSP)
14.1. Что такое JSP?
14.2. Жизненный цикл JSP
14.3. Стандартные директивы JSP
14.4. Стандартные действия и скрипты
14.5. Расширение функциональности JSP-страниц с помощью библиотеки тегов
14.6. JSP и EJB
14.7. Преимущества JSP
14.8. Пример JSP
14.9. Заключение
Глава 15. Model-Driven Architecture (MDA)
15.1. Несколько вступительных слов
15.2. Для чего нужен UML?
15.3. Визитная карточка UML
15.4. Основные понятия UML
15.4.1. Случаи использования (use case)
15.4.2. Связи
15.4.3. Типы, атрибуты и системные элементы
15.4.4. Обязанность
15.5. Диаграммы UML
15.6. Семантика UML
15.7. Почему не IDL?
15.8. OCL
15.9. Meta Object Facility (MOF)
15.10. Метаданные в OMG и четырехуровневая архитектура метаданных
15.11. Структура моделей OMG
15.12. Спецификация MOF
15.13. MOF Model
15.13.1. Классы
15.13.2. Ассоциации
15.13.3. Ссылки
15.13.4. Типы данных
15.13.5. Пакеты
15.13.6. Взаимоотношения между классами
15.13.7. Отображение MOF ® IDL
15.13.8. Интерфейсы MOF
15.14. Возможные применения MOF
15.15. XMI
15.16. Common Metadata Warehousing (CMW)
15.17. Структура CWM
15.18. Для чего и как используется CWM
15.19. Сценарии использования CWM
15.19.1. Сценарий ETL
15.19.2. Сценарий OLAP
15.19.3. Сценарий Questionnaire (анкетирование)
15.19.4. Сценарий администрирования хранилища
15.20. Подмодели метамодели CWM
15.21. Основы MDA
15.21.1. Основные понятия MDA
15.21.2. Стандартизация отраслевых моделей
15.21.3. Общие сервисы
15.22. Заключение
Глава 16. Сервис хранения состояний
16.1. Основные определения PSS
16.1.1. Модель хранилища данных
16.1.2. Описание хранилища данных
16.1.3. Реализация объектов-хранилищ и складов-хранилищ
16.2. PSDL
16.2.1. Описание объектов-хранилищ, складов-хранилищ и каталогов
16.2.2. Ключи
16.2.3. Фабрики
16.2.4. Реализации объектов-хранилищ и складов-хранилищ
16.3. Каталоги
16.3.1. Транзакционные и основные сессии
16.3.2. Пул сессий
16.4. Коннекторы
16.5. Хранение CORBA-объектов
16.6. Взаимодействие с сервисом транзакций
16.7. PSS и компоненты CORBA
16.8. Заключение
Литература
Алфавитный указатель
ОТРЫВОК
Глава 1
Три основные технологии построения современных распределенных систем
Технология CORBA OMG
Технология J2EE Sun
Технология .NET
Сравнение CORBA, J2EE и .NET
Возможно, кто-то из вас с тоской вспоминает те сладкие денечки, когда тексты программ набивались на перфокарты, листингами укутывали длинные коридоры институтских помещений, а вычислительные машины представляли собой нечто вроде минотавра, визит к которому был делом важным, торжественным и небезопасным. Создание и отладка программ представляли собой увлекательный поединок с этим чудовищем, а наградой оказывалось чувство небывалого удовлетворения, сродни пушкинскому: «Ай да я! Ай да программист!»
Наверное, впервые соединяя два компьютера, и помыслить было невозможно, сколько проблем внесет это в столь гармоничный и таинственный мир программных систем. Те старые программы называют теперь монолитными, и, возможно, некоторые поклоняются им как долменам и кромлехам компьютерного мира. Что у нас там на дворе? Рококо или барокко? И какие капители нынче в моде? Ведь правда, слово «архитектура» отлично чувствует себя в компьютерном мире?
Действительно, стоило связать компьютеры в простейшую сеть, как появилось естественное и неудержимое желание попробовать запустить одну программу на одном компьютере, другую — на другом, и научить эти две программы взаимодействовать. Возможно, некоторые из нас до сих пор проклинают того, кто это сделал. Потому что этот шаг не просто добавил головной боли компьютерщикам, а привел к тому, что мир стал стремительно меняться. Мы имеем в виду отнюдь не только компьютерный мир… Впрочем, мы увлеклись описаниями, а впереди долгий путь, и нас ждут интересные вопр
осы, связанные с этими новыми возможностями распределенных компьютерных систем (и вытекающими из них проблемами).
Элементы распределенных систем должны уметь взаимодействовать. А если один из этих элементов вышел из строя? А если его вывел из строя злоумышленник? С одной стороны, появляются новые возможности: рост вычислительных мощностей, средства распараллеливания нагрузки, кластерные решения, — позволяющие строить многофункциональные системы уровня ERP и CRM и системы реального времени, а с другой — к таким системам выдвигаются и совершенно новые требования.
И еще несколько слов насчет программных средств. Во времена компьютерного неолита, приходя на работу в ту или иную контору, вы обычно не имели выбора. Вам предписывалось, какой из языков программирования использовать. Смена «прикида» происходила крайне редко, и прекрасные Алгол и Фортран1 никто из нас не посмеет назвать технологиями, хотя мы с большим уважением относимся и к ним, и к другим аксакалам компьютерного мира. А Фортран, насколько нам известно, до сих пор используют в миру, прежде всего для обработки научных исследований. И ведь не изобрели в это
й области ничего лучшего!
А теперь? Даже возмужавший и похорошевший Visual Basic столь тесно интегрирован в .NET, что это уже не столько язык, сколько часть этой технологии. Java же объединяет в себе уже такое количество взаимосвязанных технологий, что даже не все из них поместятся в эту книгу. Жить стало труднее, но зато намного интереснее.
В этой главе мы попытаемся рассказать вам о современных тенденциях в устройстве распределенных компьютерных систем. Представьте, что вы стоите на дороге, а перед вами (да-да!) так хорошо известный по сказкам столб с тремя указателями. Чтобы никого не обидеть, пусть будет так: туда пойдешь — CORBA найдешь, сюда пойдешь — J2EE найдешь, а сюда — получишь .NET. И мы постараемся, чтобы у вас не возникло ощущения, что при всем богатстве выбора другой альтернативы нет. Ведь без здоровой конкуренции мы получим… вы прекрасно знаете, что.
1.1. Технология CORBA OMG
Сразу признаемся: мы любим эту технологию. Однако наших чувств вполне хватает и на другие технологии, о которых мы напишем ниже. CORBA была первой ласточкой, и поэтому, возможно, ей пришлось трудней, чем другим. Но на наш взгляд, который мы никому не навязываем, CORBA можно любить и уважать уже хотя бы за то, что она дала компьютерному миру множество необыкновенно полезных идей, которые разлетелись по другим стандартам, технологиям, инструментальным средствам и программным системам.
Все началось в 1989 году, когда группа компаний, в которую входили HP, Sun, American Airlines, Canon и некоторые другие производители, а также — что очень важно — и потребители программных продуктов, организовала некоммерческое сообщество, которое назвали Object Management Group (OMG). Стратегическая задача, которую поставило перед собой это сообщество, состояла в создании технологии, позволяющей объединить программные приложения, выполняющиеся на различных программных и аппаратных платформах, взаимодействующие по различным протоколам, написанные на разных языках программиров
ания, созданные в различных уголках мира совершенно разными группами разработчиков. При этом были сформулированы два важнейших концептуальных момента.
Результаты деятельности OMG должны представлять собой набор спецификаций, а не готовый продукт.
В качестве идеологии построения такой технологии решили использовать объектно-ориентированный подход.
Прежде всего отметим, что это не первый подход к больной теме интеграции и унификации. Приведем в пример хотя бы попытку General Motors в начале 80-х создать однородный протокол для связи с полевым оборудованием. Забытый нынче MAP (Manufacturing Automation Protocol — протокол промышленной автоматики), представляющий собой стандартный коммуникационный стек для передачи сообщений в едином унифицированном формате, не нашел всеобщего признания, на которое рассчитывали его создатели. И это несмотря на вес GM на мировом рынке. Возможно, это произошло не только потому, что протокол оч
ень сложен и требует больших вычислительных ресурсов. Мы также не будем останавливаться на технических преимуществах и недостатках ни этого протокола, ни других способов интеграции до-CORBA. Мы лишь хотим сказать несколько слов о пользе стандартизации.
1.1.1. Pro и contra стандартов
Прежде всего сформулируем аксиому. Вопросы интеграции — это дипломатические вопросы урегулирования отношений различного типа и уровня в области компьютерных приложений. На нижнем уровне это касается отдельных программ, каждая из которых должна обладать определенной толерантностью для того, чтобы понять другую. На верхнем уровне это вопрос взаимоотношений компаний-поставщиков. Интеграция предполагает добрую волю и потребность во взаимодействии. Конкретное решение одной компании или даже группы компаний вряд ли найдет всеобщую поддержку просто по
тому, что остальным это невыгодно. Совершенно очевидно, что средство интеграции должно располагаться «вне» интересов отдельных компаний и предмета интеграции (мы бы даже сказали — над ними). Именно это место и принадлежит стандартам.
Хотим еще раз подчеркнуть, что односторонняя интеграция невозможна или, скажем мягче, неэффективна и «незаконна». Закрытое приложение, защищенное от доступа, можно, конечно, взломать, но это уже будет не интеграция, а разбой. И мы недаром употребили термин «дипломатия». Приложения, их изготовители и пользователи должны придерживаться определенных норм. Если нужно объединить два приложения, это еще могут быть их собственные нормы. Если же взглянуть на проблему шире и рассуждать об интеграции множества программных систем (а именно это является реальностью
для большинства современных компаний), учитывая, что завтра к ним добавятся новые, то приходится говорить о целом правовом компьютерном институте. Мы имеем в виду необходимость придерживаться определенных стандартов в целях получения выгоды от предоставляемых возможностей интеграции.
Именно поэтому OMG занимается только стандартами и принципиально не разрабатывает готовые продукты.
Однако вы бы заслуженно обиделись на нас, если бы мы не указали на несколько весьма существенных недостатков подобного подхода. Прежде всего, мало разработать стандарты, надо уговорить или заставить все заинтересованные стороны им следовать. Трудно представить себе, чтобы какая-либо организация могла заставить компании различных отраслей промышленности и областей бизнеса использовать тот или иной стандарт в столь интимной части, как интеграция программных приложений. Хотя мы не исключаем, что в будущем государства станут уделять этим вопросам больш
е внимания и...
У OMG, конечно, нет возможности навязывать свои стандарты. Поэтому им пришлось сделать такой стандарт, который использовать выгодно. Впрочем, путь к тому положению, которое занимает OMG сегодня, далеко не был усеян розами без шипов. Мы достаточно давно следим и какое-то время даже участвуем в деятельности сообщества. Так вот, примерно до 1998 года все публикации о CORBA, включая достаточно серьезные книги, повторяли вопрос: «Быть или не быть? Примут или не примут стандарт?» Пока этот вопрос зрел, OMG росла. Начавшись с 13 членов, сообщество сейчас насчитывает более 900
компаний, среди которых, кроме производителей и поставщиков программных решений и компьютерного оборудования, — крупные промышленные и финансовые предприятия, государственные и учебные организации, консалтинговые фирмы и системные интеграторы. Возможно, именно такая сила привела к тому, что с 1999 года нам уже не встречались подобные сомнения.
Другая проблема стандартов — старение. От появления стандарта до выхода программных решений, соответствующих этому стандарту, и их утверждения на рынке проходит определенное время. И чем сложнее стандарт, тем этот период больше. Хотя OMG выработала довольно интересную процедуру создания и принятия стандартов, которая направлена прежде всего на сокращение подобного периода (вы можете найти ее описание, например, в [8]), это и для нее остается существенной проблемой. В этом смысле готовые решения имеют перед стандартами серьезное преимущество.
С другой стороны, стандарты — это не догма. Они тоже должны развиваться, и OMG это понимает. Естественно, раз цикл развития длиннее, поддержание плавной смены стандартов становится совсем уж трудной задачей. Мы расскажем далее, как удается решать эту задачу OMG.
Нам не просто нравится CORBA и вся деятельность OMG. Мы можем сформулировать, что нас восхищает. Это сочетание современных и технически авангардных подходов с романтической устремленностью в будущее. Это бесстрашие и энтузиазм не только в постановке стратегических задач, но и в их решении. Мы назвали бы это «амбициозностью» — вслед за западными специалистами (ambitious, наверное, наиболее часто используемое по отношению к OMG прилагательное), — но в русском переводе термин приобретает нехорошую заносчивость, которой OMG начисто лишен. Как известно, в разработке ст
андартов может принять участие любой желающий. Нам нравится открытость сообщества и демократическая процедура голосования.
Но все вы прекрасно знаете множество других прекрасных и светлых начинаний, которые имеют столь бледную реализацию, что она напоминает замысел, как плохая карикатура — живой образ. Мы уже говорили о размере и запутанности спецификаций. Некоторые недостатки вы найдете и в последующих главах, некоторые обнаружите самостоятельно, о прочих услышите или прочитаете в другом месте. Но, пожалуйста, не забудьте, что CORBA стала одним из немногих стандартов, который имеет множество реализаций, эксплуатируемых уже годами, и сотни программных систем, выполняющих сво
и производственные функции, используют эти реализации.
Конечно, не все программные продукты, поддерживающие стандарт CORBA, одинаковы. Многие производители вносят что-то свое. Зачастую эти новаторские решения оказываются столь успешны, что попадают в основной стандарт. Так, на наших глазах это происходит с интерсепторами, которые придумала компания Borland. Разные реализации поддерживают разные версии стандарта, некоторые не поддерживают отдельные особенности. Разобраться в этом не так сложно, и здесь вам поможет страница сайта OMG http://www.corba.org/vendors/b.htm и технические описания этих продуктов.
Напоследок заметим, что стандарт CORBA — это живой стандарт, чья третья версия появилась совсем недавно (в июне 2002 года), так что нам неизвестны1 полностью поддерживающие ее программные продукты. Несомненно, основой CORBA 3 является компонентная модель, которой посвящена глава 11 нашей книги.
1.1.2. Философия CORBA и политика OMG
CORBA создавалась как технология, призванная объединить разрозненные сообщества компьютерных приложений. Архитектуру OMA, которая является основой CORBA, OMG назвала «архитектурой для объединения мира». С одной стороны, CORBA старается научить приложения общаться, причем не делает различия между «правоверными» объектно-ориентированными или «еретиками», написанными на Коболе. CORBA — демократическая технология и, несмотря на заведомую сложность (если не сказать — невыполнимость) подобной задачи, OMG всегда твердо стояла на своем:
1. Объединяются приложения как новые, так и наследуемые (legacy).
2. Эти приложения могут выполняться на различных операционных платформах (вплоть до самых экзотических, типа Open VMS, Digital UNIX или OS390).
3. Стандарты не стоят ничего — их может получить и использовать любой желающий.
Когда мы первый раз увидели этот невероятный список принципов, нам показалось, что реализовать все это невозможно. Мы решили, что как и во многих других случаях, прекрасные замыслы потихоньку растеряются по мере продвижения к результату. Велико было наше удивление, когда обнаружилось, что стандарты не просто позволяют использовать в распределенной среде «старые» приложения, но есть немалое число успешно реализованных проектов, которые построены именно таким образом. Огромное количество «тяжелых» корпоративных приложений, написанных на Коболе и выполн
яющихся на мэйнфреймах, благодаря технологии CORBA получили единственный шанс прижиться в современном мире Интернета и всеобщей открытости.
Возможно, именно поэтому, не поступаясь принципами, CORBA к концу XX века заняла подобающее место, а не стала еще одним печальным опытом построения «компьютерного коммунизма».
В OMG входят сотни компаний. Но компании состоят из людей, и развитие OMG определяется добровольной и самоотверженной работой сотен и тысяч специалистов — как лидеров компьютерной науки, так и их добросовестных помощников. Мы надеемся, что по мере чтения этой книги вы увидите, какие полезные и передовые идеи открыла для нас OMG. Мы не будем перечислять имен из боязни кого-то пропустить, а всех перечислить просто невозможно. В следующих главах вам встретятся некоторые известные фамилии, другие вы можете увидеть на сайтах OMG http://www.omg.org, http://www.corba.org и на других с
айтах по технологии CORBA.
В этой главе два следующих раздела отводятся прямым конкурентам CORBA — технологиям Java и .NET. В конце главы мы планируем привести короткое сравнение этих технологий. Но сейчас речь не о том, кто лучше — кто хуже, а о том, как обстоит дело со здоровой конкуренцией. Прежде всего, родители конкурентов также являются членами OMG. Sun Microsystems Inc. является одним из основателей сообщества, а Microsoft присоединилась к OMG в 1997 году. Это произошло после того, как в CORBA были стандартизованы мосты CORBA-COM и COM-CORBA. Вскоре появились и соответствующие программные продукты. Возможно, им
енно присоединение Microsoft помогло утверждению CORBA.
Вы увидите в дальнейшем, как тесно переплетены CORBA и Java. Это и RMI поверх IIOP, о котором вы прочитаете в следующей главе и который нашел столь широкое применение. Это и симбиоз двух компонентных моделей — J2EE (Java 2 Enterprise Edition) и CСМ (CORBA Component Model), о котором вы сможете узнать из глав 9 и 11. Очевидно, что один из тезисов OMG — это принцип Кота Леопольда: «Давайте жить дружно!»
На пути всеобщей интеграции OMG пришла к логической точке создания Model-Driven Architecture, которой посвящена глава 15. Эта архитектура объединяет все вышеприведенные платформы под сенью очевидной идеи, что бизнес-логика программных приложений по большому счету не зависит от технологической основы. Поэтому первый этап моделирования приложений не должен учитывать специфику выбранной (а возможно, еще и не выбранной к этому моменту) платформы.
Конечно, каждая из технологий имеет свои полезные особенности, которые приложение может и должно использовать. Но их уместно подключать на втором этапе создания прикладных моделей. Что это — соглашательская позиция OMG? Нет, это постоянные и твердые попытки не позволить компьютерному миру распасться на враждебные лагеря ни на уровне людей и компаний, ни на уровне приложений и систем.
1.1.3. Область ответственности CORBA
Мы достаточно часто рассказываем о CORBA на семинарах и конференциях. И достаточно часто слышим от собравшихся: «Технология CORBA сложна и требует больших вычислительных ресурсов. Мы прекрасно обходимся без нее и уже съинтегрировали все, что нам надо». Мы пожимаем руки всем успешным интеграторам, как использующим CORBA, так и избегающим ее.
Любую технологию, сколь бы полезна она ни была, нельзя использовать во всех ситуациях. Посмотрите, что произошло, например, с Интернетом. После бума — резкий спад. Хорошо, что с помощью CORBA еще не переносят данные из Excel в MS SQL.
CORBA — это «тяжелая артиллерия», которая позволяет реализовать интеграцию приложений с требуемым уровнем сервисов: надежности, безопасности, целостности, производительности и т. д. Вы можете обмениваться файлами, использовать EDI, конвертировать данные или делать, что вам заблагорассудится, если вас это устраивает. Но если вам понадобится добиться серьезной производительности или реализовать гарантируемую передачу сообщений из одного приложения в другое, то, возможно, без CORBA вам не обойтись.
Конек CORBA — это, несомненно, интеграция legacy-приложений. Как мы уже говорили, для многих из них это единственная возможность приспособиться к изменившимся условиям функционирования и научиться взаимодействовать с более современными приложениями.
В области EAI (Enterprise Application Integration) существуют два направления, которые по очереди одерживают верх друг над другом. В соответствии с первым из них интеграцией занимается отдельно выделенный функциональный элемент. Второе направление возлагает эту обязанность на программных агентов, расположенных на каждом узле системы. Первое — область интеграционных серверов, второе — CORBA. В реальной жизни обычно используют некоторую комбинацию обеих возможностей. В любом случае при выборе технологии надо исходить из конкретной задачи и имеющихся в наличии возможн
остей. К последним относится знание и опыт использования той или иной технологии.
Стандарт для анализа и проектирования программных систем — язык моделирования Unified Modelling Language (UML) — используется повсеместно в различных областях компьютерных технологий. Постепенно приобретает популярность средство описания метамоделей и репозитариев — Meta Object Facility (MOF). Мы опишем эти стандарты в последней главе книги вместе с Model-Driven Architecture, которая только выходит в свет и судьба которой, надеемся, сложится так же удачно.
1.2. Технология J2EE Sun
Технология J2EE (Java 2 Enterprise Edition), формально объявленная в декабре 1999 года, представляет собой первый стандарт для создания корпоративных распределенных многозвенных приложений. Избежав обычно печальной участи «первого блина», J2EE получилась на редкость гармоничной, удобной и полезной. Впитав, как губка, другие стандарты, среди которых важнейшими являются CORBA и XML, J2EE позволяет существенно упростить труд системных архитекторов, проектировщиков и разработчиков, предлагая ясную и гибкую архитектуру и набор взаимосвязанных стандартов для использования важн
ейших системных сервисов. J2EE объединяет такие стандарты, как компонентная модель Enterprise JavaBeans, стандарты Web-приложений для формирования динамических откликов на действия пользователей — Java Servlets и JavaServer Pages, стандарт для доступа к базам данных JDBC. Мы посвятим каждому из этих стандартов по отдельной главе, здесь же хотим показать их взаимосвязь и место в общей картине J2EE и в области распределенных компьютерных приложений.
1.2.1. Семейка Java
Не удивительно ли, что в последнее время совсем не появляется языков программирования в чистом виде? Собственно, совсем молодых два: C# и Java. Если первый представляет собой важный элемент машины под названием .NET, о которой мы поговорим в следующем разделе, то назвать вторую просто языком язык не поворачивается (простите за невольный каламбур). Нам не кажется, что это случайность.
Современное программирование давно перестало быть просто написанием кода (пусть даже довольно заковыристого). По оценкам экспертов сама функциональность занимает только около 20–30 % программного кода, а все остальное отводится системному хозяйству и поддерживает должное поведение программного обеспечения. И такой перевес нарастает. Действительно, современные приложения, на которых основывается производственная, финансовая и организационная деятельность предприятий, очень сильно отличаются от более старых собратьев. Они должны поддерживать одно
временные обращения сотен и тысяч клиентов, функционировать в режиме 8ґ24ґ365, предоставлять доступ в соответствии с определенными полномочиями, обеспечивать динамический и богатый интерфейс.
Все рассматриваемые в этой главе технологии стараются освободить разработчиков от этого бремени. И если в рамках CORBA описаны стандарты для 17 системных сервисов, то в этом отношении J2EE существенно скромнее.
Стандартные сервисы, определяемые J2EE, вы можете увидеть на рис. 1.1. В дальнейшем мы остановимся подробно на некоторых из них.
Java Naming and Directory Service (JNDI), позволяющий компонентам J2EE отыскивать объекты в распределенной среде, описан в главе 3.
Java DataBase Connectivity (JDBC), занимающийся обеспечением доступа приложений к базам и репозитариям данных, рассмотрен в главе 4.
Java Transaction API и Java Transaction Service, поддерживающие порядок выполнения транзакций для компонентов J2EE, описаны в главе 6.
Java Messaging Service, стандартизующий механизм обмена сообщениями, является одним из предметов главы 8.
Мы не смогли охватить необъятное и поэтому апплеты, JavaMail (API для создания приложений, связанных с обменом и обработкой сообщений электронной почты) и коннекторы (API для взаимодействия с legacy-приложениями) не нашли отражения в этой книге. В свое оправдание хотим сказать, что про первые написано слишком много, а про последние слишком мало, чтобы мы могли надеяться описать их должным образом.
Прикладная модель J2EE (рис. 1.2) состоит из четырех слоев, каждый из которых может функционировать на одном или нескольких узлах распределенной системы. В отличие от традиционной трехзвенной архитектуры, появился слой Web-серверов, который занимается подготовкой презентационной части для клиентов. Модель состоит из четырех уровней:
уровень client-tier, объединяющий клиентские компоненты, выполняющиеся на клиентских компьютерах;
уровень web-tier, объединяющий Web-компоненты, выполняющиеся на Web-серверах;
уровень business-tier, объединяющий бизнес-компоненты, выполняющиеся на J2EE-серверах, которые называются серверами приложений;
уровень EIS-tier1, объединяющий элементы информационных систем, выполняющиеся на EIS-серверах, обычно на серверах баз данных.
Приложения, удовлетворяющие стандарту J2EE, состоят из компонентов, которые в процессе выполнения приложений взаимодействуют друг с другом. Спецификация определяет компоненты следующих типов:
клиентские приложения и апплеты, которые выполняются на клиентских компьютерах;
сервлеты и Java Server Pages, которые представляют собой Web-компоненты и выполняются на Web-серверах;
Enterprise JavaBeans, которые являются бизнес-компонентами и выполняются на прикладных серверах.
Эти компоненты общаются с помощью различных средств: HTML, XML, RMI — и взаимодействуют через различные протоколы: HTTP, HTTPS, IIOP. Они устанавливаются и выполняются в специальной прикладной среде — контейнерах, которые берут на себя груз системной поддержки и переговоры с клиентами. Для взаимодействия с существующими приложениями в рамках J2EE стандартизована модель коннекторов.
Все компоненты J2EE имеют одно общее свойство: они должны быть написаны на языке Java. Исключением являются только клиентские приложения. Стандарт разрешает CORBA-клиентам взаимодействовать с серверными компонентами J2EE. Вместе с тем компоненты J2EE отличаются от других J2EE-приложений по нескольким параметрам:
они должны соответствовать спецификации J2EE;
они разворачиваются во время развертывания J2EE-приложений;
они управляются и поддерживаются серверами приложений.
Клиенты J2EE-приложений могут быть нескольких типов. Кроме упоминаемых выше CORBA-клиентов можно выделить Web-клиентов, которые взаимодействуют с серверными компонентами с помощью браузеров. Такие клиенты состоят из двух частей:
динамических Web-страниц, написанных на языках разметки (XML, HTML и др.), которые генерируются Web-компонентами, выполняющимися на Web-серверах;
Web-браузеров, которые визуализируют эти страницы, получаемые от Web-серверов.
Мода на Web-клиентов вернула нас к тонким или даже сверхтонким клиентам.
Основным элементом J2EE, несомненно, является компонентная модель Enterprise JavaBeans. Можно сказать, что J2EE предоставляет стандартное API, инфраструктуру и набор типовых клиентов для EJB.
Есть еще одно понятие, которое будет встречаться нам на протяжении всей книги и о котором мы хотели бы здесь упомянуть. Это контейнеры, которые можно определить как низкоуровневые API, связывающие компоненты с клиентами и системными сервисами. Процесс инсталляции приложений теперь состоит в сборке компонентов в приложение и встраивании их в контейнер. Для каждого типа компонента существует свой тип контейнера.
Архитектура J2EE через контейнеры поддерживает различные модели для прикладных сервисов: безопасности, транзакций и наименований. Контейнеры также отвечают за жизненный цикл компонентов J2EE и взаимодействие с хранимыми данными. Мы опишем соответствующие контейнеры в главах 9, 13 и 14, посвященных EJB, сервлетам и JSP.
Одна из отличительных особенностей современных стандартов в области разработки — это пристальное внимание не только к самому процессу создания приложений, но и к специалистам, которые управляют этим процессом и осуществляют его. Наиболее подробна и внимательна в этом смысле технология J2EE, которая определяет отдельные роли, сопровождающие компонентные приложения на всех этапах жизненного цикла. Для корпоративных приложений, которые могут объединять сотни и тысячи компонентов, разделение обязанностей становится непременным условием успешности проекта. Технология J2EE выделяет следующие роли.
J2EE Product Provider — компания-разработчик, которая поставляет на рынок платформу J2EE, API и другие компоненты спецификации J2EE.
Tool Provider — компания-разработчик, которая создает средства разработки, сборки и упаковки для создания J2EE-приложений.
Application Component Provider — разработчики компонентов:
Enterprise Bean Developer — разработчики компонентов бизнес-логики, определяющие также структуру дескриптора развертывания для EJB и собирающие JAR-файл1;
Web Component Developer — разработчики Web-компонентов (сервлетов, апплетов, JSP- и HTML-страниц), которые также определяют дескриптор развертывания, только для сервлетов и JSP, и собирают WAR-файл2;
J2EE Application Client Developer — разработчики «толстых» клиентов, которые собирают JAR-файл для клиентской части;
Application Assembler — собирают из компонентов на основе предоставленных JAR- и WAR-файлов архивный EAR-файл3 приложения.
Application Deployer — конфигурируют и разворачивают приложение, устанавливая параметры дескрипторов развертывания.
Administrator — поддерживает работоспособность приложения, по необходимости изменяя установки.
В главе 9 вы сможете узнать про роли, относящиеся к созданию компонентов EJB, а в главе 10 вы более подробно познакомитесь со структурой серверной и клиентской частей J2EE-приложений и архивными файлами.
1.2.2. Область применения J2EE
Наши достоинства — продолжение наших недостатков. То, что технология J2EE ориентирована на один язык программирования, причем молодой и прогрессивный, позволило ей избежать многих проблем, с которыми столкнулась, например, CORBA. Все вы знаете, в каких муках рождалась компонентная модель CORBA, хотя, казалось бы, после появления стандарта EJB надо было только еще немного расширить эту модель.
J2EE представляет собой популярный стандарт, который используется в сотнях реализаций, называемых серверами приложений. Этот тип программного обеспечения без сомнения можно назвать одной из наиболее бурно развивающихся областей компьютерных технологий и, как следствие, областью, в которой царит острая конкуренция.
Сертификация программных продуктов (серверов приложений) по J2EE выполняется с помощью набора тестов, разработанных компанией Sun, — J2EE Compatibility Test Suite. Тесты включают проверку всех классов и методов, упоминаемых в спецификации J2EE, а также проверку взаимодействия всех компонентов спецификации. Программные продукты, выполняющиеся на программных продуктах (серверах приложений), сертифицированных на соответствие одному и тому же релизу, должны быть портируемыми. Это позволяет переносить приложения с одного сервера приложений на другой без изменения исходного кода1. Список серверов приложений, прошедших тесты, вы можете найти на http://java.sun.com/j2ee/compatibility.html.
Серверы приложений наиболее активно используются для создания Web-приложений. Пережив всплеск повышенного спроса, Web-приложения постепенно занимают свое достойное место в компьютерном мире. Именно серверы приложений позволяют относительно быстро создавать гибкие, масштабируемые и производительные Web-порталы. На самом деле пока нет технологии, которая бы лучше подходила для этих целей. Но не будем ограничивать область применения серверов приложений только порталами. Нам известны успешные примеры создания J2EE-приложений корпоративного уровня, реализующих функциональность ERP- и CRM-систем. И мы верим, что количество подобных приложений будет расти вместе с развитием технологии J2EE.
1.3. Технология .NET
Мы с трудом преодолели соблазн обойти одиозную тему в нашей книге. Но по зрелому размышлению решили, что не сказать ничего просто не можем.
Можно по-разному относиться к компании Microsoft, но честно признаемся, что и в офисе, и дома мы используем именно операционную систему Windows2. И мы уверены, что не одиноки. Конечно, любая книга ограничена, да мы и не претендуем на роль экспертов в области .NET. Поэтому в этом разделе мы не будем углубляться в технические детали, а выскажем свой взгляд на технологию, которая является противовесом первым двум, рассмотренным в этой главе.
1.3.1. Краткий обзор технологии .NET
Компонентная идея заразила Microsoft еще в начале 90-х годов. Как и другим компаниям, ей стало очевидно, что скорость создания программных систем существенно отстает от предъявляемых бизнесом требований. Вместе с тем, из программы в программу повторяются общие элементы, которые программисты исправно пишут, каждый раз изобретая велосипед. Во многом повторяя идеи, заложенные в CORBA (в частности, язык описания интерфейсов), Microsoft создала технологию COM, первая версия которой появилась в 1993 году. Однако не секрет, что COM имеет существенные недостатки. Прежде всего, COM поддерживает взаимоотношение приложений, выполняющихся на одном компьютере, что, согласитесь, в современном распределенном мире не всегда удобно. Попытки Microsoft устранить этот досадный недостаток с помощью DCOM (Distributed COM), как и всякое латание дыр, не привело к ожидаемым результатам, и тогда Microsoft приняла единственно верное решение. На базе COM и сервера транзакций Microsoft Transaction Server была разработана специальная техн
ология .NET. Впрочем, процесс разработки .NET продолжается.
В соответствии с определением, Microsoft .NET — это среда выполнения Web-приложений в ОС Windows 2000. Цель создания .NET все та же — сократить и упростить разработку, внедрение и поддержку распределенных программных систем, в данном случае — функционирующих на платформах Windows. Среда .NET добавляет к операционной системе Windows такие важные функции, как автоматическая сборка мусора и простой доступ к базам данных и Интернету, и расширяет компонентную модель COM+. Она развивает среду ASP (Active Server Page), созданную Microsoft в 1997 году как элемент Internet Information Server, который входил в Windows NT 4 Option Pack.
Основная идея .NET заключается в понятии управляемого кода, который выполняется не просто на операционной системе Windows, а под управлением ее дополнительного элемента — среды CLR (Common Language Runtime) — общей среды выполнения для программных приложений, написанных на различных языках. CLR очень похожа на Java Runtime Environment (JRE). При этом программы (с помощью, например, Visual Sudio .NET) компилируются в код на специальном языке Microsoft Intermediate Language (MSIL, или IL). Среда CLR, в частности, освобождает программистов от сборки мусора не хуже, чем Java, проводя автоматическую чистку неиспользуемой памяти (garbage collection). На нее также возложено управление доступом к программному коду.
В настоящее время существует множество компиляторов программных языков в IL, в дополнение к предоставляемым Microsoft для Visual Basic, C#, JScript и C++. Такая унификация вынудила Microsoft сблизить языки, которые поддерживаются в Visual Studio .Net. Особенно это касается новой версии Visual Basic.
Для того чтобы выполняться на конкретной операционной платформе (которых в семействе Windows тоже предостаточно), код на IL должен быть обработан just-in-time-компилятором (JITter), после чего и получается соответствующий машинный код. В настоящее время существуют JITter для Windows 2000 и Windows XP.
Таким образом в .NET реализована идея формирования машинного кода «на лету», которая с успехом используется в Java. JITter с помощью специальных настроек может формировать машинный код только один раз — во время первого вызова программы, а может повторять эту процедуру каждый раз при вызове программы.
Технология .NET также обещает избавить от одной из основных головных болей, связанную с ведением версий программных компонентов. Теперь описательный файл приложений содержит полную информацию об используемых версиях библиотек и других компонентов, а само объединение элементов приложения, получающееся в результате сборки компонентов, может содержать несколько различных версий одного и того же компонента.
Для динамического Web .NET предлагает модернизированную среду ASP .NET. В ней реализована идея отделения динамического кода от статического текста HTML-страниц, причем первый можно создавать и отлаживать в Visual Studio с помощью специальной модели Web Forms. Кроме того, ASP .NET выгодно отличается от просто ASP в возможностях сохранения состояния сессий. Конфигурационная информация Web-приложения хранится в специальном файле в формате XML, так же как и в J2EE.
Нельзя говорить о .NET и ни слова не сказать о Web-сервисах — новом направлении развития Интернета, которое по замыслу его создателей Microsoft и IBM позволит приложениям взаимодействовать, динамически отыскивая в глобальной сети необходимые сервисы и вызывая их по мере необходимости. Web-сервисы используют для передачи сообщений протокол SOAP (Simple Object Access Protocol), описываются на языке WSDL (Web Services Definition Language) и используют механизм UDDI (Universal Description, Discovery and Integration) для публикации и поиска сервисов. Все эти элементы представляют собой спецификации международной организации W3C и активно развиваются.
Для поддержки Web-сервисов Microsoft, опять же вместе с IBM, предложили новую архитектуру SOA (Service-Oriented Architecture), в основе которой лежит понятие сервиса как основы взаимоотношения приложений. Вокруг этого понятия можно очертить ролевой треугольник, в вершинах которого будут находиться Service requester (подписчик), запрашивающий сервис, Service provider, предоставляющий сервис, и Service broker, позволяющий подписчику найти провайдера.
Технологически .NET представляет собой семейство продуктов, основанное на известных стандартах в области бизнеса и Интернета, и объединяет следующие типы серверов, каждый из которых обладает собственной функциональностью и представляет собой отдельный продукт:
Application Center 2000 (используется для развертывания и управления Web-приложениями);
BizTalk Server 2002 (служит для построения бизнес-процессов, объединяющих разные приложения и организации);
Commerce Server 2000 (предназначен для построения масштабируемых решений в области электронной коммерции);
Content Management Server 2001 (выполняет роль управления контентом для динамических Web-сайтов в области электронного бизнеса);
Exchange 2000 Server (используется для передачи сообщений и обеспечения совместной работы других серверов);
Host Integration Server 2000 (применяется для интеграции наследуемых (legacy) приложений, например выполняющихся на мэйнфреймах или миникомпьютерах);
Internet Security and Acceleration Server 2000 (его роль — организовать быстрый и безопасный доступ в Интернет);
Mobile Information 2001 Server (занимается поддержкой мобильных устройств, прежде всего мобильных телефонов);
SharePoint Portal Server 2001 (служит для поиска, распределения и публикации бизнес-информации);
SQL Server 2000 (используется для запоминания, хранения, извлечения и анализа структурированных XML-данных).
1.3.2. BizTalk, или Как легко интегрировать приложения
BizTalk является развитием идей, заложенных Microsoft в Commerce Interchange Pipeline и Commerce Interchange Pipeline Manager (дополнительные элементы Site Server 3.0 Commerce Edition). BizTalk использует ту же самую библиотеку Pipecomplib.tlb.
Сервер BizTalk представляет собой интеграционный сервер и набор эффективных средств для построения и развертывания бизнес-процессов для осуществления транзакций в области EAI (Enterprise Application Integration) и B2B (Business-to-Business). Он поддерживает разнообразные протоколы, среди которых HTTP, HTTPS, SMTP, SSL, S/MIME (Secure Multipurpose Internet Mail Extensions) и SOAP.
BizTalk позиционируется Microsoft как ключевой элемент для поддержки основанных на XML бизнес-процессов, в которых могут участвовать не только разные приложения, но и разные компании.
BizTalk включает графические средства. Перечислим некоторые из них.
BizTalk Editor — средство создания спецификаций документов. Подобные спецификации представляют собой XML-файлы, которые определяют структуру, тип и версию документа.
BizTalk Mapper — графическое средство для преобразования XML-данных в различные структуры, такие как EDI (Electronic Data Interchange, например формата EDIFACT) или flat-файлы. Если формат, определенный BizTalk Editor, по каким-то причинам вас не устраивает, то вы можете использовать это средство для того, чтобы отобразить его в определенный вами формат.
BizTalk Messaging Manager — графический интерфейс, содержащий мастер (wizard) для создания портов и каналов, с помощью которых можно управлять обменом данными между приложениями. С помощью BizTalk Messaging Manager создается объектная спецификация документа, которая запоминается в базе данных MS SQL.
BizTalk Orchestration Designer — средство создания, развертывания и управления распределенными бизнес-процессами. Он основан на графическом интерфейсе Microsoft Visio. Музыкальное понятие «оркестровка» является аналогией между ролью BizTalk по отношению к бизнес-процессам и дирижером по отношению к оркестру. С помощью дизайнера создается специальное расписание на скриптовом языке, которое задает последовательность обработки бизнес-процессов.
Основными компонентами BizTalk являются Application Integration Component (AIC) и компоненты типа pipeline, которые напрямую происходят от pipeline component (типа Order Processing и Commerce Interchange) Microsoft Site Server 3.0. Другой важный элемент сервера — пользовательские препроцессоры, которые используются для предварительной обработки документов, если ее необходимо произвести до передачи документа BizTalk серверу.
BizTalk включает в себя так называемые сервисы передачи и обработки сообщений (Messaging Services), хотя в данном случае это касается не столько сообщений, сколько документов. Эти сервисы умеют:
получать входящий документ;
разбирать документ в соответствии с определенным для него форматом;
выделять ключевые идентификаторы и идентифицировать правила маршрутизации;
доставлять документ соответствующим адресатам;
отслеживать передачу документа;
связывать данные одного документа с данными другого;
поддерживать целостность документов и ограничения прав доступа.
Последняя версия BizTalk Server 2002 обладает рядом полезных особенностей. Для развертывания компонентов BizTalk используется Application Center 2000. Появился новый элемент — Windows Management Instrumentation (WMI), который позволяет управлять бизнес-процессами с помощью графического интерфейса. Новый сервер включает SOAP Toolkit 2.0, который может синхронизировать бизнес-процессы, включающие использование Web-сервисов.
В настоящее время уже создано некоторое количество адаптеров, позволяющих соединять BizTalk-сервер с различными корпоративными приложениями, например SAP, Oracle Financials, People Soft, Siebel, Remedy. Вы можете получить информацию о доступных адаптерах на странице www.microsoft.com/biztalk/evaluation/adapters.asp.
BizTalk привлекает своей простотой, доступностью, интеграцией с VisioStudio .NET и удобными средствами администрирования. Возможно, это решение будет наиболее популярным для интеграции Windows-приложений, основанной на обмене документами между приложениями, например, в области электронной коммерции, на ближайшие несколько лет.
1.4. Сравнение CORBA, J2EE и .NET
Несмотря на заведомую неблагодарность подобного занятия мы все же решили посвятить несколько страниц сравнению всех трех технологий. Постараемся отвлечься от собственных пристрастий и проанализировать ситуацию по возможности непредвзято.
На самом деле, с появлением Интернета сравнивать конкурентов в какой бы то ни было области стало неинтересно. Новаторские решения одного сразу становятся достоянием другого. Поэтому очень трудно выделить те элементы, которые присутствуют в одной технологии, но не нашли отклика в другой.
1.4.1. Сравнение идеологических подходов
Все три технологии представляют собой решение из области Enterprise Integration Application (EAI). Утвердившийся подход к интеграции приложений заключается в описании внешних интерфейсов, форматов сообщений и спецификаций, используемых для передачи этих сообщений. В процесс интеграции в современном понимании этой задачи также вовлечено понятие Quality-of-Service, в особенности все, что касается сервисов безопасности, надежности и транзакционной целостности. Но создатели всех трех технологий почувствовали, что этого недостаточно. Интеграция программных приложений, так же как и сами приложения, реализует потребности бизнеса, поэтому необходимо привлечь в интеграционную модель элементы описания бизнес-процессов.
Пожалуй, как и во многих других случаях, первопроходцем выступило OMG, которое в конце 90-х годов выпустило несколько спецификаций, формализующих понятие бизнес-объекта, средств управления бизнес-объектами и среды их функционирования (Business Object Facility (BOF) и Business Object Component Architecture (BOCA)). Стандарты моделирования OMG (UML, MOF, MDA) также позволяют связать бизнес-модель распределенной системы с техническими средствами CORBA и ее компонентной модели.
Технология J2EE пока не стандартизовала средства моделирования и проектирования бизнес-процессов. Но в реальности большинство средств разработки содержат встроенные средства моделирования, которые позволяют автоматически генерировать компоненты J2EE на основе бизнес-моделей. Приведем в качестве примера JBuilder 6 Enterprise Edition компании Borland.
В соответствии с идеологией Microsoft, заложенной в .NET, необходимым элементом реальной интеграции признаются бизнес-процессы, позволяющие определить, как и когда создаются сообщения, как они доставляются адресату, как обрабатываются им и каким образом формируется и посылается отклик, если это предусмотрено. Бизнес-процессы в .NET определяют логическую последовательность действий приложения и сопровождающий эту последовательность поток сообщений.
Еще одна важная особенность всех трех технологий связана с их местом в общей иерархии программного обеспечения. По сути, любая из рассмотренных нами сред представляет собой промежуточное программное обеспечение. Однако для всех трех (хотя для CORBA в меньшей степени) характерно постепенное сращивание с операционными платформами. И если .NET можно рассматривать как новую версию Windows 2000, то Sun One, недавно анонсированная Sun Microsystems, интегрирована и с аппаратной платформой.
В следующих главах книги вы познакомитесь с последовательностью создания современных распределенных программных приложений. Здесь все три технологии придерживаются одинаковых принципов и терминологии. Вы не найдете существенных отличий и в подходе к такому важному этапу, как сборка приложений: для всех трех технологий это объединение разнообразных файлов, составляющих приложение (естественно, типы фалов могут отличаться). Наконец, во всех трех технологиях присутствуют дескрипторы — XML-файлы, описывающие параметры, необходимые для выполнения приложений и определяющие настройки системных сервисов.
Вы можете увидеть отчетливую аналогию между ASP и JSP, недаром их названия настолько созвучны. Обе технологии: и J2EE, и .NET — придерживаются сходных подходов к созданию и обработке динамических Web-страниц. И это нас совершенно не удивляет.
Мы можем также проследить аналогию между другими Web-компонентами: сервлетами и Web Forms Server Control (серверные элементы управления динамическими страницами в ASP .NET). Но надеемся, что вы уже поняли, насколько схожи идеи, лежащие в основе соперничающих технологий.
1.4.2. Сравнение с точки зрения применения
Как же выбрать тогда технологию, наилучшим образом подходящую к решению конкретной задачи? Можно, конечно, обратиться к результатам тестов на производительность. В этом случае можем отослать вас к тестированию любимого примера Sun для J2EE, а именно магазина Pet Shop на платформе Oracle 9i Application Server. Результаты теста производительности приведены по адресу http://otn.oracle.com/tech/java/oc4j/content.html. Можно также попытаться оценить выбираемую стратегическую платформу по нескольким критериям. В качестве примера можем порекомендовать следующие:
необходимость портируемости приложения на различные платформы;
требуемые интеграционные свойства;
наличие квалифицированных разработчиков;
объем и сложность проекта.
Необходимо отметить, что по оценке Gartner Group по триаде «стоимость – риск – время на разработку» компонентная модель EJB уверенно побеждает COM. Gartner Group в отчете «Application Development Management Strategies» (декабрь 2001 г.) называют J2EE основной архитектурой для корпоративных приложений на ближайшие несколько лет. По их отзывам альтернативная технология Microsoft .NET и архитектура SOA (Service-Oriented Architecture) далеко еще не достигли ее уровня.
Аналитики Gartner Group прогнозируют завоевание технологией .NET мирового компьютерного рынка в конце 2003 года. По их мнению, именно тогда .NET достигнет необходимой зрелости и завершенности. Мы в этом смысле не столь категоричны и думаем, что к середине десятилетия две альтернативные платформы поделят рынок примерно поровну. При этом мы прогнозируем продолжение плодотворной конвергенции CORBA и J2EE.
Подведем некоторые итоги. На основе заключений экспертов, мнений пользователей и специалистов можно сделать некоторые выводы. Технология CORBA предоставляет уникальные возможности интеграции и поэтому должна применяться в сложных гетерогенных средах. Ее использование необходимо, например, при интеграции с legacy-приложениями. Технология .NET еще не окончательно доработана, поэтому применять ее надо осторожно, а лучше дождаться следующих версий. Добавим, что компонентная модель CORBA только-только появилась и поэтому никак не может конкурировать с компонентной моделью EJB, которая лежит в основе J2EE. Поэтому можно сделать вывод, что наиболее популярная, востребованная, используемая и доступная технология распределенных компонентных систем в настоящее время — это J2EE.
Основная претензия к технологии Java и, в частности, к J2EE — ее слабая производительность, которая особенно заметна на платформах Windows и вообще на любых платформах, отличных от Sun. Закон Мура, без упоминания которого не обходится ни одна компьютерная книжка (вот и мы не утерпели), гласит, что вычислительная мощность на единицу стоимости удваивается каждые восемнадцать месяцев. К чему это мы? Да к тому, что повысить производительность J2EE-приложений можно ведь и таким способом, что, собственно, весьма успешно и происходит на наших глазах.
1.4.3. Взаимное влияние
Мы уже много говорили о том, насколько похожи все три технологии. Мы с удивлением обнаружили в описании Web-сервисов от Microsoft упоминание протокола IIOP в одном ряду с DCOM и RMI. В рамках CORBA стандартизованы программные мосты CORBA-COM и COM-CORBA. J2EE активно использует стандарты CORBA, в частности IIOP (Internet Inter ORB Protocol) и системные сервисы. Как известно, в настоящее время CORBA-приложения и J2EE-приложения умеют взаимодействовать друг с другом практически в любой ситуации. И дальше в книге мы покажем, что компонентная модель CORBA включает компоненты EJB как полноправные составляющие (причем как в качестве клиента, так и в качестве сервера).
Мы уже останавливались на общих принципах и идеях, заложенных в каждую из технологий. Символично в этом смысле использование столь похожей на JVM CLR в .NET.
Новый стандарт OMG — MDA (Model-Driven Architecture) объединяет под своим крылом все три технологии. Построение независимой от платформы бизнес-модели позволяет в дальнейшем портировать такую модель на различные платформы middleware. Автоматическая генерация большей части кода сможет существенно сократить труд разработчика и повысить качество создаваемых программных систем. MDA упростит также интеграцию программных систем, функционирующих на различных платформах, с помощью построения отображения сходных сущностей. В рамках MDA уже стандартизован профиль CORBA, ведется работа над созданием аналогичных профилей для J2EE и .NET.
1.5. Заключение
На этом мы заканчиваем краткое описание трех технологий для распределенных программных систем. В дальнейшем в нашей книге вы встретитесь с двумя из них: CORBA и J2EE — прежде всего потому, что они очень тесно связаны друг с другом, причем не только идеологически, но и технически. Нам показалось особенно полезным объединить в одной книге описание современного состояния этих технологий и показать, как их можно использовать совместно.
Здесь мы прощаемся с .NET, которая кажется нам очень интересной, но еще слишком молода и не столь тесно связана с первыми двумя. Мы ожидаем, что в недалеком будущем появятся книги, подробно описывающие эту технологию. Надеемся также, что Java войдет полноправным членом в .NET и тогда, возможно, появятся программные комплексы, объединяющие компоненты трех типов, элементы которых функционируют на любой из трех платформ.
Технологии создания распределенных систем. Для профессионалов. / А. Цимбал, М. Аншина - СПб: Питер, 2002. - 576 с.
|