Серверы приложений. Топологии серверов приложений WebSphere Application Server для обеспечения высокой доступности. Выбор сервера приложений

«94 Лекция 6 Организация распределенных вычислений с использованием серверов приложений Серверы приложений (CП) являются одной из ключевых составляющих...»

Организация распределенных вычислений с использованием

серверов приложений

Серверы приложений (CП) являются одной из ключевых

составляющих IT-инфраструктуры значительной части современных крупных

предприятий. Если компания нуждается в интеграции ее

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

приложениям со стороны собственных сотрудников, партнеров и клиентов,

она рано или поздно сталкивается с необходимостью внедрения одного или нескольких серверов приложений.

Сервер приложений (англ. application server) - это программная платформа, предназначенная для эффективного исполнения процедур (программ, механических операций, скриптов), которые поддерживают построение приложений. Сервер приложений действует как набор компонентов, доступных разработчику программного обеспечения через API (интерфейс прикладного программирования), который определен самой платформой.

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

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

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



Поддержка транзакций. Транзакция – единица активности, во время которой последовательность изменений ресурсов (в одном или различных источниках) выполняется атомарно (как неделимая единица работы).

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

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

Эти компоненты могут представлять собой:

COM-объекты;

CORBA-объекты;

компоненты Enterprise JavaBeans.

В функции сервера приложений входят:

управление оптимизацией системных ресурсов (память, потоки и пр.);

обеспечение связи приложения с внешними ресурсами (включая базы данных, сети и другие приложения);

обеспечение качественной поддержки сервисов (доступность, надежность, безопасность, управление, производительность, масштабируемость);

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

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

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

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

–  –  –

Говоря о корпоративных решениях, нельзя не отметить проблему интеграции как различных приложений внутри одного предприятия, так и приложений, используемых на разных предприятиях. Одним из общепринятых способов ее решения является реализация функций приложений, к которым нужен доступ извне, в виде Web-сервисов XML, и большинство производителей СП, СУБД и средств разработки приложений реализовали поддержку Web-сервисов и связанных с ними технологий.

–  –  –

Реализация функций приложений, в виде Web-сервисов XML Технологии и стандарты Сегодня на корпоративном рынке доминируют две архитектуры серверов приложений:

NET (представлена только в исполнении Microsoft);

Java EE (ранее известная как J2EE), предоставляемая множеством компаний (мультивендорная).

Но при этом серьезную конкуренцию лидерам составляют новые программные модели, такие как Spring Framework, PHP, Ruby on Rails, Apex Code, Plain Old Java Object (POJO).

Серверы приложений могут быть доступны пользователям:

в виде продуктов, устанавливаемых собственно внутри компаний, в качестве облачных сервисов, предоставляемых провайдером.

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

Для оценки поставщиков какого-либо сегмента рынка ИТ, Gartner использует две линейные прогрессивные экспертные шкалы:

полнота видения (англ. completeness of vision), способность реализации (англ. ability to execute).

При этом, полнота видения откладывается на оси абсцисс, способность реализации - на оси ординат.

Каждый поставщик, таким образом, оказывается в одном из четырёх квадрантов плоскости, называемых:

лидеры (англ. leaders) - поставщики с положительными оценками как по полноте видения, так и по способности реализации, претенденты (англ. сhallengers) - поставщики с положительными оценками только по способности реализации, провидцы (англ. visionaries) - поставщики с положительными оценками только по полноте видения, нишевые игроки (англ. niche players) - поставщики с отрицательными оценками по обоим критериям.

Gartner называет магическим квадрантом конкретный анализ какого-либо сегмента рынка, с распределением поставщиков по указанным четвертям.

По мнению Gartner, СП могут применяться в трех основных сценариях:

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

проекты “массового рынка” - не очень сложные прикладные системы, создаваемые небольшими ИТ-компаниями. Здесь важны такие параметры, как низкая стоимость, простота развертывания, поддержки и управления, надежность. Функциональность, масштабируемость и производительность не столь существенны;

“систематично-ориентированные” проекты - реализация критически важных для бизнеса корпоративных систем, рассчитанных на долгосрочный период эксплуатации (не менее трех лет). Наряду с разнообразной функциональностью тут необходимы надежность, безопасность, управляемость, масштабируемость, производительность. Ё Ниже в магическом квадранте рассматриваются поставщики продуктов класса CП масштаба предприятия (Enterprise Application Server – EAS) - таких, которые могут применяться в третьем сценарии. При этом отмечается, что многие такие решения можно успешно использовать и в двух других вариантах.

Рисунок 39 – Магический квадрант для СП масштаба предприятия

Как видим из квадранта:

Во первых: существует довольно большое число игроков, 28 компаний, некоторые из которых предлагают решения Open Source (свободное ПО, т.е.

материалы, использованные для его создания, доступны по свободной/открытой лицензии).

Во-вторых: имеется ряд платформ, изначально ориентированных на вариант облачной вычислительной модели (в частности, нужно обратить внимание на Salesforce.com).

В-третьих: есть четко выделенная группа лидеров: IBM, Microsoft, Oracle, Red Hat (JBoss).

В-четвертых: видна острая конкурентная ситуация на рынке, которая предоставляет заказчикам широкий спектр выбора наиболее подходящих им решений. Gartner считает, что в ближайшее время здесь появятся новые серьезные игроки, такие как Google и Tibco, чьи решения (соответственно App Engine и Silver) находятся пока в режиме бета-тестирования.

–  –  –

Семейство ПО IBM WebSphere включает представительный набор EASпредложений (в т.ч. серию продуктов WebSphere Application Server -

WAS), который покрывает широкий диапазон требований заказчиков:

для “временно-ориентированных” проектов (WebSphere sMash), для массового рынка (WAS Community Edition, WAS Express), для масштабируемых корпоративных решений:

WAS Network Deployment, WebSphere Virtual Enterprise, CloudBurst Appliance, WebSphere Virtual Enterprise и др.

Некоторые из этих средств доступны в виде облачных сервисов IBM и Amazon Web Services EC2.

WAS-решения базируются в целом на стандартах Java EE и SOA, обеспечивая при этом поддержку разных моделей программирования.

Следует отметить, что IBM имеет в своем распоряжении мощные наборы средств разработки (Rational) и управления ИТ (Tivoli).

В то же время нужно сказать, что присутствие IBM на массовом рынке пока невелико. Выпущенный в середине 2008 года WebSphere sMash пока имеет относительно небольшую инсталлированную базу и весьма ограниченную поддержку со стороны третьих фирм. Продукты для облаков (WAS Hypervisor Edition, CloudBurst Appliance) появились относительно недавно, и пока в этой сфере IBM заметно отстает от лидеров. В целом Gartner отмечает, что стратегия IBM в области APaaS находится в ранней стадии своей реализации.

Microsoft

NET Framework вместе с Internet Information Server (оба являются интегрированными компонентами Windows Server) представляют собой полный набор функциональности EAS. Продукты семейства корпоративных серверов Microsoft Server System предназначены, как и другие СП, для создания и развертывания интегрированных корпоративных решений.

При относительно невысокой стоимости для этих серверов характерны:

поддержка XML,

–  –  –

По функциональности семейство серверов Microsoft Server System, в целом, заполняет практически все современные направления применения СП.

Все серверы семейства Microsoft Server System поддерживают управление COM-, COM+- и.NET-компонентами и доступны для операционных систем семейства Windows. Для других платформ эти продукты не выпускались и не выпускаются.

Из продуктов, входящих в семейство Microsoft Server System, к серверам приложений в традиционном понимании можно отнести:

сервер интеграции приложений Microsoft BizTalk Server, сервер сообщений и групповой работы Microsoft Exchange Server, сервер электронной коммерции Microsoft Commerce Server, масштабируемый сервер приложений для мобильной телефонии Microsoft Mobile Information Server, корпоративный портал Microsoft SharePoint Portal Server, сервер для управления информационным наполнением Web-сайтов Microsoft Сontent Manager Server;

сервер для управления крупными корпоративными проектами Microsoft Project Server.

Облачные предложения Microsoft реализованы в виде бета-версии Windows Azure Platform и недавно анонсированной технологии программируемой облачной платформы (xRM).

Преимущество Microsoft - огромная инсталлированная база Windows Server и обширное сообщество разработчиков ПО, что делает ее продукты стандартом де-факто на массовом рынке. При этом компания постоянно наращивает свое присутствие в сфере крупных корпоративных проектов. У компании есть весьма четкая стратегия реализации облачной модели вычислений.

Но из достоинств Microsoft вытекают и ее слабые стороны - поддержка одной ОС и использование продуктов от одного поставщика. Из-за традиционной фокусировки на массовом рынке компания постоянно запаздывает с реализацией важных технологических инициатив (например, XTP (Extreme Transaction Processing - форма обработки транзакций в информационных технологиях) и SOA). При этом у Microsoft появился ряд очень серьезных соперников (Google, Salesforce, VMware), также ориентированных на массовый рынок, но в конкурентной борьбе использующих иные деловые и технологические модели.

Основу EAS-предложений Oracle составляет JEE-семейство Oracle WebLogic Server (WLS), полученное в результате приобретения в 2008-м компании BEA Systems, и собственная разработка Oracle Application Server (она еще поддерживается, но в стратегическом плане не развивается).

Кроме того, в группу EAS-продуктов входят:

средство разработки Oracle JDeveloper, инструмент Oracle TopLink;

средство для мониторинга, администрирования и управления Oracle Enterprise Manager.

В результате приобретения Sun Microsystems компания пополнила свой EAS-арсенал еще и целым портфелем EAS-технологий (в частности свободную среду разработки NetBeans), благодаря чему заняла ведущую роль в Java-сообществе.

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

На текущий момент в Oracle слабо представлены EAS-решения, ориентированные на массовый рынок, хотя приобретение Sun GlassFish частично заполнило эту брешь в спектре ПО Oracle.

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

Red Hat

JBoss EAS - это JEE5-совместимый JBoss Application Server (c апреля 2013 WildFly). Он доступен для бесплатной загрузки (без технической поддержки) или в составе пакета для предприятий в виде JBoss Enterprise Application Platform с оплатой поддержки по подписке.

Кроме того, у Red Hat имеется набор JBoss Enterprise SOA Platform, в него входят сервер приложений и целый ряд технологий поддержки SOA, включая решение JBoss ESB, предназначенное для интеграции различных систем, в том числе несовместимых.

Имеется также EAS-предложение JBoss Communications Platform, ориентированное на использование в телекоммуникационной отрасли.

Для Web-проектов предлагается JBoss Enterprise Web Server, включающий сервер приложений Apache Tomcat.

В семейство ПО JBoss входит и целый ряд других продуктов и инструментов, в том числе средства разработки и управления ИТинфраструктурой.

Все это ПО, бесплатное или получаемое по подписке, распространяется по лицензиям LGPL 2.x или Apache Software и доступно в виде исходных кодов или объектных модулей.

JBoss EAS имеет отличную техническую репутацию на рынке, Red Hat является явным лидером среди поставщиков открытых EAS-решений, ее продукты имеют огромную инсталлированную базу и великое множество партнеров и пользователей. Фактически это единственное Open Sourceсемейство на ИТ-рынке, которое на равных конкурирует с предложениями ведущих проприетарных вендоров. Но бизнес-стратегия Red Hat, нацеленная на повышение прибыльности подразделения JBoss, иногда имеет результатом замедление внедрения инженерных инноваций. Компания явно отстает от конкурентов в освоении передовых технологий, таких как XTP, событийное управление и облачные вычисления.

Архитектуры серверов приложений

Java Platform, Enterprise Edition Java Platform, Enterprise Edition, сокращенно Java EE (до версии 5.0 - Java 2 Enterprise Edition или J2EE) - набор спецификаций и соответствующей документации для языка Java, описывающей архитектуру серверной платформы для задач средних и крупных предприятий.

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

Основная цель спецификаций - обеспечить масштабируемость приложений и целостность данных во время работы системы. JEE во многом ориентирована на использование её через веб как в интернете, так и в локальных сетях. Вся спецификация создаётся и утверждается через JCP (Java Community Process) в рамках инициативы Sun Microsystems Inc.

Популярности JEE также способствует то, что Sun предлагает бесплатный комплект разработки, SDK (Software Development Kit), позволяющий предприятиям разрабатывать свои системы, не тратя больших средств. В этот комплект входит сервер приложений GlassFish с лицензией для разработки.

Актуальная версия Java EE (JEE) имеет номер 7.0.

При переходе на версию 5.0 к набору спецификаций добавилось несколько новых технологий и изменилось название спецификации с J2EE (Java 2 Platform, Enterprise Edition), на Java Platform, Enterprise Edition, сокращённо Java EE.

–  –  –

EJB – Enterprise JavaBeans – спецификация технологии написания и поддержки серверных компонентов, содержащих бизнес-логику.

JPA – Java Persistence API – предоставляет возможность сохранять в удобном виде Java-объекты в базе данных.

Сервлет – класс, расширяющий функциональные возможности сервера.

Сервлет взаимодействует с клиентами посредством принципа запрос-ответ.

JSP - JavaServer Pages -технология, позволяющая веб-разработчикам легко создавать содержимое, которое имеет как статические, так и динамические компоненты. По сути, страница JSP является текстовым документом, который содержит текст двух типов: статические исходные данные, которые могут быть оформлены в одном из текстовых форматов HTML, SVG, WML, или XML, и JSP элементы, которые конструируют динамическое содержимое.

JSTL – JavaServer Pages Standard Tag Library – «стандартная библиотека тегов JSP». Она расширяет спецификацию JSP, добавляя библиотеку JSP тегов для общих нужд, таких как разбор XML данных, условная обработка, создание циклов и поддержка интернационализации.

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

JSF - JavaServer Faces - компонентный серверный фреймворк для разработки веб-приложений на технологии Java, предназначенный для облегчения разработки пользовательских интерфейсов (ПИ) для JEEприложений. Подход JSF основывается на использовании компонентов.

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

JAX-WS - Java API for XML Web Services - это прикладной программный интерфейс языка Java для создания веб-служб.

JNDI - Java Naming and Directory Interface - это Java API, организованный в виде службы каталогов, который позволяет Java-клиентам открывать и просматривать данные и объекты по их именам.

JMS - Java Message Service - стандарт промежуточного ПО для рассылки сообщений, позволяющий приложениям, выполненным на платформе Java EE, создавать, посылать, получать и читать сообщения.

JTA - Java Transaction API - Java API для транзакций. Определяет взаимодействие между менеджером транзакций и другими участниками распределенной транзакционной системы.

JAAS - Java Authentication and Authorization Service - реализация в языке программирования Java стандарта системы информационной безопасности PAM. Pluggable Authentication Modules (PAM, подключаемые модули аутентификации) - это набор разделяемых библиотек, которые позволяют интегрировать различные низкоуровневые методы аутентификации в виде единого высокоуровневого API. Это позволяет предоставить единые механизмы для управления, встраивания прикладных программ в процесс аутентификации.

JavaMail - это Java API, предназначенный для получения и отправки электронной почты с использованием протоколов SMTP, POP3 и IMAP.

JACC - Java Authorization Contract for Containers – это стандарт, который определяет контракты безопасности между модулями СП и политики авторизации. Эти контракты определяют способы установки, настройки и использования провайдеров авторизации в решениях доступа.

JCA - J2EE Connector Architecture – решение на базе технологии Java для соединения серверов приложений и корпоративных информационных систем в рамках решений интеграции корпоративных приложений.

JAF - JavaBeans Activation Framework - стандартное расширение для платформы Java, позволяющее воспользоваться стандартными услугами:

определить тип произвольного фрагмента данных; инкапсулировать доступ к нему; обнаружить доступные для него операции; и установить соответствующий боб (bean) для выполнения операции(й).

StAX - Streaming API for XML – интерфейс прикладного программирования для чтения и записи XML-файлов.

CDI - Context and Dependency Injection - Внедрение контекстов и зависимостей - помогают связать уровень веб-узлов и уровень транзакций платформы JEE. CDI - это набор услуг, которые, позволяют разработчикам использовать JavaBeans с JSF в веб-приложениях.

Microsoft.NET Framework

NET Framework - программная платформа, выпущенная компанией Microsoft в 2002 году. Основой платформы является общеязыковая среда исполнения Common Language Runtime (CLR), которая подходит для разных языков программирования. Функциональные возможности CLR доступны в любых языках программирования, использующих эту среду.

Считается, что платформа.NET Framework явилась ответом компании Microsoft на набравшую к тому времени большую популярность платформу Java компании Sun Microsystems (ныне принадлежит Oracle).

Хотя.NET является патентованной технологией корпорации Microsoft и официально рассчитана на работу под операционными системами семейства Microsoft Windows, существуют независимые проекты (прежде всего это Mono и Portable.NET), позволяющие запускать программы.NET на некоторых других операционных системах.

Архитектура.NET Программа для.NET Framework, написанная на любом поддерживаемом языке программирования, сначала переводится компилятором в единый для.NET промежуточный байт-код Common Intermediate Language (CIL) (ранее назывался Microsoft Intermediate Language, MSIL). В терминах.NET получается сборка, англ. assembly.

Затем код либо исполняется виртуальной машиной Common Language Runtime (CLR), либо транслируется утилитой NGen.exe в исполняемый код для конкретного целевого процессора. Использование виртуальной машины предпочтительно, так как избавляет разработчиков от необходимости заботиться об особенностях аппаратной части. В случае использования виртуальной машины CLR, встроенный в неё JIT-компилятор «на лету» (just in time) преобразует промежуточный байт-код в машинные коды нужного процессора. Современная технология динамической компиляции позволяет достигнуть высокого уровня быстродействия. Виртуальная машина CLR также сама заботится о базовой безопасности, управлении памятью и системе исключений, избавляя разработчика от части работы.

Microsoft начала разрабатывать.NET Framework в конце 1990-х под именем «Next Generation Windows Services» (NGWS). В 2000 году была выпущена первая бета-версия.NET 1.0.

–  –  –

Объектные классы.NET, доступные для всех поддерживаемых языков программирования, содержатся в библиотеке Framework Class Library (FCL). Ядро FCL называется Base Class Library (BCL).

Windows Forms – API, отвечающий за графический интерфейс пользователя.

ASP.NET(Active Server Pages) - технология создания вебприложений и веб-сервисов.

ADO.NET – технология, предоставляющая.NET-приложениям доступ к данным.

Windows Presentation Foundation (WPF) – система для построения клиентских приложений Windows с визуально привлекательными возможностями взаимодействия с пользователем. Разрабатываемые приложения могут быть автономными или запускаемыми в браузере.

Windows Communication Foundation (WCF) - программный фреймворк, используемый для обмена данными между приложениями. До выпуска в составе.NET Framework 3.0, был известен под кодовым именем Indigo. WCF позволяет создавать безопасные и надёжные транзакционные системы через упрощённую унифицированную программную модель межплатформенного взаимодействия. В WCF заложены принципы интероперабельности, которые позволяют организовывать работу с другими платформами.

Windows Workflow Foundation (WF) – технология для определения, выполнения и управления рабочими процессами (англ. workflow). (Рабочий процесс (поток) – 1. графическое представление процесса выполнения задачи и связанных с ним подпроцессов; 2. способ поступления информации к различным объектам, участвующим в процессе). WF ориентирована на визуальное программирование и использует декларативную модель программирования.

Windows CardSpace (WCS) – это способ идентификации пользователей при перемещении между ресурсами Интернета без необходимости повторного ввода имен и паролей. 15 февраля 2011 корпорация Майкрософт объявила об отмене Windows CardSpace 2.0 и о работе над замещающим ПО U-Prove.

Language Integrated Query (LINQ) - проект по добавлению синтаксиса языка запросов, напоминающего SQL (structured query language - «язык структурированных запросов»), в языки программирования платформы.NET.

ADO.NET Entity Framework (EF) - объектно-ориентированная технология доступа к данным. Предоставляет возможность взаимодействия с объектами как посредством LINQ (LINQ to Entities), так и с использованием Entity SQL.

Параллельный LINQ (PLINQ) – параллельная реализация LINQ to Objects.

PLINQ, реализующая полный набор стандартных операторов запроса LINQ в виде расширения для пространства имен T:System.Linq и имеющая дополнительные операторы для параллельных операций. PLINQ может значительно увеличить скорость запросов LINQ to Objects, эффективнее используя все доступные ядра на главном компьютере.

Task Parallel Library (TPL) - библиотека параллельных задач, представляющая собой сочетание общих типов и API, которые позволяют реализовывать параллелизм и согласованность операций. TPL является высокоуровневым каркасом параллельного программирования для.NET кода, позволяющим максимально использовать производительность многоядерных процессоров. TPL позволяет реализовать логический параллелизм (указать то, что потенциально может работать параллельно) вместо жесткого деления на потоки. Реальное распараллеливание библиотека производит во время выполнения в зависимости от доступных аппаратных средств.

Modern UI Runtime – дизайнерский стиль, ориентированный на типографское оформление интерфейса пользователя.

Task-based Asynchronous Pattern (TAP) – основанная на задачах асинхронная модель – схема программирования, направленная на создание асинхронных потоков в выполнении программы и управление ими.

Одной из основных идей Microsoft.NET является совместимость программных частей, написанных на разных языках. Например, служба, написанная на C++ для Microsoft.NET, может обратиться к методу класса из библиотеки, написанной на Delphi. Каждая библиотека (сборка) в.NET имеет сведения о своей версии, что позволяет устранить возможные конфликты между разными версиями сборок.

Среды разработки, поддерживающие.NET:

Microsoft Visual Studio (C#, Visual Basic.NET, Managed C++, F#)

–  –  –

Приложения.NET также можно разрабатывать в текстовом редакторе, просто вызывая компилятор из командной строки.

Mono Mono - проект по созданию полноценного воплощения системы.NET Framework на базе свободного программного обеспечения.

Основной разработчик проекта Mono - компания Xamarin (ранее Novell). После заключения Microsoft договорённости с Novell, платформа Mono была официально признана реализацией.NET на Unix-подобных операционных системах: Linux, Mac OS X и других. (Хотя Mono успешно работает и под Microsoft Windows). Однако договорённость касается только Novell и клиентов Novell; также технологии ASP.NET, ADO.NET и Windows Forms не были стандартизированы ECMA/ISO, и использование их в Mono находится под угрозой юридических претензий со стороны Microsoft, поэтому Mono предоставляет реализацию ASP.NET, ADO.NET и Windows.Forms, но в

Похожие работы:

«ГЛАВА VI КОСМЕТИЧЕСКИЕ СРЕДСТВА, АРОМАТИЧЕСКИЕ ВЕЩЕСТВА И БЛАГОВОННЫЕ КУРЕНИЯ Косметические средства Косметика так же стара, как человеческое тщеславие. В Египте употребление косметических средств может быть прослежено почти от того самого периода, от ко...»

«2013 – № 32 Судовые энергетические установки 185 УДК 656.61.052.484 Репетей В.Д., ОНМА СОВЕРШЕНСТВОВАНИЕ ОРГАНИЗАЦИИ УПРАВЛЕНИЯ ОПЕРАЦИЯМИ SAR Постановка задачи в общем виде. Конечной целью совершенствования управления системой является оптимизация, которая предполагает наличие целевой функции управления f(x) ограничений по её...»

«OCR: Библиотека святоотеческой литературы http://orthlib.ru (с. 299) Мёсzца тогHже въ }i-й дeнь. С™aгw ґпcла и3 є3ђлjста луки2. И# прпdбнагw їHсифа волоцкaгw. Слyжба є3гw2 пи1сана септeмвріа, f7 днS. На вечeрни п...»

«РЕКОМЕНДАЦИИ КЛАССНЫМ РУКОВОДИТЕЛЯМ Формы работы по преодолению вредных привычек обучающихся Для эффективности внеклассной работы в этом направлении можно и нужно использовать следующие формы работы: просмотр видеофильмов с последующим обсуждением, просмотр кинофильмов, которые...» Статья посвящается досудебному порядку реализации предусмотренных законом мер защиты патентных прав в Российской Федерации. Ключевые слова: административный, защита...»

Дорогие джаварашовцы, что я хочу рассмотреть в этой статье? Я просто хочу сделать небольшой обзор той части серверов приложений, которые заслуживают внимания хотя бы тем, что являются бесплатными и доступен их исходный код. Я буду исходить из того, что ваша система сходна с моей. У меня стоит Windows 7 64 бита, кроме того у меня стоит JDK 1.7 и JDK 1.8, а переменная окружения JAVA_HOME ссылается на последний из них. В моем случае это значит, что в JAVA_HOME прописан путь C:\Program Files\Java\jdk1.8.0_31. Чтобы у вас при повторении ниже описанного возникало как можно меньше вопросов типа «а почему у меня не получилось, может я что-то не так делаю?», я буду пытаться описывать каждое действие, которое я делал на своей машине. Начинаем…

Кастинг, т.е. отбор

Для начала нужно отобрать сервера приложений для нашего обзора. Для этого на википедии смотрим статью Comparison of application servers (англ., т.к. другой нет). Там есть табличка с кучей серверов приложений, но для нас интерес представляют только те, которые, с одной стороны, opensource, а с другой, поддерживают JavaEE по полной, т.е. столбец Java EE compatibility в этой таблице должен содержать строчку типа Full Platform . Из этого списка, в котором есть и WildFly , и JBoss сразу можно выкинуть последний, т.к. это просто старое название и старые версии WildFly . В результате получаем следующий список серверов, которые заслуживают нашего внимания:
  1. Glassfish (не проприетарный, а тот, что от сообщества glassfish.java.net , но который поддерживается корпорацией Oracle до такой степени, что если нужен javaEE SDK с сайта Oracle, то тебе впиндюрят и этот сервер приложений, иначе никак)
  2. (Red Hat) WildFly (бывший JBoss)
  3. (Apache) Geronimo
  4. (Apache) Tomcat (это лишь контейнер сервлетов, а не сервер приложений, но он является таким эталоном, на котором, если программа написана правильно, то она точно заработает. На других серверах программа может быть написана правильно с точки зрения JavaEE, но работать все равно будет не корректно или вообще не будет. Это я о Geronimo, о глюках которого можно говорить долго)
Теперь давайте накачаем этих серверов.
  • Для это будет сайт http://tomcat.apache.org .
  • Для Glassfish – сайт http://glassfish.java.net .
  • Для WildFly – сайт http://wildfly.org .
  • И, наконец, для – сайт http://geronimo.apache.org .
Где было можно выбрать между 32-х и 64-хбитными версиями, я выбирал архивчик под мою систему в 64 бита.

Установка

В плане установки все просто и для каждого из выбранных серверов установка – это просто распаковка архива. Я, например, создал папку AppServers на рабочем столе, куда и стал всё распаковывать.

Настройка

Настройку серверов начнем с настройки порта HTTP, на котором он будет работать. Потом пропишем себя как админа сервера. Для каждого из серверов есть свои особенности настройки. Для Tomcat. tomcat, далее папка conf , файл server.xml . Находим в этом файле число 8080 (http порт по умолчанию) и меняем его на что захотим. Я поставил 9713 . Чтобы прописать себя как админа сервера нужно, находясь в этой же папке, открыть файл tomcat-users.xml . В нем перед закрывающим тегом прописать следующий тег где в своей роли я прописал максимальное количество всяких админских прав (ролей). Это позволит мне деплоить приложения и через gui, и через удаленное подключение. Теперь запустим tomcat. Заходим в папку с распакованным tomcat, далее папка bin и запускаем файл startup.bat . Переходим в браузере по адресу http://localhost:9713 . Должно все заработать и мы увидим тигру.
Теперь давайте проверим наличие доступа в админку. Для этого переходим по адресу http://localhost:9713/manager , вводим выбранные логин и пароль и получаем доступ.
УРА! Можно временно отключить Tomcat, для этого достаточно закрыть консоль, в которой он работает. Для Glassfish. Заходим в папку с распакованным glassfish , далее в подпапку glassfish , далее подпапка domains , потом в папку domain1 . Заходим в папку config и находим файл domain.xml . Там также ищем число 8080 (это число вообще характерно в качестве http-порта по умолчанию для серверов приложений и контейнеров сервлетов) и меняем его на что захотим. Я поставил 9813 . Запустим glassfish. Заходим в папку с распакованным glassfish, далее в подпапку glassfish , потом в папку bin . Запускаем файл startserv.bat . В браузере вводим адрес http://localhost:9813 . На появившейся некрасивой странице с заголовком GlassFish Server находим ссылку go to the Administration Console и жмем на нее.
Далее, попав на красивую построенную на JSF страницу административной консоли, жмем пункт Change Administrator Password и вводим нужный нам пароль для пользователя admin , потом подтверждаем его и жмем кнопку Save .
При последующих входах в административную консоль нужно будет указывать логин admin и заданный пароль.
Теперь можно временно отключить Glassfish , для этого достаточно закрыть консоль, в которой он работает. Для WildFly. Заходим в папку с распакованным wildfly . Далее заходим в папку standalone , потом папка configuration , а в ней файл standalone.xml . Далее действуем по отлаженной схеме. Я поставил порт 9913 . Запустим сервер. Для этого перейдем в папку с распакованным wildfly . Далее заходим в папку bin и запускаем файл standalone.bat . Открываем браузер и вводим адрес http://localhost:9913 .
Жмем ссылку Administration Console для входа в админскую консоль (проще говоря, админку сервера приложений). Но не тут-то было, т.к. всплывает экран.
Этот экран сообщает нам, что админ не создан, и чтобы его создать нужно воспользоваться консольной утилитой add-user.bat . Ну, раз надо так надо. Возвращаемся в папку bin и запускаем эту утилиту. Вначале предложат выбрать тип пользователя, которого мы хотим создать. Надо выбрать пункт (a) , что будет означать, что нам нужен админ. Потом запрашивается имя этого пользователя Username и пароль Password . Пустым пароль быть не может, но односимвольным – пожалуйста. Утилита конечно поругается, но проглотит, если ей ответить yes на вопрос «Вы уверены?». Далее подтверждаем пароль повторным вводом на запрос Re-enter Password . Потом будут еще вопросы, но на них все просто отвечаем утвердительно и выходим из утилиты. Вернувшись на страницу выше, находим ссылку Try Again и жмем на нее. Теперь, введя данные только что созданного админа, можно попасть в админку.
Гасим сервер, закрыв окно консоли, через которую он был запущен. Для Geronimo. Заходим в папку с распакованным . Далее в подпапку var , потом в папку config , а в ней файл config-substitutions.properties . В этом файле описаны все используемые сервером приложений порты в удобном формате, но схема замены порта та же. Я поставил порт 10013 . Запустим сервер . Перейдем в папку с распакованным , потом в подпапку bin и запустим там файл startup.bat . Переходим на страницу http://localhost:10013 . Чтобы вы думали? Скорее всего, страницы там не будет. Почему? Все дело в том, последняя версия Geronimo (3.0) не может работать с последней версией JDK (1.8), поэтому если у вас стоит только она или пусть даже есть, скажем, 7-ая версия, но переменная окружения JAVA_HOME все равно ссылается именно на 8-ую, как у меня, то запуск сервера приложений не произойдет. Таким образом, для работы Geronimo нужно обязательно скачать JDK 1.7. Теперь допустим вы поставили 7-ой JDK, но не хотите менять значение переменной JAVA_HOME (в конце-то концов, другие программы на нее не жалуются, а значит пусть и работают с последней версией JDK). Что делать? Я советую открыть файл setjavaenv.bat , расположенный в той же папке bin , и найти в нем строку с меткой :okJdkFileCheck . После чего на следующей же строке добавьте переопределение переменной окружения. Например, так: set JAVA_HOME=C:\Program Files\Java\jdk1.7.0_75 Этой строки там нет, так что будьте добры прописать ее самостоятельно. Если у вас 32-битная система, то больше проблем быть не должно. Более того, если у вас 64-битная система и вы поставили JDK 1.7 именно в 64-битной комплектации, то у вас тоже все в шоколаде. А теперь представим, что мы решили извратиться и поставить на 64-х битную систему (у меня, например, Windows 7 64) JDK 1.7 из линейки в 32-ва бита. Что тогда? Тогда придется еще повозиться, потому как в 64-битной системе есть две папки для установки программ: Program Files и Program Files (x86) и если ничего не менять, то 32-хбитный JDK встанет именно в последнюю. Что в этом страшного? Да вроде ничего, однако, если переменная JAVA_HOME будет иметь в своем пути скобки (x86), то у Geronimo случается несварение. Почему? Черт его знает, особенно если учесть, что согласно данным с форумов, эту ошибку в 3-ей версии должны были исправить. Но ни фига подобного. Главное в этом деле не делать пи-пи, если индейцы не исправили, то мы поправим. Для этого есть два способа, которые я предпочитаю комбинировать, чтобы уж наверняка. Во-первых, опять идем а файл setjavaenv.bat и находим уже упомянутую метку :okJdkFileCheck . Под этой меткой есть строка if "%JRE_HOME%" == "" if exist "%JAVA_HOME%\bin\javac.exe" (set JRE_HOME=%JAVA_HOME%\jre) else set JRE_HOME=%JAVA_HOME% в которой для излечения Geronimo достаточно будет взять подстроку JRE_HOME=%JAVA_HOME%\jre в кавычки, т.е. заменить всю строку на if "%JRE_HOME%" == "" if exist "%JAVA_HOME%\bin\javac.exe" (set "JRE_HOME=%JAVA_HOME%\jre") else set JRE_HOME=%JAVA_HOME% . Кроме того, помните или знайте, что у папок типа Program Files в системе Windows 7 есть синонимы (например, для папки C:\Program Files (x86) синонимом будет папка C:\Progra~2 ). Поэтому если вы в файле setjavaenv.bat после метки :okJdkFileCheck установите следующее значение переменной JAVA_HOME set JAVA_HOME=C:\Progra~2\Java\jdk1.7.0_75 то у вас тоже заработает сервер под управление 32-х битного JDK в 64-х битной операционной системе. Как-то так… Ну, наконец-то, можно и запускать , вызвав startup.bat . Теперь проблем быть не должно. Переходим в браузере на страницу http://localhost:10013 . Слева вверху находим ссылку Console и жмем на нее.
Надо ввести админские логин и пароль. Сразу подскажу, что это пользователь system с паролем manager (значения по умолчанию).
Пройдя в саму консоль и проследовав по пунктам меню как на картинке ниже (выбрать радиобатон Advanced , потом выбрать Security > Users and Groups ), можно как сменить пароль для пользователя system , так и создать другого админского пользователя, а этого удалить.
Остановить сервер можно также простым закрытием окна консоли, в котором сервер был запущен.

Заключение

В этом обзоре я, по сути, просто провел установку и первоначальную настройку популярных серверов приложений и контейнера сервлетов Tomcat. За исключение Geronimo, остальные сервера были очень дружелюбны ко мне и проявили гостеприимство. В следующем посте я продолжу рассмотрение серверов приложений и сделаю 3-ий шаг на пути рассмотрения веб-сервисов, а именно, покажу как задеплоить описанный веб-сервис в эти сервера. Для этого мы создадим war-архив нашего веб-сервиса, и я наглядно покажу, что набор сторонних jar-ников, которые надо включать в этот архив для корректной работы сервиса, сильно меняется от сервера к серверу. Файл-сервер и сервер приложений очень похожи на первый взгляд. Но есть и отличия. Файл-сервер хранит данные и программы, а сервер приложений обрабатывает первые и выполняет вторые.

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

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

Предоставление сервисных услуг для программ.

Предоставление модели контейнера для приложений.

Обеспечение управления приложениями. Представление средств их разработки.

Соответствие стандартам и индустриальным спецификациям.

Обслуживание веб-страниц, поскольку в этом существует реальная востребованность.

Преимущества при работе с серверами приложений:

Целостность кода и данных. Размещение на выделенном сервере дает для всех клиентов гарантию доступа к модернизированному ПО. Исключается работа с данными из устаревших программ.

Централизованное управление. Все изменения в конфигурации прикладных программ выполняются централизованно.

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

Производительность. На сервер приложений можно возложить задачу по балансировке сетевого трафика. Результат – равномерное распределение нагрузки между физическими серверами системы.

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

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

Сервер приложений

Сервер приложений (англ. application server ) - это программная платформа (software framework), предназначенная для эффективного исполнения процедур (программ, механических операций, скриптов), которые поддерживают построение приложений. Сервер приложений действует как набор компонентов, доступных разработчику программного обеспечения через API (Интерфейс прикладного программирования), который определен самой платформой.

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

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

Преимущества серверов приложений

Целостность данных и кода

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

Централизованная настройка и управление

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

Безопасность

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

Поддержка транзакций

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

Примеры реализации

  • Под сервером приложений в случае Java EE подразумевается комплекс программ, реализующих концепцию Java EE и позволяющих запускать в себе Java EE приложения. К классу серверов приложений относятся такие продукты как Sun GlassFish, IBM WebSphere, RedHat JBoss Application Server, Apple WebObjects (англ. ) и др.
  • Zope, развитый сервер web-приложений.
  • Терминальные серверы, например поставляемые компанией Citrix

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

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

Сценарий (скрипт , script ) - программа , которая автоматизирует некоторую задачу, которую пользователь выполняет вручную, используя интерфейсы программы.

Стандарт CGI

Круг задач, решаемых Web-сервером, ограничен. В основном он сводится к поддержке НТТР-взаимодействия и доставке клиенту Web-документов. Любые "нестандартные" действия реализуются с помощью специальной программы, которая взаимодействует с веб-сервером и клиентом. Это взаимодействие подчиняется определенным правилам.

Основной набор таких правил - стандарт CGI (Common Gateway Interface - интерфейс общего шлюза), который определяет порядок запуска программы на компьютере-сервере, способы передачи программе параметров и доставки результатов ее выполнения клиенту. Программа , написанная по правилам CGI , называется CGI -сценарием ( script CGI ), хотя это не означает, что на сервере не может выполняться двоичный файл .

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

Выполнение любой программы (в том числе CGI -сценария) можно условно разделить на пять этапов.

  1. Запуск программы.
  2. Инициализация и чтение выходных данных.
  3. Обработка данных.
  4. Вывод результатов выполнения.
  5. Завершение программы.

Различия между CGI -сценарием и консольным приложением касаются первого, второго и четвертого этапов выполнения.

Каждый раз, когда веб-сервер получает запрос от клиента , он анализирует содержимое запроса и возвращает соответствующий ответ :

  • файл , находящийся на жестком диске, то сервер возвращает в составе ответа этот файл ;
  • Если запрос содержит указание на программу и необходимые для нее аргументы , то сервер исполняет программу и результат ее работы возвращает клиенту.

CGI определяет:

  • каким образом информация о сервере и запросе клиента передается программе в форме аргументов и переменных окружения ;
  • каким образом программа может передавать назад дополнительную информацию о результатах (например о типе данных) в форме заголовков ответа сервера.

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

и
. Не зная назначения атрибутов action и method , невозможно понять, как происходит вызов программы и передача параметров .

Значением атрибута action дескриптора

является URL файла, содержащего код CGI -сценария. Так, приведенное ниже выражение означает, что файл с кодом CGI -сценария находится на сервере www.myhp.edu в каталоге cgi-bin в файле script.рl .

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

  • Первый способ заключается в том, что при установке веб-сервера один из каталогов специально выделяется для хранения сценариев. Обычно такой каталог получает имя cgi-bin (или Scripts для веб-сервера IIS). В этом случае, если клиент запрашивает файл из каталога cgi-bin , сервер воспринимает такой запрос как команду на запуск сценария. Файлы из других каталогов интерпретируются как HTML-документы.
  • Второй способ использует расширение файла. При настройке сервера указывается, что файлы с определенными расширениями содержат коды сценариев.

Идентификация по расширению используется относительно редко. Чаще всего все сценарии помещаются в cgi-bin , /Scripts или в другой каталог, специально выделенный для их хранения.

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

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

НТТР/1.0 200 OK

Формирование информационных полей, входящих в состав заголовка, - задача сценария. Чтобы данные, переданные сценарием, были правильно интерпретированы клиентом, необходимо, чтобы в заголовке присутствовало как минимум поле Content-type . За заголовком должна следовать пустая строка. При отсутствии полей заголовка реакция браузера будет непредсказуемой. В подобных случаях браузер обычно пытается отобразить полученную информацию как текстовый файл .

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

Content-type: text/html ответ сценария ……………………

Обратите внимание на пустую строку после выражения Content-type: text/html . Она обязательно должна присутствовать в ответе, в противном случае клиент воспримет все последующие данные как продолжение заголовка.

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

Для вызова данного сценария достаточно включить в веб-страницу следующий фрагмент HTML -кода:

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

В большинстве случаев кроме кнопки Submit форма содержит другие интерактивные элементы, каждый из которых имеет имя ( атрибут NAME ) и значение ( атрибут VALUE , либо последовательность символов, введенная пользователем). Из имен элементов и их значений формируется строка параметров, которая имеет следующий формат.

имя=значение&имя=значение& . . . &имя=значение

Каждый параметр представляет собой имя управляющего элемента и его значение , разделенные знаком равенства, а несколько таких пар объединяют строку с помощью символа " & ". Если в состав имени или значения входит символ " & " или " = ", то подобные символы кодируются последовательность знака процента " % ", за которым следуют две шестнадцатеричные цифры, определяющие код символа . Так, например, последовательностью " %21 " кодируется восклицательный знак " !". Как правило, при передаче параметров трехсимвольными последовательностями заменяются все знаки, кроме латинских букв, цифр и символа пробела (последний заменяется знаком " + ").

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

  • Выделить из строки параметров пары имя = значение .
  • Выделить из каждой пары имя и значение .
  • В каждом имени и каждом значении заменить символы " + " пробелами.
  • Каждую последовательность из символа " % " и двух шестнадцатеричных и преобразовать в ASCII-символ.

Атрибут method дескриптора

имеет либо значение " GET ", либо значение " POST ". Значения " GET " и " POST " определяют два различных метода передачи параметров сценарию:

  • Если атрибут method имеет значение " GET ", строка параметров передается вместе с URL вызываемого сценария. Разделителем между URL и строкой параметров является символ " ?".
  • Если атрибут method имеет значение " POST ", строка параметров передается в теле HTTP-запроса.

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

Если атрибут METHOD дескриптора имел значение " GET ", строка параметр передается серверу в качестве значения переменной окружения QUERY_STRING .

При использовании метода POST данные доставляются сценарию по-другому. Они передаются через стандартный поток ввода (STDIN). Чтобы сценарий смог определить, сколько символов следует читать из стандартного ввода, веб- сервер устанавливает значение переменной окружения CONTENT_LENGTH , равным длине строки параметров.

Получив управление, сценарий в первую очередь должен выяснить, с помощью какого метода выполнялась передача параметров . Эта информация содержится в переменной окружения REQUEST_METHOD .

Таким образом, в простейшем случае, чтобы выполнить обработку строки параметров, достаточно знать назначение трех переменных окружения:

Сценарии

К основным достоинствам разработки приложений на стороне веб-сервера в форме сценариев можно отнести следующие:

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

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

В плане быстродействия сценарные языки можно разделить на:

  • Языки динамического разбора (например, command.com). Интерпретатор считывает инструкции из файла программы минимально требующимися блоками, и исполняет эти блоки, не читая дальнейший код.
  • Предварительно компилируемые (например Perl). Вначале считывается вся программа, затем компилируется либо в машинный код, либо в один из внутренних форматов, после чего получившийся код исполняется.

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

Понравилась статья? Поделиться с друзьями: