 | Уровень сложности: простой Боб Балабан, консультант,
IBM
01.02.2007 Загляните внутрь IBM Workplace Collaboration Services и узнайте о слоях, из которых состоят службы совместной работы Workplace Collaboration Services, в том числе IBM WebSphere Application Server и IBM WebSphere Portal.
Пользователям IBM Lotus Notes и Domino (особенно тем, кто использует эти программы не только для работы с электронной почтой) очень хорошо известны богатство функций и эффективность этой платформы для создания любых видов приложений для совместной работы. Многие приверженцы Notes/Domino, тем не менее, не уверены, что они могут получить выигрыш от объединения эффективности своих приложений на базе Domino с инфраструктурой J2EE (Java 2, Enterprise Edition) и продуктами от IBM. Некоторые люди все еще не особенно осведомлены о том, какие различия существуют между тремя основными продуктами J2EE: IBM WebSphere Application Server, IBM WebSphere Portal и IBM Workplace Collaboration Services. (Существует много программных предложений IBM, которые объединяет понятие Workplace (рабочее место); в этой статье речь пойдет о Workplace Collaboration Services и архитектуре, на базе которой создана программа).
Цель статьи - объяснить, из каких слоев состоят следующие три продукта J2EE, один за другим (Workplace Collaboration Services - WebSphere Portal - WebSphere Application Server), чтобы сформировать четкое целостное представление. Мы также расскажем вкратце, как можно интегрировать Lotus Domino в каждый из этих слоев, и какие разные проблемы вы можете решить при помощи каждого вида интеграции.
Более того, хотя большинство людей думают об интеграции на стороне сервера, когда говорят о Lotus Domino и J2EE, мы надеемся объяснить, какие изменения произойдут с клиентом Notes через год или два, когда он также станет полнофункциональным клиентом J2EЕ.
Техническая база: J2EE и WebSphere Application Server
Давайте начнем с вопроса, который стесняются задавать многие люди: что такое J2EE? Это собственная спецификация Sun Microsystems для платформ или инфраструктур на базе Java, на которых пользователи выполняют приложения, использующие интернет. J2EE - это не продукт (хотя многие разработчики, например, IBM, создали продукты, которые соответствуют требованиям этой спецификации). Определенно это не религия, а инструмент, который иногда может пригодиться.
Полностью идея J2EE заключается в предоставлении разработчикам нейтрального (а, следовательно, системо-независимого) способа размещения Web-приложений. Этот способ предлагает метамодель приложения (то есть, набор компонентов и инструментов, которые используются для создания приложений) и платформу, состоящую из набора сервисов, которые помогают запускать приложение, представленное в форме комплекта API Java.
Платформа построена таким образом, чтобы обеспечить приложениям, которые на ней выполняются, производительность и масштабируемость. Производительность - это очевидное понятие: любой человек хочет, чтобы приложение , которое работает на базе J2EE, обладало хорошей производительностью. Масштабируемость более сложное понятие, но, в общем, оно означает, что у вас есть способы увеличения загрузки системы (например, добавить еще пользователей или увеличить поток трафика) без заметного снижения производительности или времени отклика. Как это достигается в J2EE, и в частности, в WebSphere Application Server? Рассмотрим рисунок 1, на котором представлена принципиальная схема архитектуры базового сервера приложений J2EE.
Рисунок 1. Схема базовой архитектуры J2EE с указанием важных компонентов
На первый взгляд схема выглядит несколько перегруженной, но основные компоненты обведены эллипсами разных цветов, чтобы показать, каким образом большая картинка может быть разбита на более легко объяснимые фрагменты.
Зеленый эллипс слева, включающий в себя прямоугольники с надписями "Контейнер апплетов" и "Контейнер клиентского приложения" представляет клиентскую сторону системы. Эти два прямоугольника соединяются с прямоугольником "Web-контейнер" через стрелки HTTP и SSL, показывающие, что клиенты Java (автономные Java-приложения или апплеты, использующие браузер) используют для взаимодействия с платформами J2EE протокол HTTP. За трансляцию URL конкретных приложений в "адреса" компонентов приложений и правильную маршрутизацию команд отвечает платформа.
Реальные бизнес-компоненты, которые пишут разработчики, обведены оранжевым эллипсом. К страницам JavaServer Pages (JSP) и сервлетам можно обращаться непосредственно по URL. Они обычно обрабатывают входные данные разных типов, иногда запрашивая данные у некоторых серверных систем, а затем интерпретируют результат для клиента, который делал запрос, чаще всего в форматах HTML или XML. Страницы JSP и сервлеты выполняются в среде Web-контейнера, а набор этих контейнеров - вместе с ресурсами изображений, прочими Java-классами (bean-компонентами JavaBeans) и, иногда, параметрами конфигурации - формируют то, что мы называем Web-приложением.
Корпоративные bean-компоненты JavaBeans (EJB) - это еще один тип бизнес-компонентов J2EE, программируемый разработчиками, который несколько отличается от прочих. Эти компоненты не выполняются в Web-контейнере, а требуют размещения в контейнере EJB. Мы не будем рассматривать огромное число отличий между ними и их аналогами в Web-приложении, достаточно сказать, что bean-компоненты EJB ориентированы на управление транзакциями базы данных, чтение из реляционных баз данных и запись в них. Приложение, в котором Web-компоненты (JSP и сервлеты) объединены с bean-компонентами EJB называются корпоративными приложениями. Хотя, конечно, допускается, что приложение может состоять только из страниц JSP и сервлетов, но для вызова корпоративных bean-компонентов EJB требуются как страницы JSP, так и сервлеты. В отличие от стрелок, которые соединяют Web-клиенты с Web-контейнерами, стрелки, соединяющие Web-контейнеры с контейнерами EJB не представляют протокол HTTP. Вместо него используется более сложный, ориентированный на сессии транспортный протокол, который называется IIOP (да, это именно тот транспортный протокол IIOP, который используют классы Domino CORBA).
И, наконец, синий эллипс охватывает общий слой сервисов API, который поддерживает все основные продукты серверных приложений J2EE. Каждый прямоугольник в этом слое представляет стандартизованный API Java; в числе этих API следующие элементы (безусловно, список далеко не исчерпывающий):
- JNDI (Java Naming and Directory Interface, интерфейс имен и каталогов Java) используется для поиска в сети серверов, каталогов и других общих компонентов и взаимодействия с ними;
- JDBC (Java Database Connectivity, средство организации доступа Java-приложений к базам данных) - это Java-версия более известного интерфейса ODBC. Интерфейс JDBC используется для передачи запросов и чтения результатов из реляционных баз данных;
- JMS (Java Messaging Service, сервис обмена сообщениями Java) - это еще один вариант API, который используется для реализации надежных очередей сообщений между компонентами или процессами. Например, MQ от IBM имеет для этого интерфейс JMS.
Может быть, вы заметили, что слой сервисов в Web-контейнере идентичен такому же слою в контейнере EJB. Это не случайно: оба набора компонентов для того, чтобы выполнять свою работу, могут использовать идентичные сервисы.
Чтобы создать бизнес-приложение, вы, соответственно, пишете страницы JSP, сервлеты и/или EJB (или приобретаете любой набор инструментов, например, IBM's Rational Application Developer, который поможет сгенерировать эти компоненты). Затем вы размещаете ваши компоненты в пакете на сервере приложений. Отсюда приложение для выполнения работы отвечает на вызов URL (страниц JSP и/или сервелетов) или на запросы IIOP (EJB).
Платформа WebSphere Application Server позволяет приложениям эффективно работать (хотя, безусловно, часть бремени по написанию эффективного кода ложится на разработчиков), предоставляя множество сервисов для приложений (установление соединений с базой данных, службы каталогов, очереди сообщений и так далее). Это освобождает разработчиков приложений от необходимости самостоятельно писать код для этих сервисов и делает компоненты приложения более переносимыми на другие реализации J2EE, поскольку все сервисы стандартизованы.
Кроме того WebSphere Application Server построен так, чтобы приложение могло быть масштабируемым. Что это означает на практике? Если наше приложение (плюс платформа, на которой оно выполняется) чувствительно к внешней нагрузке (то есть, к большему количеству пользователей), мы можем "развязать" узкие места ЦПУ, разместив фрагменты приложения на нескольких компьютерах, не переписывая код ни одного из компонентов. Это, наверное, самая большая ценность архитектуры, подобной J2EE; например, вы можете поместить страницы JSP и сервлеты на один компьютер, а компоненты EJB - на другой. Все соединения управляются сервером WebSphere Application Server; код ваших приложений вообще не изменяется. Таким образом, тонкая настройка масштабируемости (опять же, при условии правильно написанного приложения) становится задачей администратора, а не задачей разработчика, как это было раньше. Конечно, использование для одного приложения слишком большого числа компьютеров перегрузит сеть, поэтому следует быть осторожным; не существует единого ответа на этот вопрос.
Этот краткий анализ того, что представляет собой IBM WebSphere Application Server, и как он обеспечивает приложениям преимущество в отношении производительности и масштабируемости, важен потому, что WebSphere Application Server является базовым слоем IBM WebSphere Portal и IBM Workplace Collaboration Services, как мы скоро убедимся.
Что это означает для Lotus Domino? Это сложный вопрос, и мы написали (или участвовали в написании) многих статей по различным аспектам этой темы. Краткий (и не совсем адекватный) общий ответ заключается в том, что правильное сочетание богатой функциональности приложения для совместной работы Lotus Domino со скоростью и масштабируемостью WebSphere Application Server может стать огромной победой. Программа Lotus Domino, при всей своей эффективности и богатстве технологического процесса, программируемости, интеграции данных и быстрой разработке приложений, иногда (по разным причинам) просто не способна справиться с предельной загрузкой приложений. В частности, Web-агенты уязвимы для очень высоких уровней активности, потому что каждый вызов URL вызывает загрузку агента из NSF в интерпретатор конечного языка (LotusScript, Java, @function и так далее). Напротив, серверные страницы JSP и сервлеты в WebSphere Application Server загружаются однократно, а затем код остается резидентно в виртуальной машине Java Web-контейнера. Параллельные запросы просто вызываются в отдельных потоках Java.
Смысл в том, что если у вас есть ситуация, в которой Web-приложение Domino (которое, скорее всего, в своей бизнес-логике использует, главным образом, агенты Web Query Open и Web Query Save) не работает под нагрузкой должным образом, возможно, вы получите преимущество, написав некоторые агенты Web Query Open/Save в виде сервлетов, выполняющихся на WebSphere Application Server. Безусловно, сделав это, вы не потеряете важную функциональность Domino; можно просто продолжить использовать Java-классы этой среды.
Подведем итог: интегрировать Web-приложения Domino с WebSphere Application Server имеет смысл, если у вас есть проблемы с производительностью. Когда мы перейдем к WebSphere Portal и Workplace Collaboration Services, вы увидите, что интеграция Lotus Domino с этими продуктами решает совершенно другие проблемы.
Слой WebSphere Portal: агрегируйте интерфейсы пользователей и независимость устройств
В то время, как WebSphere Application Server описывает производительность и масштабируемость, WebSphere Portal, напротив, описывает механизм работы пользователя (то, что мы обычно называем пользовательским интерфейсом). Основные дополнительные функции WebSphere Portal заключаются в том, что эта программа:
- Отображает много пользовательских интерфейсов приложений в одном окне браузера. Это называется агрегацией интерфейсов пользователя;
- Допускает персонализацию, благодаря чему каждый пользователь может настроить макет окна: сколько места на экране будет занимать каждое приложение и где оно будет размещаться;
- Предоставляет средство регистрации, поэтому каждый (после настройки) пользователь однократно регистрируется в системе портала, а портал вычисляет, как войти в систему каждого отдельного серверного приложения;
- Предоставляет большую степень независимости клиентских устройств. Любое данное приложение можно разместить как для клиента персонального компьютера / браузера, так и для портативных устройств, например, Palm Pilot, причем не нужно специально интерпретировать код самого приложения;
- Позволяет приложениям, совместно размещенным на портале, видеть друг друга и обмениваться данными (в несколько ограниченных пределах по соображениям безопасности). Этот принцип часто называют "on-the-glass integration" (прозрачная интеграция).
IBM WebSphere Portal по существу является приложением WebSphere Application Server. Оно представляет собой коллекцию серверных страниц JSP, сервлетов и bean-компонентов EJB, которые размещены на WebSphere Application Server в вашей конфигурации (другие продукты Portal работают так же, как соответствующие платформы сервера приложений). Код портала позволяет разработчикам реализовать (или разместить что-либо из резервных разработок) отдельный портлет для каждого типа приложения серверной части. По сути, портлеты - это специализированные сервлеты, их задача заключается в обращении к конкретному приложению серверной части (базе данных Domino, Web-сайту, Domino Web Mail, в общем, к любому приложению) и предоставить интерпретацию окна этого приложения на портале WebSphere Portal. Затем портал агрегирует все эти отображения в многопанельном окне, которое и видят пользователи. На рисунке 2 показан пример окна Portal в браузере с несколькими примерами портлетов.
Рисунок 2. Снимок экрана простого портала, показывающий несколько приложений, агрегированных в одном окне
Где можно достать портлеты? Многие доступны бесплатно (но есть и платные) на сайте IBM Workplace Soluations catalog. Если здесь не найдется того, что вам нужно, следующим шагом может стать использование одного из инструментов создания портлетов, доступных как у IBM, так и у других разработчиков. Эти инструменты предоставляют интерфейс, не требующий программирования, который позволяет описать, какие действия должен выполнять портлет, после чего инструмент сгенерирует для вас программный код.
Если это все еще не отвечает вашим потребностям, можно использовать IBM Rational Application Developer, среду разработки от IBM на базе Eclipse и написать портлет самостоятельно. Rational Application Developer поставляется со средой тестирования портала и множеством встроенных инструментов и мастеров, которые помогут облегчить задачу создания портлетов.
У модели портлета есть приятная особенность, которая заключается в том, что каждое приложение все же может претендовать на собственное постоянное место на экране. Задача портлета заключается в том, чтобы предоставлять подключение к серверной части приложения и обеспечивать интерпретацию (обычно HTML или XML) этого приложения на портале WebSphere Portal, который затем вычисляет, в какой области окна разместить приложение.
На рисунке 3 показана расширенная схема J2EE с рисунка 1 (там слой портала находится сверху, а здесь сбоку) с одним примером портлета, Domino Web Access, который обращается к серверу Domino, чтобы обеспечить интерпретацию электронного сообщения пользователя. Схема WebSphere Application Server / J2EE была сокращена и ориентирована так, чтобы слой портала находился между сервером и клиентским ноутбуком.
Рисунок 3. Схема обращения WebSphere Portal к нескольким серверным частям приложений через портлеты
И снова, что это означает для Lotus Domino? WebSphere Portal поставляется с несколькими готовыми портлетами для установки Domino NSF в интерфейс портала. Кроме того, можно использовать IBM Portlet Builder for Domino для создания и размещения своих упаковщиков для приложений Domino (или купить один из нескольких конструкторов портлетов от сторонних разработчиков).
Интеграция Lotus Domino с WebSphere Application Server может решить проблемы производительности и масштабируемости, тогда как интеграция приложений Domino и WebSphere Portal касается только интерфейса пользователя. Такая интеграция выполняется для того, чтобы перенести приложения Domino в среду портала и получить преимущество агрегации интерфейсов пользователя и независимости устройств.
Это важное разграничение, потому что если вы будете делать что-либо необдуманно, то получите только проблемы. Не стоит интегрировать приложения Domino с WebSphere Portal, чтобы решить проблемы производительности, точно так же не стоит интегрировать приложения Domino с WebSphere Application Server, чтобы получить интерфейс портала.
Слой Workplace: упакованные приложения и полнофункциональный клиент
Как перейти от портала к службам совместной работы IBM Workplace Collaboration Services? Ответ - используйте слои â. Проще всего объяснить это тем, что Workplace Collaboration Services (и смежные продукты Workplace, например, Workplace Services Express) представляют собой набор приложений, реализованных поверх WebSphere Portal. Во многих смыслах Workplace Collaboration Services - это приложение портала. Однако, если WebSphere Portal ориентирован на браузер и мобильные клиенты, Workplace Collaboration Services включает также полнофункциональный клиент, устанавливаемый (или предоставляемый) серверной частью продукта на рабочий стол пользователя. Полнофункциональный клиент, который называется Workplace Managed Client, также играет важную роль в объединении со следующей основной версией IBM Lotus Notes, рабочее имя Hannover, как мы увидим ниже.
Основные приложения пакета, которые Workplace Collaboration Services поставляет поверх инфраструктуры портала Portal (этот список не следует считать полным), предоставляют следующие функции:
- Обозреватель активности Activity Explorer;
- Управление документами на рабочем месте Workplace Document Management;
- Управление Web-содержимым на рабочем месте Workplace Web Content Management;
- Службы мгновенных сообщений и Web-конференций (в основном, как повторное размещение Lotus Sametime в инфраструктуре Workplace);
- Командные области Team Spaces;
- Электронная почта (речь не идет о полной замене или дополнении почтовой программы Workplace Messaging программой Notes mail; последний продукт предназначен для другой аудитории. Кроме того, любые портлеты, которые могут выполняться на WebSphere Portal, также будут работать в среде Workplace Collaboration Services.).
И Workplace Collaboration Services, и Workplace Services Express реализованы как приложения WebSphere Portal, поэтому вы можете интегрировать Lotus Domino прозрачно с обеими программами точно так же, как сделали бы это с программой WebSphere Portal; то есть, создав, купив или получив готовые портлеты для упаковки ваших существующих приложений Domino (как в примере на рисунке 3 вверху).
Workplace Managed Client
Существенное различие между этими двумя продуктами Workplace заключается в том, что Workplace Services Express предназначен для браузера (и мобильных устройств), тогда как Workplace Collaboration Services также предоставляет опцию размещения управляемого клиента IBM Workplace Managed Client. Пользователи Lotus Notes уже знают о том, что такое полнофункциональные клиенты и какие преимущества они предоставляют. До сих пор Workplace Collaboration Services и Workplace Managed Client поставляются по отдельности, следовательно, платоформа J2EE не имеет полнофункционального клиента, на котором можно размещать приложения.
Workplace Managed Client совершенно непохож на Lotus Notes во многих смыслах, например:
- Workplace Managed Client построен на базе инфраструктуры с открытым исходным кодом Eclipse. Eclipse изначально была средой разработки, но ей нашли новое применение в качестве клиентской инфраструктуры. Подключаемые функции в Eclipse реализованы в виде одного или нескольких подключаемых модулей, Java-программ, которые занимают место на экране и предоставляют интерфейс пользователя для выполнения различных действий. (Очень похоже на портал, не правда ли?);
- Workplace Managed Client - это управляемый клиент, в котором приложения и функции, которые видит каждый пользователь в клиентском пользовательском интерфейсе, контролируются (или предоставляются) сервером. Администратор Workplace решает, какие пакеты, приложения или обновления получат конкретные пользователи или группы в своей копии Workplace Managed Client. Если пользователи войдут в систему сервера Workplace со своего Workplace Managed Client, то новый код может быть загружен автоматически. Эта функция предоставления очень упрощает размещение кода на стороне клиента;
- Как подчеркивалось ранее, работа пользователя в среде Workplace Managed Client очень похожа на работу пользователя в среде WebSphere Portal, за тем исключением, что это не просто браузер. Интерфейс пользователя Workplace Managed Client UI, конечно, имеет встроенный браузер, но он также содержит наборы редакторов производительности или инструментов, включая текстовый редактор, электронную таблицу и редактор презентаций / слайд-шоу. Эти редакторы предоставляют большинство функций по обработке текста и электронных таблиц, которые нужны большинству людей в повседневной работе. Они понимают файлы Microsoft Office, но вместо того, чтобы сохранять данные в соответствующем формате, редакторы Workplace используют формат XML.
Архитектура подключаемых модулей Eclipse / Workplace Managed Client очень эффективна. По сути, один из подключаемых модулей, которые можно использовать с Workplace Managed Client - это Lotus Notes 7 (можно установить Lotus Notes 7 на ваш компьютер независимо, но если он есть в системе, то Workplace Managed Client распознает программу и предоставит вам возможность запускать Lotus Notes в окне Workplace Managed Client).
Таким образом, Workplace Managed Client превращается в нечто большее, чем просто окно браузера с группой приложений. Он закладывает фундамент для подлинно композитных приложений, переводя "прозрачную" интеграцию на новый уровень. Workplace Managed Client является программируемым клиентом -- вы можете писать собственные подключаемые модули Eclipse и использовать API Workplace Managed Client, распространяемые IBM, чтобы предоставить возможность компонентам на стороне клиента (независимо от того, являются ли они традиционными портлетами, приложениями на основе Notes или написанными пользователями подключаемыми модулями) взаимодействовать друг с другом и совместно использовать данные (безусловно, при соответствующем уровне безопасности).
Тип функциональности на стороне клиента включает Lotus Notes (с полной поддержкой репликации и использования в автономном режиме) и идет дальше. Интерфейс пользователя Eclipse является таким настраиваемым и расширяемым, каким никогда не был интерфейс Lotus Notes. Вам хотелось бы иметь настраиваемый пользовательский интерфейс в виде календаря? Нет проблем, напишите свой подключаемый модуль инструмента просмотра и поместите его в модель событий Workplace Managed Client. Хотите, чтобы при отправке пользователями электронной почты происходило что-нибудь особенное? Пожалуйста; вам нужно только написать обработчик событий. (Конечно, для этого необходимо быть программистом Java).
Как это может отразиться на будущем традиционного клиента Notes? Сойдет ли он со сцены? Ни в коем случае. Заменит ли IBM Workplace Lotus Domino? Конечно нет. Фактически, эти две платформы развиваются и объединяются по важным направлениям, ничего не выбрасывая из функций Notes/Domino, которые мы знаем и любим.
Эволюция полнофункциональных клиентов Notes и Workplace: слияние равноценных продуктов
Сегодня клиент Notes и клиент Workplace Managed Client выглядят как две очень разные сущности. Эта ситуация естественным образом приводит к разного рода предположениям о том, какой из них победит и будут ли вынуждены пользователи переносить приложения с одной платформы на другую.
Хорошая новость - это временное положение вещей. На самом деле, в следующей основной версии традиционного клиента Notes произойдет слияние двух клиентских платформ (Lotus Notes и Workplace Managed Client); рабочее название версии Hannover, по имени города в Германии, где было впервые объявлено о выпуске продукта. Hannover по-настоящему инновационный продукт: он все еще в основе своей является Lotus Notes, но весь интерфейс пользователя переносится на открытую инфраструктуру Eclipse, что делает компоненты Notes игроками высшей лиги в области композитных клиентских приложений. Более того, компоненты Notes будут предоставляться и с сервера Domino, и с сервера Workplace.
На самом деле это означает, что покупатели, обновляя версию программы до Hannover, получат и функцию полнофункционального клиента Workplace – в том числе, интерфейс портала, управление сервером / предоставление с сервера, расширяемый пользовательский интерфейс – и в то же время, это будет именно Lotus Notes. Более того, поскольку это все еще настоящий клиент Notes в оболочке Eclipse, то все уже имеющиеся приложения Notes/Domino можно будет запускать без изменения кода в среде Hannover.
Безусловно, традиционные автономные конфигурации Notes и Domino останутся среди предложений IBM. Никого не будут заставлять принимать новый клиент Hannover против воли. Следовательно, преимущества унифицированного полнофункционального клиента огромны, и мы прогнозируем, что большинство клиентов порадует плавность перехода и впечатляющие результаты.
Разные слои, разные преимущества
Тогда зачем нужна программа IBM Workplace? Стоит повторить (только потому, что за последние пару лет вокруг этого было так много неразберихи), что IBM Lotus Notes и Domino не сходят со сцены.
Базовая технология J2EE, воплощенная в IBM WebSphere Application Server предоставляет быструю, масштабируемую платформу, на которой организации могут размещать приложения. Интегрируя Lotus Domino с WebSphere Application Server, можно "развязать" некоторые узкие места производительности, свойственные объемным Web-приложениям Domino, не теряя ни одной из полнофункциональных опций совместной работы, которые предоставляет Lotus Domino.
Слой портала поверх WebSphere Application Server обеспечивает персонализованные рабочие столы, на которых квалифицированные пользователи смогут организовать свои рабочие места по собственному вкусу, централизованно разместив все свои важные приложения, со сквозной интеграцией их данных.
Слой IBM Workplace поверх слоя WebSphere Portal предоставляет вам серии упакованных приложений, возможность поместить существующие приложения Domino в портализованную среду и силу новых предоставляемых административных опций. Более того, службы совместной работы Workplace Collaboration Services теперь обеспечивают пользователей клиентом Workplace Managed Client, который еще больше совершенствует механизмы оперативной работы. Последняя выпущенная версия Workplace Managed Client поддерживает подключаемый модуль для Lotus Notes 7. Следующая крупная версия Lotus Notes будет представлять собой результат слияния традиционного клиента Notes с клиентом Workplace Managed Client, эластичное и эффективное усовершенствование обеих программ. Все это вовсе не означает замену Lotus Notes клиентом Workplace Managed Client, скорее, это слияние равноценных продуктов, которое приведет к взаимному повышению эффективности.
Ресурсы Научиться
Обсудить
Об авторе | | | Боб Балабан (Bob Balaban) работает в качестве ответственного консультанта в группе трансформации бизнеса в отделе Workplace, Portal и группе по программному обеспечению Collaboration IBM. До этого Боб работал над NOI, LotusScript и агентами Lotus Notes сначала как сотрудник Lotus, а в дальнейшем как представитель компании Iris Associates. До Lotus Notes он занимался в Lotus электронными таблицами и другими продуктами и получил патент на функцию Version Manager в 123/W. |
Выскажите мнение об этой странице
| |
