В предыдущих статьях серии я освещал основы объектно-ориентированной работы с данными в db4o. Одним из вопросов, которые я обошел вниманием, является использование ООСУБД в Web-приложениях и чем оно отличается от использования в приложениях Swing или SWT. Кто-то может сказать, что я проигнорировал целый круг вопросов, которые обязан знать любой .NET- или Java-разработчик.
Дело в том, что я хотел сосредоточиться на наиболее привлекательных возможностях ООСУБД: объектно-ориентированном хранении, манипулировании и выборке данных. К тому же поставщики ООСУБД как правило реализуют базовые функции, такие как управление транзакциями и обеспечение безопасности, аналогично РСУБД, предоставляя столь же широкий набор опций.
Многие Web-приложения выдают значительный объём статического контента, что означает чтение данных с диска и их последующую запись в отвечающий сокет. Возможно, эта деятельность требует относительно маленькой загрузки процессора, но и эффективность её невелика: ядро считывает данные с диска, отправляет их через границу ядро-пользователь в приложение, а затем приложение возвращает эти же данные через границу ядро-пользователь, чтобы записать в сокет. На деле приложение работает как неэффективное промежуточное звено, передающее данные с диска в сокет.
Каждый раз, когда данные пересекают границу пользователь-ядро, их необходимо копировать; при этом затрачиваются ресурсы процессора и памяти. К счастью, этого копирования можно избежать с помощью технологии с соответствующим названием— zero copy. Приложения, использующие zero copy, запрашивают ядро о копировании данных прямо с диска в сокет, не затрагивая приложения. Zero copy значительно улучшает производительность приложений и уменьшает число контекстных переключений между режимами пользователя и ядра.
Многих современные Java-приложения включают сложный набор распределенных и зависящих друг от друга компонентов, а также обладают динамической структурой. Поэтому производительность и степень готовности приложения потенциально зависят от множества внешних факторов. Подобные зависимости практически невозможно свести на нет, либо точно смоделировать в тестовом окружении перед вводом в эксплуатацию. А значит, при работе приложения могут происходить всякие неожиданности. Тем не менее можно облегчить последствия и сократить длительность нежелательных событий путем создания и сопровождения системы для всеобъемлющего мониторинга среды, в которой выполняется ваше приложение.
В данной серии из трех статей рассматриваются некоторые принципы и подходы к реализации подобной системы. Сами принципы, а также некоторая часть используемой терминологии имеют общий характер. В сочетании с примерами кода и иллюстрациями они помогут вам сформировать концептуальное представление о мониторинге производительности приложений. Подобная картина подчеркивает необходимость решения данной задачи и помогает в выборе этого решения (коммерческого, с открытым исходным кодом или расширением существующей системы) либо, для особо мотивированных читателей, может служить руководством по разработке такового.
До сих пор в публикациях этой серии я уделял основное внимание тесной связи Scala с экосистемой Java, демонстрируя вам то, как Scala включает в себя преобладающую часть объектной функциональности Java. Однако если бы Scala просто являлся другим способом написания объектов, он бы не представлял собой ничего интересного, а тем более выдающегося, как это есть на самом деле. Объединение в Scala функциональных и объектных концепций, усиленное акцентом на эффективность процесса программирования, ощутимо усложняет и замедляет изучение языка, что может быть неочевидно для начинающего Java/Scala-программиста.
Об этой серии
Тед Ньюорд погружается в язык программирования Scala и берет вас с собой. В этой новой серии от developerWorks вы узнаете, вокруг чего поднят такой шум, и увидите некоторые лингвистические возможности Scala в действии. Код Scala и код Java будут показаны бок о бок, если таковое сравнение будет важно. Правда, как скоро выяснится, многие вещи в Scala не могут быть напрямую соотнесены с чем-либо таким, что вам знакомо из Java-программирования, — но в этом и заключается основное очарование Scala! В конце концов, если что-то можно сделать на Java — зачем утруждать себя изучением Scala?
Портлеты – это компоненты приложений с пользовательским интерфейсом, формирующие содержимое в одном из стандартных форматов разметки (к примеру, HTML). Эта разметка предназначена для агрегирования портлетов с другими фрагментами в единое большое приложение, например, страницу порталa
Портлеты могут рассматриваться как сервисы пользовательского графического интерфейса, который распространяют сервис-ориентированную архитектуру (SOA) на интерфейс для конечных пользователей.
Портлеты Java стали популярны после выхода первой версии Java Portlet Specification, JSR-168, выпущенной в 2003 сообществом Java Community Processes. С этого момента почти все вендоры, разрабатывающие порталы Java, как коммерческие, так и с открытым исходным кодом, реализовали этот стандарт, и разработчики стали писать портлеты, использующие Java Portlet API.
