Ну что вам рассказать про Байконур...
		(На космодроме летная погода)

	Заканчивалась холодная осень 1998 года. Глаза устали следить за ужимками и прыжками курса  доллара. Российский фондовый рынок продолжал находится в реанимации с высокой вероятностью летального исхода. Выжившие заказчики прибывали в послекризисном ступоре. Активизировавшееся было общение с друзьями и знакомыми все в большей степени начало сводиться к стандартному диалогу "Как у вас?" - "Хреново" (вариант - "Никак"). "А у вас?" "У меня тоже". Многочасовый ежедневный серфинг в Интернете назло провайдеру (я тебе покажу, гаду, что такое flat rate - если уж дозвонился, то не вылезу) тоже начал надоедать.
   Поэтому получение письма от редактора Компьютерры Георгия Башилова внесло приятное разнообразие в монотонность моих праздных будней.

В письме говорилось, что:
 1. Компьютерра, повернувшись лицом к российскому производителю, решила сформировать специальный выпуск (может даже, не один), посвященный российским  разработчикам софта.
 2. В связи с этим выход моих статей задерживается на неопределенное время до завершения формирования выпуска.
 3. Поскольку выпуск выйдет не раньше середины января,  не слабо ли мне подготовить материал о продукте Baikonur от фирмы Epsilon Technologies.
	"Не слабо!" ответил я, тем более, что этот продукт весьма интересовал и меня самого.	

		История знакомства 

Моя первая встреча с тем, что впоследствии стало называться Baikonur, случилась летом 1996 года, когда я, будучи начальником отдела информационных технологий крупной брокерской фирмы, выбирал платформу и компанию - разработчика для реализации корпоративной информационной системы. 

	Фирма Epsilon Technologies была известна мне как основной российский дистрибьютор  и консультант по продукции фирмы Borland (ныне Inprise).  Через Epsilon шло порядка 60% продаж борландовских продуктов на российском рынке. Их широкая  распространенность среди российских разработчиков - во многом заслуга Epsilon.

	В Epsilon я обратился, как к поставщику Delphi (на этом продукте была изготовлена работавшая в то время версия системы), рассудив, что если они продают продукт и являются ведущими специалистами по нему, то наверное, и от прикладной разработки не откажутся.

	Тут я оказался не прав - от разработки они отказались, так как это не соответствовало философии фирмы, но приехавший на переговоры господин Сергеев продемонстрировал на своем ноутбуке свежее, только что разработанное решение для создания Web-приложений с помощью Delphi. Известное тестовое приложение Delphi (база данных рыбок), работало  у него под Web-браузером, выглядело и вело себя почти так же, как в родном GUI-интерфейсе. 
При этом исходный текст этого приложения, портированного под web, практически не отличался ни по объему, ни по логике от исходного, и более того - разработка приложения велась в стандартной визуальной среде Delphi с помощью набора компонент, практически дублирующего стандартный.
	Правда, для того, чтобы все это работало, требовался специальный Web-сервер, также изготовленный Epsilon Technologies.

	Роман с Epsilon у нас тогда не состоялся, так как мы искали команду для реализации проекта "под ключ", но сама идея такого инструмента для визуальной разработки сложных web-приложений показалась мне чрезвычайно интересной. Это был, вообще говоря, настоящий прорыв. Значимость его способны оценить те,  кто сталкивались с разработкой "в лоб" сложных web-приложений, работающих с базами данных, и знают, какое это трудоемкое занятие, и насколько плохо при этом работают получившееся приложения, если не прилагать очень специальных усилий для их оптимизации.  

Спроектированные для работы в условиях массового обслуживания традиционные Web-сервера бесконтекстны - т.е. каждый приходящий от браузера пользователя  запрос содержит всю информацию, необходимую для обработки его сервером, логика работы которого вообще говоря, никак не зависит от предыдущих действий пользователя. 

Традиционная технология разработки динамических Web-приложений основана на том, что на каждый приходящий от браузера запрос запускается так называемый CGI-скрипт, то есть, вообще говоря, отдельный процесс с точки зрения операционной системы, получающий параметры запроса, и выполняющий необходимые действия по его обработке и формированию HTML-страницы, которая будет возвращена в ответ на запрос.

В современных WEB-серверах существуют разные модификации этого механизма - ISAPI (Information server API), позволяющий  не запускать отдельный процесс, а обращаться к функциям DLL, SSI (Server Side include) и ASP (Active server pages), позволяющие описывать страницы с частично статическим, частично генерируемым содержимым, и др. 

Эти методы позволяют сделать несколько более эффективным работу web-приложений, и облегчить проектирование динамических страниц, но не решают проблему бесконтекстности - по прежнему на каждый запрос нужно разбираться, как его выполнять, т.е. какие процедуры и/или задачи нужно запускать, и в каком контексте. 
	В частности, если используется ASP, то на каждый запрос должны быть порождены все необходимые COM-объекты, установлены соединения с базой данных, исполнены запросы, разорваны соединения с базой, уничтожены COM-объекты, причем все это должно корректно работать в условиях, когда несколько запросов приходит одновременно. Вся эта кухня работает очень не быстро, и требует достаточно нетривиального программирования. 

	Естественная идея состоит в том, чтобы кроме WEB-сервера иметь постоянно запущенную задачу (задачи), хранящую в себе весь необходимый контекст (контексты), держащую в нужном количестве открытые соединения с базой данных, и выполняющую фактически всю обработку логики приложения.
При этом web-сервер выполняет роль некоторого "коммутатора", связывающего пользователя, работающего с web-браузером, и работающую в его интересах задачу на сервере. При этом у каждого пользователя может быть своя задача, или одна задача может обслуживать много (ограниченное или неограниченное количество) пользователей.

	Но такой подход немедленно порождает новые проблемы - такие задачи нужно запускать, когда в них возникает потребность, и убивать, когда потребность исчезает - например, пользователь отпал.  Серверу нужно уметь разбираться, какой задаче адресовать какой из пришедших запросов. И наконец, нужно иметь средства разработки задач, работающих под управлением такого web-сервера.

	Все это и было сделано в продукте, продемонстрированном  Epsilon Technologies. 

В декабре 1996 года эта разработка получила имя собственное "Байконур" и статус продукта. Продукт состоял из двух частей 
	- собственно, Baikonur Web Application server, умеющий запускать приложения, взаимодействовать и управлять ими.
	- библиотека компонент Delphi для разработки Baikonur-приложений, в основном дублирующая обычную библиотеку визуальных компонент, с некоторыми ограничениями и расширениями
  
	Следующая моя встреча с Байконуром произошла весной 1998 года на РОЦИТовском форуме. Оказавшись за одним обеденным столом, я обменялся визитками с Андреем Чесноковым, и увидел на его визитке надпись "руководитель проекта Байконур". По этому поводу я решил проявить эрудицию и рассказал, что я с Байконуром знаком, что это такой космодром в Казахстане, и заодно такая система для разработки сложных Web-приложений на Delphi.

	На что Чесноков поморщился, и сообщил, что на самом-то деле Байконур - это телекоммуникационный многопротокольный монитор транзакций, а Delphi  и WEB-сервера - это так, дань конъюнктуре.
Чем заинтриговал меня черезвычайно, так как про мониторы транзакций я слышал, но глубоко с ними не разбирался, а причем тут телекоммуникационный и многопротокольный, для меня вообще являлось загадкой. Продолжения этот разговор тогда не получил.

	После этого до меня время от времени доходила информация что Байконур используется в Центральном банке, Лукойле, Аэрофлоте, Онэксим-банке, еще где-то. Периодически в я также поглядывал новости на  Web-сервере Epsilon - www.demo.ru.

		Следующий шаг - JAT и Taxxi

	Летом 1998 года появились пресс-релизы Epsilon об их новом продукте, названном JAT (Java application terminal). Вкратце - это такое Java-приложение, которое умеет отрисовывать картинки, передаваемые ему Baikonur-сервером от задачи, работающей на сервере и заточенной.

	Для того, чтобы понять, что это такое, и зачем это нужно, стоит немного порассуждать об эволюции Интернет-приложений. Толчок нынешнему развитию Интернет дало появление HTTP, WWW-серверов и браузеров.  Но простота  "pure web" интерфейса скоро стала тормозом на пути развития Интернет-приложений. Развитие языков скриптов (Java script, VB script), новые версии HTML, новые протоколы (ShockWare, и т.д.),  средства доставки и запуска приложений на компьютеры пользователей (JAVA, ActiveX) стремятся к одной цели - возможности создавать Интернет-приложения, по удобству интерфейса не уступающие традиционным GUI-приложениям, и при этом пользующиеся всеми преимуществами работы в глобальной распределенной сети. Предельным выражением этой тенденции являются специальные загружаемые приложения, использующие собственные протоколы и сервера, и рассматривающие Интернет только как транспортную среду.

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

	JAT - это некоторый разумный компромисс между указанными выше критериями. На компьютер пользователя должно быть загружено небольшое (порядка 100К) Java-приложение, которое не содержит никакой бизнес-логики, и поэтому поддерживает все приложения, разработанные под JAT. При этом компьютер пользователя занимается только отрисовкой интерфейса, передаваемого с сервера, и передачей на сервер событий, инициированных действиями пользователя.

	Интерфейс представлен множеством объектов, отрисовкой каждого из которых занимается отдельный Java-класс. В случае отсутствия у клиента Java-класса, ответственного за отрисовку некоторого типа объекта, появившегося в новом приложении, он автоматически подгружается с сервера. По сети идут только изменения свойств объектов, за счет чего траффик удается делать исчезающе малым. Разработчики утверждают, что большинство JAT-приложений нормально работают на скорости соединения 4800bps. 
Протокол JAT формально инкапсулирован в HTTP, хотя естественно, не имеет смысла для обычных браузеров.

	Разработка JAT-приложений ведется с помощью библиотеки компонент, практически ничем не отличающихся от стандартных компонент VCL Delphi. Утверждают, что для того, чтобы перевести уже имеющееся приложение под JAT, достаточно текстуально заменить названия компонент на их JAT-аналоги, и пересобрать задачу.

	Таким образом, JAT-это следующий прорыв Epsilon Technologies, позволяющий промышленным образом не только разрабатывать Интернет-приложения как обычные, но и создавать приложения, которые на компьютере пользователя ведут себя так же, как и стандартные GUI-приложения.

	Следующий шаг не заставил себя долго ждать - осенью 1998 года общественности был предложен специализированный клиент, названный Taxxi. Он работает с теми же приложениями и по тому же протоколу, что и JAT, но отрабатывает в 10-20 раз быстрее. Платой за это является зависимость от операционной среды (сейчас Taxxi имеется только для Windows-сред) и необходимость инсталляции.  При этом сам Taxii не включает в себя телекоммуникационных функций, а пользуется для этой цели телекомуникационными возможностями ядра сервера Baikonur, который также должен быть установлен на компьютере пользователя. Впрочем, размеры всего этого хозяйства позволяют его без особых проблем скачать через сеть (Taxxi-менее 400К,  Personal Baikonur - менее 1М).

	В принципе, той информации, которой я располагал, было вполне достаточно для написания небольшой статьи. Но у меня не шли из головы слова о "многопротокольном сервере транзакций". Кроме того, на сервере не удалось найти практически никакой информации о success story продукта, его предыстории, позиционировании продукта на рынке и планах компании.

	Поэтому получив заказ на статью, я созвонился с Андреем Чесноковым, и отправился в наверное, знакомый многим Демо-центр Epsilon, расположенный в странном одиноко стоящем строении На улице Нарвской, что в районе метро Водный стадион. 

	Сразу предупреждаю - разобраться, что такое вообще сервер транзакций, и чем конкретно занимаются порядка 300 тысяч строк исходного кода Байконура, я с достаточной степенью ясности не смог. Боюсь, что без детального изучения документации и практического опыта программирования в этой среде сделать это не удастся. Тем не мнение, я попытался кратко  описать основные функции и архитектуру сервера - вдруг те, кому это близко, поймут?

Байконур состоит из ядра, и набора драйверов-обработчиков протоколов.

  Основными понятиями, которыми оперирует Baikonur Web Application Server, являются пользователь, сессия, приложение и протокол.
	  Пользователь инициирует сессию по некоторому допустимому протоколу. Ядро сервера определяет тип протокола, и обращается к обработчику соответствующего протокола, который идентифицирует пользователя принятыми для данного протокола методами, и определяет, какое приложение должно его обслуживать. 
	Ядро предоставляет широкий набор функций, которые могут быть использованы при разработке драйвера протокола, и стандартный интерфейс подключения. Поэтому набор драйверов протоколов легко расширяем. В настоящее время поддерживаются FTP, HTTP, DAAP, IIOP, LDAP, POP3, SMTP, IMAP4 и ряд других протоколов. 

	Определив протокол и приложение, и идентифицировав сессию,  сервер создает т.н. "блок управления подключением', и для данного пользователя запускается приложение (или присоединяется уже запущенное). Для вновь запущенного приложения создает т.н. "информационная магистраль", т.е. канал подключения его к серверу, через которую приложению приходят запросы на обслуживание, и уходят ответы. Приложения могут быть одно- и многопользовательскими. 
	Многопользовательские приложения должны самостоятельно хранить специфический контекст для каждого пользователя, (если таковой имеется). Сервер сообщает многопользовательскому приложению все, что он знает о пользователе, а так же о появлении новых пользователей и исчезновении старых. Эти сигналы приложение обрабатывает самостоятельно. Впрочем, это облегчено соответствующей реализацией компонент, из которых собирается приложение. 

	Сервер управляет всеми запущенными приложениями и TCP/IP сессиями, обрабатывая прерывание и возобновление сессий, "слеты" и зависания приложений, находящихся по его контролем, и сам убивает приложения, оставшиеся без пользователей.

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

	Сервер реализован с использованием многопоточной технологии, что позволяет достигать очень высокой производительности. Каждая пользовательская сессия и запущенное приложение ведется своей "нитью". Приложение, "отдав" северу ответ на запрос, сразу освобождается для обработки следующих запросов. Далее отправкой ответа через сеть занимается "нить", ответственная за сессию. 

	Все это позволяет серверу Байконур  работать в условиях массового обслуживания, достигая очень высокой производительности. Так, на испытаниях, проведенных фирмой Intel, на четырехпроцессорном сервере Pentium с 512МБ, успешно имитировалось 10000 одновременно работающих пользователей, запустивших 700 приложений.

		История проекта

	До 1995 года Epsilon спокойно продавала продукты фирмы Борланд, а ее программисты занимались тестированием, разработкой примеров, и прочей деятельностью, направленной на то, чтобы быть в состоянии консультировать пользователей.	
	Взрывообразный рост Интернет-а поставил на повестку дня вопрос присутствия фирмы в web-пространстве. Было решено попытаться создать не только презентационный сайт фирмы, но и большой и интересный игорный сайт, как маркетинговый, а в перспективе и коммерческий проект. Заодно это позволило бы приобрести не очень загруженным программистам новую квалификацию и протестировать имеющиеся технологии разработки Интернет-приложений.
	Реализация прототипа такого сайта была выполнена, но затем проект был свернут, так как выяснилось, что разработанное "в лоб", на CGI-скриптах приложение является очень тяжелым и совершенно неуправляемым за счет смеси в исходном коде бизнес-логики, интерфейса и управления соединением. 
	Проведя поиск на рынке инструментария, и не найдя ничего подходящего, специалисты Epsilon Technologies констатировали наличие рыночной ниши средств быстрой разработки web-приложений. В это же время в Epsilon пришла группа программистов, занимавшихся разработкой систем асинхронного межпроцессорного обмена данными в транспьютерных сетях и телекоммуникационным монитором ОБЬ на EC-овских мэйнфреймах.

Телекомуникационными мониторами на  IBM-овских мэйнфреймах назывались системы, позволяющие задаче общаться с интеракитвными терминальным оборудованием. Они не были органической частью операционной системы, так последние изначально ориентировались на режим пакетной обработки. Монитор предоставлял задаче набор вызовов, с помощью которй происходило ее общение с терминалом, при этом скрывая от нее особенности конкретных устройств. Наиболее известными были мониторы CICS (IBM) и Compleet (Software AG).
ОБЬ была оригинальной отечественной разработкой. Кроме своего собственного интефрйеса она поддерживала стандартные ЕС-овские телекомуникацинные методы доступа (протоколы) БТМД и ОТМД и огромный терминальный парк – свыше тысячи устройств. ОБЬ была широко распостронена в СССР – под ней работало 40% всех ЕС-овских машин, против 15% под CICS. ОБЬ была существенно менее требовательна к ресурсам, чем CICS, имела более удобный интерфейс разработчика и поддерживала гораздо больше типов терминалов, включая редкие тогда персоналки.

	После этого проект обрел конкретные очертания - телекоммуникационный монитор транзакций для протоколов, базирующихся на TCP/IP, и соответствующие библиотеки для разработки в его среде. 

Наиболее трудной задачей этого этапа, по словам Андрея Чеснокова, было создание команды проектировщиков из системных программистов старой школы и "борландовских" программистов - слишком разное было у них профессиональное мировоззрение.
Но именно это сочетание "старой школы", воспитанной в традициях многозадачных и хорошо структурированных операционных систем IBM-овских мэйнфреймов и   сохранившей навыки борьбы за эффективность с одной стороны, и разработчиков, привыкших к RAD-инструментам с другой, позволило обеспечить уникальное на сегодняшний день сочетание удобство разработки приложений и производительности, отличающие Байконур.

	17 Декабря 1996 года была выпущена первая "коробочная" версия. К этому времени уже было несколько компаний-разработчиков, лицензировавших у Epsilon эту технологию.

       Летом 1998 года был запущен игровой сайт www.games.demo.ru, где в качестве демонстрации технологий Байконур было реализовано несколько карточных игр - пасьянсы и др. По словам Чеснокова, игры были реализованы буквально за несколько дней программистом-практикантом. Примерно через месяц после появление сервера в сети на нем стали фиксировать резкое увеличение траффика. Анализ показал, что обращения идут в основном из США, причем от пользователей Web-TV приставок. Потом начали приходить письма с благодарностями - в основном от инвалидов. Оказалось, что это один из немногих сайтов, где с приемлемой скоростью работают игры, которыми можно пользоваться с приставок, а эти приставки  американская служба социального обеспечения широко раздавала по программе социальной помощи инвалидам.
	После этого реализация игр была быстро "заточена" под Web-TV (там используется язык чуть более богатый, чем стандартный HTML), сохранив впрочем, способность работать и в стандартном HTML.
	Сейчас этот сервер генерирует 7% мирового траффика Web-TV. C августа месяца его посетило более 180000 посетителей (уникальных хостов). За те четыре часа, что я провел в Демо-центре, на сервере побывало свыше 2000 пользователей, сгенерировавших свыше 120 000 хитов. Сервер за это время отгрузил порядка 200 мегабайт. И все это на Pentium-133 c 64M памяти!

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

	Во всяком случае, уже продано более 300 лицензий, и среди покупателей – много известных россйиских компаний, две американских, четыре немецких и две французских. В течение последних месяцев  с www.demo.ru ежемесячно отгружается более 300 копий trial-версии Baikonur Web Application Server-a.

	Все это было достаточно интересно, но самое интересное ждало меня еще впереди. 

			Интернет-3 

	Оказалось, что не ограничиваясь ролью поставщика хорошего инструментального средства, Epsilon нацелилось не больше не меньше, как на реформирование Интернет! 
	Идеологическая подоплекой этого является утверждение о том, что сочетание производительности, компактности и легкости разработки приложений, достигаемые с помощью средств разработки семейства Байконур, способны кардинально изменить лицо Интернет, породив то, что директор Epsilon Александр Сергеев назвал Интернет-3.

	Интернет-3 характеризуется
	- широким использования полнофункциональных "сверхтонких" клиентов (типа Taxxi), способных работать на любых мобильных устройствах, и обеспечивать работу с приложениями любой сложности;
	- вынесением на удаленные сервера гораздо более широкого спектра приложений, чем это возможно сейчас, включая аутсорсинг всей серверной инфраструктуры как для индивидуальных, так и корпоративных пользователей.
	- исчезновением разделения компьютеров на "серверы" и "клиенты". Возможность запихнуть 1МБ Baikonur Web Server на каждый компьютер, в том числе на Palmtop, делает их все равноправными.

	Правда, все это должно наступить после этапа Интернет-2, на котором должны быть решены вопросы устойчивой и по возможности беспроводной связи, после чего любой компьютер можно будет считать подключенным к Интернет в режиме постоянного доступа.

	Лично меня в этой перспективе несколько пугает исчезновение стандартного протокола и стандартного интерфейса, позволяющих легко интегрироваться с "чужими" web-приложениями, но похоже, что это все равно неизбежно - после полного HTML-единообразия грядет эпоха "смешения языков". Будем надеяться, что Интернет при этом не повторит судьбу вавилонской башни.

	Если пытаться сравнивать технологию Байконур  с конкурирующими продуктами, оказывается, что таковых существуют три традиционно различающихся класса:
-	Web-серверы приложений – Netsckape (ex-Kiwa), Oracle, Sun (NetDynamics), Progress, Haht, BlueStone, Appitivity, ColdFusion и др.:
-	Терминальные серверы со сверхтонкими клиентами– Citrix WinFrame, Microsoft Gidra, и др.;
-	Мониторы транзакций – IBM CICS, BEA Tuxedo, MTS, и др.

К сожалению, в коротком обзоре невозможно указать, чем отличается Байконур от всего вышеперечисленного. Более того, мониторы транзакций и web-сервера приложений все очень разные, основаны на разных концепциях, имеют разную функциональность, и в конечном счете имеют достаточно мало общего между собой, поэтому сравнивать нужно с каждым конкретным продуктом.  
Но, по утверждениям специалистов Epsilon, проводивших такой	 анализ, в каждом случае сравнение с Баконуром обнаруживает большое количество крупных и мелких различий, как правило, осложняющих разработку, и/или увеличивающих сетевой траффик приложения, и почти всегда снижающих стойкость сервера к нагрузке.
 Но для для выбранной предметной области (сложные Интернет-приложения, расчитаные на массовое обслуживание) эти количественные по своей природе различия в трудоемкости разработки и требованиям к производительности аппаратного сервера быстро переходят в качество, зачастую выводя проект за границы реализуемости при разумном размере затрат.  

Кроме того, Байконур является перспективной платформой для разработки того, что обычно называется instant communications (общепринятый русский перевод отсуствует) – продуктов, обеспечивающих прямое (не опосредованное серверами) мгновенное взаимодействие клиентов друг с другом. Примером такого средства является широко известная программа ICQ (Mirabilis, ныне AOL).

Именно в этом смысле состоит “уникальном торговом предложении” Epslion Technologies. Все реализованные в Baikonur механизмы где-то да встречаются, но по сочетанию набора реализованных функций, потенциалу расширения, скорости разработки приложений и способности держать нагрузку технология Байконур, по-видимому уникальна, и не имеет прямых конкурентов. 

		Последний отчет

Естественно, менять лицо  Интернет, находясь в российской глубинке, невозможно. Поэтому последний год руководство Epsilon посвятило поиску стратегических западных партнеров и инвесторов. Значительное количество выставок и переговоров привели к результату.

 В декабре были подписаны стратегические соглашения с несколькими инвестиционными фондами, специализирующимися на финансировании высоких технологий, и Epsilon получил первый транш инвестиционных денег. Создано представительство Epsilon в Нью Йорке, и ряд совместных предприятий. Таким образом, Epsilon превращается в транснациональную корпорацию, повторяя путь многих других российских разработчиков, выходящих на западный рынок.

	Александр Сергеев поделился своими впечатлениями о процессе поиска инвесторов. "Самое удивительное, сказал он, что если у тебя есть хороший проект, то нет такой проблемы - найти инвестора. С момента, когда ты начинаешь говорить на том же языке, что и инвесторы, проблемы исчезают. Наши люди считают, что инвестиции нужно искать где-то как-то по знакомству. На самом деле существует огромное количество организаций, озабоченных тем, куда вложить деньги. Ты входишь не по знакомству через заднюю дверь, а с парадного входа, и спрашиваешь - "Где здесь дают деньги?" Тебя проводят в комнату, где сидит скучающий клерк, с надеждой спрашивающий "вы пришли за инвестициями?". И если ваш проект мало-мальски соответствует их требованиям, то деньги вы получаете со 100% вероятностью"

	Не знаю, правда, много ли есть фондов, для которых Интернет-технологии, реализуемые российской фирмой, попадают под определение "мало-мальски соответствующих", но факт остается фактом - Александру Сергееву удалось их найти. Так что в ближайшем будущем можно ждать масштабной PR-компании Epsilon Technologies, в том числе (по инерции) и на российском рынке.

	На вопрос об том, кто конкретно является инвесторами, и каков объем инвестиций, Александр Сергеев ответить отказался, скромно заметив, что "их достаточно, для того чтобы стать новым Netscape-ом".

	 Пошел предстартовый отсчет - Epsilon Technologies International стартует со своего Байконура! Очень надеюсь, что ее не постигнет судьба 12 телекоммуникационных спутников Global Star, сгоревших через несколько минут после старта с вышеозначенного космодрома 10 сентября прошлого года.