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

Сервер приложений (англ. 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

«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рни п...»

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

Сначала были Файл-сервер и Принт-сервер, довольно быстро к ним добавился Почтовый сервер. Не успели мы как следует привыкнуть к 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-апплеты и новые бины.

Рис. 4. Контейнер Enterprise Java Beans

По технологии 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. И за счет поддержки распределенности, возможностей выравнивания загрузки, отслеживания распределенных неоднородных транзакций, управления безопасностью и многих других своих возможностей. Именно эти интеллектуальные приложения находят в Серверах Приложений могучую опору.

Рис. 5. Java 2 Enterprise Edition

Вскользь упомяну о следующих усилиях по созданию технологии компонентного программного обеспечения, снова связанных с 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) в трехуровневой клиент-серверной архитектуре (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.

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки

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

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

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

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

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