Top 30+ JMS (Java Message Service) Întrebări despre interviu

top 30 jms interview questions

Cele mai populare întrebări și răspunsuri la interviurile JMS pentru profesioniști mai noi și cu experiență:

Serviciul de mesagerie JMS sau Java a devenit în prezent unul dintre cele mai dominante modele de livrare sigură, fiabilă și scalabilă a mesajelor în întreaga lume.

Acest model este foarte bine structurat și acceptă o serie de forme de tehnici și protocoale de mesagerie.

Să ne aruncăm cu capul și să examinăm câteva întrebări și răspunsuri care sunt adresate frecvent pe această temă în întreaga industrie.

Cele mai populare întrebări de interviu JMS

Mai jos este prezentată o listă cu cele mai frecvente întrebări de interviu pentru Java Message Service, împreună cu răspunsuri detaliate.

Q # 1) Ce este JMS?

Răspuns: Serviciul de mesagerie Java este un API Java, care permite sistemelor să creeze, să citească, să trimită și să primească mesaje.

Cea mai importantă parte a algoritmului este foarte bine structurată și permite unei aplicații să trimită un mesaj către o altă aplicație și permite, de asemenea, funcții de difuzare către abonați.

Q # 2) Care sunt tipurile de comunicare furnizate de JMS? Explicați în detaliu.

Răspuns: Acest API oferă două tipuri de comunicare:

• Asincron: Mesajul va fi livrat clientului, nu este necesar ca acesta să trimită cereri pentru a-l primi. Aplicația client o va primi odată ce transmite aplicația expeditorului.
• De încredere: Aici mesajul este trimis aplicației client odată ce protocolul API asigură disponibilitatea aplicației receptor.

Î # 3) Care este numărul de modele de mesagerie disponibile pe JMS?

Răspuns: Mai exact, există două tipuri de model furnizate de JMS:

Punct la punct: După cum sugerează și numele, este un mecanism de mesagerie unu la unu, în care expeditorul trimite un mesaj către un singur receptor. Mesajul este disponibil pentru aplicația receptorului odată ce este gata și până atunci mesajul este stocat în coadă.

Cea mai importantă parte a acestuia este că există zero dependențe în ceea ce privește timpul dintre aplicația emițătoare și cea a receptorului.

Publicați și abonați-vă: Acest mecanism de mesagerie este foarte unic conceput de JMS.

De exemplu , un cititor se abonează la un blog unde persoana este interesată. Acum pot exista mai multe persoane interesate de un anumit blog.

Și se abonează / se înregistrează la acel blog. Acum, odată ce o nouă postare sau subiect este publicat pe blog, toți cititorii înregistrați vor primi o actualizare. Acest model de mesagerie se numește Publish and Subscribe.

Q # 4) Ce este o coadă?

Răspuns: În mecanismul punct-la-punct al JMS, aplicația sursă trimite un mesaj către aplicația de destinație, mesajul este consumat de aplicația de destinație odată ce este disponibilă, până la acel moment unitatea de stocare din momentul respectiv este numită coadă.

Q # 5) Ce este un subiect?

Răspuns: În modelul Publicare / Abonare, aplicația client / editor generează un mesaj și acel mesaj este disponibil pentru toți abonații sau aplicațiile de destinație. Acest mesaj se numește subiect.

Q # 6) Care este principala diferență între mecanismul de lucru al JMS și RPC?

Răspuns: Diferența identificabilă între cele două modele constă în modul în care este transmis mesajul.

În cazul JMS, aplicația expeditorului trimite mesajul către aplicația de destinație și apoi așteaptă din nou / sau procesează un alt mesaj conform criteriilor de programare.

În timp ce în cazul RPC, firul este finalizat odată ce mesajul ajunge la destinație și controlul revine la metoda responsabilă pentru transportul mesajului.

Q # 7) Ce este Middleware orientat spre mesaj?

Răspuns: Mesajul orientat către mesaje este un software care funcționează între aplicația expeditorului și aplicația de destinație în modelul de lucru JMS.

Q # 8) Cum este Middleware-ul orientat spre mesaj responsabil pentru nicio dependență de timp între componenta expeditor și receptor în ceea ce privește modelul punct la punct de pe JMS?

Răspuns: Deoarece middleware-ul MOM funcționează între componenta expeditor și receptor, acesta se ocupă de mesaj și transportă mesajul prin mecanism de așteptare. Deci, până când aplicația de destinație / receptor devine disponibilă pentru a primi / citi mesajul, mesajul este stocat într-o coadă.

Cea mai importantă parte este că metoda responsabilă pentru trimiterea mesajului nu este ocupată până când aplicația receptorului nu primește mesajul. Astfel, atât aplicația expeditor, cât și destinatarul funcționează independent, fără dependență de timp.

Q # 9) Denumiți tipurile de mesagerie acceptate de JMS.

Răspuns: Tipul de mesaje acceptate de JMS este:

• Mesaje text
• Mesaje în flux
• Mesaje de hartă
• Mesaje de octeți
• Mesaje obiect

Q # 10) Ce este un mesaj de octeți?

Răspuns: Obiectul Bytes Message este de fapt responsabil pentru trimiterea mesajului care conține un flux de octeți neîntrerupți și moștenește din interfața mesajului și adaugă un corp de mesaj de octeți. Receptorul mesajului este responsabil pentru interpretarea mesajului.

API-ul JMS permite transportul acestui tip de mesaje, dar conform oracle docs, acestea nu sunt de obicei utilizate deoarece includerea proprietăților poate afecta formatul mesajului.

Q # 11) Ce este un StreamMessage?

Răspuns: Un obiect StreamMessage este utilizat pentru a trimite fluxul de tipuri de date primitive în limbajul de programare Java. Datele sunt completate și citite secvențial. Moștenește de la interfața Mesaj și adaugă un corp de mesaj flux.

java.io.DataInputStream și java.io.DataOutputStream sunt API-uri care acceptă aceste tipuri de mesagerie.

Q # 12) Ce este un mesaj text?

Răspuns: Un mesaj text este cel care este îngrijit de java.lang.String și moștenește din interfața mesajului și adaugă un corp de mesaj text. Acesta este utilizat pentru a transporta mesajele care conțin un text.

Q # 13) Ce este un mesaj Object?

Răspuns: Un mesaj obiect conține în general un obiect Java serializabil în corpul mesajului. În general, aplicația receptor primește mesajul Object într-un mod de numai citire.

Q # 14) Ce este un mesaj pe hartă?

Răspuns: Corpul mesajului obiectului Map Message conține un set de perechi nume-valoare, unde numele sunt obiecte String, iar valorile sunt primitive Java. Intrările pot fi accesate secvențial sau aleatoriu după nume. Map Message moștenește de fapt din interfața Message și adaugă un corp de mesaj care conține o hartă.

Q # 15) Ce este JNDI? Cum este legat de JMS?

Răspuns: JNDI este interfața Java Naming și Directory. Dacă o aplicație este conectată la o bază de date, aceasta permite dezvoltatorului de aplicații să dea un nume acelei baze de date în loc să se îngrijoreze de datele de conectare la baza de date.

API-ul JNDI va accesa directorul de denumire și va găsi maparea între nume și obiectul bazei de date și se va conecta corespunzător. Putem folosi acest mecanism în timp ce ne conectăm la orice connectionFactory (coadă sau subiect) pentru trimiterea mesajelor.

Q # 16) Cum transportă / trimite o aplicație expeditor un mesaj prin JMS?

Răspuns: Mai jos sunt prezentate câteva moduri în care un mesaj este trimis prin JMS:

• Implementați JNDI pentru a căuta acreditările connectionFactory.
• Creați un obiect connectionFactory pentru implementare.
• Identificați obiectele de destinație (unul sau mai multe).
• Utilizați obiectul connectionFactory pentru a stabili conexiunea JMS.
• Creați una sau mai multe sesiuni.
• Utilizați o sesiune și destinațiile pentru a crea MessageProducers și MessageConsumers necesari.
• Comunicați folosind canalul.

Q # 17) Denumiți componentele JMS.

Răspuns: Componentele JMS includ:

• Furnizor JMS
• Client JMS
• Mesaje
• Obiecte administrate
• Clienți nativi

Q # 18) Ce este obiectele administrate în JMS?

Răspuns: Obiectul administrat de JMS este de fapt acele acreditări configurate de administrator pentru a se conecta cu clientul JMS și sunt definite în JNDI. Aceste obiecte sunt configurate înainte de conectarea cu clientul JMS din interiorul serverului.

Q # 19) Care sunt funcționalitățile unui furnizor JMS?

Răspuns: JMS Provider se ocupă practic de securitate și date.

Este responsabil pentru asigurarea că mesajul este livrat într-un mod sigur, se ocupă și de criptarea datelor și standardele de codificare a datelor și este responsabil pentru invocarea mesajului pentru clientul non-JMS.

Q # 20) Ce este o sesiune JMS?

Răspuns: O sesiune JMS este o stare care controlează fluxul total de la trimiterea la primirea mesajelor JMS.

Q # 21) Putem folosi JMS pentru trimiterea de e-mailuri automate?

ce tip de test este utilizat pentru a verifica dacă noul sistem funcționează cu date reale?

Răspuns: JMS nu are API-uri standard care să susțină această funcție, însă putem folosi JavaMail pentru a trimite e-mailuri automate.

Q # 22) Care este funcționalitatea unui ascultător de mesaje în contextul JMS?

Răspuns: Ascultătorul de mesaje este de obicei utilizat cu consumatorul de mesaje în cazul livrării asincrone. Pentru livrarea asincronă se poate înregistra un obiect din MessageListener cu messageConsumer.

Q # 23) Ce este clientul JMS?

Răspuns: Clientul JMS este în esență o componentă scrisă în limbajul de programare Java care este responsabil pentru invocarea și consumarea corpurilor mesajelor.

Q # 24) Ce este un mesaj?

Răspuns: Un mesaj este un corp, mai degrabă o componentă care comunică între clienții JMS.

Q # 25) Care este funcționalitatea unui producător de mesaje JMS?

Răspuns: Un producător de mesaje este practic o componentă care este creată de o sesiune JMS pentru trimiterea unui mesaj către aplicația receptor.

Se poate crea o sesiune și se poate implementa interfața MessageProducer pentru a defini un obiect de destinație, un obiect de coadă sau un obiect subiect. Se poate declara un producător ca nespecificat atribuind nul în argumentul său în locul unui obiect. Mai târziu putem folosi supraîncărcarea metodei Java pe metoda de trimitere pentru a specifica o destinație, un mesaj ca argumente sau parametri.

Q # 26) Care este funcționalitatea consumatorilor de mesaje JMS?

Răspuns: Un consumator de mesaje este în esență o componentă creată de o sesiune JMS pentru primirea unui mesaj de către aplicația receptor. Se poate crea o sesiune și se poate implementa o interfață MessageConsumer pentru a defini obiectul de destinație, obiectul de coadă sau obiectul subiect.

Se poate folosi createDurableSubscriber cu obiectul sesiunii pentru a crea un abonat subiect durabil, dar se poate folosi pentru a crea un subiect pentru modelul Publicare / Abonare și nu pentru crearea cozilor.

Consumatorul devine activ odată creat obiectul consumatorului. Putem folosi obiectul pentru a primi și a trimite mesaje. Pentru a dezactiva acest lucru, se poate folosi o metodă apropiată pentru un MessageConsumer.

Q # 27) Care este funcționalitatea unui browser de coadă JMS?

Răspuns: După cum am discutat anterior conceptul cozii, unde mesajul este stocat până când receptorul îl primește. Funcționalitatea de navigare a mesajelor din coadă și afișarea valorilor antetului este acceptată de obiectul QueueBrowser.

Se poate crea un obiect QueueBrowser prin. Sesiune JMS.

Q # 28) Care este funcționalitatea unui selector de mesaje JMS?

Răspuns: Selectorul de mesaje JMS este practic un API care este responsabil pentru filtrarea mesajelor pe care le primește pentru orice aplicație anume. Selectorele de mesaje atribuie de fapt jobul către furnizorul JMS, care este de fapt responsabil pentru filtrarea mesajelor.

Un selector de mesaje ia de fapt valori de tip șir ca intrare.

WatchType = 'Titan' SAU WatchType = 'Rolex'

Metodele createConsumer și createDurableSubscriber permit specificarea unui selector de mesaje ca argument atunci când se creează un consumator de mesaje.

Q # 29) Cum să gestionăm excepția cauzată de JMS?

Răspuns: Principala clasă responsabilă pentru aruncarea excepțiilor legate de JMS de către API-ul JMS este JMSException.

Capturarea JMSException oferă un mod generic de gestionare a tuturor excepțiilor legate de API-ul JMS.

Clasa de excepții JMS include următoarele subclase, care sunt descrise în documentația API:

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

Î # 30) Cum să gestionați sesiunile care nu sunt tranzacționate cu privire la JMS?

Răspuns: În cazul sesiunilor netratate, mesajele sunt confirmate pe baza argumentului trecut în timpul creării unui obiect de sesiune a metodei QueueSession sau TopicSession.

Opțiunile de mai jos sunt utilizate în general în funcție de cerințele comerciale:

• Sesiune. RECUNOAȘTERE AUTO: Dacă treceți acest argument în timp ce creați un obiect de sesiune, atunci, dacă apare JMSException, atunci un consumator de încredere așteaptă câteva secunde și apoi apelează metoda MessageConsumer.receive pentru a primi din nou mesajele. Datorită reluării, dacă un mesaj nu este livrat, atunci acesta va fi redistribuit.

• Sesiune. CLIENT_ACKNOWLEDGE: Dacă se trece acest argument în timp ce creează un obiect de sesiune, atunci, dacă apare JMSException, consumatorul apelează Session.recover înainte de a apela Message.aknowledge sau MessageConsumer.receive, deoarece Session.recover este responsabil pentru recuperarea și redistribuirea mesajelor neacceptate.

• Sesiune. DUPS_OK_ACKNOWLEDGE: Dacă treceți acest argument în timp ce creați un obiect de sesiune, atunci, dacă apare JMSException, atunci un consumator de încredere așteaptă câteva secunde și apoi apelează metoda MessageConsumer.receive pentru a primi din nou mesajele. Dar aici se pot primi mesaje duplicate sau aceleași mesaje re-livrate ca în acest mod înainte de failover, mesajele confirmate pot fi livrate din nou.

Notă : Aici, în exemplul de cod, am folosit QueueSession, dar se poate folosi TopicSession pentru a transmite aceste argumente.

Q # 31) Care este funcționalitatea serverului Oracle Glassfish? Ce avantaj adăugat are pe serverul Apache Tomcat?

Răspuns: Glassfish server este de fapt un server de aplicații și poate fi folosit și ca servere web, ceea ce înseamnă că poate gestiona cererile HTTP de la browserele web.

Ca server de aplicații, este dezvoltat pentru a gestiona toate tipurile de aplicații Java Enterprise în ceea ce privește servletele / JSP și, de asemenea, componentele EJB.

În timp ce serverul Tomcat este de fapt un container servlet care este utilizat în general pentru manipularea componentelor servlet sau JSP.

Q # 32) Cum se creează o sesiune EJB pentru a porni o conexiune JMS?

Răspuns: Putem crea o sesiune EJB pentru JMS așa cum am scris în codul de mai jos.

Q # 33) Descrieți conceptul de grupare a boabelor conduse prin mesaje.

Răspuns: Dacă o aplicație bazată pe componente EJB este implementată pe orice cluster de server de aplicații, atunci aceasta poate fi configurată pentru a rula pe orice server din cluster pentru a oferi disponibilitate și scalabilitate pentru aplicație.

Dacă un EJB este sub formă de Message Driven Bean (MDB), atunci acesta poate rula pe orice server din interiorul clusterului și poate fi inițiat paralel cu un număr de servere de aplicații din cluster.

Concluzie

Sper că această listă cu întrebările de top ale interviurilor JMS ar fi fost cu adevărat informativă și sunt sigur că puteți interveni cu succes cu orice cunoștință a acestei liste.

Sperăm că acest lucru v-ar fi ajutat foarte mult !! Învățare fericită !!

Lectură recomandată

• Întrebări și răspunsuri la interviu
• Câteva întrebări interesante despre testarea software-ului
• Întrebări și răspunsuri la interviuri de testare ETL
• Top 12 Întrebări despre interviul Mockito (Interviul Mocking Framework)
• Cele mai importante întrebări despre interviu pentru formulare și rapoarte Oracle
• Software de testare manuală Întrebări de interviu pentru profesioniști experimentați
• Implementarea Java: crearea și executarea fișierului Java JAR
• Top Oracle Apps Technical and Oracle SOA Interview Questions