Серверы приложений: Что такое сервер приложений? — Хабр Q&A

Серверы приложений | Сетевые технологии

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

Сервер приложений — это сервисная программа, которая обеспечивает доступ клиентов к прикладным программам, выполняющимся на сервере. Сервер приложений обычно выделяется как среднее звено (рис. 1) в трехуровневой клиент-серверной архитектуре (3-tier):

Модель «сервер приложений»

1. Первый уровень, интерфейсный, как правило, графический (GUI).
2. Средний уровень, исполнимый программный код, размещенный обычно на выделенном сервере.
3. Третий уровень, фоновый — базы данных. Сюда же относятся, унаследованные средства доступа к данным и управления транзакциями.

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

Бизнес-логика может быть реализована на стороне сервера как целиком (удаленный код), так и частично (распределенный код). В первом случае к серверу могут обращаться терминалы и «тонкие» клиенты и такое взаимодействие соответствует модели «сервер терминалов». «Толстые» и rich-клиенты могут получать компоненты серверного приложения и выполнять их на своей стороне (например javascript, апплеты, flash).

Мобильный софт

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

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

Клиенты могут взаимодействовать с приложениями через API сервера (Java-клиент <—> контейнер сервлетов <—> сервлет). Большую гибкость и универсальность представляет взаимодействие через сторонние сервисы, в первую очередь — через веб-сервер.

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

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

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

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

Реализации

По приведенным признакам в рассматриваемую категорию попадают, например, традиционные терминал-серверные системы, технология CGI, контейнеры Java-сервлетов и др.

Унаследованные решения

Серверы терминалов представляют среду для удаленного выполнения программ, в качестве которой выступает сама операционная система. Доступ к ним осуществляется по протоколам удаленного управления (telnet, ssh, RDP, VNC и т. п.) из клиентского ПО (эмулятор терминала, средства управления удаленным рабочим столом и т.п.). Управление запущенной программой выполняется через эмулируемый на клиенте пользовательский интерфейс (текстовый или графический) операционной системы. На серверной стороне взаимодействие программ с ОС реализуется через системные вызовы. Управление также осуществляется средствами операционной системы. Разработка может вестись на любом языке, доступном в конкретной ОС.

Общий шлюзовый интерфейс (CGI) — технология доступа к приложениям через веб-сервер. Отличия от сервера терминалов здесь в том, что пользовательский интерфейс предоставляется в виде веб-страниц. Запросы веб-клиентов, обращенные к программам, размещенным в выделенном каталоге (как правило cgi или cgi-bin) перенаправляются на их вход через стандартный поток ввода (stdin). Результаты выполнения в виде гипертекста приложение возвращает веб-серверу через stdout.

Серверы Java-приложений

Платформа Java является индустриальным стандартом, позволяющим создавать из унифицированных компонентов интероперабельные программные решения для самых разных систем, в которых может быть запущена виртуальная машина Java (JVM).

Контейнер сервлетов — один из архитектурных компонентов J2EE, представляющий окружение для выполнения сервлетов. Сервлет — это Java-приложение, выполняющееся на стороне сервера (в отличие от апплета). Контейнер сервлетов может работать как полноценный самостоятельный сервер, но чаще используется (интегрируется) совместно с другим серверным ПО. Обеспечивает обмен данными между сервлетом и клиентами, берёт на себя выполнение таких функций, как создание программной среды для функционирующего сервлета, идентификацию и авторизацию клиентов, организацию сессии для каждого из них.

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

Примером реализации контейнера сервлетов является Apache TomCat, который используется в таких серверах приложений как Apache Geronimo, JBoss, GlassFish, IBM WebSphere Application Server (WAS).

Другие решения

Компания Microsoft представляет собственные решения для поддержки бизнес-логики и сервисной инфрастуктуры на основе ОС Windows Server и технологии .NET Framework. Основным средством разработки является язык C#.

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

Для сценариев на языке PHP, широко используемом для создания веб-сайтов, компания Zend Technologies (разработчик самого языка PHP) создала сервер приложений Zend Server.

Серверы приложений: плюсы и минусы

Преимущества

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

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

Централизованное управление

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

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

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

Производительность

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

Общая стоимость владения

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

Недостатки

Централизация

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

Защита информации

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

Анатольев А.Г., 06.08.2013

Постоянный адрес этой страницы:

Сервер приложений — не пуп Земли? | Открытые системы. СУБД

Сначала были Файл-сервер и Принт-сервер, довольно быстро к ним добавился Почтовый сервер. Не успели мы как следует привыкнуть к Web-серверам, как судьба подкидывает нам новые испытания — изволь осваивать Сервер Приложений. Особая проблема возникает при переложении понятия на русский язык. Тут уже путаница становится просто невообразимой. Искушенный читатель может с досадой воскликнуть — «Э! Да что же тут нового? Это же обычная многозвенка: сервер приложений, сервер базы данных и клиент!» — и прекратить чтение. Однако, Сервер Приложений — это Федот, да не совсем тот.

Итак, начнем по порядку, чтобы и не столь искушенный читатель понял, что имеется в виду. Предмет наших размышлений — это Application Server или Сервер Приложений. Ныне модно в качестве предисловия давать рекламу наоборот — перечислять то, чего в написанном нет; то ли из ложной скромности, то ли следуя завету Микеланджело: убирать все лишнее. Поэтому вы не найдете в этой статье серьезного доказательного сравнения технических реализаций Серверов Приложений, описания методов и приемов работы с этими реализациями, примеров файлов, листингов и кусков кода — приведен лишь список источников, в которых можно все это отыскать. Здесь же займемся более общими, но не менее увлекательными вопросами — что такое Сервер Приложений, зачем это нужно, как это покупать и выбирать и как с этим работать. Предвижу недовольство читателей, которые убеждены в том, что их не пускают на «кухню» и, следовательно, в приготовленном кушанье будет намешано неизвестно что. Приведу краткие соображения, почему следует читать и писать не только сугубо технические статьи. Прежде чем готовить еду, надо определить что — суп или гарнир, легкий ужин или обед для званых гостей, надо составить меню, заготовить продукты, выработать план изготовления, а уже потом приступать к поварскому ритуалу. Какой этап важнее — на этот предмет существует известная сказка, в которой плотник, портной и кукольник спорят, кому должна принадлежать сделанная ими кукла. Насколько я помню, в сказке побеждал кукольник, поскольку именно он вдохнул в куклу жизнь. В этом смысле таким волшебником несомненно является программист-разработчик. Нимало не преуменьшая его роль, я все-таки замечу, что современные программные приложения всегда плод коллективной работы. Поэтому провал или даже неудовлетворительное выполнение любого промежуточного этапа могут безнадежно загубить все дело.

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

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

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

Раз уж мы ввели строительный термин — монолит, то приведем строительно-архитектурную параллель. Первая — монолитная эра, эра дольменов и кромлехов, отдельных решений, автоматизирующих конкретные производственные задачи заказчика. Опыта еще мало — каждое сооружение в некотором смысле произведение искусства. Вторая эра — однотипные поселения, каждое их которых характеризуется зaмком (сервером) и постройками попроще вокруг (клиентами). И если простые постройки не представляют большой архитектурной ценности, то замки — решения штучные и дорогостоящие. А переходим мы в эру массовой застройки, когда «строительство» программных приложений поставлено на поток. И сколько бы мы ни ругали такую застройку, именно этот способ позволяет обеспечить жильем — программными приложениями, всех желающих за разумную цену и в реальные сроки.

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

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

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

Итак, если со стороны бизнеса все красиво, как на затейливом персидском ковре, то зато на изнанке — уйма всяких узелков и зацепок. Последние годы мировое программное сообщество усиленно пытается внести порядок в эту изнанку, в чем, надо сказать весьма преуспело. Основная возможность здесь — стандартизация компонентов, приведение их к единой природе. Блоки здания должны быть сопрягаемы. Нити ковра должны быть из близких материалов. Идея здесь достаточно проста — внешние интерфейсы компонентов должны быть описаны в едином стиле — на одном и том же языке. Поэтому два известных на сегодняшний день стандарта, CORBA и COM+ создали свои варианты IDL — Языка Описания Интерфейсов. CORBA, COM+ и технология Java, которая, естественно, использует для описания интерфейсов язык Java, предлагают близкие подходы к методу взаимодействия компонентов. На основе описания внешних интерфейсов создаются прокси (заместители) для клиента и сервера, которые позволяют им связываться друг с другом в реальном времени. Прокси для клиента принято называть стабом, а прокси для сервера — скелетоном. (Мы договорились — я не претендую на изложение технологий, а только даю краткий взгляд на них. Поэтому, в частности, не касаюсь возможностей динамического взаимодействия компонентов в технологии CORBA, когда внешние интерфейсы не определены на момент компиляции системы и появляются дополнительные динамические элементы.)

После стандартизации интерфейсов, мировое компьютерное сообщество перешло на следующий уровень стандартизации — самих компонентов. Из рис. 3 понятно, что я имею в виду под следующим уровнем стандартизации — все дальше от «железа», все ближе — к пользователю. В технологии CORBA это:

• ССМ (CORBA Component Model)- компонентная объектная модель, компонентное развитие модели бизнеса ВОМ — Business Object Model;
• BOCA (Business Object Component Architecture) — принципы архитектуры компонентных систем, развитие OMA (Object Management Architecture) на вышележащий уровень стандартизации;
• CDL (Component Definition Language)- язык определения компонентов, развитие IDL.

Разработка этих стандартов продвигается, правда, не так быстро, как хотелось бы всем заинтересованным сторонам. Но признанным героем на поле стандартизации компонентов стала технология компании Sun — Enterprise Java Beans (EJB). Возможно причина ее успеха в том, что в «семейном кругу» одного языка программирования намного проще решить вопросы взаимодействия. Тем более языка молодого и резвого, который многие проблемы, такие как вызов удаленных методов (RMI — Remote Method Invocation), умеет решать сам. Не иcключено, что универсальные цели консорциума OMG, развивающего технологию CORBA, — объединить компоненты, написанные на разных языках программирования, функционирующие на разных системах и разных компьютерах в разных точках земного шара, являются в данном случае некоторым тормозом. В дальнейшем мы увидим как две технологии, сомкнувшись, отбросив амбиции, дают замечательный результат на радость всем заинтересованным сторонам.

Что же такое этот «бин» (beаn — боб) и почему, стремительно выскочив как джин из бутылки в компьютерный мир, он уже завоевал такую популярность? Если перевести определение Sun как можно ближе к оригиналу — то «это модель для создания и развертывания серверных компонентов многократного использования, написанных на языке Java.» Продолжим вместе с Sun расплетать косу этого определения, — «компоненты — это заранее разработанные куски программного кода, которые могут быть установлены в работающие прикладные системы». Если классы Java образуют компонентную модель для проектирования приложений в технологии Java, то Java Beans логически развивает эту модель на следующем уровне интеграции создания автоматизированных систем и абстрагирования от процесса программирования — стадии внедрения. По сути, это переход от разработки приложения под заказ из готовых программных компонентов к сборке из готовых ЕJB действующих компонентов. Если раньше дома складывали из кирпичей, то теперь — из комнат-секций. Cлово Enterprise в названии Enterprise Java Beans означает новую ступень технических задач, стоящих перед программными приложениями. Такие задачи привычны для приложений уровня Предприятия: поддержка распределенности, службы именования, транзакций, безопасности, уведомлений-сообщений, долговременного хранения, и т.д. Неудивительно, что этот список напоминает список Служб технологии CORBA.

С точки зрения разработки, EJB представляют собой Java-классы специального типа вместе с описателем-паспортом бина и параметрами среды функционирования, которые бин умеет обрабатывать. Описатель бина (Deployment Descriptor) в свою очередь представляет собой XML-файл, в котором содержатся правила, связанные с управлением бином, например, права доступа пользователей к бину. Несколько бинов могут объединяться, образуя приложения, Java-апплеты и новые бины.

По технологии EJB бобы-бины размещаются в стручке — контейнере (рис. 4) На контейнер возложены обязанности по защите бинов и поддержке их взаимоотношений с внешним миром: регистрация-прописка объектов, обеспечение для них внешних интерфейсов, создание и разрушение реализаций этих объектов, охрана безопасности, управление их состояниями и координация транзакций. В технологии не определено, как конкретно должен быть реализован контейнер. Это могут быть как многопоточные процессы на отдельном сервере, в которых выполняются бины, так и законченные программные приложения, которые можно переносить или распределять между серверами и/или процессами. Клиентские бины обрабатываются внутри виртуальных контейнеров, таких как Web-страницы, формы, составные документы, и т.д.

В технологии определены два основных типа бинов. Session Beans — сеансы клиент-серверного взаимодействия отрабатывают действия клиента, например, запись в базу данных, выполнение вычислений, и т.д. Это окна клиента в мир программных приложений. Они, в свою очередь, также бывают двух типов:

• Stateless session — не умеют сохранять свое состояние и существуют только на протяжении текущего сеанса. В случае сбоя сеанс не может быть восстановлен;
• Stateful session — сохраняют свое состояние; сеанс может быть восстановлен.

Entity Bean — компоненты объектного представления данных, размещаемых в хранилище. Entity Bean транзакционны и восстанавливаемы. Каждая их реализация имеет уникальную метку, называемую «первичным ключом» (Primary Key) по аналогии с таблицами баз данных. В свою очередь эти бины делятся на две группы по способу определения где, в каком хранилище и как хранятся данные:

• Bean-Managed Persistence — самостоятельные бины, управление хранением осуществляется на уровне бинов;
• Container-Managed Persistence — «опекаемые» бины, чьим хранением заправляет контейнер.

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

• Home Interface — доступ к «домашним» службам бина, таким как начало или отбой для Session Bean или поиск Entity Bean. Этот интерфейс реализует все службы жизненного цикла компонента и позволяет контейнеру управлять и руководить его поведением;
• Remote Interface — доступ к бизнес-службам бина.

Клиентские приложения общаются с бинами через контейнер, который открывает наружу оба интерфейса бина: Home и Remote. С помощью первого открывается сеанс или находится нужный бин, а с помощью второго — осуществляется отработка действий клиента в Session или транзакционная механика обработки Entity.

Итак, повторим идею технологии с прикладной точки зрения. Прикладная бизнес-логика приложения делится на изолированные бизнес-объекты, каждый из которых реализуется в виде EJB. Они устанавливаются на Сервере Приложений или EJB Сервере и реализуют запрашиваемую логику для клиента (локального или удаленного). Давайте прямо сейчас, при первом появлении понятия Сервер Приложений в технологии Java, развеем непонимание, о котором уже говорилось в начале статьи. Написав оба слова, составляющие понятие, с заглавных букв, мы магическим образом преобразовали сервер приложений, реальную машину из корпуса, начинки и кабелей, в программное приложение.

Обратимся вновь к интерпретации Sun. Под Сервером Приложений в технологии Java понимается программное приложение, обеспечивающее оптимальную среду для выполнения EJB. Сервер Приложений занимается «коммунальным хозяйством» дома — программной системы. На его руках надзор за системными ресурсами, такими как процессы, потоки, память, связь с базами данных, сетевые отношения, выравнивание загрузки распределенных узлов. Кроме этого важнейшая обязанность Сервера Приложений заключается в предоставлении cle;, компонентам.

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

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

Стандарты продолжают захватывать все новые области информационных технологий. Но, если в сетевых технологиях стандарты полностью прижились, то в области программных приложений они еще только набирают силу. Понятны опасения специалистов использовать в собственных решениях «неправильный» стандарт, который зачастую, невзирая на грамотные технические решения, заложенные в его основу, не идет дальше прекрасных инициатив и не получает развития. Выбирая дорогу, всегда есть опасность оказаться в тупике. Именно поэтому стоит внимательно читать указатели (в смысле дорожные знаки) и прислушиваться к мнению мирового сообщества. Серверы Приложений уже сейчас имеют реализации от большинства крупных производителей программных систем (компании Inprise, Oracle, Sybase, Sun, BEA, Iona, IBM). Кроме того, в данной области архитектуры программных приложений пока не появилось ни одного достойного конкурента. Так что стиль пока единственный — Сервер Приложений.

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

«А надо ли городить огород?, — спросит недоверчивый читатель. — Зачем мне такое дополнительное ПО для моего сугубо конкретного программного приложения?»

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

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

Архитектор

Поставщик серверной платформы (EJB Server Provider) — специалист в области распределенной платформы и служб. Он предоставляет инфраструктуру разработки и среду выполнения для программных приложений.

Конструктор

Поставщик контейнеров (EJB Container Provider) — эксперт в области распределенных систем, системной безопасности и поддержки транзакций. Он обеспечивает системный уровень контейнеров, то есть системную оболочку для одного или более компонентов — Enterprise Bean.

Снабженец

Поставщик бизнес-компонентов (Enterprise Bean Provider) — аналитик в функциональной области, который реализует бизнес-компоненты как разработчик или подбирает готовые.

Монтажник

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

Прораб

Внедренец (Deployer) — специализируется в установке приложений. Он настраивает приложение на реальную среду.

Управдом

Администратор системы (System Administrator) — обеспечивает работоспособность системы на этапе эксплуатации.

Конечно, то, что компания Sun описала именно такие роли, не означает, что любой проект, связанный с Enterprise Java Beans обязательно требует одного и только одного указанного специалиста и именно такой состав комплексной бригады. Да и найти, скажем, готового поставщика контейнеров не так-то просто. Что совершенно необходимо — так это не упустить специфические для компонентного проекта моменты: выбор архитектуры и способы реализации системных служб, определение структуры и поведения контейнеров и проработка вопросов внедрения (развертывания).

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

Разочарованный читатель возмутится: «Зачем же нам объясняли про EJB, если в определении про них нет ни слова!» Попробую пояснить. Я намеренно привела универсальное определение Сервера Приложений, которое относится ко всем типам компонентов (CORBA, EJB, COM+). Серверы Приложений, зародившись внутри технологии EJB, оказались столь удобны, что достаточно уверенно продвигаются как единое решение для всех компонентных технологий. Реализации Серверов Приложений уже умеют работать с разными компонентами. В качестве примера приведу Application Server компании Inprise, который можно успешно использовать в среде компонентов EJB и CORBA. Другой наблюдаемый процесс — смыкание технологий Java и CORBA. С небольшой долей натяжки можно считать, что EJB могут иметь двойное гражданство, а именно представлять собой еще и CORBA-объекты. С моей точки зрения, поддержка CORBA является необходимым условием для конкурентности реализации Сервера Приложений. Ведь из всех перечисленных технологий только эта поддерживает Унаследованные Системы — функционально пригодные, но технически устаревшие. Если считать парк автоматизации современного предприятия или компании некоторым поселением — деревушкой или городком, создаваемая интеллектуальная компьютерная среда должна включать уже существующие постройки. Одинаково неправильно требовать сноса существующих зданий или не обращать на них внимания.

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

1. Интеграционный Сервер Приложений. (Application -integration-centric application server)

Основная задача такого Сервера — интеграция Бизнес-приложений в единую интеллектуальную среду. Такие Серверы особенно актуальны для организации приложений, связанных с задачами типа Supply Chain (Цепочки Поставщиков) и электронной коммерции. К таким серверам относятся реализации крупнейших поставщиков брокеров объектных запросов — компаний Inprise и Iona.

2. Информационный Сервер Приложений (Data-centric application server)

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

3. Обрабатывающий Сервер Приложений (Processing-centric application server)

Центральной заботой таких серверов является обеспечение специфической бизнес-логики. Например, сервер, реализующий распределенные вычисления, или сервер ERP-системы. К таким реализациям относится IBM Websphere.

4. Управляющий Сервер Приложений (Rules-based application server)

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

5. Сервер XML (XML Server)

Этот сервер представляет собой подмножество Информационного сервера, с той лишь разницей, что в качестве хранилищ данных выступают XML — документы. С другой стороны, такой сервер может представлять собой подмножество Интеграционного сервера, в котором в качестве механизма интеграции выбран XML. Известна реализация такого сервера от компании Bluestone Software.

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

Предвижу следующий вопрос читателей: — « А это уже где-нибудь работает?» Ответ — «Да!». Особенно востребованы Сервера Приложений во всем, что касается использования Internet. И за счет поддержки распределенности, возможностей выравнивания загрузки, отслеживания распределенных неоднородных транзакций, управления безопасностью и многих других своих возможностей. Именно эти интеллектуальные приложения находят в Серверах Приложений могучую опору.

Вскользь упомяну о следующих усилиях по созданию технологии компонентного программного обеспечения, снова связанных с Java. Это J2EE (Java 2 Enterprise Edition) — стандарт для многозвенных систем уровня предприятия, прикладная платформа, обеспечивающая взаимодействие Enterprise Java Beans, Java Server Pages, апплетов и сервлетов. рис. 5 в точности иллюстрирует то, как это выглядит у компании Sun.

Средства взаимодействия компонентов располагаются в нижней части рисунка. J2EE впервые стандартизовала выполнение родного для Java протокола удаленных вызовов методов через Internet — IIOP (Internet InterOrb Protocol). Таким образом, к сотрудничеству между CORBA и Java добавился еще один пункт. Серверные компоненты заключены в контейнеры, взаимодействующие с помощью специальных коннекторов. На уровне контейнеров задаются системные сервисы: Транзакций, Сообщений и Почты. На верхнем уровне находится API-интерфейс и Средства управления. Сказать об этой технологии в контексте Серверов Приложений меня вынудило не только то, что этот стандарт является логическим развитием технологии EJB, в которой впервые определился наш герой, но и то, что уже появляются Серверы Приложений, удовлетворяющие новому стандарту. Я имею в виду уже упоминавшийся Application Server (Inprise).

Но, стоп, боюсь, что Вы уже устали от обилия технологий и нагромождения стандартов? Если да — то тогда обратитесь к рис. 6, где я попыталась свести все воедино.

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

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

Об авторе

Марина Аншина — сотрудник отдела системной интеграции компании «ТопС, Системный Интегратор». С ней можно связаться по электронной почте по адресу: [email protected]

Моральный кодекс молодого строителя программного обеспечения — Сервера Приложений

Сервер Приложений обязан

1. Создавать сеансы взаимодействия клиента и сервера и управлять ими.
2. Защищать корпоративные данные от несанкционированного доступа.
3. Обеспечивать транзакционную целостность информации.
4. Распределять нагрузку между серверными приложениями.
5. Поддерживать требуемый уровень качества предоставляемых клиенту сервисов.
6. Отыскивать для клиента сервер требуемой функциональности.End Sub

Источники

http://www.inprise.ru — документация на русском языке по Inprise Application Server и возможность загрузки пробной версии
http://www.infoworld.com/sponsor/supplements/appdev3/appdev3.html
http://www.borland.com/appserver/
http://www.geocities.com/SiliconValley/Way/ 9006/mw.html
http://www.appserver-zone.com/
http://www.app-serv.com/
http://javaboutique.internet.com/articles/AppServers/
http://www.flashline.com/components/appservermatrix.jsp
http://www.iona.com/products/iPortal/appserver.htm
http://webreview.com/wr/pub/1999/02/26/appservers/index.html
http://www.beasys.com/products/weblogic/server/papers.html

Сервер приложений — Карта знаний

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

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

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

Источник: Википедия

Связанные понятия

Трёху́ровневая архитекту́ра (трёхзве́нная архитекту́ра, англ. three-tier) — архитектурная модель программного комплекса, предполагающая наличие в нём трёх компонентов: клиента, сервера приложений (к которому подключено клиентское приложение) и сервера баз данных (с которым работает сервер приложений).

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

Разработка приложений для мобильных устройств — это процесс, при котором приложения разрабатываются для небольших портативных устройств, таких, как КПК, смартфоны или сотовые телефоны. Эти приложения могут быть предустановлены на устройство в процессе производства, загружены пользователем с помощью различных платформ для распространения ПО или являться веб-приложениями, которые обрабатываются на стороне клиента (JavaScript) или сервера.

Одностраничное приложение (англ. single page application, SPA) — это веб-приложение или веб-сайт, использующий единственный HTML-документ как оболочку для всех веб-страниц и организующий взаимодействие с пользователем через динамически подгружаемые HTML, CSS, JavaScript, обычно посредством AJAX.

Веб-интерфе́йс — веб-страница или совокупность веб-страниц предоставляющая пользовательский интерфейс для взаимодействия с сервисом или устройством посредством протокола HTTP и веб-браузера. Веб-интерфейсы получили широкое распространение в связи с ростом популярности всемирной паутины и соответственно — повсеместного распространения веб-браузеров.

Упоминания в литературе

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

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

Если планируется, что разрабатываемый продукт будет развиваться, можно будет применить инкрементальную модель, хотя и не совсем подходящую, или спиральную модель. Ее преимущества в том, что она подходит для реализации постоянно развивающегося программного средства. А в нашем случае заказчик, вероятно, потом захочет добавить дополнительную функциональность: например, подключение систем электронных платежей (WebMoney, Яндекс. Деньги и т. д.), кредитных карт (нужен будет сервер приложений, осуществляющий верификацию данных пользователей, проверку наличия достаточных средств на карте и т. д.), отслеживание пути движения заказа, sms-информирование клиента и т. д. Однако спиральная модель может не очень хорошо подходить, если этап анализа рисков очень дорог. Но для нашего проекта можем обойтись упрощенным анализом рисков – спиральная модель будет приемлемым решением.

Связанные понятия (продолжение)

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

Се́рверное програ́ммное обеспечение (се́рвер, англ. server от to serve — служить; множественное число се́рверы, в разговорном языке также употребляется сервера́) — в информационных технологиях — программный компонент вычислительной системы, выполняющий сервисные (обслуживающие) функции по запросу клиента, предоставляя ему доступ к определённым ресурсам или услугам.

Пла́гин (англ. plug-in, от plug in «подключать») — независимо компилируемый программный модуль, динамически подключаемый к основной программе и предназначенный для расширения и/или использования её возможностей. Плагины обычно выполняются в виде библиотек общего пользования.

Виртуализация сетевых функций (англ. Network Functions Virtualization, NFV) — это концепция сетевой архитектуры, предлагающая использовать технологии виртуализации для виртуализации целых классов функций сетевых узлов в виде составных элементов, которые могут быть соединены вместе или связаны в цепочку для создания телекоммуникационных услуг (сервисов). Концепция виртуализации сетевых функций была предложена в 2012 году Европейским институтом телекоммуникационных стандартов (ETSI).

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

Контроллер доставки приложений англ. Application delivery controller — обычно размещается в центре обработки данных между брандмауэром и серверами приложений. Первое поколение контроллеров доставки приложений в основном занималось ускорением работы приложений и балансировкой нагрузки между серверами.

Вебтоп — интерфейс рабочего стола, встроенного в браузер или подобное приложение-клиент. Вебтоп объединяет в себе веб-приложения, веб-сервисы, клиент-серверные приложения, серверы приложений. Вебтоп представляет собой рабочий стол, похожий на Windows, Mac, или графический интерфейс на системах Linux или Unix, работающий внутри браузера как обычный веб-сайт. Внутри него, приложения, данные, файлы и настройки сохраняются на сервере и при необходимости передаются в вебтоп. Браузер, в таком случае, в…

Нативные приложения (англ. native application) — это прикладные программы, которые были разработаны для использования на определённой платформе или на определённом устройстве.

Насыщенное интернет-приложение (англ. rich internet application, RIA) — это веб-приложение, загружаемое пользователем через интернет, предназначенное для выполнения функций традиционных настольных приложений и работающее на устройстве пользователя (не на сервере).

Рутинг (англ. Rooting) — процесс получения прав суперпользователя root на устройствах под управлением операционной системы Android. Основными целями рутинга являются снятие ограничений производителя либо оператора связи, манипулирование системными приложениями и возможность запуска приложений, требующих прав администратора. Устройство, прошедшее процесс рутинга, называется рутованным. Аналогичный процесс для устройств на базе Apple iOS называется Jailbreak, а для устройств на базе Windows Phone…

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

О типе данных в БД см. BLOB.Блоб (от англ. binary linked object — объект двоичной компоновки) — объектный файл без публично доступных исходных кодов, загружаемый в ядро операционной системы. Обычно этот термин применяется только по отношению к модулям, загружаемым в ядро свободной или открытой операционной системы; термин редко применяется по отношению к коду, выполняющемуся не в режиме ядра, например, код BIOS, микропрограммный код устройств, программы, выполняющиеся в пользовательском режиме.

Подробнее: Блоб

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

Адаптер программного компонента — это тип программного обеспечения, которое логически располагается между двумя программными компонентами и устраняет различия между ними.

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

Веб-сервер — сервер, принимающий HTTP-запросы от клиентов, обычно веб-браузеров, и выдающий им HTTP-ответы, как правило, вместе с HTML-страницей, изображением, файлом, медиа-потоком или другими данными.

Установка программного обеспечения, инсталляция — процесс установки программного обеспечения на компьютер конечного пользователя. Выполняется особой программой (пакетным менеджером), присутствующей в операционной системе (например, RPM, APT или dpkg в Linux, Установщик Windows в Microsoft Windows), или же входящим в состав самого программного обеспечения средством установки. В операционной системе GNU очень распространено использование системы GNU toolchain и её аналогов для компиляции программного…

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

Текстовый пользовательский интерфейс, ТПИ (англ. Text user interface, TUI; также Character User Interface, CUI) — разновидность интерфейса пользователя, использующая при вводе-выводе и представлении информации исключительно набор буквенно-цифровых символов и символов псевдографики. Характеризуется малой требовательностью к ресурсам аппаратуры ввода-вывода (в частности, памяти) и высокой скоростью отображения информации. Появился на одном из начальных этапов развития вычислительной техники, при развитии…

Мультимедийный фреймворк (англ. multimedia framework) — фреймворк для работы с аудио- и видеоданными. Обычно состоит из системы плагинов (кодеков, фильтров, (де)мультиплексаторов, вывода на экран, работы с файлами и т. п.), которые можно соединить в граф для конвейерной обработки аудио/видео потока. Хорошие мультимедийные фреймворки имеют удобный API, работают и с файлами, и с сетевыми потоками, и позволяют пользователю устанавливать свои собственные плагины.

Дра́йвер (англ. driver, мн. ч. дра́йверы) — компьютерное программное обеспечение, с помощью которого другое программное обеспечение (операционная система) получает доступ к аппаратному обеспечению некоторого устройства. Обычно с операционными системами поставляются драйверы для ключевых компонентов аппаратного обеспечения, без которых система не сможет работать. Однако для некоторых устройств (таких, как видеокарта или принтер) могут потребоваться специальные драйверы, обычно предоставляемые производителем…

Служба маршрутизации и удаленного доступа (англ. routing and remote access service — RRAS) — интерфейс программирования приложений и серверное программное обеспечение компании Microsoft, которое позволяет создавать приложения, обеспечивающие маршрутизацию в сетях IPv4 и IPv6, а также взаимодействие между удаленными пользователями и сайтами посредством подключений виртуальной частной сети (VPN) или удаленного доступа. Разработчики также могут использовать RRAS для реализации протоколов маршрутизации…

Планировщик задач — программа (служба или демон), часто называемая сервисом операционной системы, которая запускает другие программы в зависимости от различных критериев, как, например…

Виртуальная файловая система (англ. virtual file system — VFS) или виртуальный коммутатор файловой системы (англ. virtual filesystem switch) — уровень абстракции поверх конкретной реализации файловой системы. Целью VFS является обеспечение единообразного доступа клиентских приложений к различным типам файловых систем. VFS может быть использована для доступа к локальным устройствам и файлам (fat32, ext4, ntfs), сетевым устройствам и файлам на них (nfs), а также к устройствам, не предназначенным для…

Дистрибути́в операцио́нной систе́мы — это форма распространения системного программного обеспечения. Наличие дистрибутивов вызвано тем, что форма программного обеспечения, используемая для его распространения, почти никогда не совпадает с формой программного обеспечения работающей системы, за исключением использования Live CD..

Загру́зчик (англ. loader) — в информатике, программа, отвечающая за загрузку исполнимых файлов и запуск соответствующих новых процессов. Обычно является частью операционной системы, но может быть и самостоятельной программой — к примеру, позволяющей операционной системе запускать программы, скомпилированные для других операционных систем (см. также: эмуляторы, WINE).

Пакетный файл (англ. batch file) — текстовый файл в MS-DOS, OS/2 или Windows, содержащий последовательность команд, предназначенных для исполнения командным интерпретатором. После запуска пакетного файла программа-интерпретатор (как правило, COMMAND.COM или cmd.exe) читает его строка за строкой и последовательно исполняет команды. Пакетный файл — аналог скриптовых файлов командной строки (shell script) в Unix-подобных операционных системах.

Система управления пакетами — набор программного обеспечения, позволяющего управлять процессом установки, удаления, настройки и обновления различных компонентов программного обеспечения. Системы управления пакетами активно используются в различных дистрибутивах операционной системы Linux и других UNIX-подобных операционных системах.

Зеркали́рование (англ. port mirroring, SPAN — аббр. от Switched Port Analyzer) — дублирование пакетов одного порта сетевого коммутатора (или VPN) на другом.

Библиоте́ка (от англ. library) в программировании — сборник подпрограмм или объектов, используемых для разработки программного обеспечения (ПО).

Мультимедиастанция (также медиастанция) — электронное устройство, универсальный проигрыватель, позволяющий просматривать и/или прослушивать мультимедиа, не прибегая к помощи персонального компьютера, используя телевизор и/или AV-ресивер. Может входить в состав домашнего кинотеатра.

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

Внутрисхемное программирование (англ. in-system programming, сокр. ISP, также in-circuit serial programming, ICSP) — технология программирования электронных компонентов (ПЛИС, микроконтроллеры и т. п.), позволяющая программировать компонент, уже установленный в устройство. До появления этой технологии компоненты программировались перед установкой в устройство, для их перепрограммирования требовалось их извлечение из устройства.

Маршрутизация (англ. Routing) — процесс определения маршрута следования данных в сетях связи.

Оболо́чка операцио́нной систе́мы (от англ. shell «оболочка») — интерпретатор команд операционной системы, обеспечивающий интерфейс для взаимодействия пользователя с функциями системы.

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

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

Клие́нт — это аппаратный или программный компонент вычислительной системы, посылающий запросы серверу.

Визуальное программирование — способ создания программы для ЭВМ путём манипулирования графическими объектами вместо написания её текста. Визуальное программирование часто представляют как следующий этап развития текстовых языков программирования. Наглядным примером может служить утилита Визуальный Pascal или Microsoft Visual Studio, где редактируются графические объекты и одновременно отображается соответствующий текст программы. В последнее время визуальному программированию стали уделять больше…

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

Выделенный сервер (англ. dedicated server) — вид хостинга, при котором клиенту целиком предоставляется отдельная физическая машина (в противоположность виртуальному хостингу). Обычно используется для запуска приложений, которые не могут сосуществовать на одном сервере с другими проектами или имеют повышенные требования к ресурсам.

Загрузчик операционной системы — системное программное обеспечение, обеспечивающее загрузку операционной системы непосредственно после включения компьютера (процедуры POST) и начальной загрузки.

Сервер последовательных интерфейсов, преобразователь или конвертер последовательных интерфейсов в Ethernet, консольный сервер, сервер терминалов (англ. Serial Device Server, Console server, Terminal server) — это сетевое устройство, которое передает данные между локальной сетью Ethernet и последовательным портом устройства (COM-портом, таким как RS-232/422/485).

Серверы приложений — это… Что такое Серверы приложений?



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

Сервер приложений (англ. application server) — сервер, исполняющий некоторые прикладные программы. Термин также относится и к программному обеспечению, установленному на таком сервере и обеспечивающему выполнение прикладного ПО. Сервер приложений — сервер, схожий по своей структуре с локальными компьютерами и использующие сетевой ресурс для хранения программы и данных. Функции сервера: хранения данных и кода программы. Функции клиента: обработка данных происходит исключительно на стороне клиента. Плюсы: низкая стоимость разработки; высокая скорость разработки; невысокая стоимость обновления и изменения ПО.

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

Ссылки

Wikimedia Foundation.
2010.

• Серверный кластер
• Серверный эмулятор

Смотреть что такое «Серверы приложений» в других словарях:

• серверы автоматизации — Автоматизация. Клиенты и серверы автоматизации. Автоматизация (ранее известная как OLE автоматизация – OLE Automation) – это одно из наиболее важных средств технологии ActiveX, позволяющее программно управлять объектами из других… …   Справочник технического переводчика

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

• Сервер приложений — сервер, предназначенный для выполнения прикладных процессов. Сервер приложений: взаимодействует с клиентами, получая задания; и взаимодействует с базами данных, выбирая данные, необходимые для обработки. См. также: Серверы приложений Сетевые роли …   Финансовый словарь

• Файловая сеть — В этой статье не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена. Вы можете отредактировать эту статью, добавив ссылки на авторитетные источники. Эта отметка… …   Википедия

• Proliant — Сервер HP ProLiant 380 G5 Proliant является торговой маркой серверов, которые были первоначально разработанны и продавались компанией Compaq. Proliant были одними из первых серверов x86 для продажи в стоичном исполнении, и лидировали на рынке сра …   Википедия

• SAP NetWeaver Application Server — (прежнее название SAP Web Application Server)  это компонент SAP NetWeaver, выполняющий функции сервера веб приложений для решений компании SAP. Включает в себя серверы приложений ABAP (прежнее название SAP R/3 Basis) и Java. Возможна… …   Википедия

• Softswitch — (англ. Softswitch  программный коммутатор)  гибкий программный коммутатор, один из основных элементов сети связи следующего поколения NGN. Softswitch в составе Сети Связи Общего Пользования …   Википедия

• Media Gateway — (MGW, или медиашлюз)  это устройство, осуществляющее преобразование между разделенными телекоммуникационными сетями. 3GPP для IMS архитектуры определяет MGW как элемент взаимодействия IP сети с PSTN или беспроводными сетями 2G, 2,5G, PLMN, а …   Википедия

• Медиашлюз — Media Gateway (MGW, или медиашлюз)  это устройство, осуществляющее преобразование между разделенными телекоммуникационными сетями. 3GPP для IMS архитектуры определяет MGW как элемент взаимодействия IP сети с PSTN или беспроводными сетями 2G …   Википедия

• WSGI — (англ. Web Server Gateway Interface, обычно произносится сообществом как «висги» или «виски»[1][2][3])  стандарт взаимодействия между Python программой, выполняющейся на стороне сервера, и самим веб сервером, например, Apache.… …   Википедия

Книги

• Python. Создание приложений. Библиотека профессионала, Уэсли Дж. Чан. Вы уже знаете язык Python, но хотите узнать больше? Намного больше? Погрузитесь в разнообразие тем, связанных с реальными приложениями. Книга охватывает регулярные выражения, сетевое… Подробнее  Купить за 4865 грн (только Украина)
• Python. Создание приложений. Библиотека профессионала, Чан Уэсли. Вы уже знаете язык Python, но хотите узнать больше? Намного больше? Погрузитесь в разнообразие тем, связанных с реальными приложениями. Книга охватывает регулярные выражения, сетевое… Подробнее  Купить за 3803 руб
• Eclipse:Платформа Web-инструментов: разработка Web-приложений на языке Java, Дей Нейси, Мандел Лоренс, Райман Артур. Платформа Web-инструментов (Web Tools Platform, WTP) Eclipse объединяет в себе все инструменты, необходимые для современных Web-разработок на Java. Платформа WTP — беспрецедентное средство… Подробнее  Купить за 599 грн (только Украина)

Другие книги по запросу «Серверы приложений» >>

Компьютеры и Интернет

Сервер приложений – это сервер, предназначенный для запуска определенных приложений. В основном, он может использоваться для запуска одного приложения. Если это приложение является тем, что поддерживает сетевую сеть и, следовательно, представляет собой массивное приложение, оно может охватывать все требования к ОЗУ и ПЗУ одного сервера.
Другая возможность заключается в том, что сервер используется для запуска определенных видов приложений. Например, у компании может быть несколько текстовых редакторов, электронных таблиц или настольных издательских программ, и все эти приложения могут находиться на одном типе сервера. Каждый, кто должен получить доступ к этим программам, будет заходить на сервер Desktop Publishing Server, например, для использования любой проектной программы, которую компания может порекомендовать и иметь под рукой.

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

Подобно муравьям и пчелам, которые имеют определенные роли в жизни, серверы приложений имеют определенные части, чтобы играть свою роль в общем муравейнике или улье компании. Как и во многих вещах, связанных с компьютером, существует более сложный пример. Oracle, один из основных разработчиков серверов, вышел с сервером J2EE (Java Platform Enterprise Edition). Огромное количество компаний во всем мире используют сервер J2EE, который может запускать очень мощные приложения, к которым можно получить доступ с нескольких компьютеров, подключенных к этому серверу в сети.

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

1. Серверы приложений: типы, назначение, функции.

Cерверы
приложений — это программное
обеспечение, предназначенное для
создания систем с выделенными сервисами
бизнес-логики. Чаще всего серверы
приложений выполняются под управлением
серверных операционных систем (различных
версий UNIX, Windows NT Server, Windows 2000 Server).
Компоненты, реализующие бизнес-логику
распределенного приложения и выполняющиеся
под управлением сервера приложений,
могут представлять собой COM- или
CORBA-объекты, Java-серверы либо Enterprise Java
Beans (EJB) — Java-компоненты. Многие серверы
приложений позволяют реализовать
приложения, устойчивые к сбоям. В
настоящее время серверы приложений
являются основой многих корпоративных
решений, например распределенных
приложений, реализующих следующие
схемы:

• «предприятие —
  потребитель» (B2C, business-to-consumer), такие как
  онлайновая продажа товаров, бронирование
  билетов и мест в гостиницах, услуги
  страхования;

• «предприятие —
  предприятие» (B2B, business-to-business), такие как
  виртуальные торговые площадки,
  позволяющие заключать торговые сделки
  между предприятиями;

• «предприятие —
  сотрудник» (B2E, business-to-employer), такие как
  корпоративные порталы.

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

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

Из
технологий, поддерживаемых современными
серверами приложений, следует в первую
очередь отметить средства интеграции
приложений, созданных на различных
платформах, в том числе поддержку
Web-сервисов, средства разработки
приложений, наличие продуктов
специализированного назначения,
основанных на данном сервере приложений
(например, средств управления информационным
наполнением), поддержку беспроводных
Лидерами рынка серверов приложений на
данный момент является компания IBM. Из
других наиболее известных продуктов,
относящихся к категории серверов
приложений, следует отметить серверы
компаний Oracle, Sun Microsystems, Borland, Sybase,.

Прикладные
протоколы

Протоколы
прикладного уровня служат для передачи
информации конкретным клиентским
приложениям, запущенным на сетевом
компьютере. В IP-сетях протоколы прикладного
уровня опираются на стандарт TCP и
выполняют ряд специализированных
функций, предоставляя пользовательским
программам данные строго определенного
назначения. Ниже мы кратко рассмотрим
несколько прикладных протоколов стека
TCP/IP.

Протокол
FTP

Как
следует из названия, протокол FTP (File
Transfer Protocol) предназначен для передачи
файлов через Интернет. Именно на базе
этого протокола реализованы процедуры
загрузки и выгрузки файлов на удаленных
узлах Всемирной Сети. FTP позволяет
переносить с машины па машину не только
файлы, но и целые папки, включающие
поддиректории на любую глубину вложений.
Осуществляется это путем обращения к
системе команд FTP, описывающих ряд
встроенных функций данного протокола.

Протоколы
SMTP
и POP3

Прикладные
протоколы, используемые при работе с
электронной почтой, называются SMTP
(Simple Mail Transfer Protocol) и РОРЗ (Post Office Protocol),
первый «отвечает» за отправку исходящей
корреспонденции, второй — за доставку
входящей. В функции этих протоколов
входит организация доставки сообщений
e-mail и передача их почтовому клиенту.
Помимо этого, протокол SMTP позволяет
отправлять несколько сообщений в адрес
одного получателя, организовывать
промежуточное хранение сообщений,
копировать одно сообщение для отправки
нескольким адресатам. И РОРЗ, и SMTP
обладают встроенными механизмами
распознавания адресов электронной
почты, а также специальными модулями
повышения надежности доставки сообщений.

Протокол
HTTP

Протокол
HTTP (Hyper Text Transfer Protocol) обеспечивает передачу
с удаленных серверов на локальный
компьютер документов, содержащих код
разметки гипертекста, написанный на
языке HTML или XML, то есть веб-страниц.
Данный прикладной протокол ориентирован
прежде всего на предоставление информации
программам просмотра веб-страниц,
веб-браузерам, наиболее известными из
которых являются такие приложения, как
Microsoft Internet Explorer и Netscape Communicator. Именно с
использованием протокола HTTP организуется
отправка запросов удаленным http-серверам
сети Интернет и обработка их откликов;
помимо этого HTTP позволяет использовать
для вызова ресурсов Всемирной сети
адреса стандарта доменной системы имен
(DNS, Domain Name System), то есть обозначения,
называемые URL (Uniform Resource Locator) вида http:/
/www.domain.zone/page.htm (.html).

Протокол
TELNET

Протокол
TELNET предназначен для организации
терминального доступа к удаленному
узлу посредством обмена командами в
символьном формате ASCII. Как правило, для
работы с сервером по протоколу TELNET на
стороне клиента должна быть установлена
специальная программа, называемая
telnet-клиентом, которая, установив связь
с удаленным узлом, открывает в своем
окне системную консоль операционной
оболочки сервера. После этого вы можете
управлять серверным компьютером в
режиме терминала, как своим собственным
(естественно, в очерченных администратором
рамках). Например, вы получите возможность
изменять, удалять, создавать, редактировать
файлы и папки, а также запускать на
исполнение программы на диске серверной
машины, сможете просматривать содержимое
папок других пользователей. Какую бы
операционную систему вы ни использовали,
протокол Telnet позволит вам общаться с
удаленной машиной «на равных». Например,
вы без труда сможете открыть сеанс UNIX
на компьютере, работающем под управлением
MS Windows.

remote
procedure call, RPC

Идея
удаленного вызова процедур (remote procedure
call, RPC) появилась в середине 80-х годов и
заключалась в том, что при помощи
промежуточного программного обеспечения
функцию на удаленном компьютере можно
вызывать так же, как и функцию на локальном
компьютере. Чтобы удаленный вызов
происходил прозрачно с точки зрения
вызывающего приложения, промежуточная
среда должна предоставить процедуру-заглушку
(stub), которая будет вызываться клиентским
приложением. После вызова процедуры-заглушки
промежуточная среда преобразует
переданные ей аргументы в вид, пригодный
для передачи по транспортному протоколу,
и передает их на удаленный компьютер с
вызываемой функцией. На удаленном
компьютере параметры извлекаются
промежуточной средой из сообщения
транспортного уровня и передаются
вызываемой функции (рис.
2.2).
Аналогичным образом на клиентскую
машину передается результат выполнения
вызванной функции.

Рис.
2.2. 
Удаленный вызов процедур

Существует
три возможных варианта удаленного
вызова процедур.

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

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

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

Разработка мобильного приложения без сервера / Блог компании Surf / Хабр

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

Такая ситуация может происходить по разным причинам. Однако, чаще всего на старте разработки, бэкэнд просто не написан и клиент начинает без него. В таком случае начало разработки затягивается на 2-4 месяца

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

Как я к этому пришелКак я вообще к этому пришел? Заканчивался мой первый год работы в компании и меня поставили на новенький e-commerce проект. Менеджер сказал, что проект нужно сделать за 4 месяца, но бэкэнд команда (на стороне заказчика) начнет разработку только через 1.5 месяца. А мы за это время должны накидать уже много UI-фич.

Я предложил написать моковый бэкэнд (до того как стать iOS разработчиком я игрался с .NET в универе). Идея реализации была проста: нужно было по заданной спецификации написать методы-заглушки, которые бы брали данные из заранее подготовленных JSON-файлов. На том и порешили.

Через 2 недели я ушел в отпуск и задумался: «А чего бы мне не генерировать все это автоматически?». Так за 2 недели отпуска я написал подобие интерпретатора, который берет спецификацию APIBlueprint и генерит из нее .NET Web App (код на C#).

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

Сейчас, спустя несколько лет, я учел допущенные мной ошибки (а их было очень много) и полностью переписал инструмент.

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

Введение

Как правило, любое клиент-серверное приложение выглядит примерно вот так:

На каждый экран приходится как минимум 1 запрос (а часто больше). Переходя по экранам вглубь, нам нужно сделать все больше и больше запросов. Иногда мы даже не можем сделать переход, до тех пор пока сервер не скажет нам «Покажи кнопку». То есть мобильное приложение очень сильно завязано на сервер, не только во время своей непосредственной работы, но и на этапе разработки. Рассмотрим абстрактный цикл разработки продукта:

1. Сначала мы проектируем. Декомпозируем, описываем и обсуждаем.
2. Получив задачи и требования, начинаем разработку. Пишем код, верстаем и т.п.
3. После того, как мы что-то реализовали, готовится сборка, которая уходит на ручное тестирование, где работа приложения проверяется по разным кейсам.
4. Если у нас все нормально, и тестеры апрувят сборку, она уходит заказчику, который выполняет приемку.

Каждый из этих процессов очень важен. Особенно последний, так как заказчик должен понимать на каком этапе мы действительно находимся, а иногда ему нужно отчитываться о результатах перед руководством или инвесторами. Как правило, подобные отчеты происходят, в том числе, в формате демонстрации мобильного приложения. На моей практике был случай, когда заказчик демонстрировал буквально половину MVP, которая работала только на моках. Приложение на моках выглядит как настоящее и крякает как настоящее. Значит оно настоящее (:
Однако это розовая мечта. Давайте рассмотрим, что произойдет на самом деле, если у нас не будет сервера.

1. Процесс разработки будет проходить медленнее и болезненнее, так как сервисы мы написать нормально не можем, проверить все кейсы тоже не можем, приходится писать заглушки, которые потом нужно будет удалить.
2. После того, как мы с горем пополам сделали сборку, она попадает тестерам, которые смотрят на нее и не понимают что с ней делать. Проверить ничего нельзя, половина вообще не работает, потому что сервера нет. Как следствие — пропускают много багов: как логических, так и визуальных.
3. Ну а после «как смогли посмотрели», надо отдать сборку заказчику и тут начинается самое неприятное. Заказчик не может толком оценить работу, он видит 1-2 кейса из всех возможных и уж точно не может показать это своим инвесторам.

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

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

Таким образом, есть следующие проблемы:

1. Сервер отсутствует полностью. Из-за этого невозможно разрабатывать, проверять и презентовать.
2. Сервер не успевает, что мешает разрабатывать и может мешать тестировать.
3. Мы хотим тестировать граничные кейсы, а сервер не может этого позволить без долгих телодвижений.
4. Аффектит тестирование и угрожает презентации.
5. Сервер падает (однажды мы уже во время стабильной разработки лишились сервера на 3.5 дня).

Чтобы бороться с этими проблемами и был создан Mocker.

Принцип работы

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

Последовательность следующая:

1. Клиент отправляет запрос.

2. Mocker получает запрос.

3. Mocker находит нужный мок.

4. Mocker возвращает нужный мок.

Если с пунктами 1,2 и 4 все понятно, то 3 вызывает вопросы.

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

Мок — это файл с JSON-ом в следующем формате:

{
    "url": "string",
    "method": "string",
    "statusCode": "number",
    "response": "object",
    "request": "object"
}

Разберем каждое поле отдельно.

url

Этот параметр используется для того, чтобы указать URL запроса, по которому обращается клиент.

Например, если мобильное приложение делает запрос на url host.dom/path/to/endpoint, то в поле url нам нужно написать /path/to/endpoint.

То есть это поле хранит относительный путь до эндпоинта.

Это поле должно быть отформатировано в формате url-template, то есть допускается использовать следующие форматы:

1. /path/to/endpoint — обычный url адрес. Во время получения запроса сервис будет сравнивать строки посимвольно.
2. /path/to/endpoint/{number} — url с path-паттерном. Мок с таким URL будет реагировать на любой запрос, который удовлетворяет этому шаблону.
3. /path/to/endpoint/data?param={value} — url c parameter-паттерном. Мок с таким url сработает на запрос, содержащий заданные параметры. При этом, если одного из параметров не будет в запросе, то он не будет соответствовать шаблону.

Таким образом, управляя URL параметрами можно явно определить, что на какой-то определенный url вернется какой-то определенный мок.

method

Это ожидаемый http method. Например POST или GET.
Строка обязательно должна содержать только заглавные буквы.

statusCode

Это код http статуса для ответа. То есть запросив этот мок, клиент получит ответ со статусом записанным в поле statusCode.

response

Это поле содержит JSON объект, который будет отправлен клиенту в теле ответа на его запрос.

request

Здесь записывается тело запроса, которые ожидается получить от клиента.Это будет использоваться для того, чтобы отдать нужный response в зависимости от тела запроса request. Например, если мы хотим менять ответы в зависимости от параметров запроса.

{
    "url": "/auth",
    "method": "POST",
    "statusCode": 200,
    "response": {
        "token": "cbshbg52rebfzdghj123dsfsfasd"
    },
    "request": {
        "login": "Tester",
        "password": "Valid"
    }
}

{
    "url": "/auth",
    "method": "POST",
    "statusCode": 400,
    "response": {
        "message": "Bad credentials"
    },
    "request": {
        "login": "Tester",
        "password": "Invalid"
    }
}

Если клиент отправит запрос с телом:

{
    "login": "Tester",
    "password": "Valid"
}

То в ответ он получит:

{
    "token": "cbshbg52rebfzdghj123dsfsfasd"
}

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

{
    "login": "Tester",
    "password": "Invalid"
}

То в ответ он получит:

{
    "message": "Bad credentials"
}

И мы сможем проверить кейс с неверным паролем. И так для всех остальных кейсов.

А теперь разберемся как работает группировка и поиск нужного мока.

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

Сервер объединяет разные моки по url и method. Это необходимо в том числе и для того, чтобы мы могли создать на один url много разных моков.

Например, мы хотим, чтобы постоянно дергая Pull-To-Refresh, приходили разные ответы и состояние экрана все время менялось (чтобы проверить все граничные кейсы).

Тогда мы можем создать много разных моков с одинаковыми параметрами method и url, а сервер будет возвращать их нам итеративно (по очереди).

Например, пусть у нас будут такие моки:

{
    "url": "/products",
    "method": "GET",
    "statusCode": 200,
    "response": {
        "name": "product",
        "currency": 1,
        "value": 20
    }
}

{
    "url": "/products",
    "method": "GET",
    "statusCode": 200,
    "response": {
        "name": "gdshfjshhkfhsdgfhshdjgfhjkshdjkfsfgbjsfgskdf",
        "currency": 5,
        "value": 100000000000
    }
}

{
    "url": "/products",
    "method": "GET",
    "statusCode": 200,
    "response": null
}

{
    "url": "/products",
    "method": "GET",
    "statusCode": 400,
    "response": null
}

Тогда, когда мы первый раз вызовем метод GET /products, то сначала получим в ответ:

{
    "name": "product",
    "currency": 1,
    "value": 20
}

Когда вызовем второй раз — указатель итератора сместится на следующий элемент и нам вернется:

{
    "name": "gdshfjshhkfhsdgfhshdjgfhjkshdjkfsfgbjsfgskdf",
    "currency": 5,
    "value": 100000000000
}

И мы сможем проверить как поведет себя приложение если мы получим какие-то большие значения. И так далее.

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

Кэширующий прокси

Mocker умеет работать в режиме кэширующего прокси. Это означает, что когда сервис получает запрос от клиента, он достает из него адрес хоста, на котором расположен реальный сервер и схему (для определения протокола). Далее берет полученный запрос (со всеми его хедерами, так что если метод требует аутентификации, то ничего страшного, ваш Authorization: Bearer ... перенесется) и вырезает из него служебную информацию (тот самый host и scheme) и отправляет запрос на реальный сервер.

Получив ответ с 200-м кодом Mocker сохраняет ответ в моковый файл (да, вы потом можете его скопировать или поменять) и возвращает клиенту то, что он получил от реального сервера. Причем, он не просто сохраняет файл в случайное место, а организует файлы так, чтобы с ними можно было затем работать вручную Например, Mocker отправляет запрос по следующему URL: hostname.dom/main/products/loans/info. Тогда он создаст папку hostname.dom, затем внутри нее он создаст папку main, внутри нее папку products…

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

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

X-Mocker-Redirect-Is-On: "true",
X-Mocker-Redirect-Host: "hostaname.ex:1234",
X-Mocker-Redirect-Scheme: "http"

Явное указание пути к мокам

Иногда хочется, чтобы Mocker возвращал только те моки, которые мы хотим, а не все которые есть в проекте.

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

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

X-Mocker-Specific-Path: path

К примеру, пусть у Mocker-а в корне вот такая структура папок

root/
    block_card_test_case/
        mocks....
    main_test_case/
        blocked_test_case/
        mocks...

Если необходимо прогнать тест-кейс о заблокированных картах, тогда
X-Mocker-Specific-Path: block_card_test_case
Если необходимо прогнать тест-кейс связанный с блокировкой главного экрана, тогда
X-Mocker-Specific-Path: main_test_case/blocked_test_case

Интерфейс

Сначала мы работали с моками напрямую по по ssh, но с ростом числа моков и пользователей перешли на более удобный вариант. Сейчас мы используем CloudCommander.
В примере docker-compose, он связывается с контейнером Mocker-а.

Выглядит это примерно так:

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

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

Развертывание

Для того, чтобы развернуть Mocker проще всего использовать Docker. К тому же, развернув сервис из докера, автоматически развернется web-интерфейс через который удобнее работать с моками. Файлы необходимые для развертывания через Docker лежат в репозитории.

Однако, если вас не устраивает этот вариант, можете самостоятельно собрать сервис из исходников. Для этого достаточно:

git clone https://github.com/LastSprint/mocker.git
cd mocker
go build .

Затем нужно написать конфиг файл (пример) и запустить сервис:

mocker config.json

Известные проблемы

• После каждого нового файла надо делать curl mockerhost.dom/update_models для того, чтобы сервис прочел файлы заново. Я не нашел быстрый и элегантный способ обновлять его иначе
• Иногда CloudCommander багует (или я что-то не так сделал) и он не дает редактировать моки, которые были созданы через web-интерфейс. Лечится чисткой кэша у браузера.
• Сервис работает только с application/json. В планах поддержка form-url-encoding.

Итог

Mocker— это web-сервис, который решает проблемы разработки клиент-серверных приложений в том случае, когда сервер по каким-то причинам не готов.

Сервис позволяет создавать множество разных моков на один URL, позволяет связать между собой Request и Response с помощью явного указания параметров в url, либо прямо с помощью задания ожидаемого тела запроса. У сервиса есть web-интерфейс, который сильно упрощает жизнь пользователям.

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

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

Репозиторий на GitHub.

Определение сервера приложений

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

Серверы приложений используются для многих целей. Ниже приведены несколько примеров:

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

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

Зачем нужен сервер приложений?

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

Обновлено: 22 ноября 2019 г.

TechTerms — Компьютерный словарь технических терминов

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

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

.

новых вопросов о сервере приложения — qaru

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

Загрузка…

2. Авторизоваться
   зарегистрироваться

3. текущее сообщество
   

   • Переполнение стека

     Помогите
     болтать

   • Переполнение мета-стека

   ваши сообщества

   Зарегистрируйтесь или

.Веб-сервер

— веб-сервер против сервера приложений

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

Загрузка…

.

No related posts.