|
|
|
| Главная | О компании | Новости | Обучение | Обратная связь | Форум |
ABACUS Financial ABACUS Builder ABACUS Professional
|
Технологии распределенных вычислений
Информационная поддержка бизнеса - одно из слагаемых успеха любой компании. В транспортных, финансовых и производственных компаниях, простите за очевидность, без компьютерных комплексов и коммуникационных технологий сегодня не обойтись. Информационные технологии нужны, но какие? И как правильно с архитектурной точки зрения создавать программные системы? Эта статья - первый шаг к ответам на поставленные вопросы. При проектировании информационных систем масштаба предприятия разработчики традиционно ориентируются на технологию клиент-сервер. Она, безусловно, завоевала место под солнцем на рынке средних и крупных информационных систем, практически вытеснив настольные и файл-серверные технологии. Казалось бы, все хорошо, есть великолепные SQL-серверы, есть замечательные инструментальные средства для разработки клиент-серверных систем, - но подводные камни, которые встретятся разработчикам и эксплуатирующему персоналу, могут полностью перечеркнуть весь экономический эффект от внедрения. Давайте попробуем разобраться, чего можно ожидать, и самое главное, как можно решать не только сегодняшние задачи, но и создавать гибкие долгоживущие системы. Проблемы, с которыми сегодня сталкиваются в ходе разработки информационных систем менеджеры проектов, архитекторы и программисты, - это на самом деле только "вершина айсберга". После внедрения системы или доработки уже существующей специалистам все равно скучать не приходится. Причина неустранимая - мир вокруг нас не стоит на месте, он постоянно изменяется. Соответственно, развивается и одна из его составляющих - бизнес-условия. Вот эту проблему сложнее решить, намного труднее поддерживать в течение продолжительного времени адекватное состояние и функциональность системы, чем спроектировать её с нуля. Бизнес чутко реагирует на все технологические новшества и открытия. Примеров более чем достаточно. Пожалуй, самый яркий из них - Интернет. Его развитие как технологической основы Интернет-торговли действительно революционно. На наших глазах меняется сама модель бизнеса, что случалось в истории редко и изменения происходили в течение более длительного периода времени. Возможности электронной коммерции настолько сближают потребителя с производителем, что исчезает необходимость в таком институте, как классическая торговая сеть - она просто лишняя в бизнес-модели. В итоге мы получаем следующие составляющие: ПОКУПАТЕЛЬ, [Интернет-магазин], склад, банк и служба доставки. Красиво, эффективно и экономично. Но разработчикам такого рода систем приходится решать множество проблем, прежде всего проблему создания высоконадежных и высокопроизводительных программных комплексов. Такая прикладная задача и возможное количество пользователей (в один момент времени на сайте www.amazon.com обрабатывается от 1 до 5 тыс. пользовательских контекстов), может многих заставить отказаться от такого проекта. Вторая основная проблема - это интеграция различных систем, базирующихся на разных аппаратных платформах, и имеющих различные программные интерфейсы. В примере Интернет-магазина склад реализован с использованием SQL-сервера, а с банком нужно работать через CICS или Tuxedo, и все это в рамках единой транзакции. Еще пример: происходит слияние компаний - информационные системы должны быть сопряжены друг с другом. Как и чем лечить эти болезни? Как создавать гибкие системы? Сегодня ответ известен: системы должны быть гибкими с точки зрения бизнес-компонентов, открытыми на уровне технологий объектного взаимодействия, и что очень важно для будущего - это степень стандартизации выбранных базовых технологий. Чем больше производителей вычислительных систем поддерживают стандарт, тем ниже вероятность больших расходов при интеграции как программных, так и аппаратных комплексов. Прежде чем перейти к рассмотрению технологий, позволяющих решать перечисленные выше проблемы, вспомним клиент-серверные технологии. И посмотрим на них с точки зрения архитектуры. Такие системы состоят из двух составляющих - клиентского приложения и сервера баз данных, взаимодействующих при помощи сетевого транспортного протокола (обычно используются TCP/IP, NetBEUI или IPX/SPX). Классическая клиент-серверная архитектура представлена на рис.1.
Рис.1. Двухуровневая клиент-серверная архитектура С точки зрения функциональности, SQL-сервер выполняет следующие основные функции:
При использовании этой архитектуры возникают различные проблемы. Например, при переходе на новую версию SQL-сервера мы каждый раз получаем более богатый набор функциональности, но... усложняется транспортный протокол взаимодействия, что сразу накладывает на сетевые ресурсы предприятия повышенные требования. Сегодня нам приходится делать вложения в 100-мегабитные сети, а завтра? Что касается ресурсов на клиентской стороне, то современные клиентские библиотеки доступа к SQL-серверам в рабочем режиме требуют в среднем более 12 Мбайт свободной оперативной памяти. Конечно, за все нужно платить, в том числе и за многофункциональность, которая реализована в библиотеках доступа производителей SQL-серверов. Но если компьютерный парк в организации достигает десятков машин, то модернизация аппаратных ресурсов повлечет достаточно ощутимые финансовые затраты. Системы построенные по такой архитектуре, достаточно надежны (например, SQL-сервер и сервер IB DataBase способен гарантированно работать без сбоев более 2,5 тыс. часов) и производительны, а современные компонентно-ориентированные средства разработки, такие как Borland Delphi, Borland С++ Builder, Borland JBuilder позволяют радикально уменьшить время создания очень крупных клиент-серверных систем. Основная проблема этой архитектуры состоит в низкой способности к расширению и интеграции. Реально бизнес-логика "размазана" примерно поровну между сервером (триггера, хранимые процедуры) и клиентом (бинарный код), плюс отсутствует с той или другой стороны стандартный высокоуровневый механизм доступа к этой бизнес-логике. Её модификация или необходимость подключения новых "потребителей" или "поставщиков" требует больших затрат, увеличивая требования к аппаратному обеспечению, а также повышается вероятность внесения погрешностей при кодировке. Безусловно, после модификации такой системы администраторам необходимо установить на все рабочие места новую версию. А если рабочих мест более сотни? Недостатки архитектуры клиент-сервер очевидны, а решение находится буквально на поверхности. Необходимо сконцентрировать бизнес-логику с сервера и клиента на отдельном, среднем звене. При этом необходимо иметь стандартный протокол взаимодействия подсистем, возможно, написанных на различных языках программирования и работающих на множестве аппаратных платформ. При реализации описанного выше подхода мы получим архитектуру, представленную на рис.2. Надо отметить, что в этом случае не только бизнес-функциональность, но и все механизмы доступа к серверу баз данных располагаются в одном месте - на сервере приложений (Application Server). При этом реально ничто не мешает иметь несколько серверов с бизнес-логикой, что может использоваться как для резервирования, так и для баланса нагрузки. Администраторы могут спокойно производить регламентные работы, не опасаясь, что система может "встать". Модернизация бизнес-логики будет происходить на сервере приложений, что не только удобно, но и экономно. При использовании механизма версионности эту операцию можно производить в процессе работы системы. Очевидно, что в такой архитектуре очень просто использовать в качестве источников данных для серверов приложений различные SQL-серверы. Теперь посмотрим, что работает на клиентской стороне.
Рис.2. Трехуровневая архитектура клиент-сервер Здесь остается только код визуализации результатов работы с бизнес-логикой, представители (proxies) используемой бизнес-логики и модуль транспортного объектного взаимодействия (connectivity). Соответственно снижаются аппаратные требования к клиентским машинам. Поскольку "тонкая" конфигурация механизма доступа к БД производится на сервере приложений, значительно сокращаются затраты на развертывание и поддержку системы. А при использовании технологии Java для разработки клиентских мест или серверов приложений администраторы могут с одного места автоматически произвести обновления на всех клиентских местах и серверах. Что касается сервера баз данных, то он не "отвлекается" на выполнения часто очень объемных триггеров или хранимых процедур. Он будет заниматься тем, что лучше всего умеет делать - хранением и обеспечением целостности данных. Это положительно влияет на его производительность; сервер способен быстрее обрабатывать большие объемы данных на том же самом "железе". В любой системе управления предприятием мы можем увидеть как минимум два типа пользователей: аналитиков, работающих чаще всего в рамках длительных по времени транзакций и пользователей с коротким типом транзакций. В случае применения трехуровневой архитектуры логично разнести бизнес-логику, предназначенную для аналитиков и операционистов по разным серверам приложений. Тем самым повысится общая надежность системы в целом и ее скоростные характеристики. Даже простейшие тесты подтверждают, что скорость реакции многозвенной системы с точки зрения пользователя выше в 1,5-2,5 раза, а при использовании баланса загрузки по нескольким серверам приложений такая система справится с обслуживанием тысяч одновременно работающих пользователей. А с точки зрения прикладной архитектуры, мы получаем систему с высоким показателем компонентности на уровне бизнес-логики - значит, упрощается повторное использование функциональности системы. Транспортное взаимодействие сервера БД и сервера приложений такое же, как и в случае классического клиент-сервера. Здесь все понятно, но возникает вопрос - как обеспечить взаимодействие клиентского приложения с бизнес-объектами на стороне сервера приложений? Программное обеспечение, предназначенное для сокрытия всей сложности взаимодействия функциональных компонентов в сетевой инфраструктуре, называется middleware - обеспечение среднего звена. Среди реально присутствующих на рынке middleware существуют три технологии распределенных вычислений: - Технология DCE (Distributed Computing Environment) от консорциума OSF (Open Software Foundation, www.osf.org) - Архитектура CORBA (Common Object Request Broker Architecture) от консорциума OMG (Object Management Group, www.omg.org), более 900 постоянных членов IBM, Inprise, Oracle, Sun, Hitachi...) Это "древняя", проверенная временем технология. Реализована она в виде набора служб (Directory service, Time service, Cell service, Security Service, Thread Service...) над механизмами RPC (Remote Procedure Call). В отличие от CORBA и COM+, в DCE реализован процедурный подход к распределенным вычислениям. Это и понятно: в то время, когда DCE завоевывала мир, объектно-ориентированный подход был больше уделом лаборатории. Но сегодня ситуация совершенно другая, не надо даже говорить о важности использования ООП в разработке программных систем. Поэтому если и создавать систему, видимо, не стоит сегодня смотреть в сторону этой технологии, наверное только в случае необходимости интеграции с уже существующей системой на основе DCE. Собственно CORBA - это всего лишь спецификация, разрабатываемая участниками OMG. Сам штат консорциума не превышает 50 постоянных сотрудников, основная их задача - это координаторские функции. Конкретной реализацией CORBA-продуктов занимаются коммерческие фирмы - разумеется, в рамках разработанного стандарта. На сегодняшний день известно более 1500 продуктов на основе CORBA. Немного о том, как работает OMG. Запросы на разработку конкретной спецификации выдают сами члены OMG. Затем, после цикла обсуждений, спецификация утверждается. Важность такого подхода для разработчиков прикладных систем на основе этой технологии заключается в том, что процесс стандартизации коллективен, и, поскольку в OMG входит весь "цвет" компьютерной индустрии, разработчик может спокойно ориентироваться на любого поставщика CORBA-решений. Он всегда уверен, что его будущая система будет иметь стандартные механизмы интерфейсов. CORBA изначально задумывалась как технология, которая не должна зависеть от платформ и языков программирования. Если Вам не хватает производительности Windows NT, можно с минимальными усилиями импортировать решения на Linux, Solaris, HP-UX, AIX, OS/390. В случае использования "чистой" Java проблем с масштабированием на другую платформу просто не существует. Спецификация CORBA описывает не только взаимодействие между объектами, но и сервисы, доступные для прикладных CORBA-объектов. Базовыми сервисами являются Life Cicle Service, Location Service, Naming Service, Event Service. На сегодня стандартизировано уже более 30 системных сервисов. Основные принципы разработки на основе CORBA состоят в следующем. На абстрактном языке IDL (Interface Definition Language, который по синтаксису очень близок к С++) описывается, что из себя будет представлять объект без разработки его реализации. Следующие шаги - это генерация классов на конкретном объектно-ориентированном языке программирования для клиентского (stub) и серверного (skeleton; в последних спецификациях OMG - servant) приложений. Для этого используется компилятор IDL2CPP в C++ или IDL2JAVA для Java. На заключительном этапе мы разрабатываем реализацию серверного объекта и затем код визуализации на клиентской стороне. Причем разработки сервера может осуществляться на Java, а клиентские приложения - с использованием С++. Архитектура CORBA представлена на рис.3.
Рис.3. Архитектура CORBA Самое замечательное, что серверы приложений в случае использования CORBA взаимодействуют по стандартизированному протоколу - GIOP (Generic Interoperable Object Protocol): это позволяет не думать о том, от каких поставщиков в сетевой инфраструктуре работают брокеры объектных запросов (Object Request Broker, ORB), на каком языке разработаны и на каких платформах работают клиентские и серверные приложения. Теперь можно "померить" и более продуктивно использовать квалификацию "священнослужителей" от Unix, Windows, C++, Java, Pascal. К вопросу о квалификации. Когда ведется разработка клиент-серверной системы, то разработчикам необходимо знать и практически весь спектр базовых технологий - от взаимодействия с оконной подсистемой в клиентской операционной системе до SQL, функциональных и конструктивных особенностей конкретного SQL-сервера. Настоящих специалистов такого уровня немного, и затраты на "обладание" даже одним таким универсалом достаточно чувствительны. А, как известно, крупные системы в одиночку не разрабатываются. Если используется многозвенная архитектура, то очень просто при разработке спланировать работу сотрудников, учитывая их специализацию. Программист, глубоко знающий базы данных, пусть занимается базой данных; сотрудник, разбирающийся в бизнес-логике, пишет, соответственно, сервер приложений, специалист в области пользовательского интерфейса занимается клиентскими приложениями. Конечно, это достаточно упрощенный подход, но, очевидно, при возможности такого распределения задача в целом будет решена более качественно, в срок и с меньшими затратами. Возвратимся к примеру Интернет-магазина. Здесь как для обеспечения обычных операций над обычными объектами в рамках CORBA, так и для поддержки гетерогенных транзакционных источников данных, таких как Oracle, IB DataBase, Sybase SQL Server, любого JDBC-источника, CICS, IMS, Tixedo в OMG разработана спецификация OTS (Object Transaction Servise). Также в некоторых реализациях конкретных поставщиков OTS может брать на себя функции мультиплексирования соединений с сервером баз данных, что позволяет снизить нагрузку на сетевую инфраструктуру и SQL-сервер. С точки зрения разработчика, использующего разнородные транзакционные источники, они представлены всегда в виде единственного определения на языке IDL. Разработчику не важно, с чем он имеет дело, так как он находится в рамках стандартизированного интерфейса к транзакционным механизмам. Что касается технологии СОМ+, то по идеологии и принципам разработки она очень близка к CORBA, кроме трех пунктов: 1) Это закрытая технология (единственный поставщик, частично опубликована спецификация) Чем безусловно примечательна эта технология - это тем, что она есть на всех компьютерах, где установлены Windows 95, 98, NT. Если вы навсегда приняли решение работать только с технологиями Windows и мир вокруг вас - это тоже Windows, тогда СОМ+ будет естественным выбором. Для более детальной информации рекомендуется обратиться к странице компании Microsoft, посвященной этой технологии: www.microsoft.com/com/ Если существует необходимость наладить взаимодействие систем на базе CORBA, COM+ или DCE, то OMG позаботился и об этом. Есть спецификация места COM - ORBA, DCE - CORBA. При этом разработчик находится в привычном для себя инструментальном и технологическом окружении. Всю работу по обеспечении прозрачного взаимодействия технологических компонент берут на себя мосты. И в заключение немного о CORBA-решениях Inprise Corporation. Компания уже более двух лет поставляет на рынок собственные продукты для построения многоплатформенных многозвенных систем на основе реализации спецификации CORBA - семейство продуктов Inprise VisiBroker. VisiBroker выпускается для С++ и Java. Семейство продуктов VisiBroker представляет собой набор системных служб и библиотек разработчика. На основе VisiBroker создан Inprise Appliсation Server - комплексное решение для создания или интеграции информационных систем масштаба предприятия. Современные информационные системы таких известных компаний, как Genstar Container Corp., First Union Bank, Harvard University, Reynolds& Reynolds, A. Risk Services, Telcordia, и другие уже сегодня используют спецификацию CORBA как базисную объектную платформу для своих систем. Со стандартизованной, основанной на CORBA инфраструктуре сегодняшние решения позволят войти в третье тысячелетие максимально открытыми информационными системами с точки зрения возможной интеграции и гибкими в отношении постоянно меняющегося бизнеса.
|
|
|
|
||
