Серия программных продуктов Baikonur, созданных российской компанией Ep-sylon Technologies, была названа именем всемирно известного космодрома отнюдь не случайно. Эти продукты предназначены для запуска разнообразных приложений и представляют собой набор комплектов серверного ПО и средств разработки, функционирующих на платформе Windows NT или Windows 95. Но "запуск" - не единственная "космическая" аналогия, что становится явным при более глубоком изучении структуры приложения Baikonur и принципов взаимодействия сервера Baikonur с клиентом.
Серверное приложение состоит из основной и отделяемой "ступеней" кода (например, C++ или Pascal для основной, JavaScript или JAVA - для отделяемой). В процессе взаимодействия "отделяемая часть" получает информацию для формирования текущей диалоговой страницы, которая направляется клиенту с необходимой информацией (пользователь может внести на эту страницу новые данные). Затем "отделяемая ступень" возвращает страницу в свое приложение, способное обработать полученные данные и передать их любой другой программе.
Основные функции продуктов Baikonur в сетевой структуре (локальной или глобальной) в общих чертах таковы. Используя в качестве средств доступа клиента обычный Web-браузер, разработанные на базе технологии Baikonur приложения обеспечивают интерактивный доступ и работу с любой информаций (в том числе - с хранящейся в промышленных базах данных). Однако, в отличие от обычного Web-сервера, предоставляющего пользователям ресурсы "по-требованию", сервер Baikonur не оперирует ресурсами, а работает с информационными потоками и задачами, запуская приложения и управляя ими (поэтому и называется сервером приложений).
При этом каждое приложение может исполняться на собственном сервере (а для SQL-сервера - и под другой ОС, например Solaris, AIX, IRIX, HP/UX) и взаимодействовать с любым числом клиентов (причем, в отличие от классического сервера системы клиент-сервер, стоимость серверного ПО не зависит от числа подключаемых пользователей). Один сервер приложений Baikonur способен обслуживать сразу несколько серверов БД. Такая универсальность обеспечивается местом сервера Baikonur в архитектуре клиент-сервер: он как бы расширяет эту двухзвенную структуру до трехзвенной (рис. 1), образуя промежуточный уровень взаимодействия.
Трехзвенная архитектура сети, использующей сервер Baikonur
Например, в сети предприятия в качестве клиента можно использовать браузер, в качестве сервера базы данных - любой распространенный SQL-сервер (Oracle, Informix, Sybase, Borland IBDATABASE, MS SQL, IBM DB/2 и др.), а в качестве приложений промежуточного уровня - собственно серверные приложения, построенные при помощи визуальных компонентов.
Идея компонентного проектирования таких приложений чрезвычайно проста. Вспомним, как устроены стандартные компоненты, предназначенные для связи с серверами баз данных. Одни компоненты обеспечивают подключение к базе данных, другие при обращении к ним "экстрагируют" запрос на языке SQL для данного сервера БД. В продуктах Baikonur все устроено аналогично: в состав библиотеки разработки входят как компоненты, реализующие соединение с сервером приложений, так и "экстрагирующие" при обращении к ним некий текст - только текст не SQL-запроса, а сценария, написанного на языке HTML, JavaScript или каком-либо другом (для иных, не HTTP-протоколов), или даже текст исполняемого модуля.
Исторически сложилось так, что большую часть компонентов, входящих в состав Baikonur Web App Server и Baikonur Enterprise, составляют HTML-компоненты. При инсталляции байконуровской библиотеки разработчик получает и другие компоненты, предназначенные для связи с сервером приложений, формирования таблиц, вывода графики, работы с файлами, базами данных, JavaScript, Java, ActiveX и т. д.
Благодаря появлению промежуточного звена, способного решать вопросы взаимодействия с сервером самостоятельно, пользователь избавляется от необходимости иметь на своем ПК набор специализированных клиентских программ для доступа к разнообразным серверам; появляется возможность использования на рабочей станции клиента практически любой платформы (DOS, Windows 3.11, Macintosh, UNIX, OS/2, Windows NT). Клиент сервера Baikonur должен иметь на ПК лишь браузер и совместимый с сервером Baikonur интерфейс.
Связь может быть реализована как в локальной сети, по протоколу TCP/IP, так и (через модем) по обычной телефонной или выделенной линии. Если функциональности обычного браузера недостаточно, то технология Baikonur позволяет разработать специализированное ПО клиента. Такой подход можно применять для построения информационных систем (ИС) разного класса, например систем сбора распределенной информации с датчиков, геомониторинговых систем и электроных магазинов, и даже создания игровых программ.
Одна из основополагающих особенностей технологии Baikonur - динамическая смена протоколов, которая дает возможность не только управлять информационными потоками, реализующими пересылку HTML-страниц по Internet, но и работать с другими типами данных (речь, файлы, почтовые сообщения, видеоданные и пр.). Важной составной частью этой технологии являются средства защиты данных и обеспечения безопасности сети предприятия, в том числе ПО мониторинга нештатных ситуаций и сценарии их отработки (например, "взлома" системы). Далее мы остановимся на тех особенностях продуктов серии Baikonur, которые отличают их от программ, выполняющих аналогичные функции.
Отличия Baikonur от аналогичных продуктов
Baikonur и Internet
Ответ сторонникам UNIX. Те, кто подбирают себе программный продукт для организации корпоративного Web-сервера, могут спросить: зачем использовать сервер приложений Baikonur для Windows NT, когда существует масса бесплатных и очень приличных Web-серверов для UNIX? В данном случае ответ очевиден. Если сервер требуется лишь для размещения статических и кем-то подготавливаемых HTML-страничек, то применять сервер Baikonur бессмысленно - он способен работать и в таком качестве, но подобное использование будет равноценно забиванию гвоздей микроскопом. Технологии Baikonur могут понадобиться в крупных Internet-проектах, требующих дополнительных возможностей для разработки сложной логики сервера. Компонентная сборка (принятая за основу технологии) позволяет очень быстро сформировать необходимый механизм сервера из готовых узлов, а получаемая в результате производительность приложений оказывается заметно более высокой, чем при невизуальной реализации аналогичного проекта с применением стандарта CGI.
Ответ сторонникам NT. Для Windows NT тоже существует множество версий Web-серверов, и многие из них, в частности Microsoft Internet Information Server (MS IIS), - подходящий вариант для освоения Internet-технологии. В MS IIS для расширения функциональности сервера предназначены средства ISAPI (интерфейса для расширений сервера) и технология ASP (активных серверных страниц). Все это существенно отличается от применяемого в сервере Baikonur визуального компонентного подхода. На практике, технологии Baikonur позволяют строить более сложные системы с меньшими усилиями, чем в случае применения ASP.
Убедиться в том, что это правда (или неправда!), достаточно легко: пробные версии Baikonur вместе с библиотекой компонентов и документацией можно бесплатно получить на сервере http://www.demo.ru. Кстати, в версии Enter-prise поддерживается ISAPI.
Baikonur и корпоративные системы клиент-сервер
Главный вопрос, который нередко задают сторонники "чистой" архитектуры клиент-сервер: зачем использовать трехзвенную архитектуру типа клиент-промежуточное звено-сервер, если можно обойтись схемой клиент-сервер. Ведь существует масса удачных многопользовательских систем, где клиентским рабочим местом выступает собранное на Delphi или любом другом RAD-инструменте клиент-серверное приложение.
Все верно, однако администрирование таких систем обходится весьма дорого - попробуйте-ка установить приложение клиент-сервер на десятки рабочих станций. Эти системы обречены на "вечную борьбу" - даже при наличии улучшенной версии клиентской программы системный администратор далеко не всегда готов заниматься деинсталляцией старой версии и инсталляцией новой на большом количестве рабочих мест. В случае системы на основе Baikonur на каждой станции раз и навсегда устанавливается браузер, и клиент автоматически запускает на сервере последнюю версию программы.
Архитектура Baikonur заметно снижает общий трафик системы и позволяет избежать перегрузок сети. В то же время нагрузочная способность системы и, следовательно, потенциальное число рабочих мест являются гораздо большими, чем в "чистой" архитектуре клиент-сервер.
Для сервера Baikonur не существует разницы между клиентом локальной сети и удаленным клиентом, поэтому пользователи способны работать по модему точно так же, как и в локальной сети. Если модемное соединение разорвалось, пользователь может восстановить сеанс, дозвонившись заново.
Немалое значение имеет и сумма, которую компания готова выложить за клиентские лицензии. Вспомним, что ограничений на оплату, учитывающих число клиентских подключений, в сервере Baikonur нет.
Остается нерешенным еще один важный вопрос: насколько перспективна архитектура продукта Baikonur? Другими словами, может ли руководитель информационного отдела положиться на технологию Baikonur? Каковы потенциальные возможности развития продуктов серии Baikonur? Насколько быстро они будут развиваться и модернизироваться?
Готовых ответов на эти вопросы нет. Каждая компания сама определяет, что для нее наиболее важно. Можно лишь привести далеко не полный список компаний, выбравших российскую технологию Baikonur для своей корпоративной сети: Центробанк, Онэксим-банк, Уникум-банк, Внешторгбанк, Минобороны РФ, ЦНИИС Минсвязи РФ, Белый дом, Государственная дума, "Ростелеком", "Роспак", "Русская телефонная компания", Аэрофлот, "Лукойл", "Юкос", "Межрегионгаз", "Топливно-заправочная компания", Borland AO.
Продукты серии Baikonur
В серию продуктов под общей маркой Baikonur входят следующие комплекты ПО:
- Baikonur Web App Server 1.1 - простой сервер приложений для Internet и интрасетей предприятий вместе с библиотекой компонентов для визуального проектирования приложений серверного слоя (для Borland Delphi 2.0-3.01 и Borland C++ Builder). Продукт работает под управлением Windows NT 4.0, Windows NT 3.51 и Windows 95. Стоимость по каталогу - 299 дол., число клиентских подключений не ограничено;
- Baikonur Enterprise Web App Server 1.3 - промышленный сервер приложений. В дополнение к функциям версии 1.1 пакет содержит ряд новых компонентов: средства защиты от несанкционированного доступа, поддержку стандартов SSL 2.0, SSL 3.0, SSI, FTP, GOPHER, FINGER, ISAPI, механизм полнотекстовой индексации по русскоязычным текстам Яndex. Стоимость продукта по каталогу - 995 дол.;
- Baikonur SuperServer 1.5 - многопротокольный универсальный сервер приложений. К функциям версии Enterprise 1.3 добавлена поддержка протоколов SMTP, POP3, IMAP4, IIOP, DAAP. В состав продукта включены утилиты файловой репликации, расширяемый универсальный администратор UniAdmin, утилита анализатора входа в систему, компоненты, поддерживающие Java, ActiveX и работу с фреймами, а также BaikAPI - набор процедур и функций для управления сервером из приложений. Продукт допускает возможность балансировки загрузки сервера и может функционировать в качестве сервера-посредника (proxy). Стоимость по каталогу составляет 2450 дол.;
- Baikonur GIS ToolKit и Baikonur GIS ToolKit Pro - наборы компонентов для Delphi 3.0, позволяющие создавать прикладные профессиональные геоинформационные системы. Стоимость продуктов соответственно 299 и 1495 дол., без серверной составляющей.
Сервер и приложения
Рассмотрим основные функции сервера Baikonur.
1. Запуск и освобождение приложений. Сервер приложений способен по запросу пользователей запускать и освобождать (выгружать) приложения на серверной машине - это его главная задача.
2. Коммутация потоков информации между задачами и клиентами. Сервер приложений умеет коммутировать потоки информации от пользователей (клиентов) к задачам и от задач - к клиентам. На рис. 2 показаны всего 4 запущенные задачи и 6 подсоединившихся пользователей, а в паутине информационных потоков уже непросто разобраться. Когда число пользователей достигнет нескольких сотен, паутина переплетений и переключений информационных потоков станет невероятно сложной.
Простая схема коммутации клиент-сервер Baikonur
Задачи, которые запускает сервер приложений Baikonur, могут быть однопользовательскими (каждому клиенту - своя копия задачи) и многопользовательскими (много клиентов обращаются к одной задаче). Это серьезно усложняет проблему коммутации потоков информации между задачами и клиентами. Чтобы подойти к решению этой проблемы, серверу Baikonur приходится осуществлять аутентификацию пользователей.
3. Аутентификация пользователей. Сервер приложений при помощи доступных ему методов и в зависимости от используемого протокола аутентифицирует пользователей системы. Определив подключающегося пользователя, Baikonur запускает однопользовательскую задачу или присоединяет пользователя к многопользовательской. Сервер работает в сеансе связи до тех пор, пока пользователь не отключится от него. Все это время Baikonur коммутирует потоки информации между задачами и пользователями.
4. Поддержка большого числа сетевых протоколов. Источник и приемник информации должны передавать и принимать ее потоки в соответствии со специальными соглашениями - протоколами, определяющими, как устроена информация, для чего предназначена, каковы заголовки в передаваемых пакетах, как определить получателя и что с данными пакетами вообще делать. С точки зрения архитектуры сервера неважно, по каким протоколам осуществляется информационный обмен. А вот для запускаемой на сервере задачи это имеет значение.
Сервер Baikonur обеспечивает одновременную работу с большим количеством разных протоколов. Кроме того, в его архитектуре предусмотрено расширение сервера новыми протоколами. На рис. 3 "разъемы", позволяющие подключать пользователей по различным протоколам, изображены треугольниками. В действительности, для сервера Baikonur эти треугольники - не что иное, как подключаемые dll-библиотеки программ-разборщиков (parser) соответствующих протоколов.
Схема многопротокольной коммутации клиент-сервер Baikonur
Такое необычное устройство сервера может привести к терминологической путанице. В самом деле, если мы подключаем протокол HTTP, то Baikonur превращается в Web-сервер, если протокол FTP, то в ftp-сервер, если же SMTP, POP3 или IMAP4, то Baikonur становится почтовым сервером. А если подключены все сразу - как его называть?
5. Слой шифрования трафика. Эта функция не является обязательной; в младшей версии сервера Baikonur она не реализована. Если клиентские программы способны работать со стандартами шифрования SSL, то весь информационный поток может проходить через процедуру шифрования/дешифрования.
В зависимости от применяемого протокола различаются типы программ-клиентов. Если используется протокол HTTP, то программа-клиент обычно называется браузером (Internet Explorer, Netscape Navigator, AMSD Ariadna, Opera, Lynx, HotDog и т. д.), если почтовый протокол - почтовым клиентом, если же FTP - ftp-клиентом. Возникает естественный вопрос: можно ли написать для Baikonur собственную клиентскую программу? Да, можно. А клиентскую программу, работающую по никому не известному нестандартному протоколу? И это можно.
6. Серверные приложения для сервера Baikonur - это обычные исполняемые программы, связанные управляющими компонентами с сервером. Baikonur умеет запустить на серверной стороне любой исполняемый модуль согласно клиентскому запросу. Возможен даже удаленный запуск на сервере таких программ, как Excel, Word или Delphi. Однако радоваться тут нечему: эти программы не способны самостоятельно общаться с удаленными клиентами через сервер Baikonur, поэтому бессмысленно запускать их на серверной стороне.
Совсем другое дело, когда разработчик заранее предполагает написание приложения для Baikonur. Тогда он использует библиотеки, связывающие серверное приложение с сервером Baikonur. На рис. 4 показаны 4 приложения, которые связаны с сервером через компоненты управления. Аналогия с космодромом в данном случае достаточно убедительна. Приложения получают от сервера управляющие команды и потоки информации от клиентов, передавая в обратном направлении сформированные потоки информации для клиентов (которые сервер пересылает по сети). Каким быть приложению - многопользовательским или нет, - определяет разработчик.
Схема управления приложениями сервера Baikonur
7. Хранение информации о сеансе связи клиента и серверного приложения. Сервер аутентифицирует клиента и хранит информацию о предыдущем сеансе связи с приложением, даже если клиент отсоединился. Соответственно, информация о контексте сессии не теряется. Сервер "помнит" клиентов, которые недавно с ним работали, и при повторном соединении им не приходится запускать приложение заново - работа продолжается с прерванного места.
А что делать, если пользователь, который завершил работу с удаленной задачей, просто выключил компьютер, не выгрузив серверное приложение? Ничего нового тут не придумаешь - используется обычный механизм таймаутов. В случае если пользователь не проявляет себя в течение определенного времени, задача принудительно закрывается (в однопользовательском случае) или освобождается занятая соединением память (в случае многопользовательского приложения).
Архитектура сервера Baikonur
Основной особенностью архитектуры сервера Baikonur (рис. 5) является то, что для него одинаковы все клиенты - и удаленные, и локальные.
Структурная схема взаимодействия основных элементов ядра Baikonur Web App Server: 1 - поиск/построение IP-менеджера, 2 - поиск/построение коммуникационного блока, 3 - разбор запроса IP-менеджером, 4 - поиск/построение блока управления приложением, 5 - связывание блока приема запроса с блоком управления приложением
Каждый запрос, поступающий на порт TCP от клиентского браузера, обрабатывается подзадачей обслуживания коммуникационного порта (listener), которая контролирует канал связи и отслеживает соединения. Запрос анализируется программой-разборщиком запроса (parser), одновременно идентифицирующей клиента. При возникновении события "соединение" listener инициирует программу "IP-менеджер", которая предназначена для обслуживания подзадач сессии клиента. Анализатор проверяет, нужно ли генерировать новую подзадачу сессии или поток данных от клиента следует переключить на существующую задачу. При этом, благодаря однозначной идентификации клиента, потери контекста при переключении задач исключены.
Обработка данных не завершается их передачей задаче. Поток информации обрабатывается внутри каждой задачи ее базовым компонентом (THTML Control) и распределяется между активными визуальными компонентами. Параллельная обработка всех процессов сервера Baikonur обеспечивает независимое исполнение каждой подзадачи.
Работа клиента с сервером поисходит следующим образом. Когда пользователь в сеансе связи подсоединяется к серверу, указывая в качестве URL имя задачи (например, http://www.demo.ru/baikonur /demo/task1.exe), сервер распознает запрос и адресует его задаче task1.exe, собранной разработчиком из компонентов Baikonur и работающей в составе сервера Baikonur. Если задача не была запущена другим пользователем, сервер запускает ее. В противном случае в приложении генерируется событие, связанное с появлением нового пользователя.
После выяснения статусов самого пользователя и вызванного приложения этот пользователь получает доступ к текущему экрану нужного приложения и возможность работы с экранами. Когда данные внесены и переданы серверу, он переадресовывает информацию рабочему модулю приложения. Дальнейшие "действия" приложения определяются логикой, заложенной в него программистом.
Расширения сервера
Все расширения сервера осуществляются при помощи приложений. При столь универсальной архитектуре сервера и столь мощных средствах визуальной компонентной разработки было бы странно, если бы компания Epsylon Technologies не воспользовалась имеющимися возможностями для расширения функциональности и совместимости своих программных продуктов. Действительно, большинство дополнительных функций реализованы именно в виде серверных приложений Baikonur.
Поисковый механизм Яndex, позволяющий организовывать локальный поиск по Web-узлу, встроен в виде приложения yandex.exe и дополнительного индексатора. Приложение isapiter.exe обеспечивает совместимость со стандартом ISAPI. BaikTrends.exe анализирует лог-файл сервера (фиксируется, кто и когда заходил на узел, каково соотношение между загрузкой виртуальных серверов, какие файлы чаще всего скачиваются по ftp и т. д). Для упрощения управления содержимым на виртуальных серверах реализован репликатор файлов под названием colonel.exe. Если разработчики захотят включать текущую информацию в статически сформированные страницы, им обеспечит эту возможность многопользовательское приложение ssi.exe (расширения в стандарте SSI).
Для работы с почтовыми протоколами SMTP, POP3, IMAP4 в состав Baikonur SuperServer введены соответствующие визуальные серверные компоненты, при помощи которых разработчик способен быстро собрать почтового робота, сортирующего приходящие на сервер (или отправляемые во внешний мир) почтовые сообщения. Необходимость в таком роботе возникает в корпоративных системах, которые принимают отчеты филиалов в виде писем с присоединенной информацией, записанной в dbf-файлах. Почтовый робот может разархивировать сообщение и проверить правильность структуры dbf-файла. Возможности клиентских рабочих мест расширяют включенные в поставку Baikonur SuperServer библиотеки визуальных компонентов, выполненных по JAT-технологии.
В общем случае функций HTML достаточно для обеспечения приемлемой функциональности Internet-варианта приложения. Однако иногда ограничения языка HTML сужают возможности разработчиков. К сожалению, HTML не позволяет достичь той интерактивности клиентского рабочего места, к которой уже успели привыкнуть пользователи Windows-программ. Для решения этих проблем HTML и предназначена JAT-технология, которая в виде библиотеки JAT-компонентов входит в состав поставки Baikonur SuperServer 1.5.
Суть технологии заключается в том, что для расширения функциональности компонентов используется специальный JAT-аплет, который можно включить в HTML-страничку. Размер аплета не превышает 40 Кбайт, поэтому его применение не создает трудностей даже удаленным пользователям, работающим через модем.
JAT-компоненты предназначены для сборки серверных многопользовательских приложений, работающих под управлением сервера Baikonur. Для работы с таким приложением на клиентском месте достаточно иметь либо браузер, либо специальное клиентское JAVA-приложение, называемое JAT-загрузчиком.
С одной стороны, приложение, собранное из JAT-компонентов, - это приложение, которое написано на Delphi или C++ Builder, и таким его видит сервер. С другой стороны, клиентская часть приложения состоит из чистого Java-кода. Однако разработчику не требуется знать язык Java: реально приложение пишется целиком на Delphi или C++ Builder, что обеспечивают JAT-компоненты.
Сформированное с помощью JAT-компонентов приложение клиент-сервер работает под управлением сервера Baikonur, а чтобы удаленный пользователь смог с ним работать, достаточно загрузить в ПК-клиент аплет размером не более 30 Кбайт.
В самом ближайшем будущем большинство ИС крупных предприятий будет переходить от оффлайновых систем (типа электронной почты) к оперативным и многофункциональным интрасетям. Безболезненного перехода пока не гарантирует ни один разработчик (кроме Epsylon Technologies). Многопротокольный сервер позволяет решить как эту, так и другие сложные проблемы взаимодействия клиентов с многопользовательскими приложениями ИС и администрирования объектов системы.
Важно и другое. Сопровождение такой системы не требует особых усилий со стороны менеджеров ИС (ПО клиента - простой браузер) и не приводит к дополнительным материальным затратам при модификации серверного ПО, увеличении числа пользователей и пр. Основная нагрузка при любой реструктуризации ИС ложится на плечи разработчиков, которые при помощи визуальных компонентов Baikonur способны достаточно быстро написать необходимые серверные программы. Размер системы (максимальное количество пользователей) определяется только мощностью сервера Baikonur, которую можно наращивать, связывая несколько серверов в единую структуру.
По сути, технологии Baikonur позволяют организациям использовать для построения интрасети сверхбыстрый способ разработки разных серверных приложений с помощью одной визуальной среды программирования. Кроме того, они гарантируют защиту данных и надежность работы всей системы - как на внешнем уровне, с помощью шифрования исходящего трафика, так и на внутреннем (используются механизм балансировки внутренней загрузки и кластеризация для изменения загрузки серверов и восстановления информации после сбоев).
Заметим, что клиент всегда работает с динамически генерируемыми интерактивными страницами - даже если "целевое" приложение не обладает развитым графическим интерфейсом. При нарушении связи сервер сохраняет контекст сессии, что дает возможность продолжить работу с того места, где произошел обрыв соединения.
Более подробную информацию можно найти по адресу www.demo.ru.
Информация о компании: Epsylon Technologies
Epsylon Technologies - компания со стопроцентно российским частным капиталом. Организованная в 1989 г., она пережила несколько этапов реорганизации, став в 1994 г. одним из наиболее сильных партнеров фирмы Borland. В этом же году стартовал маркетинговый проект "Демоцентр клиент-серверных технологий", и компания долгое время оставалась известной как Демоцентр, или Центр поддержки продуктов компании Borland.
В декабре 1996 г. был выпущен первый коммерческий вариант ПО Baikonur Web App Server 1.0, а в апреле 1997 г. - версия 1.1. Осенью 1997 г. появился программный продукт Baikonur Enterprise Web App Server 1.3, в начале 1998 г. - Baikonur SuperServer 1.5 и Baikonur GIS ToolKit.
Продукты серии Baikonur - это инструментальные средства для создания очень крупных многопользовательских систем. Для таких систем (особенно - используемых государственными организациями, работающими в корпоративных или глобальных сетях) особенно важны сертификация программных продуктов, обеспечение безопасности и защиты от несанкционированного доступа. В настоящее время компания подала документы в государственные органы для проведения сертификации своих программных продуктов. Ведутся совместные с официальными организациями работы по встраиванию в Baikonur средств криптозащиты, соответствующих государственным стандартам России.
Руководство компании имеет собственный взгляд на политику передачи технологий и реализации своих продуктов. По его мнению, не бывает программных проектов, которые не требуют переделок или адаптации. Эти проблемы наиболее эффективно решаются группой хорошо обученных специалистов того предприятия, где внедряется проект.
Epsylon Technologies не просто продает продукт, а заключает с клиентом контракт на передачу технологий, в рамках которого происходит начальное обучение группы разработчиков, участвующих в проекте, а затем совместное построение первоначального макета системы. Эксперты из Epsylon Technologies курируют проект и, в случае необходимости, осуществляют доработки, создают компоненты или предоставляют примеры решения особо сложных задач.
Существуют очевидные аргументы в пользу именно такого способа построения крупных корпоративных информационных систем. Любая крупная система оперирует большим количеством отраслевых понятий, поэтому успешное внедрение обеспечивается, в первую очередь, тесными контактами местной группы разработчиков, хорошо знающих отраслевую специфику, и специалистов-экспертов, владеющих технологией построения крупных корпоративных информационных систем. Корпоративная информационная система - это сердце предприятия, и она должна быть абсолютно надежна и защищена. Компании не всегда готовы делиться со сторонними разработчиками своими секретами, поэтому контракт на передачу технологий - это разумный компромисс, позволяющий максимально эффективно решить задачу построения корпоративной информационной системы.
В рамках компании Epsylon Technologies существует Учебный центр, где проводится обучение по программным продуктам Borland (Delphi, C++ Builder, IB DATABASE, IntraBuilder) и технологиям Baikonur. Центральный офис и Учебный центр компании находятся в Москве, технологический центр - в Зеленограде.
Александр Сергеев - директор компании Epsylon Technologies. С ним можно связаться по адресу aes@demo.ru.