1. Сначала поймите концепцию и роль сервера приложений.Сервер приложений
(независимо от того, какова функция сервера приложений) занимает большую часть вычислительной территории между сервером базы данных и конечным пользователем. Это поле имеет хорошо известное имя — промежуточное программное обеспечение, и это имя также говорит вам, что делают серверы приложений. Прежде всего, серверы приложений связывают информацию базы данных (обычно полученную с сервера базы данных) с программами конечного пользователя или клиента (часто работающими в веб-браузере). Причин наличия промежуточного слоя в связи с этим много. Эти причины включают уменьшение размера и сложности клиентских программ, кэширование и лучший контроль над потоком данных для повышения производительности, а также обеспечение безопасности при обмене данными и взаимодействии пользователей.
Однако это не все, на что способен сервер приложений. На заре появления серверов приложений было обнаружено, что сами приложения (программы, которые люди используют для выполнения работы) становились все больше и сложнее. Это верно независимо от того, как приложение написано и поддерживается. В то же время приложения все больше нуждаются в совместном использовании данных, а иногда и функций. Дополнительные приложения помещаются в сеть или используют функцию расширения сети. Кажется логичным запускать определенные типы приложений в сети: это помогает организованно и эффективно распределять функциональные возможности приложения, упрощая написание, управление и поддержку приложения.
Конечным результатом такого мышления является текущий сервер приложений. Однако эти серверы впервые появились в клиент-серверных и локальных сетях. Во-первых, их часто связывают с «многоуровневыми» приложениями, где функциональность таких приложений интерпретируется как двухуровневая (база данных и клиентские программы), трехуровневая (база данных, клиентские программы и серверы приложений) и N-уровневая (включая двухуровневые, трехуровневые и многоуровневые) приложения. Это был (и остается) сложный шаблон разработки приложений, который нельзя применять в больших масштабах. Затем появилась всемирная паутина. Сеть представляет собой автоматическое трехуровневое приложение (база данных, клиентская программа и веб-сервер), так что управление данными с использованием возможностей сервера приложений вдруг становится не только лучшим подходом в программировании, но и необходимостью. Это подняло серверы приложений из безвестности до известности. Не будет преувеличением сказать, что в разработке программных продуктов для серверов приложений участвовали десятки компаний.
Неудивительно, что компании, занимающиеся серверами приложений, не пришли и до сих пор не согласны с ролью и миссией серверов приложений. Они не конкурируют напрямую, а делают что-то другое. Серверы приложений имеют много разных ролей, и не всем клиентам требуется одинаковая функциональность. Масштабируемость является хорошим примером. Некоторые компании используют серверы приложений только для того, чтобы помочь им управлять веб-приложениями, чтобы они могли лучше управлять своей бизнес-логикой, чтобы они могли легче отслеживать данные и обеспечивать безопасность данных. Им не нужны тысячи серверов. Другим, особенно крупным, необходимо управлять тысячами серверов. Для таких компаний очень важна масштабируемость сервера приложений. Поэтому некоторые серверы приложений подчеркивают масштабируемость, некоторые серверы приложений могут делать другие вещи, а некоторые серверы приложений могут делать все.
Таким образом, когда вы просматриваете информацию о различных программах для серверов приложений в этой колонке, вам действительно нужно иметь собственное мнение о том, что нужно вашей организации и что требуется в данной ситуации. что самое важное Безопасность, масштабируемость, управление бизнес-правилами или подключение к базе данных?
Еще одна вещь (и еще одна сложность, связанная с серверами приложений): продукты для серверов приложений попадают в различные области программирования. Большинство серверов приложений (хотя и не все) написаны на языке Java. Некоторые серверы приложений совместимы с продуктами Microsoft, а некоторые нет. Поддержка системы Microsoft в основном зависит от того, поддерживает ли она CORBA (общую архитектуру посредника объектных запросов) или Microsoft COM+ (конечно, некоторые поддерживают и то, и другое). Важно рассматривать эти серверы с точки зрения справочника по программированию учреждения.
2. Введение в jboss
JBoss — это сервер приложений J2EE , на котором работает EJB . Это проект с открытым исходным кодом, соответствующий последней спецификации J2EE . С самого начала проекта JBoss он превратился из контейнера EJB в веб-операционную систему на основе J2EE (операционную систему для Интернета), которая воплощает в себе новейшие технологии в спецификации J2EE и до сих пор находится в списке «Выбор редакции JavaWorld». 2002 г. Награжден наградой «Лучший сервер приложений Java» по результатам отбора.
3. EJB, J2EE, спецификация J2EE, контейнер EJB, POJO
http://www.jdon.com/idea/j2eebasic.htm
http://www.jdon.com/jdonframework/app.htm
Что такое EJB ?
разработка на основе компонентов
С помощью EnterpriseJavaBean ( EJB ) вы можете разрабатывать компоненты EJB, такие как строительные блоки , а затем вы или другие лица можете собирать или повторно собирать эти компоненты EJB в различные приложения. Например, вы можете создать bean-компонент Customer (клиент) ( bean-компонент — это компонент, просто называемый по-другому), который представляет клиента в базе данных. Этот компонент Customer может использоваться в нескольких приложениях, таких как программы аудита, системы корзины для покупок в электронной коммерции или приложения технической поддержки.Поскольку клиент должен быть представлен в приложении, этот компонент можно использовать практически везде. На самом деле , для некоторых bean-компонентов разработчик bean-компонента и сборщик приложения, которые используют bean-компонент , могут не работать в одной компании или даже не знать друг друга.
Если вы являетесь разработчиком бина , вы можете создать бин Order ( заказ) , бин Payroll (зарплата) или бин ShoppingCart (корзина) , чтобы разработчики из других компаний (которые могут не иметь к вам никакого отношения) могли отправлять Вы покупаете эти компоненты и используете их для создания собственных приложений.
Компонентная разработка имеет большое преимущество, а именно: на основе компонентов повторное использование кода может подняться на новый уровень. Вместо повторного использования класса Java вы повторно используете более крупный блок функций. То, как работает компонент, обычно можно изменить снаружи, не затрагивая Java- код внутри компонента ! Как вы узнаете из этой главы, для развертывания bean- компонента на сервере вы можете сконфигурировать и настроить bean-компонент декларативно (то есть с помощью дескриптора развертывания на основе XML ), так что вам нужно будет только изменить дескриптор развертывания. компонента во время выполнения.
С помощью разработки на основе компонентов вы можете вывести повторное использование кода на новый уровень. При объектно-ориентированной разработке повторно используются классы, а на основе компонентов повторно используются более крупные функциональные блоки, и эти повторно используемые компоненты можно настраивать, не касаясь конкретных кодов!
4. Концепция Framework
Framework не является точкой зрения jboss, но многие приложения java в основном связаны с Framework, так что это все еще первое, что нужно понять.
Наряду с развитием разработки программного обеспечения, в многоуровневых проектах разработки программного обеспечения люди все больше предпочитают повторно используемые, легко расширяемые и хорошо протестированные программные компоненты. Это означает, что люди могут тратить достаточно времени на анализ и создание приложений бизнес-логики вместо сложной разработки кода. Таким образом, люди абстрагируют решения однотипных проблем и извлекают их в структуру приложения. Это то, что мы называем фреймворком.
Фреймворк Framework предоставляет набор четких механизмов, позволяющих разработчикам легко расширять и контролировать структуру всей разработки Framework. Обычно в структуре Framework присутствует компонент «command and control» («командно-контрольный компонент») — Framework Factory and Manager.
Среда приложений, основанная на режиме «запрос-ответ», в основном состоит из следующих логических структур.
Контроллер (Controller) — управляет координацией различных компонентов во всем Фреймворке.
Уровень бизнес-логики — для самой Framwork это всего лишь концепция и несколько базовых компонентов, которые предоставляют достаточно сервисов Реальная реализация соответствует бизнес-логике заказчика, и разработчикам необходимо снова расширить возможности Framework.
Уровень логики данных — большинству прикладных систем необходимо взаимодействие с данными, этот уровень в основном включает логику данных и интерфейс доступа к данным. Для логики данных, если вы понимаете моделирование данных (моделирование данных), это может быть легко понять.