Кросс-платформенные
технологии
Кросс-платформенные технологии обеспечивают совместную эксплуатацию различных аппаратных и программных платформ в интересах организаций-потребителей.
Такими могут быть, как правило, сервисные программы, системные утилиты, текстовые и графические редакторы, компиляторы, достаточно простые корпоративные программы. Развитая корпоративная информационная система, как правило, не может состоять из отдельных, не связанных между собой компонентов.
Эта архитектура получила распространение с начала 1990-х годов на фоне роста рынка персональных компьютеров и снижения спроса на мэйнфреймы. В архитектуре "клиент-сервер" программное обеспечение разделено на две части -клиентскую часть и серверную часть. Задача клиентской-части (программы-клиента) состоит во взаимодействии с пользователем, передаче пользовательского запроса серверу, получение запроса от серверной части (программы-сервера) и представление его в удобном для пользователя виде. Программа-сервер же обрабатывает запросы клиента и выдает ответы. Классические примеры: Web -технологии (клиент-браузер, сервер- Web -сервер), работа с распределенными СУБД (клиент - специальная программа, сервер - сервер базы данных). Развитие архитектуры "клиент-сервер", а особенно появление современных графических интерфейсов, привело сначала к появлению разновидности архитектуры клиент-сервер, называемой "архитектура с толстым клиентом".Здесь логика представления данных и бизнес-логика размещаются на клиенте, который (скажем, в случае, когда сервером является СУБД ) общается с логикой хранения и накопления данных на сервере, используя язык структурированных запросов SQL.Однако необходимость установки "толстых клиентов", требующих значительного количества специальных библиотек и специальной настройки окружения, на большое число пользовательских компьютеров с различными операционными средами, как правило вызывает массу проблем. Как альтернатива поэтому возникла также двухзвенная архитектура "с тонким клиентом".При этом в идеале программа-клиент реализует лишь графический интерфейс пользователя (GUI) и передает/принимает запросы, а вся бизнес-логика выполняется сервером. В идеале клиентом является просто интернет-браузер, который имеется в стандартной операционной среде любого пользовательского компьютера и не требует специальной настройки, установки специализированного ПО и т.п. К сожалению, такая схема тоже не свободна от недостатков, хотя бы уже потому, что серверу приходится брать на себя иногда не свойственные для него функции реализации бизнес-логики приложения (например, серверу СУБД приходится выполнять расчеты!)
Начало процессу развития корпоративного программного обеспечения в многозвенной архитектуре было положено еще в рамках технологии "клиент/сервер". В них наряду с клиентской частью приложения и сервером баз данных появились серверы приложений (Application Servers).В идеале:
Программа-клиент, таким образом, может быть "тонкой". Преимущества такой архитектуры очевидны:
Следующий логический шаг - дальнейшее увеличение числа звеньев, причем возрастет не только за счет разбиения, когда "утоньшается" каждое из известных технических звеньев, но вся бизнес-модель строится как многозвенная. Современные корпоративные программные системы представляют собой, как правило, сложные системы взаимодействующих между собой на разных уровнях компонентов, каждые из которых могут являться клиентами для одних компонентов и серверами для других.
Основной проблемой систем, основанных на двухзвенной архитектуре "клиент-сервер", или тем более на многозвенной архитектуре, является то, что от них требуется мобильность в как можно более широком классе аппаратно-программных сред. Даже если ограничиться UNIX- ориентированными локальными сетями, в разных сетях применяется разная аппаратура и протоколы связи. Попытки создания систем, поддерживающих все возможные протоколы, приводит к их перегрузке сетевыми деталями в ущерб функциональности. Еще более сложный аспект этой проблемы связан с возможностью использования разных представлений данных в разных узлах неоднородной локальной сети. В разных компьютерах может существовать различная адресация, представление чисел, кодировка символов и т.д. Это особенно существенно для серверов высокого уровня: телекоммуникационных, вычислительных, баз данных.
Общим решением проблемы мобильности такого рода систем является использование технологий, реализующие протоколы удаленного вызова процедур (RPC - Remote Procedure Call) стандартизованным и платформо-независимым способом. При использовании таких технологий обращение к сервису в удаленном узле выглядит как обычный вызов процедуры (методов удаленных объектов). Средства RPC,в которых, естественно, содержится вся информация о специфике аппаратуры локальной сети и сетевых протоколов, переводит вызов в последовательность сетевых взаимодействий. Тем самым, специфика сетевой среды и протоколов скрыта от прикладного программиста.
При вызове удаленной процедуры, программы RPC производят преобразование форматов данных клиента в промежуточные машинно-независимые форматы, и затем преобразование в форматы данных сервера. При передаче ответных параметров производятся обратные преобразования. Таким образом, если система реализована на основе стандартного пакета RPC,она может быть легко перенесена в любую открытую среду.
CORBA (Common Object Request Broker Architecture) - это набор открытых спецификаций интерфейсов, определяющий архитектуру технологии межпроцессного и платформо-независимого манипулирования объектами. Разработчиками данных интерфейсов являются OMG и X/Open.
Object Management Group, Inc. (OMG) - это интернациональная организация, основана в 1989 г., состоящая более чем из 800 членов: поставщиков информационных систем, разработчиков программного обеспечения и пользователей. OMG продвигает теорию и практику объектно-ориентированной технологии в область практической разработки программного обеспечения. Этот процесс включает в себя разработку промышленных стандартов и спецификаций управления объектами с целью создания общей базы для разработки программного обеспечения. Первоочередными задачами являются: повторное использование, переносимость и интероперабельность объектно-ориентированного программного обеспечения в распределенных, гетерогенных средах. Поддержка данных стандартов создает возможность разрабатывать гетерогенные приложения, работающие на всех основных платформах и операционных системах.
X/Open - независимая всемирная открытая организация, поддерживаемая большинством крупнейших поставщиков информационных систем, пользовательских организаций и компаний-производителей программного обеспечения. X/Open разрабатывает на основе существующих и создающихся стандартов всеобъемлющее и интегрированное системное окружение - Common Applications Environment (CAE).Компоненты CAE определены в стандартах X/Open CAE.Основная цель CAE - создание пакетов программных интерфейсов (API) которые могут применяться на практике с сохранением максимальной переносимости на уровне исходных кодов программ. API также повышают уровень взаимодействия приложений при помощи предоставления определений и ссылок на протоколы и их профили.
Вышеназванные спецификации тщательно тестируются, выдержавшим тестирование присваивается X/Open trademark (XPG brand),лицензированная X/Open.
Концептуальной инфраструктурой, на которой базируются все спецификации OMG,является Object Management Architecture (OMA).В состав OMA входят разнообразные стандартизованные или в настоящий момент стандартизируемые OMG службы, сервисы, программные образцы и шаблоны (CORBAservices, horizontal and vertical CORBAfacilities),язык определения интерфейсов распределенных объектов IDL (Interface Definition Language),стандартизованные или стандартизируемые отображения IDL на языки программирования и, наконец, объектная модель CORBA.
Реализовать технологию в соответствии со спецификациями может кто угодно. Созданные программные продукты, естественно, уже не являются открытыми, а становятся коммерческими продуктами.
CORBA определяет, каким образом программные компоненты, распределенные по сети, могут взаимодействовать друг с другом вне зависимости от окружающих их операционных систем и языков реализации. Центральным элементом архитектуры CORBA является ORB (Object Request Broker) - программное обеспечение, обеспечивающее связь между объектами, в том числе позволяющее
Тем самым ORB является связующим звеном между распределенными частями основанной на технологии CORBA системы, позволяя одной части системы не заботиться о физическом расположении других частей (объектов) системы. На рынке представлены ORB разных производителей (например, VisiBroker, WebLogic),но все они соответствуют единой спецификации CORBA. Поэтому в принципе CORBA позволяет строить распределенные системы, одновременно используя ORB разных производителей, и строя систему одновременно на различных платформах и различных сетевых протоколах (это в терминологии CORBA называется интероперабельностью - interoperability).В архитектуре CORBA каждый объект, методы которого доступны другим объектам (обычно его называют CORBA -объектом) имеет уникальную по всей доступной сети Объектную Ссылку (IOR - Interoperable Object Reference),по которой к нему можно обратиться. Искать CORBA -объекты можно как по IOR, так и по символическим именам, если они зарегистрированы (обычно при создании) в специальном сервисе имен (NameService).Для обращения к методам CORBA -объекта последний имеет открытый для всех остальных CORBA -объектов интерфейс. Интерфейсы CORBA -объектов принято описывать на специальном, определенном спецификацией CORBA языке IDL (Interface Definition Language). Производители ORB поставляют вместе с ORB также и утилиты, преобразующие описания интерфейсов CORBA -объектов в конструкции соответствующих языков программирования.
Основой интероперабельности является протокол GIOP - General inter-ORB Protocol,предназначенный для связи между объектами и ORB в сети. Стандартизация коммуникационного протокола позволяет разработчикам различных частей корпоративной системы совершенно не заботиться об используемых ORBах в других частях ( ORB доменах)
системы. Почти все современные ORBbi строятся на основе IIOP - Internet inter-ORB Protocol (это версия общего протокола GIOP,предусматривающая использование в качестве транспортного протокола TCP/IP).
Спецификация CORBA предусматривает также ряд стандартизованных сервисов (CORBA Services) и горизонтальных и вертикальных Общих Средств (Common Facilities). Сервисы представляют собой обычные CORBA -объекты со стандартизованными (и написанными на IDL ) интерфейсами. К таким сервисам относится, например, уже упомянутый сервис имен NameService,сервис сообщений, позволяющий CORBA -объектам обмениваться сообщениями, сервис транзакций, позволяющий CORBA -объектам организовывать транзакции. В реальной системе не обязательно должны присутствовать все сервисы, их набор зависит от требуемой функциональности. На сегодня разработано всего 14 объектных сервисов.
Между объектными сервисами и общими средствами CORBA нет четкой границы. Последние тоже представляют собой CORBA -объекты со стандартизованными интерфейсами. Common Facilities делятся на горизонтальные (общие для всех прикладных областей) и вертикальные (для конкретной прикладной области). Например, разработаны Common Facilities для медицинских организаций, для ряда производств и т.п.
Основное содержание SOAP (Simple Object Access Protocol) состоит в обмене сообщениями между удаленными объектами по протоколу HTTP с использованием XML в качестве транспорта. Спецификация SOAP поддерживается и развивается консорциумом W3C (см. http : //www .w3.org/TR/SOAP/).
По функциональным возможностям технология SOAP весьма сходна с первыми версиями CORBA.Однако у нее есть одно несомненное достоинство: простота. На уровне передачи данных в глобальных сетях, между предприятиями, где большой сложности взаимодействие не предвидится - это оптимальное решение по соотношению время разработки/функциональность. Существуют многочисленные мосты (CORBA/SOAP, C++/SOAP, Java/SOAP).
COM (Component Object Model) - это стандарт Microsoft,определяющий структуру и взаимодействие компонентов программного обеспечения в современных операционных системах MS Windows.Архитектура современных Windows -приложений основана на COM:мир этих приложений - это мир COM -компонент. Компоненты COM обладают уникальностью и предоставляют другим компонентам COM стандартным образом описанные интерфейсы, позволяющие получить доступ к методам этих компонентов. COM определяет механизм связи только между локальными (т.е. находящимися на том же компьютере) компонентами.
DCOM (Distributed Component Object Model) - это распределенная версия COM, обеспечивающая механизм связи между удаленным COM -компонентами (т.е. находящимися на разных компьютерах, но в среде MS Windows).Фактически DCOM это COM с добавленным к последнему механизмом RPC (remote procedure call).Сходную функциональность взаимодействия удаленных Windows -приложений можно получить с использованием активно развиваемой в последнее время фирмой Microsoft технологии .NET.Важно подчеркнуть, что упомянутые в данном разделе технологии относятся исключительно к операционным системам Microsoft.
Архитектура EJB - это компонентная архитектура, предназначенная для разработки и развертывания распределенных бизнес-приложений, основанных на компонентах. Приложения, созданные с помощью архитектуры EJB,являются масштабируемыми, ориентированными на транзакции и безопасными при работе в многопользовательском режиме. Эти приложения, однажды написанные, могут затем быть развернуты на любой серверной платформе, поддерживающей спецификацию EJB.Это определение можно немного упростить при помощи описанных ранее понятий. Enterprise Java Beans - это стандартная модель серверных компонентов для мониторов компонентных транзакций. Enterprise Bean -компоненты являются Java (J2EE) объектами, реализующими технологию Enterprise Java Beans (EJB).Каждый такой компонент выполняется под управлением сервера приложений, который должен соответствовать так называемой спецификации EJB- контейнера, т.е. поддерживать соответствующий API - EJB Container API (обычно сервер приложений в таком случае называют EJB -контейнером). EJB -контейнер предоставляет компонентам (Enterprise Beans) сервисы системного уровня (например, многопоточность, механизм транзакций), оставаясь при этом прозрачным для разработчика приложений. Эти системные сервисы позволяют разработчику быстро создавать и разворачивать Enterprise Bean -компоненты: контейнер как бы "закрывает" от разработчика EJB все сложности системного характера (например, уже упомянутые многопоточность или механизм транзакций), позволяя ему сосредоточиться исключительно на бизнес-логике приложения. Enterprise Bean -компонент - это объект требуемого класса, описанного на языке программирования Java,расположенный на стороне сервера приложений и выполняющий часть бизнес-логики приложения (этим занимается собственно код компонента, осуществляющий задачи приложения). Например, в приложении контроля инвентаря, Enterprise Bean -компоненты могут реализовывать бизнес-логику приложения в методах checkInventoryLevel() и orderProduct(). Вызывая эти методы, удаленные клиенты могут получать доступ к инвентарным сервисам приложения.
Существует несколько причин, по которым использование Enterprise Bean -компонентов упрощает разработку больших распределенных корпоративных приложений.
Следует задуматься об использовании Enterprise Bean -компонент, если ваше приложение отвечает хотя бы каким-то требованиям из перечисленных ниже.
На сегодняшний день корпорацией Sun Microsystems было выпущено пять спецификации EJB - EJB 1.0, EJB 1.1, EJB 2.0, EJB 2.1 и EJB 3.0. В спецификации EJB 1.0 были впервые описаны сеансовые (session bean) и объектные (entity bean) компоненты. Спецификация EJB 1.1 расширяет спецификацию EJB 1.0.В EJB 2.0 были добавлены компоненты, управляемые асинхронными сообщениями JMS (Java Messaging Service),а также EJB Query Language (EQL) - язык запросов. В EJB 2.1 был модифицирован и улучшен EQL, добавлена возможность вызова объектных компонент через HTTP/SOAP.Также компоненты, управляемые сообщениями, смогли принимать сообщения не только по протоколу JMS,но и по другим протоколам. Последняя на данный момент версия EJB - EJB 3.0.В ней модифицированы механизмы описания компонент (вместо XML -файла - метаданные), а сам процесс разработки переведен на JAVA 5.0.
Jini представляет собой технологию создания распределенных систем, ориентированную исключительно на использование Java.В настоящий момент Jini является торговой маркой Sun Microsystems.
Технология Jini состоит из трех основных компонентов:
В отличие от EJB,технология JINI не требует наличия специальных серверов приложений. Кроме того, если модель использования EJB принципиально двух- или трехзвенна (существует клиент, запрашивающий методы EJB,работающий под управлением контейнера, и, как правило, сервер, например, СУБД, к которому обращается в процессе работы EJB,причем иерархия запросов в этой схеме строго задана), то в модели JINI все сервисы абсолютно равноправны между собой (каждый из них может быть как сервером, так и клиентом к любому). Такая "равноправная" архитектура взаимосвязей называется одноранговой (peer-to-peer).В модели JINI сервисы представляют, таким образом, своего рода "интеллектуальные устройства" (можно представить себе в качестве примера сервис печати), общающиеся между собой по стандартизованным правилам, имеющие стандартизованные имена, общую модель безопасности и т.п. Такой универсум сервисов-"интеллектуальных устройств" JINI принято называть JINI Federation."Интеллектуальные устройства" могут сами добавлять себя в этот универсум (например, сервис печати при включении принтера) или, наоборот, выходить из него (сервис печати при выключении принтера), без необходимости какого-либо "внешнего" воздействия (диспетчера, оператора и т.п.)
Поиск сервиса, который может выполнить определенную задачу, происходит приблизительно по такому сценарию.
Технология Jini разрабатывалась с целью создания системы, которая бы требовала к себе мало внимания при обслуживании, успевала за постоянным изменением и наращиванием системы и обеспечивала постоянную доступность сервисов посредством Интернета. Безопасность системы и конфиденциальность информации передаваемой в сети достигается за счет распределенной системы безопасности. Наращиваемость систем возможна за счет добавления новых, наследования и изменения старых сервисов, доступных посредством интернет. Постоянная доступность становится возможной за счет рассредоточенности системы, в которой можно изменять приложения беспрерывно, так, что сервис будет доступен из Интернета постоянно.