Топ 30+ JMS (Java Message Service) интервюта

top 30 jms interview questions

Най-популярните въпроси и отговори за интервю за JMS за по-свежи и опитни професионалисти:

Понастоящем услугата за съобщения JMS или Java се превърна в един от най-доминиращите модели за сигурна, надеждна и мащабируема доставка на съобщения по целия свят.

Този модел е много добре структуриран и поддържа редица техники и протоколи за съобщения.

Нека да се потопим и да разгледаме някои въпроси и отговори, които често се задават по тази тема в цялата индустрия.

Най-популярни въпроси за интервю за JMS

По-долу е даден списък с най-често задаваните въпроси за интервю за Java Message Service, заедно с подробни отговори.

В # 1) Какво е JMS?

Отговор: Java Messaging Service е Java API, който позволява на системите да създават, четат, изпращат и получават съобщения.

Най-важната част от алгоритъма е много добре структурирана и позволява на едно приложение да изпраща съобщение до друго приложение, а също така дава възможност за излъчване на функции на абонатите.

В # 2) Какви са видовете комуникация, предоставяни от JMS? Обяснете подробно.

Отговор: Този API осигурява два вида комуникация:

• Асинхронно: Съобщението ще бъде доставено на клиента, не е необходимо клиентът да изпраща заявки, за да го получи. Клиентското приложение ще го получи, след като подателят изпрати приложението.
• Надежден: Тук съобщението се изпраща до клиентското приложение, след като API протоколът осигурява наличността на приложението приемник.

В # 3) Какъв е броят на моделите за съобщения, налични в JMS?

Отговор: По-конкретно, има два типа модели, предоставени от JMS:

Точка до точка: Както самото име подсказва, това е механизъм за съобщения един към един, при който подателят изпраща съобщение до един приемник. Съобщението е достъпно за приложението на получателя, след като е готово и дотогава съобщението се съхранява в опашката.

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

Публикуване и абониране: Този механизъм за съобщения е много уникално проектиран от JMS.

Например , един читател се абонира за един блог, където човекът се интересува. Сега може да има няколко души, които се интересуват от определен блог.

И те се абонират / регистрират за този блог. След като нова публикация или тема бъде публикувана в блога, всички регистрирани читатели ще получат актуализация. Този модел за съобщения се нарича Публикуване и абониране.

В # 4) Какво е опашка?

Отговор: В механизма от точка до точка на JMS, приложението източник изпраща съобщение до приложението дестинация, съобщението се консумира от приложението дестинация, след като е налично, до този момент единицата за съхранение от самото време се нарича опашка.

В # 5) Какво е тема?

Отговор: В модела Публикуване / Абониране приложението клиент / издател генерира едно съобщение и това съобщение е достъпно за всички абонати или целеви приложения. Това съобщение се нарича тема.

В # 6) Каква е основната разлика между работния механизъм на JMS и RPC?

Отговор: Различимата разлика между двата модела е между начина, по който се доставя съобщението.

В случай на JMS, приложението подател изпраща съобщението до целевото приложение и след това отново изчаква / или обработва друго съобщение според критериите за програмиране.

Докато в случая на RPC, нишката е завършена, след като съобщението достигне местоназначението и контролата се връща към метода, отговорен за транспортирането на съобщението.

В # 7) Какво представлява Middleware ориентираният към съобщенията?

Отговор: Message Oriented Middleware е софтуер, който работи между приложението подател и приложението местоназначение в работния модел на JMS.

В # 8) Как е ориентиран към съобщения Middleware отговорен за липса на времева зависимост между изпращача и получателя по отношение на модела от точка до точка в JMS?

Отговор: Тъй като междинният софтуер на MOM работи между компонента на подателя и получателя, той се грижи за съобщението и транспортира съобщението чрез механизъм за опашки. Така че, докато приложението дестинация / получател стане достъпно за получаване / четене на съобщението, съобщението се съхранява на опашка.

Най-важната част е, че методът, отговорен за изпращането на съобщението, не е зает, докато приложението на получателя не получи съобщението. По този начин приложението на подателя и получателя работи независимо, без никаква времева зависимост.

В # 9) Назовете типовете съобщения, поддържани от JMS.

Отговор: Типът съобщения, които се поддържат от JMS, са:

• Текстови съобщения
• Потокови съобщения
• Съобщения на картата
• Байтови съобщения
• Съобщения на обекти

В # 10) Какво представлява байтово съобщение?

Отговор: Обектът Bytes Message всъщност е отговорен за изпращането на съобщението, съдържащо поток от непрекъснати байтове и наследява от интерфейса на съобщението и добавя байтово тяло на съобщението. Получателят на съобщението е отговорен за интерпретацията на съобщението.

JMS API позволява транспортирането на този тип съобщения, но според oracle docs те обикновено не се използват, тъй като включването на свойства може да повлияе на формата на съобщението.

В # 11) Какво е StreamMessage?

Отговор: Обект StreamMessage се използва за изпращане на потока от примитивни типове данни в езика за програмиране Java. Данните се попълват последователно и се четат. Той се наследява от интерфейса на съобщението и добавя тяло на съобщението на потока.

java.io.DataInputStream и java.io.DataOutputStream са API, поддържащи тези видове съобщения.

В # 12) Какво е текстово съобщение?

Отговор: Текстовото съобщение е това, за което се грижи java.lang.String и то наследява от интерфейса на съобщението и добавя тяло на текстово съобщение. Това се използва за транспортиране на съобщенията, съдържащи текст.

В # 13) Какво е съобщение на обект?

Отговор: Съобщението на обект обикновено съдържа сериализуем Java обект в тялото на съобщението. Като цяло приложението-приемник получава съобщението Object в режим само за четене.

В # 14) Какво е съобщение на картата?

Отговор: Тялото на съобщението на обекта Map Message съдържа набор от двойки име-стойност, където имената са String обекти, а стойностите са Java примитиви. Записите могат да бъдат достъпни последователно или произволно по име. Map Message всъщност наследява от интерфейса на Message и добавя тяло на съобщението, което съдържа Map.

В # 15) Какво е JNDI? Как е свързано със JMS?

Отговор: JNDI е интерфейсът за имена на Java и имена. Ако приложението е свързано с база данни, това позволява на разработчика на приложението да даде име на тази база данни, вместо да се тревожи за идентификационните данни за свързване на базата данни.

JNDI API ще влезе в директорията за именуване и ще намери съпоставянето между името и обекта на базата данни и ще се свърже съответно. Можем да използваме този механизъм, докато се свързваме с произволна connectionFactory (опашка или тема) за изпращане на съобщения.

Въпрос # 16) Как приложението подател транспортира / изпраща съобщение чрез JMS?

Отговор: По-долу са дадени няколко начина за изпращане на съобщение чрез JMS:

• Приложете JNDI, за да търсите идентификационните данни на connectionFactory.
• Създайте обект connectionFactory за изпълнение.
• Идентифицирайте обектите на местоназначението (един или повече).
• Използвайте обекта connectionFactory, за да установите JMS връзка.
• Създайте една или повече сесии.
• Използвайте сесия и дестинациите, за да създадете необходимите MessageProducers и MessageConsumers.
• Общувайте с помощта на канала.

Въпрос # 17) Назовете компонентите на JMS.

Отговор: Компонентите на JMS включват:

• Доставчик на JMS
• JMS клиент
• Съобщения
• Администрирани обекти
• Родни клиенти

В # 18) Какво е Администрирани обекти в JMS?

Отговор: Административен обект JMS всъщност са тези идентификационни данни, конфигурирани от администратора, за да се свърже с JMS клиента и са дефинирани под JNDI. Тези обекти се конфигурират преди свързване с JMS клиента вътре в сървъра.

В # 19) Какви са функционалностите на JMS доставчика?

Отговор: JMS доставчикът основно се грижи за сигурността и данните.

Той е отговорен за гарантирането, че съобщението се доставя по сигурен начин, той също така се грижи за криптирането на данните и стандартите за кодиране на данни и е отговорен за извикването на съобщението за клиента, който не е JMS.

В # 20) Какво представлява JMS сесията?

Отговор: JMS сесията е състояние, контролиращо общия поток от изпращане до получаване на JMS съобщения.

В # 21) Можем ли да използваме JMS за изпращане на автоматизирани имейли?

как да отворя json файл?

Отговор: JMS няма стандартни API, поддържащи функцията, но ние можем да използваме JavaMail за изпращане на автоматизирани имейли.

Въпрос # 22) Каква е функционалността на слушателя на съобщения в контекста на JMS?

Отговор: Слушателят на съобщения обикновено се използва с потребителя на съобщения в случай на асинхронна доставка. За асинхронна доставка може да се регистрира обект на MessageListener с messageConsumer.

В # 23) Какво представлява JMS клиентът?

Отговор: JMS клиентът е основно компонент, написан на програмния език Java, който е отговорен за извикване и консумиране на тела на съобщения.

В # 24) Какво е съобщение?

Отговор: Съобщението е тяло, а по-скоро компонент, който комуникира между клиентите на JMS.

В # 25) Каква е функционалността на производителя на JMS съобщения?

Отговор: Производителят на съобщения е основно компонент, който се създава от JMS сесия за изпращане на съобщение до приложението на приемника.

Може да се създаде сесия и да се приложи интерфейсът MessageProducer за дефиниране на обект на дестинация, обект на опашка или обект на тема. Човек може да обяви производител за неуточнен, като присвоява null в аргумента си вместо обект. По-късно можем да използваме Java претоварване на метода за изпращане, за да посочим дестинация, съобщение като аргументи или параметри.

В # 26) Каква е функционалността на потребителите на JMS съобщения?

Отговор: Потребителят на съобщения е основно компонент, който се създава от JMS сесия за получаване на съобщение от приложението на приемника. Може да се създаде сесия и да се приложи интерфейс MessageConsumer за дефиниране на обект на дестинация, обект на опашка или обект на тема.

Човек може да използва createDurableSubscriber с обекта на сесията, за да създаде траен абонат на тема, но може да го използва за създаване на тема за Публикуване / Абониране на модел, а не за създаване на опашки.

Потребителят става активен, след като потребителският обект е създаден. Можем да използваме обекта за получаване и изпращане на съобщения. За да деактивирате това, можете да използвате близък метод за MessageConsumer.

В # 27) Каква е функционалността на JMS Browser Browser?

Отговор: Както вече обсъждахме концепцията за опашката, където съобщението се съхранява, докато получателят го получи. Функционалността на разглеждане на съобщенията в опашката и показване на стойностите на заглавката се поддържа от обекта QueueBrowser.

Може да се създаде обект QueueBrowser чрез. JMS сесия.

В # 28) Каква е функционалността на JMS Message Selector?

Отговор: Избирачът на JMS съобщения е основно API, който отговаря за филтрирането на съобщенията, които получава за всяко конкретно приложение. Избирателите на съобщения всъщност възлагат работата на доставчика на JMS, който всъщност отговаря за филтрирането на съобщенията.

Селекторът за съобщения всъщност приема стойности от типа низ като вход.

WatchType = ‘Titan’ ИЛИ WatchType = ‘Rolex’

Методите createConsumer и createDurableSubscriber позволяват да се посочи селектор на съобщения като аргумент, когато се създава потребител на съобщение.

В # 29) Как да се справим с изключението, причинено от JMS?

Отговор: Основният клас, отговорен за изхвърлянето на JMS изключения от JMS API е JMSException.

Улавянето на JMSException предоставя общ начин за обработка на всички изключения, свързани с JMS API.

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

• IllegalStateException
• InvalidClientIDException
• InvalidDestinationException
• InvalidSelectorException
• JMSSecurityException
• MessageEOFException
• MessageFormatException
• MessageNotReadableException
• MessageNotWriteableException
• ResourceAllocationException
• TransactionInProgressException
• TransactionRolledBackException

В # 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, за да предаде тези аргументи.

В # 31) Каква е функционалността на сървъра Oracle Glassfish? Какво допълнително предимство има върху сървъра Apache Tomcat?

Отговор: Сървърът Glassfish всъщност е сървър за приложения и може да се използва и като уеб сървър, което означава, че може да обработва HTTP заявки от уеб браузърите.

Като сървър за приложения той е разработен за обработка на всички видове Java Enterprise приложения по отношение на сървлети / JSP, а също и EJB компоненти.

Докато сървърът Tomcat всъщност е контейнер за сървлети, който обикновено се използва за работа със сървлет или JSP компоненти.

Въпрос # 32) Как да създам EJB сесия, за да стартирам JMS връзка?

Отговор: Можем да създадем EJB сесия за JMS, както сме написали в кода по-долу.

Въпрос # 33) Опишете концепцията за клъстериране, управлявано от съобщения.

Отговор: Ако приложение на базата на EJB компонент е разположено на който и да е клъстер на сървър на приложения, то то може да бъде конфигурирано да се изпълнява на всеки сървър вътре в клъстера, за да осигури наличност и мащабируемост за приложението.

Ако EJB е под формата на Message Driven Bean (MDB), тогава той може да работи на всеки сървър вътре в клъстера и може да бъде иницииран успоредно на редица сървъри на приложения в клъстера.

Заключение

Надявам се, че този списък с най-добрите въпроси за интервюта в JMS наистина би бил информативен и съм сигурен, че можете да пробиете успешно всяко интервю с задълбочено познаване на този списък.

Надяваме се, че това би ви помогнало много !! Честито обучение !!

Препоръчително четене

• Интервюирайте въпроси и отговори
• Някои интересни въпроси за интервю за тестване на софтуер
• Въпроси и отговори за интервю за ETL тестване
• Топ 12 въпроса за интервю за Mockito (подигравателно рамково интервю)
• Водещи въпроси за интервюта за формуляри и доклади на Oracle
• Софтуерно ръчно тестване Интервю въпроси за опитни професионалисти
• Разполагане на Java: Създаване и изпълнение на Java JAR файл
• Най-добрите технически въпроси за Oracle Apps и интервюта за Oracle SOA