30 найкращих запитань щодо інтерв’ю у JMS (служба повідомлень Java)

top 30 jms interview questions

Найпопулярніші запитання та відповіді на інтерв’ю у JMS для більш свіжих та досвідчених професіоналів:

На даний момент служба обміну повідомленнями JMS або Java стала однією з найбільш домінуючих моделей безпечної, надійної та масштабованої доставки повідомлень у всьому світі.

Ця модель дуже добре структурована і підтримує ряд форм методів обміну повідомленнями та протоколів.

Давайте зануримось і розглянемо деякі запитання та відповіді, які часто задають на цю тему у всій галузі.

Найпопулярніші запитання щодо інтерв’ю у JMS

Нижче наведено перелік найпоширеніших запитань щодо інтерв’ю Java Message Service разом із детальними відповідями.

Q # 1) Що таке JMS?

Відповідь: Служба обміну повідомленнями Java - це Java API, який дозволяє системам створювати, читати, надсилати та отримувати повідомлення.

Найважливіша частина алгоритму дуже добре структурована і дозволяє одній програмі надсилати повідомлення іншій програмі, а також забезпечує можливість трансляції функцій для абонентів.

Q # 2) Які типи зв'язку забезпечує JMS? Поясніть детально.

Відповідь: Цей API забезпечує два типи зв'язку:

• Асинхронні: Повідомлення буде доставлено клієнту, для того, щоб отримати його, клієнт не повинен надсилати запити. Клієнтська програма отримає її після передачі програми відправника.
• Надійний: Тут повідомлення надсилається клієнтській програмі, коли протокол API забезпечує доступність програми-одержувача.

Запитання №3) Яка кількість моделей обміну повідомленнями, доступних у JMS?

Відповідь: Зокрема, JMS пропонує два типи моделі:

Точка в точку: Як випливає з назви, це механізм обміну повідомленнями один на один, коли відправник надсилає повідомлення одному одержувачу. Повідомлення доступне додатку-одержувачу, коли воно буде готове, а до тих пір воно зберігається в черзі.

Найважливіша його частина полягає в тому, що між відправником та додатком-одержувачем є нульові залежності щодо часу.

Публікуйте та передплачуйте: Цей механізм обміну повідомленнями унікально розроблений JMS.

Наприклад , один читач передплачує один блог, де людині цікаво. Зараз може бути декілька людей, зацікавлених у тому чи іншому блозі.

І вони підписуються / реєструються на цей блог. Тепер, коли в блозі буде опубліковано нове повідомлення або тему, усі зареєстровані читачі отримають оновлення. Ця модель обміну повідомленнями називається Опублікувати та підписатись.

Q # 4) Що таке Черга?

Відповідь: У механізмі 'точка-точка' у JMS вихідна програма надсилає повідомлення цільовій програмі; повідомлення споживається цільовою програмою, коли воно стає доступним, до тих пір, поки одиниця зберігання самого часу не називається чергою.

Q # 5) Що таке тема?

Відповідь: У моделі «Опублікувати / підписатись» програма клієнт / видавець генерує одне повідомлення, і це повідомлення доступне всім передплатникам або цільовим програмам. Це повідомлення називається Темою.

Q # 6) Яка принципова різниця між робочим механізмом JMS та RPC?

Відповідь: Відмінна різниця між двома моделями полягає у способі доставки повідомлення.

У разі JMS додаток-відправник надсилає повідомлення цільовій програмі, а потім знову чекає / або обробляє інше повідомлення відповідно до критеріїв програмування.

У той час як у випадку RPC, потік завершується, як тільки повідомлення доходить до місця призначення, і елемент керування повертається до методу, відповідального за транспортування повідомлень.

Q # 7) Що таке орієнтоване на повідомлення проміжне програмне забезпечення?

Відповідь: Message Oriented Middleware - це програмне забезпечення, яке працює між додатком відправника та додатком призначення в робочій моделі JMS.

Запитання №8) Як відповідальне за повідомлення повідомлення проміжне програмне забезпечення відповідає за відсутність часової залежності між компонентом відправника та одержувача щодо моделі Point-Point на JMS?

Відповідь: Оскільки проміжне програмне забезпечення MOM працює між компонентом відправника та одержувача, воно піклується про повідомлення та транспортує повідомлення за допомогою механізму черги. Отже, поки програма призначення / одержувача не стане доступною для отримання / зчитування повідомлення, повідомлення зберігається в черзі.

Найважливіша частина полягає в тому, що метод, відповідальний за відправлення повідомлення, не використовується, поки програма-одержувач не отримає повідомлення. Таким чином, програма відправника та одержувача працює незалежно, без будь-якої часової залежності.

Q # 9) Назвіть типи повідомлень, що підтримуються JMS.

Відповідь: Тип повідомлень, які підтримує JMS:

• Текстові повідомлення
• Потокові повідомлення
• Повідомлення на карті
• Повідомлення байтів
• Повідомлення об’єктів

Q # 10) Що таке байтове повідомлення?

Відповідь: Об'єкт Bytes Message фактично відповідає за надсилання повідомлення, що містить потік безперервних байтів, і він успадковує інтерфейс повідомлення та додає байтове тіло повідомлення. Одержувач повідомлення відповідає за інтерпретацію повідомлення.

JMS API дозволяє транспортувати повідомлення цього типу, але, згідно з документами oracle, вони зазвичай не використовуються, оскільки включення властивостей може вплинути на формат повідомлення.

Q # 11) Що таке StreamMessage?

Відповідь: Об'єкт StreamMessage використовується для передачі потоку примітивних типів даних мовою програмування Java. Дані послідовно заповнюються та зчитуються. Він успадковується від інтерфейсу повідомлення та додає тіло повідомлення потоку.

java.io.DataInputStream та java.io.DataOutputStream - це API, що підтримують такі типи обміну повідомленнями.

Q # 12) Що таке текстове повідомлення?

Відповідь: Текстове повідомлення - це те, про яке піклується java.lang.String, воно успадковується від інтерфейсу повідомлення та додає тіло текстового повідомлення. Це використовується для транспортування повідомлень, що містять текст.

Q # 13) Що таке повідомлення про об'єкт?

Відповідь: Повідомлення об’єкта, як правило, містить об’єкт Java, що серіалізується, у своєму тілі повідомлення. Як правило, програма-одержувач отримує повідомлення 'Об'єкт' у режимі лише для читання.

Q # 14) Що таке повідомлення на карті?

Відповідь: Тіло повідомлення об'єкта Map Message містить набір пар імен-значення, де імена є об'єктами String, а значення - примітивами Java. Доступ до записів можна отримати послідовно або випадково за назвою. Map Message фактично успадковується від інтерфейсу Message і додає тіло повідомлення, яке містить Map.

Q # 15) Що таке JNDI? Як це пов'язано із JMS?

Відповідь: JNDI - це інтерфейс іменування та каталогу Java. Якщо додаток підключено до бази даних, це дозволяє розробнику програми давати ім'я цій базі даних, а не турбуватися про облікові дані підключення до бази даних.

API JNDI отримає доступ до каталогу імен, знайде відображення між іменем та об'єктом бази даних та підключиться відповідно. Ми можемо використовувати цей механізм під час підключення до будь-якої фабрики зв’язку (черги чи теми) для надсилання повідомлень.

Q # 16) Як додаток-відправник транспортує / надсилає повідомлення через JMS?

Відповідь: Нижче наведено кілька способів надсилання повідомлення через JMS:

• Впровадити JNDI для пошуку облікових даних з'єднання Factory.
• Створіть об'єкт connectionFactory для реалізації.
• Визначте об’єкти призначення (один або кілька).
• Використовуйте об'єкт connectionFactory для встановлення з'єднання JMS.
• Створіть один або кілька сеансів.
• Використовуйте сеанс і пункти призначення, щоб створити потрібні MessageProducers та MessageConsumers.
• Спілкуйтеся за допомогою каналу.

Q # 17) Назвіть компоненти JMS.

Відповідь: До компонентів JMS належать:

• Провайдер JMS
• Клієнт JMS
• Повідомлення
• Адміністративні об'єкти
• Рідні клієнти

Q # 18) Що таке об’єкти, що адмініструються в JMS?

Відповідь: Об'єкт, яким керує JMS, насправді є тими обліковими даними, які налаштовані адміністратором для підключення до клієнта JMS і визначаються в JNDI. Ці об'єкти налаштовуються перед підключенням до клієнта JMS усередині сервера.

Q # 19) Які функціональні можливості постачальника JMS?

Відповідь: Постачальник JMS в основному піклується про безпеку та дані.

Він несе відповідальність за забезпечення безпечної доставки повідомлення, а також відповідає за стандарти шифрування даних та кодування даних і відповідає за виклик повідомлення для клієнта Non-JMS.

Q # 20) Що таке сесія JMS?

Відповідь: Сеанс JMS - це стан, який контролює загальний потік від надсилання до отримання повідомлень JMS.

Питання # 21) Чи можемо ми використовувати JMS для надсилання автоматизованих електронних листів?

як писати автоматизовані тестові скрипти

Відповідь: JMS не має стандартних API, що підтримують цю функцію, однак ми можемо використовувати JavaMail для надсилання автоматизованих електронних листів.

Q # 22) Яка функціональність прослуховувача повідомлень у контексті JMS?

Відповідь: Слухач повідомлень, як правило, використовується із споживачем повідомлень у разі асинхронної доставки. Для асинхронної доставки можна зареєструвати об'єкт MessageListener за допомогою messageConsumer.

Q # 23) Що таке клієнт JMS?

Відповідь: Клієнт JMS - це в основному компонент, написаний мовою програмування Java, який відповідає за виклик і споживання тіл повідомлень.

Q # 24) Що таке повідомлення?

Відповідь: Повідомлення - це тіло, а не компонент, який здійснює зв'язок між клієнтами JMS.

Питання # 25) Яка функціональність виробника повідомлень JMS?

Відповідь: Виробник повідомлень - це, в основному, компонент, який створюється сеансом JMS для надсилання повідомлення додатку-одержувачу.

Можна створити сеанс і реалізувати інтерфейс MessageProducer для визначення об'єкта призначення, об'єкта черги або об'єкта теми. Можна оголосити виробника невизначеним, присвоївши в аргументі значення null замість об’єкта. Пізніше ми можемо використовувати перевантаження методу Java для методу send, щоб вказати пункт призначення, повідомлення як аргументи чи параметри.

Q # 26) Яка функціональність споживачів повідомлень JMS?

Відповідь: Споживач повідомлень - це в основному компонент, який створюється сеансом JMS для отримання повідомлення програмою-одержувачем. Можна створити сеанс і реалізувати інтерфейс MessageConsumer для визначення об'єкта призначення, об'єкта черги або об'єкта теми.

Можна використати createDurableSubscriber з об’єктом сеансу для створення довговічного передплатника теми, але можна використовувати його для створення теми для моделі Publish / Subscribe, а не для створення черг.

Споживач стає активним після створення споживчого об'єкта. Ми можемо використовувати об’єкт для отримання та надсилання повідомлень. Для того, щоб деактивувати це, можна скористатися методом close для MessageConsumer.

Q # 27) Яка функціональність браузера JMS Queue?

Відповідь: Як ми вже обговорювали концепцію черги, де повідомлення зберігається, поки одержувач його не отримає. Функціональність перегляду повідомлень у черзі та відображення значень заголовків підтримується об’єктом QueueBrowser.

Можна створити об'єкт QueueBrowser за допомогою. Сесія JMS.

Q # 28) Яка функціональність засобу вибору повідомлень JMS?

Відповідь: Засіб вибору повідомлень JMS - це в основному API, який відповідає за фільтрацію повідомлень, які він отримує для будь-якої конкретної програми. Селектори повідомлень фактично призначають роботу постачальнику JMS, який фактично відповідає за фільтрацію повідомлень.

Селектор повідомлень фактично приймає значення типу рядка як вхідні дані.

WatchType = 'Titan' АБО WatchType = 'Rolex'

Методи createConsumer і createDurableSubscriber дозволяють вказати селектор повідомлень як аргумент, коли створюється споживач повідомлень.

Q # 29) Як обробляти виняток, спричинений JMS?

Відповідь: Основним класом, відповідальним за створення винятків, пов'язаних із JMS, за допомогою API JMS є JMSException.

Зловживання JMSException забезпечує загальний спосіб обробки всіх винятків, пов'язаних з API JMS.

Клас винятків JMS включає такі підкласи, які описані в документації API:

• IllegalStateException
• Недійсний викликClientIDE
• InvalidDestinationException
• InvalidSelectorException
• JMSSecurityException
• MessageEOFException
• MessageFormatException
• MessageNotReadableException
• MessageNotWriteableException
• ResourceAllocationException
• TransactionInProgressException
• TransactionRolledBackException

Q # 30) Як обробляти сеанси, за якими не здійснюється транзакція щодо JMS?

Відповідь: У випадку сеансів, які не виконували транзакції, повідомлення підтверджуються на основі аргументу, переданого під час створення об'єкта сеансу методом QueueSession або TopicSession.

Наведені нижче варіанти зазвичай використовуються відповідно до бізнес-вимог:

• Сесія. AUTO_ACKNOWLEDGE: Якщо хтось передає цей аргумент під час створення об'єкта сеансу, тоді, якщо трапляється JMSException, надійний споживач чекає кілька секунд, а потім викликає метод MessageConsumer.receive для отримання повідомлень знову. Через відмову, якщо будь-яке повідомлення не буде доставлено, воно буде повторно надіслано.

• Сесія. CLIENT_ACKNOWLEDGE: Якщо хтось передає цей аргумент під час створення об'єкта сеансу, тоді, якщо відбувається JMSException, споживач викликає Session.recover перед тим, як викликати Message.aknowledge або MessageConsumer.receive, оскільки Session.recover відповідає за відновлення та повторну доставку непідтверджених повідомлень.

• Сесія. DUPS_OK_ACKNOWLEDGE: Якщо хтось передає цей аргумент під час створення об'єкта сеансу, тоді, якщо трапляється JMSException, надійний споживач чекає кілька секунд, а потім викликає метод MessageConsumer.receive для отримання повідомлень знову. Але тут можна отримати повторювані повідомлення або такі ж повідомлення, що повторно доставлені, як у цьому режимі, перед відмовою, підтверджені повідомлення можуть бути повторно доставлені.

Примітка : Тут у прикладі коду я використовував QueueSession, але для передачі цих аргументів можна використовувати TopicSession.

Q # 31) Яка функціональність сервера Oracle Glassfish? Яка додаткова перевага у нього над сервером Apache Tomcat?

Відповідь: Сервер Glassfish насправді є сервером додатків і може також використовуватися як веб-сервери, що означає, що він може обробляти HTTP-запити з веб-браузерів.

Як сервер додатків, він розроблений для обробки всіх типів програм Java Enterprise з точки зору сервлетів / JSP, а також компонентів EJB.

Тоді як сервер Tomcat насправді є контейнером сервлетів, який зазвичай використовується для роботи з сервлетом або компонентами JSP.

Q # 32) Як створити сеанс EJB для того, щоб запустити з'єднання JMS?

Відповідь: Ми можемо створити сеанс EJB для JMS, як ми писали в коді нижче.

Q # 33) Опишіть концепцію кластеризації керованих бобових повідомлень.

Відповідь: Якщо додаток на основі компонентів EJB розгорнуто на будь-якому кластері серверів додатків, його можна налаштувати для запуску на будь-якому сервері всередині кластера для забезпечення доступності та масштабованості програми.

Якщо EJB у формі Message Driven Bean (MDB), він може працювати на будь-якому сервері всередині кластера і може ініціюватися паралельно ряду серверів додатків у кластері.

Висновок

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

Сподіваємось, це могло б вам дуже допомогти !! Щасливого навчання !!

Рекомендована література

• Запитання та відповіді на інтерв’ю
• Деякі цікаві питання для тестування програмного забезпечення
• Запитання та відповіді на інтерв’ю для тестування ETL
• Найпопулярніші 12 запитань інтерв’ю Mockito (глузуюче рамкове інтерв’ю)
• Найпопулярніші запитання для інтерв’ю щодо форм та звітів Oracle
• Тестування посібника для програмного забезпечення Інтерв’ю Питання для досвідчених професіоналів
• Розгортання Java: створення та виконання файлу Java JAR
• Найпопулярніші технічні запитання щодо програм Oracle та запитання щодо інтерв’ю SOA Oracle