Технология Клиент-Сервер 2007'2
	Home Поиск Издания Контакты k-press.ru

Продолжается подписка на наши издания! Вы не забыли подписаться?

Middleware для организации современного рабочего места

Автор: Александр Цимбал

Опубликовано: 06.12.2002
Версия текста: 1.0

Данная статья является «обзорно-архитектурным» введением в комплекс технологий организации рабочего места сотрудника компании, работа которого подразумевает систематическое обращение к различным источникам информации и взаимодействие с руководством, коллегами и партнерами. Более подробное рассмотрение практических аспектов создания приложений и интеграции с распространенными информационными системами – тема последующих статей.

Часть рассматриваемых технологических решений и их реализаций создавались и развиваются силами сообществ разработчиков, часть – компанией IBM. Поскольку речь идет о решениях, независимых от аппаратных платформ и операционных систем, то основой является комплекс Java-технологий. Кроме того, использование Java – в настоящий момент один из «столпов» процесса разработки информационных систем в IBM.

Постановка задачи

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

Традиционно массовые клиентские приложения относились к одному из двух типов – «тонкие клиенты», когда «входной точкой» пользователя для доступа к данным являлось универсальное приложение, такое, как web-браузер, или к «толстым клиентам», которые подразумевают установку на компьютер клиента специальной программы, ориентированной на работу с определенным классом информации. Каждый из этих подходов имеет свои достоинства и недостатки.

«Тонкие» клиенты:

• Обеспечивают универсальный доступ к информации, представленной в стандартном виде (HTML, XML, медиа-форматы)
• Не требуют сложных настроек при доступе к данным различных видов и поступающих от разных источников
• Обеспечивают простую процедуру доставки приложений, которые должны выполняться на стороне клиента (таких, например, как апплеты Java), с сервера.

Тем не менее, такой подход связан и с серьезными недостатками и ограничениями, самыми важными из которых, пожалуй, являются следующие:

• Очень сложно обеспечить сложный, удобный и эстетичный интерфейс пользователя, особенно при использовании различных мобильных устройств.
• Приложение зависит от наличия сетевого соединения с источником информации.
• Источники информации часто изолированы друг от друга, отсюда практическая необходимость запуска нескольких изолированных сеансов работы, открываемых в различных «окнах».

Такие особенности определяют область применения тонких клиентов – обычно они используются тогда, когда «интерактивная» часть работы не слишком существенна (главное – «чтение» данных), на стороне клиента не требуется реализации части бизнес-логики системы и хранения данных.

Некоторые недостатки такого подхода, например, слабая интеграция информации, полученной из различных источников, компенсируются за счет действий на стороне сервера. Одним из наиболее распространенных решений является создание порталов, которые предоставляют клиентам более или менее интегрированную (с точки зрения ее восприятия) информацию.

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

«Толстым» клиентам присущи следующие достоинства и недостатки:

• Развитый и удобный интерфейс пользователя, что повышает эффективность работы в рамках решаемой задачи.
• Возможность реализации части функциональности системы на стороне клиента.
• Возможность хранения информации на клиенте с последующей «пакетной» передачей на сторону сервера – в случае, если непрерывное сетевое соединений обеспечить невозможно или нецелесообразно.

Недостатки такого решения тоже серьезны:

• Несколько приложений, необходимых для работы, могут требовать наличия на компьютере клиента разнообразных ресурсов – библиотек, драйверов устройств, взаимодействия с БД и т.п.
• Модернизация таких клиентских приложений является очень сложной организационной и ресурсоемкой задачей.
• Необходимо разработать и использовать специальную процедуру установки приложений на клиентские компьютеры.
• Настройка приложений на каждом рабочем месте является отдельной и сложной задачей.

Все это приводит к тому, что «толстые» клиенты обычно используются для организации рабочих мест в составе корпорации.

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

Возникла необходимость в создании комплекса технологий, который смог бы:

• Быстро создавать серверные интегрированные составные приложения, т.е. такие приложения, которые позволяют быстро и эффективно объединять данные разных типов из разных источников.
• Передавать эти данные клиентам на различных аппаратных платформах, использующих различные операционные среды и каналы передачи данных.
• Обеспечить качественный интерфейс пользователя.
• Обеспечить поддержку мобильных клиентов, т.е. клиентов, для которых обычной является ситуация периодического отсутствия сетевых соединений с серверами.
• Обеспечить полноценную защиту данных в соответствии с требованиями, принятыми в той или иной организации.
• Обеспечить централизованную (по «инициативе» сервера) установку и настройку самых различных клиентских приложений.

Другими словами, потребовалось совместить достоинства обоих традиционных подходов и ликвидировать – или, как минимум - уменьшить их недостатки.

Основные принципы

Принципы, которые положены в основу предлагаемого IBM решения, естественным образом следуют из поставленной задачи:

• Решение должно основываться на открытых стандартах, реально воспринятых и одобренных широкими массами архитекторов и программистов.
• Решение не должно быть привязано к конкретным аппаратным платформам, операционным системам и транспортным протоколам.
• Реализации должны нормально функционировать на наиболее распространенных в настоящее время (или ближайшем будущем) устройствах.
• Необходимо наличие организационной «инфраструктуры» поддержки данного решения – достаточное число подготовленных разработчиков, консультантов, преподавателей и пр.
• Решение должно быть открытым – в смысле расширяемым, т.е. разработчики должны иметь возможность создавать собственные приложения, поддерживаемые в рамках предлагаемой архитектуры.
• Решение должно поддерживать динамические совокупности компонентов, т.е. составных частей системы. В общепринятых терминах, связь компонентов, из которых строится интегрированное приложение, должна быть «слабой», так как только такой подход обеспечивает необходимую гибкость.

Всем этим требованиям – по крайней мере, в странах с развитой информационной инфраструктурой – отвечает комплекс технологий, базирующийся на использовании Java. Конечно, было бы прекрасно, если бы удалось отказаться и от привязки к языку программирования, но история с CORBA показывает, что поговорка о том, что «лучшее – враг хорошего», остается в силе.

В настоящий момент, т.е. момент, когда описанная выше задача стала реально актуальной, уже «созрели» концепции и технологии, которые позволяют решить поставленную проблему. Речь, разумеется, идет о Сервис-Ориентированной Архитектуре (SOA) и способе структурирования произвольной информации – XML.

Некоторые задействованные стандарты

Здесь, разумеется, речь не пойдет о таких стандартах, как XML, SOAP или J2EE – в предлагаемом IBM комплексе технологий задействованы (де-юре или де-факто) стандарты «попроще». В первую очередь, имеются в виду следующие стандарты:

• OSGi
• Eclipse Rich Client Platform (Eclipse RCP)

OSGi

Eclipse

Портлеты

Lotus Expeditor

Компоненты Lotus Expeditor

Принципы работы клиента, управляемого сервером

Инфраструктура на стороне сервера

Инфраструктура на стороне клиента

Модель взаимодействия компонентов

Что нужно знать для создания приложений Expeditor

Заключение

Использование Eclipse Rich Client Platform вместе с портальными решениями позволяет быстро создавать качественные визуальные интегрированные клиентские приложения, обладающие достоинствами как толстых, так и тонких клиентов, и при этом свободные от их недостатков. Эти решения могут быть развернуты на различных аппаратных платформах, под управлением различных операционных систем. Кроме того, они основаны на открытых стандартах. Создание приложений в большинстве случаев при наличии современных средств разработки не требует глубоких знаний программирования и доступно широким кругам разработчиков.

Copyright © 1994-2016 ООО "К-Пресс"