Najlepšie 30+ otázky týkajúce sa rozhovorov s JMS (Java Message Service)

top 30 jms interview questions

Najobľúbenejšie otázky a odpovede týkajúce sa rozhovorov JMS pre čerstvejších a skúsených profesionálov:

Služba JMS alebo Java Messaging Service sa v súčasnosti stala jedným z najdominantnejších modelov bezpečného, ​​spoľahlivého a škálovateľného doručovania správ po celom svete.

Tento model je veľmi dobre štruktúrovaný a podporuje množstvo foriem techník a protokolov zasielania správ.

Poďme sa ponoriť a prejdime si niekoľko otázok a odpovedí, ktoré sa na túto tému v priemysle často kladú.

Najobľúbenejšie otázky týkajúce sa rozhovorov JMS

Ďalej je uvedený zoznam najčastejšie kladených otázok pri rozhovoroch so službou Java Message Service spolu s podrobnými odpoveďami.

Otázka 1) Čo je JMS?

Odpoveď: Java Messaging Service je rozhranie Java API, ktoré umožňuje systémom vytvárať, čítať, odosielať a prijímať správy.

Najdôležitejšia časť algoritmu je veľmi dobre štruktúrovaná a umožňuje jednej aplikácii poslať správu inej aplikácii a tiež umožňuje predplatiteľom funkcie vysielania.

Otázka 2) Aké sú typy komunikácie poskytované JMS? Vysvetlite podrobne.

Odpoveď: Toto API poskytuje dva typy komunikácie:

• Asynchrónne: Správa bude doručená klientovi, nie je potrebné, aby klient zasielal žiadosti, aby ju mohol prijať. Klientska aplikácia ju dostane hneď po odoslaní aplikácie odosielateľa.
• Spoľahlivý: Tu sa správa odošle do klientskej aplikácie, akonáhle protokol API zabezpečí dostupnosť aplikácie prijímača.

Otázka č. 3) Aký je počet modelov zasielania správ dostupných v JMS?

Odpoveď: Konkrétne JMS poskytuje dva typy modelov:

Z bodu na bod: Ako už samotný názov napovedá, ide o mechanizmus zasielania správ jeden na jedného, ​​kedy odosielateľ odošle správu jednému príjemcovi. Správa je k dispozícii aplikácii prijímača, akonáhle je pripravená, a dovtedy sa správa uloží do poradia.

Najdôležitejšou časťou je, že medzi aplikáciou odosielateľa a príjemcu nie sú žiadne časové závislosti.

Zverejniť a prihlásiť sa na odber: Tento mechanizmus zasielania správ je veľmi jedinečne navrhnutý spoločnosťou JMS.

Napríklad , jeden čitateľ sa prihlási na odber jedného blogu, kde má daná osoba záujem. Teraz môže mať záujem o konkrétny blog niekoľko ľudí.

A prihlásia sa na odber / registráciu do tohto blogu. Po zverejnení nového príspevku alebo témy na blogu dostanú všetci registrovaní čitatelia aktualizáciu. Tento model správ sa nazýva Publikovať a Prihlásiť sa na odber.

Otázka č. 4) Čo je to poradie?

Odpoveď: V mechanizme point-to-point JMS zdrojová aplikácia odošle správu cieľovej aplikácii, správa je spotrebovaná cieľovou aplikáciou, akonáhle je k dispozícii, dovtedy sa úložná jednotka toho istého času nazýva front.

Otázka č. 5) Čo je téma?

Odpoveď: V modeli Publikovať / Prihlásiť sa na odber aplikácia klienta / vydavateľa vygeneruje jednu správu a táto správa je k dispozícii všetkým predplatiteľom alebo cieľovým aplikáciám. Táto správa sa nazýva Téma.

Otázka č. 6) Aký je zásadný rozdiel medzi pracovným mechanizmom JMS a RPC?

Odpoveď: Identifikovateľný rozdiel medzi týmito dvoma modelmi spočíva v spôsobe doručenia správy.

V prípade JMS aplikácia odosielateľa odošle správu cieľovej aplikácii a potom opäť čaká / alebo spracuje ďalšiu správu podľa programovacích kritérií.

Zatiaľ čo v prípade RPC sa vlákno dokončí, akonáhle sa správa dostane do cieľa, a ovládací prvok sa vráti späť k metóde zodpovednej za prenos správy.

Otázka č. 7) Čo je to Messageware Middleware?

Odpoveď: Message Oriented Middleware je softvér, ktorý pracuje medzi aplikáciou odosielateľa a cieľovou aplikáciou v pracovnom modeli JMS.

Otázka č. 8) Ako je Message Oriented Middleware zodpovedný za žiadnu časovú závislosť medzi komponentom odosielateľa a príjemcu, pokiaľ ide o model Point to Point na JMS?

Odpoveď: Keďže middleware MOM funguje medzi komponentom odosielateľa a prijímača, stará sa o správu a správu prenáša mechanizmom zaradenia do fronty. Takže kým nebude aplikácia príjemcu / príjemcu k dispozícii na príjem / čítanie správy, správa sa uloží do frontu.

Najdôležitejšou časťou je, že metóda zodpovedná za odoslanie správy nie je obsadená, kým aplikácia prijímača správu neprijme. Aplikácia ako odosielateľ, tak aj prijímač teda fungujú nezávisle bez akejkoľvek časovej závislosti.

Otázka č. 9) Pomenujte typy správ podporované JMS.

Odpoveď: Typ správ, ktoré podporuje služba JMS, sú:

• Textové správy
• Streamujte správy
• Mapové správy
• Správy bajtov
• Správy o objektoch

Otázka 10) Čo je to správa Bajtov?

Odpoveď: Objekt Správa bajtov je skutočne zodpovedný za odoslanie správy obsahujúcej prúd neprerušovaných bajtov a dedí z rozhrania správy a pridáva telo správy bajtov. Príjemca správy je zodpovedný za interpretáciu správy.

Rozhranie JMS API umožňuje prenos tohto typu správ, ale podľa dokumentov Oracle sa zvyčajne nepoužívajú, pretože zahrnutie vlastností môže ovplyvniť formát správy.

Otázka č. 11) Čo je StreamMessage?

Odpoveď: Objekt StreamMessage sa používa na odoslanie toku primitívnych údajových typov v programovacom jazyku Java. Údaje sa postupne plnia a načítajú. Dedí z rozhrania správy a pridáva telo správy streamu.

java.io.DataInputStream a java.io.DataOutputStream sú rozhrania API podporujúce tieto typy správ.

Otázka č. 12) Čo je textová správa?

Odpoveď: Textová správa je tá, o ktorú sa stará java.lang.String a ktorá dedí z rozhrania správy a pridáva telo textovej správy. Používa sa na prenos správ obsahujúcich text.

Otázka 13) Čo je správa o objekte?

Odpoveď: Správa objektu obvykle obsahuje v tele správy serializovateľný objekt Java. Aplikácia prijímača všeobecne prijíma správu Object v režime iba na čítanie.

Otázka č. 14) Čo je správa na mape?

Odpoveď: Telo správy objektu Mapová správa obsahuje množinu párov názov-hodnota, kde názvy sú reťazcové objekty a hodnoty sú primitívne Java. K položkám je možné pristupovať postupne alebo náhodne podľa názvu. Mapová správa v skutočnosti dedí z rozhrania správy a pridáva telo správy, ktoré obsahuje mapu.

Otázka č. 15) Čo je JNDI? Ako to súvisí s JMS?

Odpoveď: JNDI je rozhranie Java Naming and Directory Interface. Ak je aplikácia pripojená k databáze, umožňuje vývojárovi aplikácie pomenovať túto databázu namiesto obáv o prihlasovacie údaje k databáze.

Rozhranie JNDI API bude mať prístup k pomenovaciemu adresáru, nájde mapovanie medzi menom a databázovým objektom a podľa toho sa pripojí. Tento mechanizmus môžeme použiť, keď sa pripájame k akejkoľvek connectionFactory (fronte alebo téme) na odosielanie správ.

Otázka 16) Ako prenosová aplikácia odosiela / odosiela správu cez JMS?

Odpoveď: Ďalej uvádzame niekoľko spôsobov, ako sa správa odosiela prostredníctvom služby JMS:

• Implementujte JNDI na vyhľadanie poverení connectionFactory.
• Vytvorte objekt connectionFactory na implementáciu.
• Identifikujte cieľové objekty (jeden alebo viac).
• Na nadviazanie spojenia JMS použite objekt connectionFactory.
• Vytvorte jednu alebo viac relácií.
• Použite reláciu a ciele na vytvorenie potrebných MessageProducers a MessageConsumers.
• Komunikujte pomocou kanála.

Otázka č. 17) Pomenujte komponenty JMS.

Odpoveď: Medzi komponenty JMS patria:

• Poskytovateľ JMS
• Klient JMS
• Správy
• Spravované objekty
• Nativní klienti

Otázka 18) Čo sú spravované objekty v JMS?

Odpoveď: Spravovaný objekt JMS sú vlastne tie poverenia nakonfigurované správcom, aby sa mohli spojiť s klientom JMS, a sú definované v rámci JNDI. Tieto objekty sú nakonfigurované pred pripojením k klientovi JMS vo vnútri servera.

Otázka č. 19) Aké sú funkcie poskytovateľa JMS?

Odpoveď: Poskytovateľ JMS sa v zásade stará o bezpečnosť a dáta.

Zodpovedá za zabezpečenie bezpečného doručenia správy, stará sa tiež o štandardy šifrovania a kódovania údajov a je zodpovedná za vyvolanie správy pre klienta iného ako JMS.

Otázka 20) Čo je relácia JMS?

Odpoveď: Relácia JMS je stav riadiaci celkový tok od odoslania k prijatiu správ JMS.

Otázka č. 21) Môžeme použiť JMS na odosielanie automatických e-mailov?

ako písať automatizované testovacie skripty

Odpoveď: Služba JMS nemá žiadne štandardné rozhrania API podporujúce túto funkciu, na odosielanie automatických e-mailov však môžeme používať program JavaMail.

Otázka č. 22) Aká je funkčnosť poslucháča správ v kontexte JMS?

Odpoveď: Prijímač správ sa zvyčajne používa u spotrebiteľov v prípade asynchrónneho doručenia. Pre asynchrónne doručenie je možné zaregistrovať objekt MessageListener s messageConsumer.

Otázka č. 23) Čo je klient JMS?

Odpoveď: Klient JMS je v podstate komponent napísaný v programovacom jazyku Java, ktorý je zodpovedný za vyvolanie a konzumáciu tiel správ.

Otázka č. 24) Čo je správa?

Odpoveď: Správa je telo, skôr komponent, ktorý komunikuje medzi klientmi JMS.

Otázka č. 25) Aká je funkčnosť producenta správ JMS?

Odpoveď: Producent správ je v zásade komponent, ktorý je vytvorený reláciou JMS na odosielanie správ do aplikácie prijímača.

Je možné vytvoriť reláciu a implementovať rozhranie MessageProducer na definovanie cieľového objektu, objektu frontu alebo objektu témy. Výrobcu je možné označiť za nešpecifikovaného tak, že v jeho argumente namiesto objektu priradíte hodnotu null. Neskôr môžeme použiť preťaženie metódy Java na metódu send, aby sme určili cieľ, správu ako argumenty alebo parametre.

Otázka č. 26) Aká je funkčnosť Spotrebitelia správ JMS?

Odpoveď: Spotrebiteľ správy je v zásade komponent, ktorý je vytvorený reláciou JMS na príjem správy aplikáciou prijímača. Je možné vytvoriť reláciu a implementovať rozhranie MessageConsumer na definovanie cieľového objektu, objektu frontu alebo objektu témy.

Jeden môže použiť createDurableSubscriber s objektom relácie na vytvorenie trvalého odberateľa tém, ale môže ho použiť na vytvorenie témy pre model Publish / Subscribe a nie na vytváranie front.

Spotrebiteľ sa stane aktívnym po vytvorení spotrebiteľského objektu. Objekt môžeme použiť na príjem a odosielanie správ. Aby sme to deaktivovali, je možné použiť metódu close pre MessageConsumer.

Otázka č. 27) Aká je funkčnosť prehliadača frontov JMS?

Odpoveď: Ako sme už diskutovali o koncepte frontu, kde sa správa ukladá, kým ju prijímateľ neprijme. Funkciu prehliadania správ vo fronte a zobrazovanie hodnôt hlavičky podporuje objekt QueueBrowser.

Jeden je možné vytvoriť objekt QueueBrowser pomocou. Relácia JMS.

Otázka č. 28) Aká je funkčnosť selektora správ JMS?

Odpoveď: Selektor správ JMS je v podstate API, ktoré je zodpovedné za filtrovanie správ, ktoré prijíma pre ľubovoľnú konkrétnu aplikáciu. Selektory správ skutočne priradia úlohu poskytovateľovi JMS, ktorý je skutočne zodpovedný za filtrovanie správ.

Selektor správ v skutočnosti prijíma hodnoty typu reťazca ako vstup.

WatchType = ‘Titan‘ ALEBO WatchType = ‘Rolex’

Metódy createConsumer a createDurableSubscriber umožňujú človeku určiť selektor správ ako argument pri vytváraní spotrebiteľa správy.

Otázka č. 29) Ako zvládnuť výnimku spôsobenú JMS?

Odpoveď: Hlavnou triedou zodpovednou za vyhadzovanie výnimiek súvisiacich s JMS pomocou JMS API je JMSException.

Zachytenie JMSException poskytuje všeobecný spôsob spracovania všetkých výnimiek týkajúcich sa JMS API.

Trieda JMS Exception obsahuje nasledujúce podtriedy, ktoré sú popísané v dokumentácii API:

• IllegalStateException
• Výnimka InvalidClientIDE
• InvalidDestinationException
• InvalidSelectorException
• JMSSecurityException
• MessageEOFException
• MessageFormatException
• MessageNotReadableException
• MessageNotWriteableException
• ResourceAllocationException
• TransactionInProgressException
• TransactionRolledBackException

Otázka 30) Ako zvládnuť netransakčné relácie týkajúce sa JMS?

Odpoveď: V prípade netransakčných relácií sa správy potvrdzujú na základe argumentu odovzdaného pri vytváraní objektu relácie metódou QueueSession alebo TopicSession.

Nasledujúce možnosti sa zvyčajne používajú podľa obchodných požiadaviek:

• Session. AUTO_ACKNOWLEDGE: Ak tento argument zadáte pri vytváraní objektu relácie, ak sa vyskytne JMSException, potom spoľahlivý spotrebiteľ počká niekoľko sekúnd a potom zavolá metódu MessageConsumer.receive, aby správy znova prijal. Z dôvodu zlyhania, ak sa niektorá správa nedoručí, bude doručená znova.

• Session. CLIENT_ACKNOWLEDGE: Ak tento argument zadáte pri vytváraní objektu relácie, potom ak dôjde k JMSException, spotrebiteľ zavolá Session.recover pred volaním Message.aknowledge alebo MessageConsumer.receive, pretože Session.recover je zodpovedný za obnovu a opätovné doručenie nepotvrdených správ.

• Session. DUPS_OK_ACKNOWLEDGE: Ak tento argument zadáte pri vytváraní objektu relácie, ak sa vyskytne JMSException, potom spoľahlivý spotrebiteľ počká niekoľko sekúnd a potom zavolá metódu MessageConsumer.receive, aby správy znova prijal. Ale tu je možné prijímať duplicitné správy alebo rovnaké správy znova doručené ako v tomto režime pred zlyhaním, potvrdené správy môžu byť doručené znova.

Poznámka : Tu v príklade kódu som použil QueueSession, ale na odovzdanie týchto argumentov je možné použiť TopicSession.

Otázka č. 31) Aká je funkčnosť servera Oracle Glassfish? Čo má ďalšiu výhodu na serveri Apache Tomcat?

Odpoveď: Server Glassfish je vlastne aplikačný server a možno ho použiť aj ako webové servery, čo znamená, že dokáže spracovať požiadavky HTTP z webových prehliadačov.

Ako aplikačný server je vyvinutý na spracovanie všetkých typov aplikácií Java Enterprise z hľadiska servletov / JSP a tiež komponentov EJB.

Zatiaľ čo server Tomcat je v skutočnosti kontajner servletu, ktorý sa zvyčajne používa na spracovanie komponentov servletu alebo JSP.

Otázka č. 32) Ako vytvoriť reláciu EJB s cieľom nadviazať spojenie JMS?

Odpoveď: Môžeme vytvoriť reláciu EJB pre JMS, ako sme napísali v nasledujúcom kóde.

Otázka č. 33) Popíšte koncept Message Driven Bean Clustering.

Odpoveď: Ak je aplikácia založená na komponentoch EJB nasadená v ľubovoľnom klastri aplikačných serverov, možno ju nakonfigurovať na spustenie na ľubovoľnom serveri v klastri, aby bola zaistená dostupnosť a škálovateľnosť aplikácie.

Ak je EJB vo forme Message Driven Bean (MDB), môže bežať na ľubovoľnom serveri vo vnútri klastra a môže byť spustený paralelne s množstvom aplikačných serverov v klastri.

Záver

Dúfam, že tento zoznam najdôležitejších otázok týkajúcich sa rozhovorov s JMS by mal byť skutočne informačný a som si istý, že akýkoľvek rozhovor môžete úspešne prelomiť s dôkladnou znalosťou tohto zoznamu.

Dúfajme, že by vám to veľmi pomohlo !! Šťastné učenie !!

Odporúčané čítanie

• Dotazy a odpovede na pohovor
• Niektoré zaujímavé otázky týkajúce sa testovania softvéru
• ETL Testovacie otázky a odpovede na pohovor
• 12 najčastejších otázok týkajúcich sa rozhovorov (modelový rozhovor)
• Najlepšie otázky týkajúce sa rozhovorov s formulármi a správami Oracle
• Softvérové ​​ručné testovanie, otázky na pohovor pre skúsených profesionálov
• Nasadenie Java: Vytvorenie a vykonanie súboru Java JAR
• Najdôležitejšie otázky týkajúce sa technických riešení Oracle Apps a rozhovorov Oracle SOA