Типы программ на java

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

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

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

JAVA ДЛЯ ДЕБИЛОВ #1 ТИПЫ ДАННЫХ | ПОЛНЫЙ ТУТОРИАЛ ПО ДЖАВЕ С НУЛЯ

Или это будет CD-привод, DVD-привод или еще какой-либо другой тип носителя . Но переносимость обычных приложений ограничивается одним типом операционных систем. Например, приложение MS Windows® не будет работать под Linux, и наоборот. Программы, написанные на языке Java , выполняются под управлением специальной программы -виртуальной Java -машины, и поэтому обладают переносимостью на любую операционную систему, где имеется соответствующая Java -машина. Благодаря этому они являются не приложениями какой-либо операционной системы, а приложениями Java.

Программы, написанные на языке Java , представляют из себя наборы классов и сохраняются в текстовых файлах с расширением . java . (Про то, что такое классы, будет рассказано несколько позже). При компиляции текст программы переводится (транслируются) в двоичные файлы с расширением . class . Такие файлы содержат байт-код — инструкции для абстрактного Java -процессора в виде байтовых последовательностей команд этого процессора и данных к ним. Для того, чтобы байт-код был выполнен на каком-либо компьютере, он должен быть переведен в инструкции для соответствующего процессора. Именно этим и занимается Java -машина. Первоначально байт-код всегда интерпретировался: каждый раз, как встречалась какая-либо инструкция Java -процессора, она переводилась в последовательность инструкций процессора компьютера. Естественно, это значительно замедляло работу приложений Java .

В настоящее время используется более сложная схема, называемая JIT -компиляцией (Just-In-Time) – компиляцией «по ходу дела», «налету». Когда какая-либо инструкция (или набор инструкций) Java -процессора выполняется в первый раз, происходит компиляция соответствующего ей байт-кода с сохранением скомпилированного кода в специальном буфере. При последующем вызове той же инструкции вместо ее интерпретации происходит вызов из буфера скомпилированного кода. Поэтому интерпретация происходит только при первом вызове инструкции.

Программирование на Java с нуля #8. Ссылочные типы

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

Поэтому бывает выгоднее сначала запустить процесс интерпретации, а параллельно ему в фоновом режиме компилировать инструкцию. Только после окончания процесса компиляции при последующих вызовах инструкции будет исполняться ее скомпилированный код. – До этого все ее вызовы будут интерпретироваться. Разработанная Sun виртуальная машина HotSpot осуществляет JIT -компиляцию только тех участков байт-кода, которые критичны к времени выполнения программы. При этом по ходу работы программы происходит оптимизация скомпилированного кода.

Благодаря компиляции программ Java в платформонезависимый байт-код обеспечивается переносимость этих программ не только на уровне исходного кода, но и на уровне скомпилированных приложений. Конечно, при этом на компьютере, где выполняется приложение , должна быть установлена программа виртуальной Java -машины ( Java Virtual Machine — JVM ), скомпилированная в коды соответствующего процессора ( native code – «родной» код). На одном и том же компьютере может быть установлено несколько Java -машин разных версий или от разных производителей. Спецификация Java -машины является открытой, точно так же, как требования к компилятору языка Java . Поэтому различные фирмы, а не только Sun , разрабатывают компиляторы Java и Java -машины.

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

Приложения Java обладают не только хорошей переносимостью, но и высокой скоростью работы. Однако даже при наличии JIT -компиляции они все-таки могут выполняться медленнее, чем программы, написанные на C или C++.

Это связано с тем, что JIT — компиляция создает не такой оптимальный код как многопроходный компилятор C/C++, который может тратить очень большое время и много ресурсов на отыскивание конструкций программы, которые можно оптимизировать. А JIT — компиляция происходит «на лету», в условиях жесткой ограниченности времени и ресурсов.

Для решения этой проблемы были разработаны компиляторы программ Java в код конкретных программно-аппаратных платформ ( native code – «родной» код). Например, свободно распространяемый фондом GNU компилятор gjc. Правда, заметные успехи Sun в усовершенствовании Java -машины позволили практически достичь, а в ряде случаев даже обогнать по быстродействию программы, написанные на других языках. В частности, приложения Java , активно занимающиеся выделением-высвобождением памяти, работают быстрее своих аналогов, написанных на C/C++, благодаря специальному механизму программных слотов памяти ( slot – «паз, отверстие для вставки чего-либо»).

Виртуальная Java -машина не только исполняет байт-код (интерпретирует его, занимается JIT -компиляцией и исполняет JIT -компилированный код), но и выполняет ряд других функций. Например, взаимодействует с операционной системой, обеспечивая доступ к файлам или поддержку графики. А также обеспечивает автоматическое высвобождение памяти, занятой ненужными объектами – так называемую сборку мусора ( garbage collection ). Программы Java можно разделить на несколько основных категорий:

• Приложение (application) – аналог «обычной» прикладной программы.
• Апплет ( applet ) – специализированная программа с ограниченными возможностями, работающая в окне WWW-документа под управлением браузера.
• Сервлет ( servlet ) — специализированная программа с ограниченными возможностями, работающая в WWW на стороне сервера. Используется преимущественно в рамках технологии JSP (Java Server Pages — Серверных Страниц Java ) для программирования WWW-документов со стороны сервера.
• Серверное приложение ( Enterprise application ) – предназначено для многократного использования на стороне сервера.
• Библиотека (Java Class Library – библиотека классов, либо NetBeans Module – модуль платформы NetBeans) – предназначена для многократного использования программами Java

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

Сервлеты – это приложения Java , запускаемые со стороны сервера. Они имеют возможности доступа к файловой системе и другим ресурсам сервера через набор управляющих конструкций , предопределенных в рамках технологии JSP и пакета javax. servlet . Технология JSP заключается в наличии дополнительных конструкций в HTML -или XML -документах, которые позволяют осуществлять вызовы сценариев («скриптов»), написанных на языке Java . В результате удается очень просто и удобно осуществлять обработку данных или элементов документа, и внедрять в нужные места документа результаты обработки. Сценарии Java перед первым выполнением автоматически компилируются на стороне сервера, поэтому выполняемый код выполняется достаточно быстро. Но, конечно, требует, чтобы была установлена соответствующая Java -машина. Например, входящая в состав Sun Application Server – программного обеспечения, обеспечивающего поддержку большого количества необходимых серверных возможностей для работы в WWW . Отметим, что Sun Application Server также распространяется бесплатно и входит в комплект NetBeans Enterprise Pack.

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

Виртуальную Java -машину часто называют исполняющей средой ( Java Runtime Environment — JRE ).

Существует два основных способа установки Java -машины на клиентский компьютер :

• JRE из поставки Software Development Kit ( SDK ) — Комплекта разработки программного обеспечения.
• Специализированный вариант JRE в составе Интернет-браузера, называющийся Java plugin.

Комплект последних версий SDK можно свободно загружать с сайта Sun http://java.sun.com/.

При использовании апплетов требуется, чтобы в состав браузера входил специализированный комплект JRE . Как правило, он поставляется вместе с браузером, и может при необходимости обновляться. Для MS Internet Explorer такой комплект и его обновления могут быть свободно загружены с сайта Microsoft.

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

Комплекты SDK имеют классификацию, опирающуюся на версию Java (языка программирования и, соответственно, Java -машины) и тип создаваемых приложений. Так, ко времени написания данного текста выходили версии SDK 1.0, 1.1, 1.2, 1.3, 1.4, 1.5 и 1.6. У каждой версии имеется ряд подверсий, не сопровождающихся изменением языка программирования, а связанных в основном с исправлением ошибок или внесением небольших изменений в библиотеки. Например, 1.4.1_01 или 1.5.0_04.

Версии Java 1.0 и 1.1 принято называть Java 1. Все версии Java начиная c 1.2 называют Java 2. Однако более надежно классифицировать по номеру SDK , так как язык Java для версии SDK 1.5 очень заметно отличается по возможностям от языка Java для более ранних версий SDK – в него добавлено большое количество новых синтаксических конструкций, а также изменен ряд правил. Поэтому код, правильный в Java для версии SDK 1.5, может оказаться неправильным в Java для версии SDK 1.4. Не говоря уж про Java для версии SDK 1.3 или 1.2. Кроме того, недавно компания Sun перестала использовать в названиях комплектов программного обеспечения термин Java 2 и происходящие от него сокращения вида j2.

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

• Java ME – комплект Java Micro Edition (микро-издание) http://java.sun.com/j2me/, предназначенный для программирования «тонких аппаратных клиентов». То есть устройств, обладающих малыми ресурсами — наладонных компьютеров, сотовых телефонов, микроконтроллеров , смарт-карт . Старое название J2ME .
• Java SE – комплект Java Standard Edition (стандартное издание) http://java.sun.com/j2se/, предназначенный для программирования » толстых клиентов «. То есть устройств, обладающих достаточно большими ресурсами — обычных компьютеров. Старое название J2SE .
• Java EE – комплект Java Enterprise Edition http ://java.sun.com/j2ee/, предназначенный для написания серверного программного обеспечения. Старое название J2EE .

При распространении какого-либо продукта, написанного на Java , возможна установка только программного обеспечения Java -машины ( JRE – Java Runtime Environment ). Например, в случае использования Java 1.4.1_01 — комплекта j2re1.4.1_01. При этом создается папка с именем j2re1.4.1_01 с вложенными папками bin и lib. В папке bin содержатся файлы и папки, необходимые для работы Java -машины и дополнительных инструментов для работы с ней в специальных режимах. В папке lib содержатся вспомогательные файлы и библиотеки, в основном связанные с параметрами настроек системы.

Также возможна установка целиком SDK . Например, при установке SDK Java SE 1.5.0_04 создается папка JDK1.5.0_04 с вложенными папками bin , demo , include , jre , lib, sample, а также архивом src. zip с исходными кодами стандартных классов Java . В папке bin содержатся файлы инструментов разработки, в папке demo — файлы примеров с исходными кодами. В папке include — заголовки файлов C для доступа к ряду библиотек Java и отладчику виртуальной Java -машины на платформо-зависимом уровне — на основе интерфейсов JNI ( Java Native Interface ) и JVMDI ( Java Virtual Machine Debugging Interface ), соответственно. В папке jre находятся файлы, необходимые для работы с виртуальной Java -машиной. Папка lib содержит ряд библиотек и сопроводительных файлов, необходимых для работы инструментов из папки bin . В папке sample находятся примеры с исходными кодами.

Аббревиатура JDK расшифровывается как Java Development Kit – комплект разработки программного обеспечения на Java . К сожалению, в комплекте отсутствует даже самая простейшая документация с описанием назначения имеющихся в нем инструментов – даны ссылки на сайт компании Sun , где можно найти эту информацию. Поэтому перечислим назначение основных инструментов. Они делятся на несколько категорий.

Таблица 1.1. Средства разработки приложений Утилита Назначение

javac	Компилятор в режиме командной строки для программ, написанных на языке Java
java	Утилита для запуска в режиме командной строки откомпилированных программ-приложений
appletviewer	Утилита для запуска на исполнение и отладку апплетов без браузера. При этом не гарантируется работоспособность отлаженного апплета в браузере.
jdb	Отладчик программ, написанных на языке Java
javadoc	Генератор документации по классам на основе комментариев, начинающихся с /**
jar	Создание и управление Java-архивами jar
javah	Генератор заголовочных файлов C/C++ для подключения к программам Java внешних библиотек C/C++ на основе интерфейса JNI
javap	Дизассемблер классов
extcheck	Утилита для обнаружения конфликтов между файлами архивов jar
native2ascii	Утилита для конвертации в режиме командной строки параметра, передаваемого в виде текста на национальном алфавите, в последовательность символов UNICODE.

Кроме этого, имеются средства поддержки работы в WWW и корпоративных сетях ( интранет ) с интерфейсом RMI — интерфейсом удаленного вызова методов. Это программы rmic, rmiregistry, rmid. Также имеются средства поддержки информационной безопасности keytool, jarsigner, policytool, и ряд файлов других категорий утилит.

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

Источник: intuit.ru

Типы Java программ

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

Самостоятельные программы (назовём их приложения Java), работающие независимо на локальном компьютере.

Апплеты (applets), работающие в Internet. [2]

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

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

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

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

Для повышения производительности апплетов в браузерах используется компиляция «на лету»- Just-In-Time compilation (JIT). При первой загрузке аплета его код транслируется в обычную исполнимую программу, которая сохраняется на диске и запускается. В результате общая скорость выполнения аплета Java увеличивается в несколько раз. Из соображений безопасности апплеты (в отличие от обычных приложений Java) не имеют никакого доступа к файловой системе локального компьютера. Все данные для обработки они могут получить только от сервера Web.

1.2. Этапы подготовки исполняемой программы.

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

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

не может произойти переполнение или «исчерпание» стека

параметры для инструкций байт-машины имеют нужный тип

доступ к полям и методам объектов не нарушает объявленных в классе правил (public, private, protected)

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

При разрешении ссылки на какой-либо класс он ищется прежде всего в локальном пространстве. Это не позволяет «внешним» кодам подменить один из базовых классов в системе. Также в процессе интерпретации происходит подключение необходимых библиотек (файлы с расширением jar). Весь описанный процесс исполнения Java программ изображён на рис. 1.

Рис. 1. Процесс создания работающего Java-приложения

Как уже было сказано выше, технология Java предполагает лёгкую переносимость программных продуктов с одной платформы на другую. Такую степень лёгкости переноса не обеспечивает ни какой язык программирования. На рис. 2 показвно, как приложение, изначально разработанное на языка С для Windows NT, переносится на платформу Apple Macintosh.

Платформа Windows NT Платформа Apple Macintosh

Источник: kazedu.com

Введение в Java EE

Сегодня поговорим о том, что это такое — Java EE: из чего состоит, каковы особенности архитектуры Java EE приложений, и приведем описания различных технологий данной платформы. Тема обширная сама по себе, но на азах мы не остановимся. В конце проведем небольшое сравнение Java EE со Spring Framework и ответим на вопрос: “что лучше учить” (спойлер: конечно же, учить нужно всё =) ) Начнем с основ.

Java EE — что это?

Java EE — это платформа, построенная на основе Java SE, которая предоставляет API и среду времени выполнения для разработки и запуска крупномасштабных, многоуровневых, масштабируемых, надежных и безопасных сетевых приложений. Подобные приложения называют корпоративными (Enterprise applications), так как они решают проблемы, с которыми сталкиваются большие бизнесы. Однако использовать подобные приложения и преимущества, которые дает Java EE, могут не только крупные корпорации и правительственные структуры. Решения, которые предлагает платформа Java EE, полезны, а порой просто необходимы отдельным разработчикам и небольшим организациям.

Развитие Java EE

• J2EE 1.2 (Декабрь 1999)
• J2EE 1.3 (Сентябрь 2001)
• J2EE 1.4 (Ноябрь 2003)
• Java EE 5 (Май 2006)
• Java EE 6 (Декабрь 2009)
• Java EE 7 (Май)
• Java EE 8 (Август 2017)
• Jakarta EE 8 (Сентябрь 2019)

Архитектура Java EE приложений

• во-первых, многоуровневость. Java EE приложения — многоуровневые, и об этом мы еще поговорим подробнее;
• во-вторых, вложенность. Есть Java EE сервер (или сервер приложений), внутри него располагаются контейнеры компонентов. В данных контейнерах размещаются (бинго!) компоненты.

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

• клиентский;
• средний уровень;
• уровень доступа к данным.

• JavaServer Faces technology (JSF);
• Java Server Pages (JSP);
• Expression Language (EL);
• Servlets;
• Contexts and Dependency Injection for Java EE (CDI).

• Enterprise JavaBeans (EJB);
• JAX-RS RESTful web services;
• Java Persistence API entities;
• Java Message Service.

• Java Database Connectivity API (JDBC);
• Java Persistence API;
• Java EE Connector Architecture;
• Java Transaction API (JTA).

Сервера приложений, контейнеры, компоненты

Взглянем на определение Java EE из Википедии. Java EE — набор спецификаций и соответствующей документации для языка Java, описывающий архитектуру серверной платформы для задач средних и крупных предприятий. Чтобы лучше понять, что означает в данном контексте “набор спецификаций”, проведем аналогию с Java-интерфейсом. Сам по себе Java-интерфейс лишен функциональности. Он просто определяет некоторый контракт, согласно которому реализуется некоторая функциональность. А вот реализуют интерфейс уже другие классы. Причем у одного интерфейса допустимы несколько реализаций, каждая из которых может друг от друга отличаться некоторыми деталями. Со спецификацией все точно так же. Голая Java EE — это просто набор спецификаций. Данные спецификации реализуют различные Java EE сервера. Java EE сервер — это серверное приложение, которое реализует API-интерфейсы платформы Java EE и предоставляет стандартные службы Java EE. Серверы Java EE иногда называют серверами приложений. Данные сервера могут содержать в себе компоненты приложения, каждый из которых соответствует своему уровню в многоуровневой иерархии. Сервер Java EE предоставляет этим компонентам различные сервисы в форме контейнера. Контейнеры — это интерфейс между размещенными на них компонентами и низкоуровневыми платформо-независимыми функциональными возможностями, поддерживающими компонент. Контейнеры предоставляют размещенным на них компонентам определенные службы. Например, управление жизненным циклом разработки, внедрение зависимости, параллельный доступ и т. д. Контейнеры скрывают техническую сложность и повышают мобильность. В Java EE существует четыре различные типа контейнеров:

1. Контейнеры апплетов выполняются большинством браузеров. При разработке апплетов можно сконцентрироваться на визуальной стороне приложения, в то время как контейнер обеспечивает безопасную среду.
2. Контейнер клиентского приложения (ACC) включает набор Java-классов, библиотек и других файлов, необходимых для реализации в приложениях Java SE таких возможностей, как внедрение, управление безопасностью и служба именования.
3. Веб-контейнер предоставляет базовые службы для управления и исполнения веб-компонентов (сервлетов, компонентов EJB Lite, страниц JSP, фильтров, слушателей, страниц JSF и веб-служб). Он отвечает за создание экземпляров, инициализацию и вызов сервлетов, а также поддержку протоколов HTTP и HTTPS. Этот контейнер используется для подачи веб-страниц к клиент-браузерам.
4. EJB (Enterprise Java Bean) контейнер отвечает за управление и исполнение компонентов модели EJB, содержащих уровень бизнес-логики приложения. Он создает новые сущности компонентов EJB, управляет их жизненным циклом и обеспечивает реализацию таких сервисов, как транзакция, безопасность, параллельный доступ, распределение, служба именования либо возможность асинхронного вызова.

Также в Java EE выделяют четыре типа компонентов , которые должна поддерживать реализация Java EE спецификации:

1. Апплеты — это приложения из графического пользовательского интерфейса (GUI), выполняемые в браузере. Они задействуют насыщенный интерфейс Swing API для производства мощных пользовательских интерфейсов.
2. Приложениями называются программы, выполняемые на клиентской стороне. Как правило, они относятся к графическому пользовательскому интерфейсу (GUI) и применяются для пакетной обработки.
3. Веб-приложения (состоят из сервлетов и их фильтров, слушателей веб-событий, страниц JSP и JSF) — выполняются в веб-контейнере и отвечают на запросы HTTP от веб-клиентов. Сервлеты также поддерживают конечные точки веб-служб SOAP и RESTful.
4. Корпоративные приложения (созданные с помощью технологии Enterprise Java Beans, службы сообщений Java Message Service, интерфейса Java API для транзакций, асинхронных вызовов, службы времени) выполняются в контейнере EJB. Управляемые контейнером компоненты EJB служат для обработки транзакционной бизнес-логики. Доступ к ним может быть как локальным, так и удаленным по протоколу RMI (или HTTP для веб-служб SOAP и RESTful).

На диаграмме ниже представлена типичная архитектура Java EE приложения:

Технологии

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

Технология Назначение

Servlets	Java-классы, которые динамически обрабатывают клиентские запросы и формируют ответы (обычно HTML страницы).
Java Server Faces (JSF)	Фреймворк для построения веб приложений с пользовательским интерфейсом. Позволяет включать на страницу компоненты пользовательского интерфейса (например, поля и кнопки), преобразовывать и валидировать данные компоненты, а также сохранять эти данные в хранилищах на стороне сервера.
Java Server Faces Facelets technology	Представляет из себя подтип приложения JSF, в котором вместо JSP страниц используются XHTML страницы
Java Server Pages (JSP)	Текстовые документы, которые компилируются в сервлеты. Позволяет добавлять динамический контент на статические страницы (например, HTML-страницы)
Java Server Pages Standard Tag Library (JSTL)	Библиотека тегов, в которой инкапсулирована основная функциональность в контексте JSP страниц.
Expression Language	Набор стандартных тегов, которые используются в JSP и Facelets страницах для доступа к Java EE компонентам.
Contexts and Dependency Injection for Java EE (CDI)	Представляет собой набор сервисов, предоставляемых Java EE контейнерами, для управления жизненным циклом компонентов, а также внедрения компонентов в клиентские объекты безопасным способом.
Java Beans Components	Объекты, которые выступают в роли временного хранилища данных для страниц приложения.

В таблице ниже приведены технологии используемые на уровне бизнес-логики:

Технология Назначение

Enterprise Java Beans (enterprise bean) components	EJB — это управляемые компоненты, в которых заключена основная функциональность приложения.
JAX-RS RESTful web services	Представляет из себя API для разработки веб-сервисов, соответствующих архитектурному стилю REST.
JAX-WS web service endpoints	API для создания и использования веб-сервисов SOAP.
Java Persistence API (JPA) entities	API для доступа к данным в хранилищах данных и преобразования этих данных в объекты языка программирования Java и наоборот.
Java EE managed beans	Управляемые компоненты, которые предоставляют бизнес-логику приложения, но не требуют транзакционных функций или функций безопасности EJB.
Java Message Service	API службы сообщений Java (JMS) — это стандарт обмена сообщениями, который позволяет компонентам приложения Java EE создавать, отправлять, получать и читать сообщения. Что обеспечивает распределенную, надежную и асинхронную связь между компонентами.

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

• ERP (англ. Enterprise Resource Planning, система планирования ресурсов предприятия),
• CRM (англ. Customer Relationship Management, система управления взаимоотношениями с клиентами).

Java EE vs Spring

Конкурентном Java EE считается Spring Framework. Если взглянуть на развитие двух данных платформ, выходит интересная картина. Первые версии Java EE были созданы при участии IBM. Они вышли крутыми, но неповоротливыми, тяжеловесными, неудобными в использовании.

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

Простота Spring привела к тому, что практически все стали использовать данный фреймворк в своих проектах. А далее Spring и Java EE начали свой путь к одному и тому же, но с разных концов. Компания Pivotal Software, разработчик Spring, стали выпускать проект за проектом, чтобы покрыть все возможные и невозможные потребности Java-разработчиков.

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

Все это время JCP работал над одним — добиться максимального упрощения всего, что только можно внутри Java EE. В итоге в современном EJB для описания бина достаточно указать одну аннотацию над классом, что предоставляет разработчику доступ ко всей мощи технологии Enterprise Java Beans. И подобные упрощения затронули каждую спецификацию внутри Java EE.

В итоге по функционалу Spring и Java EE примерно разделяют паритет. Где-то что-то лучше, где-то что-то хуже, но если смотреть глобально, больших различий нет. То же самое касается сложности работы. И Spring, и Java EE являются превосходными инструментами. Пожалуй, лучшими из того, что сейчас есть, для построения корпоративных сетевых приложений на языке Java.

Однако, Java EE может работать в общем случае только в рамках Enterprise Application Server’a (Tomcat таковым не является), а приложение на Spring стеке может работать на чем угодно (на том же Tomcat), и даже вообще без сервера (так как запустит его внутри себя самостоятельно). Это делает Spring идеальным инструментом для разработки небольших приложений с GUI на Front-end или для микросервисной архитектуры.

Но отказ от зависимости от серверов приложений отрицательно сказался на масштабируемости Spring-приложений. А Java EE хорошо подходит для реализации масштабируемого монолитного кластерного приложения. На рынке труда на текущий момент более востребованы разработчики, знакомые со Spring Framework.

Так сложилось исторически: в те времена, когда Java EE была излишне усложнена, Spring «набрал клиентскую базу». И тем не менее, однозначного ответа на вопрос что учить Spring или Java EE, нет. Новичку можно дать следующий совет. Познакомиться (хотя бы поверхностно) с обеими платформами. Написать небольшой домашний проект и на Java EE и на Spring.

А далее углубляться в тот фреймворк, который потребуется на работе. В итоге, переключаться между Spring и Java EE не составит большого труда.

Итоги

Масштабную тему, конечно же, одной статьей не охватить! После тонны новых терминов наверняка хочется “приложить” эти знания к жизненному примеру. Поэтому мы продолжим изучать Java EE: уроки практические, по настройке локального окружения для Java EE разработки, вы найдете в следующей статье.

Источник: javarush.com