Jakarta что это за программа
Перейти к содержимому

Jakarta что это за программа

  • автор:

Единый Клиент Jakarta — что это такое?

Единый Клиент Jakarta — программа для работы и настройки USB-токенов, смарт карт JaCarta (изменение PIN-пароля, доступ к информации об устройстве, просмотр данных, создание ключей и др.).

Разбираемся

  1. Единый Клиент Jakarta это программа, которая нужна для работы двухфакторной аутентификации, настройки и работы с USB-токенами и смарт-картами JaCarta.
  2. Эта программа позволяет просмотреть содержимое и настроить USB-токены, смарт карты. Поддержка отечественных и зарубежных криптографических алгоритмов. Поддержка популярных криптопровайдеров. Генерация ключевых пар и запросов на сертификат (чтобы получить доступ к конфиденциальной информации).
  3. JaCarta – новое поколение смарт-карт, USB-, MicroUSB- и Secure MicroSD-токенов для строгой аутентификации, электронной подписи и безопасного хранения ключей, цифровых сертификатов. Название JaCarta происходит от Java Card, т.е. они сделаны с использованием технологии Java. Внутри токена находится чип смарт-карты, на него записывается специальный Java апплет и ключ закрывается от записи. После этого ключ полностью выполняет те функции, которые в нем заданы загруженным Java апплетом, по такой же технологии выполнены ключи предыдущего поколения eToken.

Надеюсь данная информация оказалась полезной. Удачи и добра.

Единый Клиент JaCarta

Единый Клиент JaCarta

Поддерживается работа с известными криптопровайдерами (например, КриптоПро CSP, ViPNet CSP и др.) без установки дополнительного программного обеспечения.

ПК «Единый Клиент JaCarta» может работать в двух режимах.

  • Режим пользователя позволяет просматривать краткие сведения о подсоединённых USB-токенах/смарт-картах и предоставляет доступ к базовым операциям с ними.
  • Режим администрирования позволяет просматривать полные сведения о подсоединённых USB-токенах/смарт-картах и предоставляет доступ ко всем операциям с ними.

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

Единое прикладное программное обеспечение

Единое прикладное программное обеспечение для разных моделей USB-токенов и смарт-карт JaCarta

Работа с комбинированными USB-токенами и смарт-картами

Работа с комбинированными USB-токенами и смарт-картами (например, JaCarta-2 PKI/ГОСТ) в одном окне

Поддержка устройств

Поддержка устройств как c российской, так и с зарубежной криптографией

Две версии интерфейса

Две версии интерфейса: упрощённый — для рядовых пользователей и расширенный — для продвинутых пользователей (администраторов)

Запрос на цифровой сертификат

Возможность создания запроса на цифровой сертификат

Работа с популярными криптопровайдерами

Работа с популярными криптопровайдерами, например, с КриптоПро CSP

JaCarta SecurLogon

Возможности ПК «Единый Клиент JaCarta» могут быть расширены при активации платной опции JaCarta SecurLogon, позволяющей быстро осуществить переход от однофакторной аутентификации с использованием пары логин/пароль к усиленной двухфакторной аутентификации с помощью USB-токенов и смарт-карт JaCarta.

При этом разворачивать инфраструктуру открытых ключей (PKI) или Active Directory не обязательно — в устройства записывается сложный пароль, используемый в процессе аутентификации в информационной системе в момент предъявления USB-токена/смарт-карты и ввода PIN-кода пользователя.

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

Поддержка новых ГОСТов 2012 года

JaCarta-2 ГОСТ

ПК «Единый Клиент JaCarta» поддерживает новое поколение USB-токенов и смарт-карт JaCarta-2 ГОСТ, в которых аппаратно реализованы как старые криптографические алгоритмы ГОСТ Р 34.11-94 и ГОСТ Р 34.10-2001 , так и новые алгоритмы ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012 .

Применение JaCarta-2 ГОСТ позволяет обеспечить совместимость с существующими прикладными системами и сервисами, использующими старые стандарты электронной подписи (ЭП), и плавно перейти на использование новых стандартов формирования ЭП.

Технические подробности

Microsoft Windows

  • Windows 11
  • Windows 10 (32/64-бит)
  • Windows 8.1 (32/64-бит)
  • Windows 7 SP1 (32/64-бит)

Microsoft Windows Server

  • Windows Server 2022
  • Windows Server 2019
  • Windows Server 2016
  • Windows Server 2012 R2
  • Windows Server 2012
  • Windows Server 2008 R2 SP1

Linux (x64, х86)

  • Astra Linux SE 1.6/1.7 (x64)
  • РЕД ОС 7.2/7.3/8 (x64)
  • Альт 8 СП (x64)
  • Альт Рабочая станция 10 (x64)
  • Альт Сервер 10 (x64)
  • Ubuntu 16/18/20/22/24 (x64)
  • Ubuntu 16 (x86)
  • Debian 9/10/11 (x64)
  • ОС «СТРЕЛЕЦ» (x64)
  • ОС ОCнова (x64)
  • СинтезМ Клиент (x64)
  • CentOS 7/8/9 (x64)
  • ОС РОСА КОБАЛЬТ/ХРОМ/ФРЕШ (x64)
  • ОС AlterOS (x64)
  • ЕМИАС ОС 1.0 (64-бит)
  • Simply Linux (x64)
  • GosLinux
  • Linux Mint 21

Linux (Байкал-М/amr64)

  • Astra Linux 4.7
  • Альт рабочая станция 10
  • РЕД ОС 7.3
  • Simply Linux

Linux (Эльбрус/e2k-8c)

macOS (x64, arm64)

  • macOS 10.12 Sierra
  • macOS 10.13 High Sierra
  • macOS 10.14 Mojave
  • macOS 10.15 Catalina
  • macOS 11 Big Sur
  • macOS 12 Monterey
  • macOS 13 Ventura
  • macOS 14 Sonoma
  • Для USB-токенов — USB-порт.
  • Для смарт-карт необходимо наличие подключенного смарт-карт ридера (например, JCR721).
  • Для USB-токенов в форм-факторе microUSB можно использовать USB-порт через переходник microUSB-to-USB.
  • JaCarta PKI
  • JaCarta PKI/BIO
  • JaCarta ГОСТ
  • JaCarta PKI/ГОСТ
  • JaCarta PKI/BIO/ГОСТ
  • JaCarta PRO
  • JaCarta PRO/ГОСТ
  • JaCarta PKI/Flash
  • JaCarta ГОСТ/Flash
  • JaCarta PKI/ГОСТ/Flash
  • JaCarta WebPass
  • JaCarta U2F/WebPass
  • JaCarta SF/ГОСТ
  • JaCarta LT
  • JaCarta-2 ГОСТ
  • JaCarta-2 PKI/ГОСТ
  • JaCarta-2 PKI/BIO/ГОСТ
  • JaCarta-2 PRO/ГОСТ
  • JaCarta-2 SE
  • Единый Клиент JaCarta
  • JaCarta SecurLogon (платное дополнение)

Версия 3.1

  • Добавили поддержку новых версий ОС (РЕД ОС 8, macOS 14 Sonoma, РОСА ХРОМ/ФРЕШ, Ubuntu 24);
  • Поддержали работу в планшетном режиме Astra Linux;
  • Добавили возможность использования Aladdin SecurBIO Reader в продукте Aladdin SecurLogon;
  • Добавили возможность зарегистрировать JaCarta Virtual Token в т.ч. до входа в ОС;
  • Оптимизировали работу в сценариях подключения Linux -> Windows по RDP;
  • Повысили качество и скорость работы Единой Библиотеки;
  • Реализовали возможность форматирования JaCarta PKI по шаблону;
  • Реализовали возможность настроить показ уведомления об истечении времени жизни PIN-кода;
  • Добавили логирование действий пользователя в журнале событий ОС Linux;
  • Добавили отображение имени издателя сертификата в блоке «Ключи и сертификаты»;
  • Добавили отображение лицензии Secret Disk в блоке «Ключи и сертификаты»;
  • Выполнили ряд улучшений и исправлений в работе ПО.

Версия 3.0

  • Поддержали биометрический смарт-карт ридер Aladdin SecurBIO Reader в ОС Windows, Linux;
  • Поддержали отечественный процессор Байкал-М под ОС Astra Linux 4.7, Альт, РЕД ОС;
  • Поддержали отечественный процессор Эльбрус (e2k-8c) под Astra Linux 8.1;
  • Выполнена сборка под архитектуру процессоров Apple M1/M2;
  • Реализовали возможность форматирования JaCarta LT с заблокированным PIN-кодом администратора;
  • Добавили поддержку следующих ОС: Альт Рабочая станция 10, Simply Linux, ОСнова, ОС Стрелец, Синтез-М, Ubuntu 22, Debian 11, Windows 11/Server 2022, macOS 12/13;
  • Реализовали возможность изменения качества PIN-кода пользователя для JaCarta PKI без форматирования устройства;
  • В JaCarta SecurLogon поддержали обработку политик PIN-кода токена;
  • Добавлена поддержка работы по профилям JaCarta SecurLogon в популярных браузерах;
  • Для токенов JaCarta PKI, JaCarta PRO поддержаны механизмы подписи PSS для алгоритмов RSA;
  • Добавлена поддержка работы с VPN сервисами (openvpn, fortinet и др.) через минидрайвер и pkcs#11 интерфейс;
  • Поддержали работу минидрайверов для JaCarta PKI и JaCarta PRO в Windows с включенным LSA Protection;
  • Добавлена возможность разблокировки PIN-кода пользователя в оснастке “Управление токеном” по PIN-коду администратора;
  • Отображаем дату истечения PIN-кода, если задан срок действия;
  • Добавлена возможность уведомления об истечении срока действия PIN-кода в виде диалогового окна;
  • Логирования операций в журнал событий Windows;
  • Реализовали переключение режимов работы ридеров JCR (режим, соответствующий стандарту ISO 7816-3 и ускоренный режим);
  • Реализовали переключение режимов работы биометрической системы (стандартный режим биометрической системы смарт-карт ридера и упрощённый режим);
  • Добавлена возможность изменения количества JaCarta Virtual Reader в GUI инсталятора.

Версия 2.13

  • Драйверы режима ядра аттестованы и подписаны службой Microsoft Windows Hardware Compatibility Publisher для функционирования в ОС Microsoft Windows с включенным режимом безопасной загрузки (UEFI Secure Boot), начиная с Windows 10 и Server 2016.
  • Добавлена поддержка следующих операционных систем семейства Linux:
    • Ubuntu 16, 18, 20
    • Debian 9, 10
    • CentOS 7, 8
    • AlterOS
    • Альт 9
    • РЕД ОС 7.3 МУРОМ
    • РОСА «КОБАЛЬТ» 7.3
    • ROSA ENTERPRISE LINUX 7.3
    • macOS 11 Big Sur
    • Microsoft Windows XP
    • Microsoft Windows Vista
    • Microsoft Windows Server 2003.
    • криптопровайдер Athena
    • модуль поддержки Signal-COM CSP
    • АРМ УЦ
    • поддержка работы устаревших моделей JaCarta (выпуск до 2014 года включительно) в продуктах VMware
    • поддержка JaCarta Secure MicroSD (данный драйвер доступен отдельно на сайте компании).

    Версия 2.12.2

    • Добавлена поддержка операционных систем семейства Linux и macOS
    • Для ОС Astra Linux SE 1.5, 1.6 и 1.7 «Смоленск» (64-бит) реализована возможность двухфакторной аутентификации пользователя по сертификату на USB-токене или смарт-карте JaCarta PKI при входе в систему
    • При установке ПО «Единый Клиент JaCarta» для Microsoft Windows по умолчанию используется Microsoft Base Smart Card Cryptographic Service Provider. Для использования Athena CSP необходимо запустить установку ПО «Единый Клиент JaCarta» в режиме «Изменение» и выбрать соответствующую опцию
    • Добавлена поддержка разблокировки токенов JaCarta-2 ГОСТ с помощью специальной строки, полученной от администратора безопасности (Challenge-Response)
    • Обновлён компонент АРМ УЦ для генерации запросов на сертификат, онлайн- и офлайн режимов работы с КриптоПРО УЦ 2.0
    • Добавлена поддержка КриптоПро JCP 2.0
    • Добавлена возможность отключения уведомлений об истекших сертификатах
    • При форматировании токенов JaCarta-2 ГОСТ осуществляется удаление всех объектов на токене
    • Отключена возможность копирования сертификатов в локальное хранилище Microsoft Windows
    • Добавлена поддержка драйвера виртуального смарт-карт ридера JaCarta Virtual Reader
    • Обеспечена корректная идентификация моделей JaCarta SF/ГОСТ и JaCarta-2 SF
    • Добавлена поддержка смарт-карт ридера JCR721 производства компании «Аладдин Р.Д.»
    • Расширен список поддерживаемых USB-устройств (VID/PID)
    • Оптимизирован способ хранения информации в файловой системе токена JaCarta LT
    • Обеспечена поддержка VipNet Client 4.5.1 и 4.5.2
    • Повышена стабильность работы
    • Устранены уязвимости, выявленные с помощью статического анализатора исходного кода

    Версия 2.11

    • Добавлена поддержка устройств JaCarta-2 ГОСТ (включая комбинированные модели) — нового поколения USB-токенов и смарт-карт с аппаратной реализацией криптографических алгоритмов ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012 для работы с усиленной квалифицированной электронной подписью и строгой двухфакторной аутентификации;
    • Добавлена поддержка USB-токенов и смарт-карт JaCarta PRO — сертифицированных устройств для строгой двухфакторной аутентификации на основе зарубежных криптоалгоритмов и совместимых с инфраструктурой для eToken PRO (Java);
    • Добавлена поддержка USB-токенов и смарт-карт eToken PRO (Java) 72К (в том числе eToken Anywhere) без необходимости установки дополнительного программного обеспечения (ПО);
    • В состав дистрибутива добавлено ПО JaCarta АРМ УЦ, позволяющее формировать запросы к Удостоверяющему центру на получение сертификата открытого ключа и записывать полученные сертификаты в память USB-токенов и смарт-карт JaCarta ГОСТ или eToken ГОСТ. При этом закрытые ключи пользователей генерируются в устройствах и никогда их не покидают.

    Предполагаемые принципы проектирования для Jakarta EE

    Привет, Хабр! У нас совсем недавно вышла книга «Изучаем Java EE. Современное программирование для больших предприятий» от немецкого Java-чемпиона Себастьяна Дашнера.

    Господин Дашнер активно пишет и выступает на темы, связанные с современной Java EE, поэтому в своем блоге не обошел вниманием и общие принципы проектирования для платформы Jakarta EE, ныне разрабатываемой Eclipse. Перевод именно этой статьи (июньской) мы сегодня предлагаем вашему вниманию.

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

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

    Я решил написать эту статью, вдохновившись предложениями Дмитрия Корнилова о том, в каком направлении должно пойти техническое развитие Jakarta EE.

    Первым делом – бизнес-логика

    Модель программирования, принятая в Java EE, позволяет разработчику сосредоточиться именно на том, на чем требуется – то есть, на бизнес-логике. Больше не требуется наследовать классы API; разработчик может излагать логику своей предметной области на обычном языке Java и преимущественно декларативно (при помощи аннотаций) управлять поведением сервера приложений. Таким образом, фреймворк гладко интегрируется в ваш код и, в сущности, его столь же легко оттуда убрать. При проектировании рассчитывайте не на переиспользование, а на легкое удаление.

    Однако, реализации должны по максимуму избавлять разработчика от наиболее тяжелого труда – то есть, позволить ему отвлечься от технических требований, не связанных с бизнес-логикой. Примеры – многопоточность, транзакции, инверсия управления или обработка HTTP-запросов. На стороне приложения занудство – благо 🙂

    Мне кажется важным, что фреймворк не только не мешает реализации бизнес-логики, но и стимулирует программистов быстрее выводить в продакшен разрабатываемые возможности. Незачем полировать фреймворк до блеска – лучше довести до идеала код бизнес-логики. Сравните современную Java EE или Spring с дедовскими версиями J2EE – думаю, сразу поймете, о чем я.

    Jakarta EE должна развиваться в том же русле и, соответственно, сосредоточиться на спецификациях, которые позволят разработчикам максимально быстро реализовывать бизнес-логику.

    Соглашения по конфигурации

    В Java EE сведена к минимуму конфигурация, необходимая для определения типичного корпоративного приложения. В большинстве практических ситуаций соглашения работают прямо из коробки, никакой конфигурации соблюдать не требуется. Так, больше не нужно никаких XML-файлов, чтобы сконфигурировать простое приложение для Java EE. Другой пример – в JAX-RS предоставляются действующие по умолчанию коды HTTP-откликов, соответствующие возвращаемым значениям методов JAX-RS.

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

    Интероперабельность спецификаций

    Jakarta EE должна продолжать и расширять интероперабельность спецификаций. В Java EE соблюдаются существующие спецификации и та присутствующая в них функциональность, которая уже стала частью стандарта.

    Разработчики могут рассчитывать на то, что разрозненные спецификации будут хорошо взаимодействовать друг с другом, и никакой конфигурации при этом не потребуется. Стандарты требовали: если среда времени выполнения поддерживает как спецификацию A, так и спецификацию B, то A + B должны взаимодействовать друг с другом. Примеры: валидация компонентов, JAXB или JSON-B могут применяться в классах ресурсов JAX-RS, и никакой дальнейшей конфигурации не требуется.

    Внедрение зависимостей и CDI

    Конечно, нежелательно, чтобы в Jakarta EE заново изобретались те вещи, которые уже существуют – например, внедрение зависимостей, относящееся к CDI. Желательно, чтобы спецификации использовали и акцентировали сильные стороны JSR 330 или, если потребуется, CDI.

    Свежий пример — использование UriInfo из JAX-RS в методах ресурсов. Аннотация @Inject пока еще не поддерживает внедрения методов такого типа. Программисту тем удобнее работать, чем больше он полагается при этом на универсальный механизм.

    Другая конкретная мера такова: в спецификациях должны предоставляться поставщики CDI, а при необходимости – квалификаторы typesafe для типов, которые потребуется создавать. Так, на настоящий момент экземпляр клиента JAX-RS можно получить только программно, через API ClientBuilder . Производители и квалификаторы упрощают работу программиста, поскольку обеспечивают декларативные определения.

    Декларативные подходы

    При всем этом API Java EE серьезно полагается на декларативный подход, при этом используется инверсия управления. Таким образом, разработчики не вызывают функционал напрямую; за вызов функционала отвечает контейнер, при этом мы опираемся на определения кода. Примеры (из наиболее современных спецификаций) — JAX-RS, JSON-B или CDI.

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

    Стратегии развертывания

    Характернейшая особенность (а на мой взгляд – и большое преимущество) Java EE заключается в том, что предлагаемая здесь модель развертывания, в которой проблемы бизнес-логики отмежевываются от реализации. Разработчик программирует исключительно под API, который не входит в состав артефакта развертывания и реализуется контейнером приложения.
    Такие компактные артефакты развертывания упрощают и ускоряют доставку программы, в том числе, сборку, публикацию и развертывание как таковое. Также они совместимы с уровнями контейнерной файловой системы, используемой, например, в Docker. В процессе сборки необходимо всего лишь пересобрать или повторно передать изменившиеся элементы.

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

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

    Тестируемость

    Применяя вышеперечисленные принципы, особенно отдавая предпочтение декларативному программированию и внедрению зависимостей, мы совершенствуем тестируемость бизнес-кода. Таким образом, разработчики могут напрямую инстанцировать объекты в тестовых сценариях, поскольку теперь не требуется наследовать классы API или вызывать неудобный функционал, который ранее потребовалось бы сымитировать.

    Однако, в Jakarta EE требуется серьезно доработать стандартизацию интеграционного тестирования на уровне кода, так, чтобы оно не зависело от производителя. Ранее именно с этим приходилось иметь дело при работе с Arquillian. В реальных проектах был бы полезен такой стандарт, который позволяет объявлять только сценарии тестового развертывания и вызывать функционал для одного или нескольких компонентов. Ранее я уже писал, что не считаю чрезмерно важным интеграционное тестирование на уровне кода, например, при выполнении приложения во встроенных контейнерах. Однако, если стандартизировать интеграционные тесты на уровне кода, это явно даст положительный эффект.

    Думаю, неслучайно API Java EE так широко применяются в реальных проектах: эти API хорошо продуманы и спроектированы в соответствии с четкими принципами, благодаря которым удалось унифицировать даже не единственную спецификацию, а целую платформу. Они позволяют пользоваться сразу несколькими спецификациями, выдержанными в едином духе. Здесь удалось избавиться от искусственных препятствий, только усложняющих работу программиста – поэтому, полагаю, вся enterprise-разработка стала гораздо приятнее.

    • Блог компании Издательский дом «Питер»
    • Программирование
    • Java

    Jakarta EE как мост между старыми и новыми ИТ

    Технология Jakarta EE, ранее известная как Java EE, помогает соединить старые и новые технологии — скажем, обеспечить сочетание старых и облачных приложений в гибридной облачной среде, — и позволяет приложениям эффективно взаимодействовать, утверждают опрошенные порталом Enterprisers Project эксперты.

    «Java EE теперь находится под новым руководством», — отмечает Майк Милинкович, исполнительный директор Eclipse Foundation. Он напоминает, что Oracle передала Java EE в Eclipse в 2017 г., и она стала Open Source-проектом. Впоследствии название было изменено на Jakarta EE. Сегодня проект курируется рабочей группой Jakarta EE Working Group, в которую входят лидеры индустрии Java, такие как Fujitsu, IBM, Oracle, Payara, Red Hat и Tomitribe.

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

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

    Jakarta EE составляет основу многих критически важных современных корпоративных систем, отмечает Марк Литтл, вице-президент по разработке промежуточного ПО компании Red Hat. По его словам, стабильность, зрелость спецификаций и надежность реализаций, основанных на ней, являются основой ее ценности сегодня и в будущем.

    Что собой представляет Jakarta EE

    «Jakarta EE — это платформа коммерческого уровня, которая предлагает набор компонентов и API для разработки бизнес-приложений на Java, — говорит Милинкович. — Jakarta EE расширяет популярную платформу Java SE спецификациями для разработки и запуска масштабируемых, надежных и безопасных корпоративных приложений».

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

    «Jakarta EE — это зрелый фреймворк на базе Java, который в основном используется для разработки веб-сервисов или API», — говорит Дана Уайатт, старший инструктор по разработке ПО компании DevelopIntelligence.

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

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

    Для чего используется Jakarta EE

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

    «Ваша система оформления заказа должна взаимодействовать с вашей системой авторизации кредитов, если пользователь покупает товар онлайн с помощью кредитной карты, — говорит Уайатт. — Но, возможно, вашему приложению поддержки клиентов также необходимо взаимодействовать с вашей системой авторизации кредитов, чтобы принимать платежи по телефону или даже выдавать кредиты». Jakarta EE может стать той телефонной линией, которая эффективно соединит эти различные приложения.

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

    «Сеть отелей может предоставить API, написанный с использованием Jakarta EE, который, во-первых, обеспечивает доступ к местоположению отеля и типам номеров; во-вторых, возвращает информацию о наличии мест и ценах на основе конкретных запросов; и, в-третьих, принимает запросы на бронирование, — говорит Уайатт. — Вместо того чтобы размещать этот API на собственных компьютерах, отель размещает его в публичном облаке. Затем гостиничная сеть нанимает туристические сайты, чтобы они использовали API и предоставляли номера отеля, когда онлайн-пользователи запрашивают информацию о планируемом путешествии».

    Почему Jakarta EE важна

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

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

    По его словам, Jakarta EE служит фреймворком для разработки и поддержки как нативных облачных архитектур, таких как микросервисы, так и традиционных монолитных приложений, а также для связи с новейшими парадигмами ПО, такими как контейнеры, микросервисы и оркестровка.

    «Такая гибкость означает, что организации могут развивать свои корпоративные и коммерческие приложения таким образом, чтобы максимально использовать существующие инвестиции в технологии и инфраструктуру, — говорит Милинкович. — В то же время они могут разрабатывать новые, нативно-облачные приложения, которые повышают гибкость, согласованность и автоматизацию».

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

    «Jakarta EE помогает избежать написания лишнего кода и значительно снизить стоимость и сложность разработки, развертывания и управления модульными серверными приложениями», — говорит Владимир Синкевич, руководитель отдела Java-разработки компании ScienceSoft.

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

    Связь с гибридным облаком

    Милинкович подчеркивает открытость и нейтральность платформы Jakarta EE по отношению к производителям. Оба эти фактора имеют решающее значение для гибридных облачных и все более распределенных систем. Они также являются важным признанием современной ИТ-реальности, согласно которой переход на облачные технологии — если вы не стартап, создающий все с нуля, — не влечет за собой отказ от остального ИТ-портфеля. Именно здесь на помощь приходят API.

    «Прелесть API заключается в том, что они позволяют взаимодействовать между разнородными или разрозненными системами, используя стандартный протокол обмена сообщениями, — говорит Уайатт. — Проще говоря, это означает, что приложение, написанное на старой платформе, такой как COBOL, может взаимодействовать с API, написанными для совершенно других, более новых платформ. Ни одно из приложений не заботится о том, как работает другое, ему важно только, чтобы API принимали и возвращали данные в соответствии с ожиданиями».

    Почему еще важна эта технология? Jakarta EE также должна помочь предприятиям быстрее внедрять инновации благодаря более быстрому выпуску обновлений (за последние 20 лет для Java EE было выпущено лишь восемь релизов). Она также снижает барьеры для участия в сообществе: Eclipse Foundation обеспечивает прозрачный процесс итераций и инноваций в разнообразной экосистеме поставщиков, системных интеграторов и членов сообщества, без единого субъекта с главенствующей ролью.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *