Лекция 8 Архитектуры web-приложений.

Web-приложения (web applications, часто их называют Интернет-приложениями, internet applications) представляют собой набор страниц, объединенных общей функциональностью. Все Web-приложения являются клиент-серверными, что, очевидно, определяется технологией построения Интернета. В приложениях обычно задействуются все вышеперечисленные технологии, от DHTML, исполняемом в клиентском браузере, до расширений Web-сервера. В настоящий момент Web-приложения используются как внутри предприятий в локальных сетях, так и в Интернете - это широко известные Интернет-магазины.

Архитектура Web-приложений Все Web-приложения можно условно разбить на три составные части: серверная часть, клиентское приложение и интерфейс. Серверную часть образует Web-сервер, возвращающий страницы приложения по запросам пользователя. Чаще всего эти страницы создаются динамически на основе информации, обрабатываемой приложением. Именно на создание страниц "на лету" направлены различные расширения Web-серверов, одно из которых - CGI - уже было ранее упомянуто.Клиентское приложение (браузер) последовательно запрашивает страницы с сервера, используя Dynamic HTML для управления интерфейсом и частичной обработки информации на компьютере клиента. Пользовательский интерфейс специально выделен отдельным пунктом, так как именно формированием клиентского интерфейса и работой с ним Web-приложения отличаются от привычных клиент-серверных приложений. В последнем случае клиентское приложение обменивается с сервером только данными, используя для формирования интерфейса ресурсы приложения. В Web-приложениях интерфейс практически полностью формируется на сервере, оставляя для исполнения клиентом только управление созданной страницей. Более того, существующие стандарты на браузеры накладывают дополнительную специфику на модель поведения приложения. В частности, два свойства, которые необходимо принимать во внимание при разработке приложения -наличие истории просмотра страниц и произвольный доступ к любой странице приложения по известному адресу. Последнее свойство обязательно должно учитываться в приложениях, использующих авторизацию пользователя. Другая серьезная проблема в разработке Web-приложения -отслеживание сессии конкретного пользователя. Дело в том, что по определению HTTP-протокол не имеет понятия текущего состояния (stateless), т.е. очередной запрос страницы абсолютно не зависит от предыдущих запросов и потому не требует уникального идентификатора. Для отслеживания последовательных запросов и идентификации пользователя используются так называемые cookies.

Лекция 9 Сервис–ориентированная архитектура (SOA).

Се́рвис-ориенти́рованная архитекту́ра (SOA, англ . service-oriented architecture) - модульный подход к разработке программного обеспечения, основанный на использовании распределённых, слабо связанных (англ. loose coupling) заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам.

Программные комплексы, разработанные в соответствии с сервис-ориентированной архитектурой, обычно реализуются как набор веб-служб, взаимодействующих по протоколу SOAP, но существуют и другие реализации (например, на базе jini, CORBA, на основе REST).

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

Архитектура не привязана к какой-то определённой технологии. Она может быть реализована с использованием широкого спектра технологий, включая такие технологии как REST, RPC, DCOM, CORBA или веб-сервисы. SOA может быть реализована, используя один из этих протоколов и, например, может использовать дополнительно механизм файловой системы для обмена данными.

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

Элементы сервис-ориентированной архитектуры, по: Dirk Krafzig, Karl Banke, and Dirk Slama. Enterprise SOA. Prentice Hall.

SOA также может рассматриваться как стиль архитектуры информационных систем, который позволяет создавать приложения, построенные путём комбинации слабо-связанных и взаимодействующих сервисов. Эти сервисы взаимодействуют на основе какого-либо строго определённого платформенно-независимого и языково-независимого интерфейса (например, WSDL). Определение интерфейса скрывает языково-зависимую реализацию сервиса.

Таким образом, системы, основанные на SOA, могут быть независимы от технологий разработки и платформ (таких как Java, .NET и т. д.). К примеру, сервисы, написанные на C#, работающие на платформах.Net и сервисы на Java, работающие на платформах Java EE, могут быть с одинаковым успехом вызваны общим составным приложением. Приложения, работающие на одних платформах, могут вызывать сервисы, работающие на других платформах, что облегчает повторное использование компонентов.

SOA может поддерживать интеграцию и консолидацию операций в составе сложных систем, однако SOA не определяет и не предоставляет методологий или фреймворков для документирования сервисов.

Языки высокого уровня, такие как BPEL, или спецификации, такие как WS-CDL и WS-Coordination, расширяют концепцию сервиса, предоставляя метод оркестрации, для объединения мелких сервисов в более обширные бизнес-сервисы, которые, в свою очередь, могут быть включены в состав технологических процессов и бизнес-процессов, реализованных в виде составных приложений или порталов.

Использование компонентной архитектуры (SCA) для реализации SOA - это область текущих исследований.

Облачные системы .

Облачные (рассеяные) вычисления (англ. cloud computing, также используется термин Облачная (рассеянная) обработка данных) - технология обработки данных, в которой компьютерные ресурсы и мощности предоставляются пользователю как Интернет-сервис. Пользователь имеет доступ к собственным данным, но не может управлять и не должен заботиться об инфраструктуре, операционной системе и собственно программном обеспечении, с которым он работает. Термин «Облако» используется как метафора, основанная на изображении Интернета на диаграмме компьютерной сети, или как образ сложной инфраструктуры, за которой скрываются все технические детали. Согласно документу IEEE, опубликованному в 2008 году, «Облачная обработка данных - это парадигма, в рамках которой информация постоянно хранится на серверах в интернет и временно кэшируется на клиентской стороне, например, на персональных компьютерах, игровых приставках, ноутбуках, смартфонах и т. д.».

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

значально World Wide Web (WWW) представлялась ее создателям как «пространство для обмена информацией, в котором люди и компьютеры могут общаться между собой» (см. Berners-Lee, T. WWW: Past, present, and future. Computer 29, 10 (Oct. 1996), pp. 69-77). Поэтому первые Web-приложения представляли собой примитивные файловые серверы, которые возвращали статические HTML-страницы запросившим их клиентам. Таким образом, Web начиналась как документо-ориентированная сеть.

Следующим этапом развития Web стало появление понятия приложений, которые базировались на таких интерфейсах, как CGI (или FastCGI), а в дальнейшем - на ISAPI. Common Gateway Interface (CGI) - это стандартный интерфейс с серверами, позволяющий выполнять серверные приложения, вызываемые через URL. Входной информацией для таких приложений служило содержимое HTTP-заголовка (и тело запроса при использовании протокола POST). CGI-приложения генерировали HTML-код, который возвращался браузеру. Основной проблемой CGI-приложений было то, что при каждом клиентском запросе сервер выполнял CGI-программу в реальном времени, загружая ее в отдельное адресное пространство.

Появление Internet Server API (ISAPI) позволило не только решить проблемы производительности, которые возникали с CGI-приложениями, но и предоставить в распоряжение разработчиков более богатый программный интерфейс. ISAPI DLL можно было ассоциировать с расширениями имен файлов через специальную мета-базу. Эти два механизма (CGI и ISAPI) послужили основой создания первого типа Web-приложений, в которых, в зависимости от каких-либо клиентских действий, выполнялся серверный код. Таким образом, стала возможной динамическая генерация содержимого Web-страниц и наполнение Web перестало быть чисто статическим.

Интерфейс ISAPI - это особенность Microsoft Internet Information Server (о последней версии этого продукта вы можете прочесть в статье «Internet Information Services 6.0». ISAPI-приложения представляют собой динамические загружаемые библиотеки (DLL), которые выполняются в адресном пространстве Web-сервера. У других Web-серверов через некоторое время также появилась возможность выполнять приложения, реализованные в виде библиотек. В случае Web-серверов Netscape этот программный интерфейс назывался NSAPI (Netscape Server API). У довольно популярного Web-сервера Apache также имеется возможность выполнять Web-приложения, реализованные в виде библиотек; такие библиотеки называются Apache DSO (Dynamic Shared Objects).

Естественно, что при использовании как CGI-, так и ISAPI-приложений разработчики в основном решали одни и те же задачи, поэтому естественным шагом стало появление нового, высокоуровневого интерфейса, который упростил задачи генерации HTML-кода, позволил обращаться к компонентам и использовать базы данных. Таким интерфейсом стала объектная модель Active Server Pages (ASP), построенная на основе ISAPI-фильтра.

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

Вскоре после появления ASP были созданы и другие технологии, реализующие идею размещения внутри Web-страницы кода, выполняемого Web-сервером. Наиболее известная из них на сегодняшний день - технология JSP (Java Server Pages), основной идеей которой является однократная компиляция Java-кода (сервлета) при первом обращении к нему, выполнение методов этого сервлета и помещение результатов выполнения этих методов в набор данных, отправляемых в браузер.

Новейшая версия технологии Active Server Pages - ASP .NET, являющаяся ключевой в архитектуре Microsoft .NET Framework. С помощью ASP .NET можно создавать Web-приложения и Web-сервисы, которые не только позволяют реализовать динамическую генерацию HTML-страниц, но и интегрируются с серверными компонентами и могут использоваться для решения широкого круга бизнес-задач, возникающих перед разработчиками современных Web-приложений.

В общем случае клиентом Web-сервера может быть не только персональный компьютер, оснащенный обычным Web-браузером. Одновременно с широким распространением мобильных устройств появилась и проблема предоставления Web-серверами данных, которые могут быть интерпретированы этими устройствами. Поскольку мобильные устройства обладают характеристиками, отличными от характеристик персональных компьютеров (ограниченным размером экрана, малым объемом памяти, а нередко и невозможностью отобразить что-либо, кроме нескольких строк черно-белого текста), для них существуют и другие протоколы передачи данных (WAP - Wireless Access Protocol) и соответствующие языки разметки (WML - Wireless Markup Language, СHTML - Compact HTML и т.п.). При этом возникает задача передачи данных на мобильное устройство в соответствующем формате (и для этой цели существуют специальные сайты), либо, что представляется более удобным, происходит опознание типа устройства в момент его обращения к серверу и преобразование исходного документа (например, в формате XML) в формат, требующийся данному мобильному устройству (например, с помощью XSLT-преобразования).

Другим способом поддержки различных типов клиентов является создание «разумных» серверных компонентов, которые способны генерировать различный код в зависимости от типа клиента. Такой подход, в частности, реализован в Microsoft ASP .NET.

Другим направлением развития клиентских частей Web-приложений стало размещение некоторой части логики приложения (такой как проверка корректности вводимых данных) в самом Web-браузере. В частности, современные Web-браузеры способны интерпретировать скриптовые языки (VBScript, JavaScript), код на которых, как и ASP-код, внедряется в Web-страницу, но интерпретируется не Web-сервером, а браузером и соответственно выполняется на клиентском устройстве. Кроме того, современные браузеры способны отображать и выполнять Java-аплеты - специальные Java-приложения, которые пользователь получает в составе Web-страницы, а некоторые из браузеров могут также служить контейнерами для элементов управления ActiveX - выполняющихся в адресном пространстве браузера специальных COM-серверов, также получаемых в составе Web-страницы. И в Java-аплетах, и в элементах управления ActiveX можно реализовать практически любую функциональность.

Отметим, что с ростом объема используемых данных и числа посетителей Web-сайтов возрастают и требования к надежности, производительности и масштабируемости Web-приложений. Следующим этапом эволюции подобных приложений стало отделение бизнес-логики, реализованной в Web-приложении, а нередко и сервисов обработки данных и реализации транзакций от его интерфейса. В этом случае в самом Web-приложении обычно остается так называемая презентационная часть, а бизнес-логика, обработка данных и реализация транзакций переносятся в сервер приложений в виде бизнес-объектов. В зависимости от типа сервера приложений подобные бизнес-объекты могут быть выполняющимися самостоятельно COM-серверами, CORBA-серверами, а также объектами COM+, выполняющимися с помощью служб компонентов Windows 2000, или объектами EJB (Enterprise Java Beans), исполняемыми сервером приложений, поддерживающим спецификацию J2EE (Java 2 Enterprise Edition). В качестве механизма доступа к данным подобные объекты могут использовать OLE DB, ODBC, JDBC (это зависит от того, как реализован бизнес-объект).

Нередко подобные бизнес-объекты предоставляют доступ к данным корпоративных информационных систем либо реализуют какую-либо часть их функциональности. Нередко они позволяют, например, интегрировать Web-сайт с CRM-системами (CRM - Customer Relationship Management - приложения для автоматизации и повышения эффективности процессов, направленных на взаимоотношения с клиентами, таких как обработка заказов, маркетинг, обслуживание) или с ERP-системами (ERP - Enterprise Resource Planning - приложения для автоматизации управления внутрихозяйственными процессами предприятия, такими как производство, финансы, снабжение, управление персоналом и др.), сохраняя в корпоративных системах сведения о посетителях сайта и предоставляя потенциальным клиентам сведения об имеющейся продукции для осуществления заказов.

Поскольку современный Internet - это не столько средство демонстрации присутствия компании на рынке или инструмент маркетинга, сколько инструмент ведения бизнеса, достаточно важными становятся задачи реализации организации через Internet таких взаимоотношений с клиентами, как продажа товаров и услуг. И здесь довольно важными становятся решения для электронной коммерции типа «предприятие-клиент» (B2C - business-to-consumer). Не менее важными становятся и задачи интеграции Web-приложений c данными и приложениями партнеров с целью реализации схемы «предприятие-предприятие» (B2B - business-to-business), позволяющей заключать торговые сделки между предприятиями, обмениваться каталогами товаров, проводить аукционы, создавать электронные торговые площадки.

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

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

Следующим шагом эволюции Web-приложений, помимо доступа к корпоративным данным и данным партнеров, стало получение доступа к корпоративным приложениям. Для решения этой задачи интеграции Web-приложений с внутренними информационными системами предприятий и с приложениями, обеспечивающими взаимодействие с клиентами и партнерами, используются специальные решения, называемые корпоративными порталами (подробнее о порталах, требованиях к ним, их особенностях и средствах их создания вы можете прочесть в статье «Web-порталы: назначение, преимущества, особенности и средства», опубликованной в данном номере нашего журнала).

Нередко частью портального решения являются средства управления информационным наполнением Web-сайта - ведь объем данных, доступных пользователям с помощью сайтов крупных компаний и порталов, сейчас таков, что управление этими данными «вручную» не представляется возможным. Подробнее об управлении информационным наполнением и средствах, с помощью которых оно осуществляется, вы сможете прочесть в статье «Управление информационным наполнением Web-сайтов».

Решение многих описанных выше задач, возникающих при создании современных Web-приложений, теперь начинает возлагаться на Web-сервисы - не зависящие от платформы, объектной модели и клиента программные компоненты, которые можно вызывать из клиентских Web-приложений (а также из самих Web-сервисов) через основанный на протоколе HTTP и языке XML протокол SOAP. Для описания Web-сервисов используется XML-подобный язык WSDL, а для организации реестров Web-сервисов, в которых разработчики и компании могут искать необходимые им сервисы, а также публиковать данные о своих сервисах - интерфейс UDDI. Более подробно о технологиях, лежащих в основах Web-сервисов, можно прочитать в статье «Технологии для Web-сервисов», опубликованной в этом номере.

Поддержка Web-сервисов стала одним из главных стратегических направлений для многих компаний, специализирующихся на выпуске серверов приложений, систем управления базами данных и средств разработки приложений. В публикуемой в данном номере статье «Платформы и средства создания Web-сервисов» мы подробно рассматриваем поддержку Web-сервисов в продуктах таких компаний, как BEA Systems, Borland, Hewlett-Packard, IBM, Microsoft, Oracle, Sun Microsystems и Sybase.

Заключение

В этой статье мы рассмотрели эволюцию архитектуры Web-решений, начиная от простейших хранилищ HTML-страниц и заканчивая современными корпоративными решениями, интегрированными с корпоративными информационными системами и информационными системами партнеров. Попутно мы обсудили задачи, возникающие на каждом этапе развития Web-приложений и технологии, решающие эти задачи, включая CGI, ISAPI, ASP, JSP, применение скриптовых языков, ActiveX и Java-аплетов, взаимодействие с серверами приложений и с базами данных, применение COM, CORBA и EJB, создание и применение Web-сервисов, основанных на XML. Мы также рассмотрели средства создания таких решений, а именно: корпоративные порталы, средства управления информационным наполнением Web-сайтов, приложения для электронной коммерции.

КомпьютерПресс 6"2002

При разработке современных информационных систем разработчики столкнулись с рядом проблем.

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

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

В настоящее время принципиально изменились технологии работы компаний в интернете. Теперь все ресурсы интернета размещены на дисках компьютеров, подключенных к сети, т.е. сетевых дисках. Это означает, что мы имеем дело с распределенными сетевыми ресурсами. В случае необходимости получить доступ к информации какого-либо компьютера можно с любого компьютера без обращения к серверу, воспользовавшись сетевыми службами, которые, в свою очередь, также находятся на удаленных сетевых ресурсах. Такие службы называются веб-сервисами. Речь идет о переносе модели «клиент - сервер» на сетевую модель, где сетевая служба сама становится объектом со своими функциями (методами) и атрибутами (свойствами). Вызывая методы этой службы из своих приложений, можно решать различные задачи. Тенденция к появлению специализированных интернет-сервисов (служб) может в будущем привести к тому, что практически отпадет необходимость локального программного обеспечения. Примером могут быть облачные среды разработки приложений IDE (Integrated Development Environment), которые дают возможность с мобильного устройства (смартфона или планшета) разрабатывать приложения на различных языках программирования. К таким IDE относятся, например, EclipseOrion, Cloud 9 IDE, eXoCloudIDE. Переход разработки в «облака» приводит к изменению интерфейса информационных систем - он становится веб-интерфейсом. Общий вывод, который следует из всего изложенного, такой: главное, чтобы концептуально система не устаревала, а на уровне программно-аппаратных средств постоянно происходили бы изменения, порождающие циклический реинжиниринг системы на базе современных технологий.

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

Такая архитектура возможна, если пользователи системы распределены географически в силу естественных причин. Например, основные потребители услуг доступны через интернет (в частности, различные справочные сервисы). Другой пример - система для внутреннего применения компании, ее пользователи также могут быть распределены, но по другим причинам. Сегодня особую актуальность приобретают концепции «мобильных работников» и «домашнего офиса», которые предполагают удаленную работу с основными корпоративными системами. То есть приложения класса ERP должны поддерживать веб-интерфейс. В настоящее время идет массированная миграция традиционных приложений и систем на вебинтерфейсы. Это может быть в виде дополнительных компонент или в виде полной переработки приложения. Так как сценарий работы с распределенными пользователями поддерживается любой системой с веб-интерфейсом, такие приложения называются вебприложениями.

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

Рассмотрим архитектуру таких веб-приложений на некотором абстрактном примере с использованием конкретных программных средств и выясним, какую роль выполняет каждый компонент (рис. 1.3). В клиентской части приложения специальные компоненты отсутствуют, используются веб-браузер и офисный пакет.

Рис. 1.3. Схема взаимодействия компонентов информационных систем с использованием интернет-технологий 1

С серверной частью все сложнее. Структурно она состоит из трех крупных компонентов:

• 1) веб-сервера (НТТР-сервера);
• 2) сервера базы данных (БД);
• 3) программного интерпретатора.

Веб-сервер является связующим звеном между веб-приложе- нием и клиентом. Он принимает запросы от клиента в виде набора данных по протоколу HTTP и возвращает в ответ документы на языке HTML и файлы, которые требуются дополнительно (картинки, листы стилей, другие объекты). При этом документы и другие файлы могут быть как статическими (находиться в файловой системе сервера), так и динамическими, т.е. сформированными программной частью. Наиболее распространенным веб-сервером является Apache , его используют для организации веб-узлов более чем в 70% случаев (а для русской части интернета этот показатель достигает 90%).

Кроме того, существуют разработки специальных веб-серверов для различных приложений, входящих в большие комплексы, например при использовании веб-приложений на технологиях компании Microsoft используют Internet Information Server (IIS). От выбора сервера зависит набор возможностей по языкам программирования, применяемым для разработки информационной системы.

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

Программный интерпретатор - это сердце системы. С помощью программного интерпретатора выполняется код, содержащий логику работы системы (алгоритмы). Поясним, почему этот элемент называется именно так. В веб-среде могут выполняться приложения, написанные на различных языках программирования. Их можно разделить на две группы: компилируемые (исполняемые как обычные программы на компьютере) и интерпретируемые (требующие интерпретатора для выполнения). При разработке веб-приложений используются оба этих типа, но особую популярность заслужили именно интерпретируемые языки: Perl, PHP, Ruby, Python. Интерпретируемые программы медленнее выполняются, но процесс их разработки значительно проще и быстрее. Учитывая постоянно повышающиеся требования бизнеса на скорость внедрения изменений в программные продукты (информационные системы), быстрый цикл разработки программ становится решающим фактором. Кроме того, мощность компьютеров постоянно возрастает, позволяя до определенного предела забывать о производительности приложений в угоду удобству и скорости разработки.

В приведенном на рис. 1.3 примере используется интерпретируемый язык Рег1 как мощный и подходящий для большинства проектов по созданию информационных систем с веб-интерфейсом. Программный код системы состоит из модулей и скриптов. Эти два компонента реализуют логику выполнения и основную функциональность системы.

Выбор языка Рег1 обусловлен следующими факторами:

• способность обрабатывать произвольные фрагменты текстовых данных разнообразными способами, включая обработку регулярных выражений. Это является важным фактором для программирования баз данных, поскольку большая часть хранящейся в базах данных информации имеет текстовую природу;
• сценарии на Рег1 оказываются значительно короче, чем эквивалентные программы на Си, и обычно переносимы на другие операционные системы, где программы Рег1 выполняются после небольших модификаций или вообще без них;
• среда Рег1 поставляется бесплатно.

Хотя транслятор с языка Рег1 реализован в виде интерпретатора, на задачах, которые связаны с обработкой текста, он работает не намного медленней, чем программы с компилятором на Си. Преимуществом языка Рег1 по сравнению с использованием языка Си является его в десятки раз более короткий код. Язык Рег1 хорош при создании небольших программ и сценариев с интенсивной обработкой текстов.

Сервер баз данных выполняет накопление структурированной информации, а также ее выдачу по запросам веб-приложения. При этом между программной частью системы и сервером баз данных могут использоваться различные интерфейсы (как стандартные, так и специальные). Не все языки программирования веб-приложений имеют надежные и функциональные интерфейсы к серверам баз данных различных разработчиков. От сервера баз данных зависят производительность приложения и функциональность с точки зрения данных. Например, развитые СУБД позволяют использовать распределенные хранилища данных и имеют мощные возможности по защите от сбоев и восстановлению после них. На рис. 1.3 представлена в качестве примера СУБД MySQL, имеющая серьезную репутацию в мире веб-разработок.

Центром клиентской части веб-приложения является браузер. Любой компьютер, подключенный к интернету, содержит программу-браузер, через которую можно начать работу с веб-прило- жением. Однако существует проблема совместимости веб-прило- жений с браузерами и операционными системами. Для браузеров это выражается в некорректном отображении и некорректной работе элементов управления. Для операционных систем - это возникновение требований к установке дополнительных модулей (расширений, плагинов).

Проблема некорректного отображения обусловлена тем, что совместимость браузеров с международными стандартами не является полной, т.е. при создании HTML-кода страниц и приложений нужно учитывать особенности каждого из числа основных веббраузеров, используемых на рынке (MS Internet Explorer, Chrome, Opera, FireFox, Safari). При этом нет гарантии, что протестированное на основных видах браузеров приложение будет корректно работать на других, более редких, продуктах.

Смысл проблемы некорректной работы элементов управления состоит в том, что в большинстве браузеров предусмотрена установка расширений (дополнительных модулей, называемых плагинами). Некоторые веб-приложения построены таким образом, что требуют наличия тех или иных расширений браузера для своей работы. В мире веб-сайтов характерный пример - это Flash-объекты (анимированные мини-приложения с расширенными возможностями). До недавнего времени поддержка Flash в операционной системе Linux оставляла желать лучшего, поэтому сайты и приложения, построенные с использованием технологии плагинов, не могли там работать.

Использование мобильных устройств. В настоящее время с появлением мобильных устройств клиентом веб-сервера может быть не только персональный компьютер, оснащенный обычным веббраузером, но и собственно мобильное устройство. Мобильные устройства обладают характеристиками, отличными от характеристик персональных компьютеров. Они имеют ограниченного размера экран, малый объем памяти, а нередко и невозможность отобразить что-либо, кроме нескольких строк черно-белого текста. В настоящее время для них существуют другие протоколы передачи данных, например WAP (Wireless Access Protocol ), и соответствующие языки разметки, например, WML (Wireless Markup Language)

и CHTML (Compact HTML). Для передачи данных на мобильное устройство соответствующего формата используются специальные сайты, поддерживающие WAP и WML. Наиболее перспективными являются приложения, которые в зависимости от типа клиента умеют генерировать тот или иной код. Именно такой подход реализован в технологии Microsoft ASP.NET.

Разделение бизнес-логики и интерфейса. С ростом объема используемых данных и числа посетителей сайта возрастают и требования к надежности, производительности и масштабируемости веб-приложений. Для удовлетворения указанных требований бизнес-логику, которая реализована в веб-приложениях, отделяют от интерфейса приложения и переносят на сервер приложений в виде независимых бизнес-объектов, которые могут быть реализованы в одной из известных технологий: СОМ, Microsoft.NET и др. Часто такие бизнес-объекты реализуют какую-либо часть функциональности информационной системы (не конкретной системы, а предоставляют модуль или часть модуля, которые можно «вживлять» в любую информационную систему). Такие бизнес-объекты могут представлять веб-сервисы.

Как было сказано ранее, практически все бизнес-приложения, разрабатываемые в настоящее время, являются распределенными. На рис. 1.4 представлена схема взаимодействия сайтов в интернете с использованием распределенного веб-приложения.

• См.: Весь Рунет как на ладони: статистика доменов.ш, .рф и.su на StatOnline.