Архитектура современных Web-приложений. Архитектурные особенности проектирования и разработки веб-приложений

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

Изначально World Wide Web (WWW) представлялась ее создателям как "пространство для обмена информацией, в котором люди и компьютеры могут общаться между собой". Поэтому первые Веб-приложения представляли собой примитивные файловые серверы, которые возвращали статические HTML-страницы запросившим их клиентам. Таким образом, Веб начиналась как документо-ориентированная.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обобщая вышесказанное можно выделить основные особенности веб-архитектуры :

отсутствие необходимости использовать дополнительное ПО на стороне клиента – это позволяет автоматически реализовать клиентскую часть на всех платформах;

возможность подключения практически неограниченного количества клиентов;

благодаря единственному месту хранения данных и наличия системы управления базами данных обеспечиваются минимальные требования для поддержания целостности данных;

доступность при работоспособности сервера и каналов связи;

недоступность при отсутствии работоспособности сервера или каналов связи;

достаточно низкая скорость Веб сервера и каналов передачи данных;

относительно объема данных – архитектура Веб систем не имеет существенных ограничений.

Схематически такую архитектуру (в трехзвенном варианте) можно представить, как показано на рис. 5.9.

Рис. 5.9. Архитектура Веб-приложений

В этой статье мы рассмотрим 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).

Основной идеей 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

Введение

Ниже перечислены три наиболее распространенных шаблона:

Простой Web-клиент - чаще всего применяется с приложениями Internet, где невозможно управлять конфигурацией клиента. Для клиента требуется только обычный Web-браузер, способный обрабатывать формы. Вся бизнес-логика выполняется на сервере.

Расширенный Web-клиент - Значительная часть бизнес-логики выполняется в системе клиента. Обычно клиент применяет для работы с бизнес-логикой динамический HTML, аплеты Java или элементы ActiveX. Обмен данными с сервером по-прежнему осуществляется по протоколу HTTP.

Web-доставка - Наряду с протоколом HTTP для поддержки распределенной системы объектов, включающей и клиент, и сервер, могут применяться такие протоколы как IIOP и DCOM. Web-браузер главным образом выступает как агент хранения и доставки объектов в распределенной системе.

Простой Web-клиент

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

Условия применения

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

Известные случаи применения

С этим шаблоном работают большинство приложений электронной коммерции в Internet, поскольку было бы неправильно закрывать доступ клиентам только потому, что у них недостаточные вычислительные мощности. Электронная коммерция старается угодить всем покупателям, поскольку деньги в кошельке пользователя Commodore Amiga ничем не хуже денег пользователя Windows NT.

Структура

Основные компоненты архитектуры тонкого Web-клиента размещаются на сервере. Можно сказать, что такая архитектура - это минималистическая архитектура Web-приложения. Ее основные компоненты таковы:

Браузер клиента - Любой браузер с поддержкой форм HTML. Браузер работает как универсальное устройство пользовательского интерфейса. В архитектуре простого клиента он выполняет еще функции по отправке и приему cookie. Пользователь просматривает в браузере страницы Web. Эти страницы включают в себя все компоненты пользовательского интерфейса, текст и элементы управления, которые браузер отображает на экране монитора. Все взаимодействие пользователя с системой идет через браузер.
Web-сервер - Главный партнер для браузера клиента. Web-сервер принимает запросы браузера и отправляет статические Web-страницы или страницы, обработанные на сервере. В зависимости от запроса Web-сервер может выполнить также операции на сервере. Если запрашивается страница, которая содержит сценарий CGI, ISAPI или NSAPI, то Web-сервер передает управление интерпретатору сценариев или исполняемому модулю. В любом случае результатом будет страница HTML, которую отобразит браузер.

Соединение HTTP - Это наиболее употребительный протокол обмена данными между браузером клиента и Web-сервером. Этот элемент представляет тип связи между клиентом и сервером без установления соединения. Всякий раз, когда клиент отправляет информацию на сервер, устанавливается новое соединение. Соединения HTTP могут быть защищенными посредством Secure Sockets Layer (SSL). В таких соединениях информация, передающаяся между клиентом и сервером, зашифровывается с помощью механизмов открытого и личного ключей.

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

Сценарий - Web-страница, для которой сервер выполняет дополнительную обработку. Обычно эти страницы содержит фрагменты на языках сценариев (Active Server Pages, Java Server Pages, Cold Fusion) и передаются фильтру на сервере приложений или исполняемому модулю (ISAPI или NSAPI). Такие страницы могут работать со всеми ресурсами на сервере, в том числе компонентами бизнес-логики, базами данных и платежными системами.

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

На рисунке показана схема архитектуры простого Web-клиента.

Минимальная архитектура простого Web-клиента

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

В простом варианте сценарии на сервере обращаются напрямую к компоненту хранилища. Даже в таком варианте прямой доступ требует стандартных библиотек доступа к данным, например, RDO, ADO, ODBC, JDBC, DBLib. Поэтому сценарии должны знать о том, какая схема базы данных применяется. Сценарии создают запросы SQL и получают данные из базы данных. В небольших Web-приложениях этого бывает достаточно. Для более объемных и надежных систем оказывается целесообразным выделить бизнес-логику в отдельный блок.

Бизнес-логика реализуется в компоненте бизнес-объекта. Этот компонент обычно компилируется и выполняется на сервере приложений. Наличие такого архитектурного компонента, как бизнес-объект, обеспечивает возможность другим системам работать с ним, если применяется та же бизнес-логика. Например, для обработки запросов покупателей Internet-магазин может применять сценарии на сервер и архитектуру простого Web-клиента, но бухгалтерии этого будет недостаточно, и вместо этого будет применяться клиент-серверная система. При этом бухгалтерия будет работать с теми же бизнес-компонентами на сервере приложений, но клиентское программное обеспечение будет более функциональным.

Поскольку база данных используется в большинстве решений для бизнеса, между сервером и базой данных обычно устанавливается дополнительный компонент архитектуры. Он обеспечивает преобразование бизнес-объектов в запросы к базам данных. Этот уровень может быть реализован различными способами, и он не будет здесь обсуждаться.

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

С учетом этих компонентов логическая схема архитектуры простого клиента становится более полной. Она показана на рисунке.

Логическая схема простого Web-клиента

Большинство компонентов сервера Web-приложений могут быть найдены и для приложений, не основанных на Web. Схема и архитектура базовой программы Web-приложения мало чем отличается от схемы любой системы мейнфрейма или клиент-серверной. Web-приложения работают с базами данных и мониторами обработки транзакций (TPM) также, как другие системы. Например, технологии Enterprise Java Beans (EJB) и Microsoft Transaction Server (MTS) проектировались для Web-приложений, но они в равной степени применимы и в других архитектурах приложений.

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

Динамика

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

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

Страница может также передана для обработки исполняемому модулю, такому как ISAPI или NSAPI DLL. DLL - это скомпилированная библиотека, которая может загружаться для выполнения сервером приложений. Этот модуль может работать с теми же данными запроса (полями формы и параметрами), что и сценарии.

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

Выводы

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

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

Расширенный Web-клиент

Архитектура расширенного Web-клиента отличается от архитектуры простого Web-клиента применением сценариев на стороне клиента и активных объектов, ActiveX и аплетов Java. Шаблон расширенного Web-клиента был назван так потому, что клиент может выполнять часть бизнес-логики в своей системе, и тем самым выходит за рамки просто вместилища пользовательского интерфейса.

Условия применения

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

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

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

Известные случаи применения

Чаще всего сценарии на стороне клиента, аплеты, активные элементы и модули используются в Internet для создания расширенных пользовательских интерфейсов. Сценарии JavaScript применяются для изменения цвета или надписи кнопки или меню на страницах HTML. Аплеты Java и элементы ActiveX позволяют создавать управляющие элементы в виде иерархического списка.

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

Управляющий элемент ввода Microsoft применяется на некоторых сайтах для голосового управления и ввода команд в браузере для облегчения навигации по Web-сайту.

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

Структура

Обмен данными между клиентом и сервером, как и для простого клиента, осуществляется по HTTP. Протокол HTTP работает без установления постоянного соединения между клиентом и сервером. Информация передается только в запросах клиента. Это означает, что сценарии в клиенте, элементы ActiveX и аплеты Java могут взаимодействовать только с объектами в клиенте.

В архитектуре расширенного Web-клиента такие возможности браузера, как элементы ActiveX или аплеты Java применяются для выполнения бизнес-логики в клиенте. Элементы ActiveX - это компилируемые исполняемые программы, которые клиент может загрузить в браузер по HTTP. Элементы ActiveX по сути своей являются объектами COM и могут работать со всеми ресурсами клиента. Они могут взаимодействовать с самим браузером и со всей системой клиента. Поэтому обычно в Internet подлинность элементов ActiveX "заверяется" сторонними организациями.

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

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

Сценарии в клиенте - сценарии на JavaScript или Microsoft® VirtualBasic®, встроенные в страницы HTML. Браузер интерпретирует сценарий. W3C определил интерфейс HTML и объектную модель документа, применяемую браузером для работы со сценариями.

Документ XML - документ в формате eXtensible Markup Language (XML). Документы XML представляют данные безотносительно их форматирования для пользовательского интерфейса.

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

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

JavaBean - компонент Java, который реализует набор интерфейсов, позволяющих встраивать его в большие и сложные системы. Термин bean отражает его модульность и пригодность для одной определенной цели. Для чашки кофе требуется обычно несколько кофейных зерен, а не одно. ActiveX - это аналог JavaBean в системах от Microsoft.

На рисунке показана схема архитектуры расширенного Web-клиента.

Схема архитектуры расширенного Web-клиента

Динамика

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

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

Для применения аплетов Java и активных элементов их необходимо указать на странице HTML. Эти элементы могут работать независимо от сценариев страницы или управляться ими. Сценарии на странице HTML могут обрабатывать специальные события, которые отправляет браузер. Эти события могут указывать на окончание загрузки Web-страницы или на то, что пользователь переместил мышь в какую-то область страницы.

Сценарии работают с объектной моделью документа (DOM). Этот интерфейс стандартизирован W3C и предоставляет сценариям, аплетам и активным элементам доступ к содержимому страницы HTML. Microsoft и Netscape реализовали эту модель как динамический HTML (DHTML). DHTML - это не просто реализация интерфейса DOM, но также включает обработку событий, которые на момент написания этой книги не входили в состав спецификации DOM Level 1.

Объектная модель документа основана на ряде интерфейсов, предназначенных для обработки документов XML. XML - это гибкий язык, позволяющий использовать собственные теги. Интерфейс DOM позволяет сценариям клиента работать с документами XML.

Работа с XML как со стандартным механизмом обмена данными между клиентом и сервером обеспечивается специальными компонентами в клиенте. В клиенте могут быть установлены элементы ActiveX или аплеты Java для обработки и отправки документов XML. Например, аплет Java, встроенный в страницу HTML, может отправить запрос HTTP к Web-серверу, чтобы получить документ XML. Web-сервер по данным запроса определяет, что вернуть нужно не документ HTML, а документ XML. Аплет, работающий на странице HTML в клиенте, получает документ XML, анализирует его и взаимодействует с документом HTML в браузере для показа содержимого пользователю. Все эти действия выполняются в рамках одной и той же страницы HTML в браузере.

Выводы

Эта архитектура используется для создания реализаций, работающих в разных браузерах. Не все браузеры HTML поддерживают JavaScript или VirtualBasic Script. Элементы ActiveX могут работать только в системах Microsoft Windows. Даже если для работы используется браузер какой-то одной фирмы, реализация объектной модели документа может иметь свои особенности.

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

Web-доставка

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

Условия применения

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

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

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

Известные случаи применения

Web-сайт CNN Interactive - это один из наиболее загруженных новостных сайтов в сети. Большая часть его содержимого доступна для обычных браузеров как страницы HTML 3.2, но за кулисами Web-сайта работает сложная сеть CORBA, в которой участвуют браузеры, серверы и распределенные объекты. Distributed Computing опубликовал исследование этой системы.

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

Структура

Наиболее существенным отличием между архитектурой Web-доставки и прочими является способ связи между клиентом и сервером. Для прочих архитектур основной механизм - это HTTP, протокол без установки соединения, который связывает руки разработчику, когда дело доходит до обеспечения взаимодействия между пользователем и сервером. Значимые элементы архитектуры Web-доставки включают в себя уже перечисленные в разделе о простом клиенте, а также дополнительно следующие:

DCOM - Distributed COM - это протокол распределенных объектов Microsoft. Он позволяет объектам одной системы вызывать методы объектов другой системы.

IIOP - Internet Inter-Orb Protocol - это протокол OMG CORBA для взаимодействия распределенных объектов в Internet (или в любой сети TCP/IP).

RMI (JRMP) - Remote Method Invocation - это способ Java обеспечения взаимодействия с объектами в других системах. JRMP (Java Remote Method Protocol) - это встроенный протокол для RMI, но не единственный, который можно использовать. RMI может быть реализован с IIOP CORBA.

На рисунке показана схема архитектуры Web-доставки.

Схема архитектуры Web-доставки

Динамика

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

Основным преимуществом работы с браузером в этой распределенной системе является его способность автоматически загружать нужные компоненты с сервера. Новый компьютер может включиться в работу, просто войдя в сеть, если на нем установлен совместимый Web-браузер. Никакое другое программное обеспечение не требуется, сам браузер загрузит нужные компоненты в клиент. Компоненты будут устанавливаться в клиенте по мере необходимости. И аплеты Java, и элементы ActiveX, могут быть автоматически сохранены в клиенте. Когда эти компоненты активируются при загрузке соответствующей Web-страницы, они могут сразу включаться в асинхронный обмен данными с объектами на сервере.

Выводы

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

6 февраля 2015 в 10:12

Проектирование и разработка корпоративных web приложений

Анализ и проектирование систем ,
Разработка веб-сайтов

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

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

Рассмотрим отдельно задачу построения иерархической структуры работ. Каждое web-приложение можно представить в следующем виде:

Другими словами, каждое web-приложение отправляет http запросы на web-сервер для получения полезных данных. Программа под управлением web-сервера использует ту или иную модель для хранения данных. В современном мире чаще всего используются базы данных, SQL или NoSQL.

Формально каждое web-приложение можно разбить на 3 взаимно независимые части.

Модуль, который исполняется WEB-браузером. Это приложение может быть написано на любом языке, который поддерживает браузер. Чаще всего используется язык JavaScript, как наиболее поддерживаемый и имеющий большую библиотечную поддержку. Это очень важно, так как позволяет существенно экономить бюджеты проектов.
Модуль, исполняемый на серверной стороне под управлением web-сервера. Это приложение может быть написано на любом языке, интерпретацию которого поддерживает выбранный Вами web-сервер. Последнее время, часто, в качестве языка программирования выбирается язык Java. Этот язык также имеет серьезную библиотечную поддержку.
База данных. В этой области так же существует достаточно широкий выбор. Есть промышленные базы данных, такие как Oracle, DB2, PostgreSQL. Есть легкие базы данных, такие как MySQL. База данных выбирается основываясь на целях и области решаемых задач.

Возможные эталонные модели проектирования web-приложений.

При построении архитектуры web - приложения необходимо максимально уменьшить зависимость между структурными единицами. В общем случае приложение состоит из трех структурных единиц.

Модуль, который работает под управлением браузера.
Модуль, который работает под управлением web-сервера.
База данных.

Эти структурные единицы порождают два вида связей.

Связь между браузером и серверной частью.
Связь между серверной частью и базой данных.

Для достижения цели максимальной независимости между структурными единицами, необходимо чтобы каждая структурная единица оперировала только необходимым ей набором данных. Рассмотрим более подробно.

Браузер - это прикладное программное обеспечение для просмотра web страниц.

HTML – это стандартный язык разметки документов. Большинство современных web-браузеров способны интерпретировать язык HTML.

Web сервер - это программное обеспечение, которое способно принимать HTTP запросы от клиентов, обрабатывать их и отправлять ответ в соответствии со стандартом протокола.

База данных - это представленная в объективной форме совокупность самостоятельных материалов, систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью ЭВМ.(Wiki)

Минимизация зависимостей

Для минимизации зависимостей между «Браузером» и Web-сервером необходимо, чтобы язык разметки HTML был задействован только в браузере, а Web-сервер предоставлял интерфейс для получения необходимых данных для страницы.

Для решения этой задачи необходимо:

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

Наша диаграмма может быть преобразована в следующий вид:

Данная модель достижима двумя путями

Программа выполняемая «Браузером» написана на JavaScript и общается с Web-Сервером через AJAX, получая ответы в соответствие с определенным протоколом.
«Браузер» интерпретирует только HTML код, а преобразования происходят посредством XSLT преобразований на стороне Web-Сервера.

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

Взаимодействие Web-Сервера и Базы данных

Взаимодействие базы данных и web-сервера возможно организовать на основании двух принципиально разных сценариях:

Бизнес логика находится в базе данных.
Бизнес логика находится в коде web-сервера.

В первом случае база данных хранит данные и предоставляет интерфейс доступа к данным:

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

Программа для web-сервера является драйвером для доступа к бизнес-логике. Т.е она просто связывает Браузер с бизнес логикой, которая реализована в базе данных.

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

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

Иерархическая структура работ

На основании изложенного выше материала иерархическая структура работ примет следующий вид:

Модуль для «Браузера».
Модуль для Web-Сервера.
Модуль для Базы данных.
Протокол обмена между модулем «Браузера» и Web-Сервером.
Интерфейс взаимодействия между модулем «Браузера» и Web-Сервером.
Интерфейс взаимодействия между Web-Сервером и Базой данных.

Лекция 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 году, «Облачная обработка данных - это парадигма, в рамках которой информация постоянно хранится на серверах в интернет и временно кэшируется на клиентской стороне, например, на персональных компьютерах, игровых приставках, ноутбуках, смартфонах и т. д.».