Диссертация (1136162), страница 5
Текст из файла (страница 5)
Разработкаприложенийклиент-сервер,которые,какправило,компактнееипроизводительнее традиционных, осуществляется в среднем вдвое быстрее иобходится приблизительно на 30% дешевле по сравнению с ПО на основе раннихархитектурных подходов [252].Архитектура клиент-сервер и сопутствующие ей инструментальныесредства являются основой высокопроизводительных программных комплексов,потенциально обеспечивающих доступ к разнообразным источникам данных.Рост производительностиинструментальныхсредств проектирования иреализации снижает совокупную стоимость создания приложений (TCO) [66].1.2 Современные расширения архитектуры клиент-серверПромежуточное ПОПромежуточным программным обеспечением (ППО, или, иначе,middleware) называется ПО, связывающее приложение с необходимымипрограммными ресурсами (а, возможно, также и приложениями) [66].
Косновным преимуществам ППО относятся облегчение доступа приложений кресурсам (ППО позволяет разработчикам программных систем сосредоточитьсяна проектировании бизнес-логики, а не механизмов доступа к ресурсам) иускорение процессов взаимодействия (ППО увеличивает производительностьИС) [8].22Middleware делят на ППО обеспечения взаимодействия между активным(реализующим бизнес-логику) приложением и пассивным ресурсом (сервер БД)и ППО обеспечения взаимодействия между активными приложениями. Первуюгруппу можно разбить на ППО для работы с серверами БД (для предоставленияAPI-доступа к БД) и мониторы обработки транзакций или TP-мониторы (дляоптимизации работы системы).
К первому типу ППО относятся средствареализации спецификаций ODBC (Object Database Connectivity), OLE DB (ObjectLinking and Embedding Database) и JDBC (Java Database Connectivity). СредстваODBC дают разработчику независимый от СУБД набор функций для обработкиданных [66].TP-мониторы (Microsoft Transaction Server, BEA Systems Tuxedo, IBMCICS, Transarc Encina и др. [77]) осуществляют мультиплексирование(накопление или смешивание) запросов, направляя их пакеты в рамках одногоподключения к БД, а также предоставляют приложениям виртуальный доступ кразнородным БД.ППО,обеспечивающеевзаимодействиемеждуактивнымиприложениями, можно условно разделить на три основных типа: ППОудаленного вызова процедур (RPC, Remote Procedure Call), ППО передачисообщений (МОМ, Message Oriented Middleware) и ППО брокеров объектныхзапросов (ORB, Object Request Broker).
Средства RPC обеспечивают выделениефрагмента проектируемого программного комплекса для выполнения наудаленном компьютере с "прозрачными" вызовами удаленных методовобработки данных. Код RPC присоединяется к обоим приложениям – источникуи приемнику, осуществляет преобразования данных и активирует процедурыпередачи данных по сети. Распространение языка Java привело к появлениюаналога RPC для Java-приложений — RMI (Remote Method Invocation) [66].Системы передачи сообщений (MOM) основаны на технологии очередейсообщений: приложения обмениваются информацией посредством буферов(очередей) независимо от типов программно-аппаратных платформ и сетевыхпротоколов. Разработчику предоставляется API-интерфейс высокого уровня.23Использование МОМ позволяет объединять различные режимы связи в рамкаходнойтранзакции, чтоповышает отказоустойчивость,критичнуюдлякорпоративных программных комплексов со сложной бизнес-логикой [66].Технология брокеров объектных запросов [77], [252] является наряду сМОМ наиболее бурно развивающимся типом ППО.
ORB управляют обменомсообщениями в сети. ORB выполняет функции интеллектуального посредника,т.е. принимает запросы от клиентского приложения, осуществляет поиск иактивизацию удаленных объектов, которые принципиально могут ответить назапрос, и передает ответ объектам запрашивающего приложения. ORB, как иRPC и МОМ, скрывает от пользователя процесс доступа к удаленным объектам.Средства ППО ускоряют реализацию корпоративных программных комплексов,смещая акценты с поддержки взаимодействия многообразных приложений иресурсов на разработку бизнес-логики.При работе с однотипными БД целесообразно применение ППО БД, а длягетерогенных БД и оптимизации доступа – TP-мониторов.
Для обеспечениясинхронного взаимодействия корпоративных приложений рекомендуетсяиспользовать RPC, а для организации совместной работы слабосвязанныхприложений – МОМ. Хотя средства МОМ и ORB являются наиболееуниверсальным ППО, длядостижениянеобходимой функциональностикорпоративных программных комплексов целесообразно комбинированиеразличных типов ППО, зачастую предоставляющих интерфейсы для взаимнойинтеграции [218], [221] и др.Интернет-архитектурыВбольшинствеприкладногоПОвыделяютсяпрезентационный,коммерческий, логический и физический архитектурные уровни.
В архитектуреклиент-сервер презентационный и коммерческий уровниприкладного ПОразмещаются на клиентской, а логический и физический – на серверной стороне,что порождает ограничения на автоматическое обслуживание и распределениелогики между многими клиентами, независимую разработку гетерогенныхлогических компонент, адаптивную абстрактную логику для гетерогенных сред24хранения данных, включая и интернет-среду. В этих целях традиционноиспользовались решения с двухуровневой архитектурой. Однако, в настоящеевремя наметилась тенденция перехода от двухуровневых архитектур ктрехуровневым и далее – к интернет-ориентированным архитектурам дляпостроениябизнес-критичных,ориентированныхнапользователя,распределенных, открытых, расширяемых, высокопродуктивных приложений, ав итоге – к платформе, увеличивающей конкурентноспособность корпораций[18], [41], [83], [98], [103], [108], [115], [117], [128], [129] и др.Трехуровневые технологии предоставляют дружественный интерфейс ираспределенную интернет-архитектуру с возможностями оперативного доступак данным, высокой безопасности, быстродействия, тестируемости.
Сутьархитектуры состоит в размещении прикладной бизнес-логики на уровне ППО(илисервераприложения).Интернет-архитектураизначальноявляетсяоткрытой. Приложения строятся из повторно используемых связанныхпротоколамимногоуровневыхнезависимымоткомпонент;программно-аппаратнойинформацияплатформывизуализируетсяпользовательскиминтерфейсом [41], [103], [108] и др.
Адаптивность вычислительной средыопределяется выбором сервера приложения, поддерживающего различныекомпонентные модели данных; при этом необходимо обеспечить адаптивностьна уровне клиента и сервера данных.В интернет-архитектуре механизмы распределения презентационнойлогики варьируются от полностью HTML- и JavaScript-решений до вебсервисовMicrosoft .NET или JavaBeans-компонент для получения приложения клиентом.Выбор между функциональностью и полосой пропускания определяетраспределение презентационной логики между сценариями и компонентами.Гибкость среды разработки достигается посредством настраиваемой степенираспределенности ПО либо интегрированного набора средств разработки.1.3 Классификация современных архитектур для интернет-ИСАрхитектура брокеров объектных запросов OMG CORBA25Первые практически удовлетворительные крупномасштабные решениямассового характера с длительными сроками эксплуатации были получены в 90х гг.
на основе технологического подхода CORBA (Common Object RequestBroker Architecture), разработанного некоммерческой ассоциацией крупнейшихпроизводителей и потребителей ПО Object Management Group (OMG,www.omg.org). Стратегической задачей OMG стало создание обобщеннойобъектно-ориентированнойтехнологии,унифицирующейинтеграциюкорпоративного гетерогенного ПО независимо от программно-аппаратныхплатформ, протоколов взаимодействия, языков программирования, средствпроектирования и реализации ПО.CORBA-интеграциякорпоративныхприложенийпроизводитсяпрограммными агентами – брокерами объектных запросов, расположенными насерверах, по которым «распределена» ИС.
Формат запросов нейтрален поотношениюкархитектурно-интерфейснымособенностямкомпонентпрограммного комплекса.Технология CORBA (www.corba.org) базируется на компонентной моделиCСМ (CORBA Component Model) с архитектурой OMA (Object ManagementArchitecture) и основана на принципах программной совместимости сразличными операционными системами (ОС) и компонентами прикладного ПО,включая редко используемые и «унаследованные» (legacy).В развитие CORBA в 2002 г.
на базе архитектурного подхода ModelDrivenArchitecture (http://www.corba.org/vendors/b.htm) создан стандарт CORBA 3,имеющий целью объединение технологий CORBA, Java и .NET для реализацииприкладных программных систем с абстрагированием от программноаппаратной платформы.Важным преимуществом CORBA является принципиальная возможностьинтеграции «унаследованных» компонент корпоративного ПО в новуюглобальную вычислительную среду современных интернет-ИС с поддержаниемтребуемого уровня отказоустойчивости, масштабируемости, безопасности ицелостности данных [8], [66], [218], [252] и др.26К недостаткам технологии CORBA можно отнести сложность языкаописания компонентных интерфейсов IDL, а также довольно высокиетребования к корпоративным аппаратным вычислительным ресурсам [66], [252]и др.Архитектура J2EE (Java 2 Enterprise Edition, download.oracle.com/javaee)созданав1999г.ипредставляетсобойстандарткорпоративногораспределенного прикладного ПО на базе многозвенной (multi-tier) технологии сиспользованием ППО.