Это сервисные программы, системные утилиты, текстовые и графические редакторы, компиляторы, достаточно простые корпоративные программы. Развитая корпоративная информационная система, как правило, не может состоять из отдельных, не связанных между собой компонентов.
В архитектуре "клиент-сервер" программное обеспечение разделено на две части -клиентскую часть и серверную часть. Задача клиентской-части (программы-клиента) состоит во взаимодействии с пользователем, передаче пользовательского запроса серверу, получение запроса от серверной части (программы-сервера) и представление его в удобном для пользователя виде. Программа-сервер же обрабатывает запросы клиента и выдает ответы. Классические примеры: Web-технологии (клиент-браузер, сервер-Web-сервер), работа с распределенными СУБД (клиент - специальная программа, сервер - сервер базы данных). Развитие архитектуры "клиент-сервер", а особенно появление современных графических интерфейсов, привело сначала к появлению разновидности архитектуры клиент-сервер, называемой "архитектура с толстым клиентом". Здесь логика представления данных и бизнес-логика размещаются на клиенте, который (скажем, в случае, когда сервером является СУБД) общается с логикой хранения и накопления данных на сервере, используя язык структурированных запросов SQL. Однако необходимость установки "толстых клиентов", требующих значительного количества специальных библиотек и специальной настройки окружения, на большое число пользовательских компьютеров с различными операционными средами, как правило вызывает массу проблем. Как альтернатива поэтому возникла также двухзвенная архитектура "с тонким клиентом". При этом в идеале программа-клиент реализует лишь графический интерфейс пользователя (GUI) и передает/принимает запросы, а вся бизнес-логика выполняется сервером. В идеале клиентом является просто интернет-браузер, который имеется в стандартной операционной среде любого пользовательского компьютера и не требует специальной настройки, установки специализированного ПО и т.п. К сожалению, такая схема тоже не свободна от недостатков, хотя бы уже потому, что серверу приходится брать на себя иногда не свойственные для него функции реализации бизнес-логики приложения (например, серверу СУБД приходится выполнять расчеты!)
Начало процессу развития корпоративного программного обеспечения в многозвенной архитектуре было положено еще в рамках технологии "клиент/сервер". В них наряду с клиентской частью приложения и сервером баз данных появились серверы приложений (Application Servers). В идеале:
Программа-клиент, таким образом, может быть "тонкой". Преимущества такой архитектуры очевидны:
Следующий логический шаг - дальнейшее увеличение числа звеньев, причем возрастет не только за счет разбиения, когда "утоньшается" каждое из известных технических звеньев, но вся бизнес-модель строится как многозвенная. Современные корпоративные программные системы представляют собой, как правило, сложные системы взаимодействующих между собой на разных уровнях компонентов, каждые из которых могут являться клиентами для одних компонентов и серверами для других.
Основной проблемой систем, основанных на двухзвенной архитектуре "клиент-сервер", или тем более на многозвенной архитектуре, является то, что от них требуется мобильность в как можно более широком классе аппаратно-программных сред. Даже если ограничиться UNIX-ориентированными локальными сетями, в разных сетях применяется разная аппаратура и протоколы связи. Попытки создания систем, поддерживающих все возможные протоколы, приводит к их перегрузке сетевыми деталями в ущерб функциональности. Еще более сложный аспект этой проблемы связан с возможностью использования разных представлений данных в разных узлах неоднородной локальной сети. В разных компьютерах может существовать различная адресация, представление чисел, кодировка символов и т.д. Это особенно существенно для серверов высокого уровня: телекоммуникационных, вычислительных, баз данных.
Общим решением проблемы мобильности такого рода систем является использование технологий, реализующие протоколы удаленного вызова процедур (RPC - Remote Procedure Call) стандартизованным и платформо-независимым способом. При использовании таких технологий обращение к сервису в удаленном узле выглядит как обычный вызов процедуры (методов удаленных объектов). Средства RPC, в которых, естественно, содержится вся информация о специфике аппаратуры локальной сети и сетевых протоколов, переводит вызов в последовательность сетевых взаимодействий. Тем самым, специфика сетевой среды и протоколов скрыта от прикладного программиста.
При вызове удаленной процедуры, программы RPC производят преобразование форматов данных клиента в промежуточные машинно-независимые форматы, и затем преобразование в форматы данных сервера. При передаче ответных параметров производятся обратные преобразования. Таким образом, если система реализована на основе стандартного пакета RPC, она может быть легко перенесена в любую открытую среду.
CORBA определяет, каким образом программные компоненты, распределенные по сети, могут взаимодействовать друг с другом вне зависимости от окружающих их операционных систем и языков реализации. Центральным элементом архитектуры CORBA является ORB (Object Request Broker) - программное обеспечение, обеспечивающее связь между объектами, в том числе позволяющее
Тем самым ORB является связующим звеном между распределенными частями основанной на технологии 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).
Основное содержание SOAP (Simple Object Access Protocol) состоит в обмене сообщениями между удаленными объектами по протоколу HTTP с использованием XML в качестве транспорта. Спецификация SOAP поддерживается и развивается консорциумом W3C.
По функциональным возможностям технология 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) сервисы системного уровня (например, многопоточность, механизм транзакций), оставаясь при этом прозрачным для разработчика приложений.
Jini представляет собой технологию создания распределенных систем, ориентированную исключительно на использование Java. В настоящий момент Jini является торговой маркой Sun Microsystems.
Технология Jini состоит из трех основных компонентов:
В отличие от EJB, технология JINI не требует наличия специальных серверов приложений. Кроме того, если модель использования EJB принципиально двух- или трехзвенна (существует клиент, запрашивающий методы EJB, работающий под управлением контейнера, и, как правило, сервер, например, СУБД, к которому обращается в процессе работы EJB, причем иерархия запросов в этой схеме строго задана), то в модели JINI все сервисы абсолютно равноправны между собой (каждый из них может быть как сервером, так и клиентом к любому). Такая "равноправная" архитектура взаимосвязей называется одноранговой (peer-to-peer).
Web-технологии чрезвычайно сильно используются в современном корпоративном программном обеспечении. Перечислим основные используемые технологии Web-программирования.
CGI-скрипт - это программа, выполняемая на стороне сервера и следующая правилам интерфейса CGI (Common gateway interface). Исторически это первая технология "динамического" программирования для Web. CGI-скрипты могут быть как обычными исполняемыми модулями (написанными на любом языке программирования, например, на C++), так и сценариями ("скриптами"), написанными на интерпретируемых языках (например, на Perl, Unix shell, Tcl).
Последовательность действий при работе с CGI-скриптом следующая:
Из современных Web-технологий это, пожалуй, самая простая, но и самая немаштабируемая, а также немобильная (платформо-зависимая) и не вполне устойчивая технология.
Ряд Web-серверов предусматривают встроенные интерпретаторы специальных языков для динамического Web-программирования. Примерами являются ASP для Web-сервера Internet Information Server (IIS) и PHP (например, для Web-сервера Apache).
ASP (или, соответственно, PHP) страница представляет собой обычный HTML файл, который кроме текста и тэгов HTML содержит еще и конструкции соответствующего языка (ASP или PHP). При запросе этого документа клиентом Web-сервер сначала просматривает документ, интерпретируя директивы соответствующего языка (ASP или PHP) и преобразуя их в обычный статический HTML, который и отдается клиенту. Важно отметить, что как ASP, так и PHP, являются полноценными языками программирования, что позволяет создать с использованием этих технологий сложнейшие Web-системы (вплоть до полномоаштабномго управления производством или, например, торговлей). Эти технологии кроме того, весьма просты, и поэтому популярны, например, для создания электронных магазинов. Недостатком является принципиальная интерпретируемость этих языков, а также существенная привязка к конкретному Web-серверу (например, ASP работает только для IIS).
Апплеты - это программы на Java, работающие под управлением другой программы (как правило, интернет-браузера). Апплеты загружаются с Web сайта вместе со статическим HTML кодом, а затем выполняются браузером на компьютере пользователя (естественно, для этого браузер использует виртуальную Java-машину). Они могут использоваться для создания богатых графикой и интерактивными возможностями пользовательских интерфейсов, которые не способны выразить средствами обычного языка разметки HTML. Важно однако понимать, что апплет - это интеллектуальная программа, а не просто мультипликация (как, например, Flash анимация). Другими словами, апплет способен обрабатывать действия пользователя и динамически менять свое поведение. При работе с программами, полученными из сети, пользователь может столкнуться с неприятными последствиями их работы. Существует множество вирусов, "троянских коней" или просто некачественных программ. Апплет автоматически запускается при загрузке web-страницы, поэтому апплеты требуют повышенного режима безопасности. Для обеспечения защиты, создателями Java был разработан механизм, получивший название "песочницы" (sandbox), ограничивает доступ "ненадежных" апплетов к компьютеру пользователя. Если разработчику апплета понадобилось расширить возможности апплета - ему необходимо поставить цифровую подпись, тогда апплет воспринимается броузером как "надежный", и вы сами решаете, доверять апплету или нет. Хотя цифровая подпись не обеспечивает вашей безопасности, вы можете установить происхождение апплета, при возникновении проблем. "Песочница" включает в себя три основных механизма защиты:
Апплеты могли бы быть почти идеальным со всех точек зрения решением для создателей динамических Web-сайтов и корпоративных Web-систем: они не требуют затрат на установку, соответствуют лозунгу сторонников чистого HTML ("написано однажды -работает везде") и имеют собственный богатый графический пользовательский интерфейс. Апплеты, в общем, используются сравнительно редко. Возможно, потому, что некоторые разработчики неверно оценили накладные расходы при интерпретации байт-кода в виртуальной машине Java. У других множество нареканий вызывает защита, основанная на принципе "песочницы" (sandbox), который не позволяет Java использовать в полной мере локальные и удаленные службы. Третьи отмечают различия между виртуальными машинами основных браузеров, имеющихся на рынке. Так или иначе до сих апплеты не оправдали возложенных на них ожиданий, и Web-приложения на базе HTML не были вытеснены Web-приложениями с равным уровнем переносимости и мобильности, но функционально более мощным графическим пользовательским интерфейсом.
Сервлеты - это программы на Java, которые работают на серверном компьютере. Их выполнение инициируется Web-сервером или сервером приложений (Application Server) по запросу клиента. Последовательность выполнения сервлета следующая.
На самом деле схема, как правило, чуть более сложная. В связке с сервером работает базовый сервлет. Именно ему сервер отправляет данные и от него же получает ответ, отправляемый клиенту. Фактически, базовый сервлет является "мозгом" сервера. Основная функция этого сервлета - прочитать запрос клиента, расшифровать его и, в соответствиии с расшифровкой, передать работу сервлету, отвечающему за конкретный тип запрашиваемой информации. Зачастую, для достижения скорости, роль базового сервлета играет сам сервер. Именно по такой схеме работает, скажем, Web-сервер Jakarta Tomcat. По сути дела, в этой схеме нет ничего принципиально нового по сравнению с CGI-скриптами, кроме, конечно, большей унифицированности и существенно меньшей зависимости от платформ (благодаря использованию Java). Действительно, сервлеты и были разработаны, чтобы заменить CGI-скрипты.
Среда исполнения сервлетов, кроме того, обеспечивает некоторые полезные и экономящие время возможности, включая преобразование HTTP-запросов из сети в удобный для использования HttpServletRequest объект, обеспечивая выходной поток для программиста, чтобы использовать его для ответа, и преобразование удобного в работе объекта HttpServletResponse в HTTP-ответ, который может быть послан обратно по сети. Она также обеспечивает удобные возможности управления сессиями, в том числе хранения состояния сессии, что позволяет, например, назначать ресурсы (такие как подключения к базе данных), которые могут использоваться для многократных запросов.
По сравнению с апплетами сервлеты имеют преимущества с архитектурной точки зрения. Если апплет, посланный по сети, окажется в несовместимой с ним виртуальной машине Java, то он, скорее всего, корректно работать не будет. Сервлет развертывается в более управляемой среде. Так как параметры JVM известны, проблем совместимости не возникает. Более того, среда, которая окружает данную виртуальную машину, может увеличивать производительность сервлета. Некоторые серверы Java-приложений могут компилировать сервлеты в "родной" для себя код и тем самым значительно увеличивать скорость выполнения. Другие серверы запускают параллельно несколько JVM, иногда в различных процессах хостовой ОС. Эти стратегии увеличивают масштабируемость и отказоустойчивость службы.
Вариантом сервлета является JSP-страница (Java Server Pages). JSP-страница, подобно ASP или PHP скрипту представляет собой обычный HTML файл с записанным внутри него при помощи специального синтаксиса исходным Java-кодом сервлета. Каждая JSP-страница автоматически преобразуется в сервлет Web-сервером при запросе на эту страницу со стороны клиента. Затем сервлет выполняется по описанной схеме. Подытоживая, можно сказать, что сервлеты имеют преимущество максимальной переносимости: они могут работать на большем количестве Web-серверов или серверов приложений и на большем количестве платформ, чем любая другая технология динамических Web-приложений, доступная сегодня. Следует также отметить, что API сервлета намного проще в изучении и в использовании, чем технология EJB, поэтому и применяется пока что чаще (хотя EJB также уже стал фактически промышленной технологией).
Вывод: Таким образом, одна и та же задача по разработке программного продукта может быть решена множеством разных способов, и менеджер проекта по разработке программного продукта должен уметь выбирать платформы и технологии, исходя из особенностей задачи и конкретных условий.