DB2. Решения по интеграции


Введение


 

Серверы приложений существуют уже десятилетия. Они существуют как слой промежуточного программного обеспечения над операционной системой, предоставляя общие службы: коммуникации, безопасность, доступ к данным и поддержку транзакций. Эти службы освободили разработчика приложении от беспокойства по поводу выполняемых функций бизнеса и инфраструктуры вне приложений. Сопровождаемые развитым программным интерфейсом приложений (API – application programming interface), эти серверы приложений стали краеугольным камнем обработки деловой информации для многих предприятий. Десятилетия на мэйнфреймах IBM работают привычные прикладные программы для деловой сферы. Это тяжеловесы: абонентская информационно управляющая система (Customer Information Control System – CICS) и информационно-управляющая система (Information Management System – IMS).

Появление Web вызвало интеграцию этих традиционных или унаследованных серверов приложений с его вездесущим каналом передачи информации, Web-серверы начинались как простые файловые серверы, обеспечивая страницы содержания, написанные на языке разметки документов HTML (Hypertext Markup Language). Когда этого стало недостаточно для растущих аппетитов Internet, был создан набор интерфейсов прикладного программирования (API – Appli cation Programming Interface) для Web-программирования, чтобы разрабатывать Web-приложения. Что наиболее примечательно – общий шлюзовой интерфейс (CGI – Common Gateway Interface) принес первые Web-приложения. Он обеспечивал простой интерфейс обращения для обработки Web-форм пользователя и возврат Web-страниц пользователю. Эволюция расширила эту возможность на другие языки программирования (С, C++, Java и т.п.) через различные продукты Web-сервера (Netscape, Microsoft, Apache, IBM и т.п.).

Прошло немного времени, и эти новые Web-приложения стали нуждаться в средствах связи с традиционными прикладными программами для деловой сферы. Типичный подход реализован унаследованным клиентом модуля доступа для приложения на Web-сервере, который регистрируется в существующей системе и пересылает запросы этой прикладной части приложения. CGI запрашивает, где будет обслужен, последовательным инициированием удаленных интерфейсов унаследованных серверных приложений (либо через удаленные API, либо через считывание с экрана терминальных выходных устройств). Простые интерфейсы большинства ранних Web-серверов удовлетворяли требования первого поколения Web-приложений. Тем не менее необходимость в улучшении масштабируемости, в интегрированной безопасности, в управлении сеансом клиента и поддержки транзакций отражала те же требования к Web-ярусу, которые десятилетия назад привели к созданию унаследованных серверов приложений. Превзойти все это было необходимо производителям для достижения многоплатформенности. Приложения, написанные для Netscape, не могли переноситься на приложения IBM или Microsoft. Кроме интерфейса CGI, который имел серьезные проблемы с производительностью, не было стандарта на программный интерфейс Web-яруса. Ответом стала Java.

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

 




- Начало -  - Назад -  - Вперед -