30+ preguntes sobre les entrevistes sobre JMS (Java Message Service)

top 30 jms interview questions

Preguntes i respostes d'entrevistes JMS més populars per a professionals més experimentats i més frescos:

Actualment, el servei de missatgeria JMS o Java s’ha convertit en un dels models més dominants per a l’enviament segur, fiable i escalable de missatges a tot el món.

Aquest model està molt ben estructurat i admet diverses formes de tècniques i protocols de missatgeria.

Aprofundim en algunes preguntes i respostes que es fan sovint sobre aquest tema a tota la indústria.

Most Popular JMS Interview Questions

A continuació es mostra una llista de les preguntes més freqüents de l'entrevista de Java Message Service juntament amb respostes detallades.

P # 1) Què és JMS?

Resposta: El servei de missatgeria Java és una API Java, que permet als sistemes crear, llegir, enviar i rebre missatges.

La part més important de l'algorisme està molt ben estructurada i permet a una aplicació enviar un missatge a una altra aplicació i també permet transmetre funcions als subscriptors.

Q # 2) Quins són els tipus de comunicació que proporciona JMS? Explica amb detall.

Resposta: aquesta API proporciona dos tipus de comunicació:

• Asíncron: El missatge es lliurarà al client, no és necessari que el client enviï sol·licituds per rebre'l. L’aplicació client la rebrà un cop la sol·licitud remitent la transmeti.
• Fiable: Aquí el missatge s’envia a l’aplicació client un cop el protocol API garanteix la disponibilitat de l’aplicació receptora.

P # 3) Quin és el nombre de models de missatgeria disponibles a JMS?

Resposta: En concret, hi ha dos tipus de models proporcionats per JMS:

Punt a punt: Com el seu propi nom indica, és un mecanisme de missatgeria individual, on l’emissor envia un missatge a un únic receptor. El missatge estarà disponible per a l’aplicació del receptor un cop estigui llest i fins aleshores el missatge s’emmagatzemarà a la cua.

La part més important és que hi ha zero dependències pel que fa al temps entre l'emissor i l'aplicació receptora.

Publica i subscriu-te: Aquest mecanisme de missatgeria està dissenyat de manera única per JMS.

Per exemple , un lector es subscriu a un bloc on la persona està interessada. Ara pot haver-hi diverses persones interessades en un bloc concret.

I es subscriuen / registren a aquest bloc. Ara, un cop publicat un tema o publicació nova al bloc, tots els lectors registrats rebran una actualització. Aquest model de missatgeria s’anomena Publica i subscriu-te.

Q # 4) Què és una cua?

Resposta: En el mecanisme punt a punt de JMS, l'aplicació d'origen envia un missatge a l'aplicació de destinació; l'aplicació de destinació el consumeix un cop estigui disponible, fins al moment en què la unitat d'emmagatzematge del mateix temps s'anomena cua.

P # 5) Què és un tema?

Resposta: Al model de publicació / subscripció, l’aplicació client / editor genera un missatge i aquest missatge està disponible per a tots els subscriptors o aplicacions de destinació. Aquest missatge s’anomena tema.

Q # 6) Quina és la principal diferència entre el mecanisme de treball de JMS i RPC?

Resposta: La diferència identificable entre els dos models rau en la forma en què es transmet el missatge.

En el cas de JMS, l'aplicació remitent envia el missatge a l'aplicació de destinació i després torna a esperar / o processa un altre missatge segons els criteris de programació.

Mentre que en el cas de RPC, el fil es completa un cop el missatge arriba a la destinació i el control torna al mètode responsable del transport de missatges.

P # 7) Què és el middleware orientat als missatges?

Resposta: Message Oriented Middleware és un programari que funciona entre l'aplicació remitent i l'aplicació de destinació en el model de treball JMS.

Q # 8) Com és el middleware orientat al missatge responsable de la dependència de temps entre el component emissor i receptor respecte al model punt a punt de JMS?

Resposta: Com que el middleware MOM funciona entre el component emissor i receptor, es fa càrrec del missatge i el transporta mitjançant un mecanisme de cua. Per tant, fins que l’aplicació de destinació / receptor estigui disponible per rebre / llegir el missatge, el missatge s’emmagatzema en una cua.

La part més important és que el mètode responsable d’enviar el missatge no s’ocupa fins que l’aplicació receptora el rep. Per tant, tant l’aplicació emissora com la receptora funcionen independentment sense cap dependència horària.

Q # 9) Anomeneu els tipus de missatgeria admesos per JMS.

Resposta: El tipus de missatges compatibles amb JMS són:

• Missatges de text
• Reprodueix missatges
• Missatges del mapa
• Missatges de bytes
• Missatges d'objectes

Q # 10) Què és un missatge de bytes?

Resposta: L'objecte Bytes Message és realment responsable d'enviar el missatge que conté un flux de bytes ininterromputs i hereta de la interfície del missatge i afegeix un cos de missatge de bytes. El receptor del missatge és responsable de la interpretació del missatge.

L’API JMS permet transportar aquest tipus de missatges, però segons els documents d’Oracle, normalment no s’utilitzen, ja que la inclusió de propietats pot afectar el format del missatge.

Q # 11) Què és un StreamMessage?

Resposta: Un objecte StreamMessage s'utilitza per enviar el flux de tipus de dades primitives en el llenguatge de programació Java. Les dades s’omplen i es llegeixen de manera seqüencial. Hereta de la interfície de missatges i afegeix un cos de missatge de flux.

java.io.DataInputStream i java.io.DataOutputStream són API que admeten aquest tipus de missatgeria.

P # 12) Què és un missatge de text?

Resposta: Un missatge de text és el que java.lang.String té en compte i hereta de la interfície del missatge i afegeix un cos de missatge de text. S'utilitza per transportar els missatges que contenen un text.

P # 13) Què és un missatge Object?

Resposta: Un missatge objecte conté generalment un objecte Java serialitzable al cos del missatge. Generalment, l’aplicació receptora rep el missatge Object en mode de només lectura.

P # 14) Què és un missatge de mapa?

Resposta: El cos del missatge de l'objecte Missatge de mapa conté un conjunt de parells nom-valor, on els noms són objectes de cadena i els valors són primitives de Java. Es pot accedir a les entrades de manera seqüencial o aleatòria per nom. Map Message realment hereta de la interfície Message i afegeix un cos de missatge que conté un mapa.

P # 15) Què és JNDI? Com es relaciona amb JMS?

Resposta: JNDI és la interfície de directori i denominació de Java. Si una aplicació està connectada a una base de dades, permet al desenvolupador d'aplicacions donar un nom a aquesta base de dades en lloc de preocupar-se per les credencials de connexió de la base de dades.

L'API JNDI accedirà al directori de denominació i trobarà l'assignació entre el nom i l'objecte de base de dades i es connectarà en conseqüència. Podem utilitzar aquest mecanisme mentre ens connectem a qualsevol connectionFactory (cua o tema) per enviar missatges.

P # 16) Com transporta / envia un missatge una aplicació remitent mitjançant JMS?

Resposta: A continuació es detallen algunes maneres en què s’envia un missatge a través de JMS:

• Implementeu JNDI per cercar les credencials de la connectionFactory.
• Creeu un objecte connectionFactory per implementar-lo.
• Identifiqueu els objectes de destinació (un o més).
• Utilitzeu l’objecte connectionFactory per establir la connexió JMS.
• Creeu una o més sessions.
• Utilitzeu una sessió i les destinacions per crear els MessageProducers i MessageConsumers necessaris.
• Comunicar-se mitjançant el canal.

P # 17) Anomeneu els components de JMS.

Resposta: Els components de JMS inclouen:

• Proveïdor de JMS
• Client JMS
• Missatges
• Objectes administrats
• Clients nadius

P # 18) Què són els objectes administrats a JMS?

Resposta: L'objecte administrat per JMS és en realitat aquelles credencials configurades per l'administrador per connectar-se amb el client JMS i que es defineixen a JNDI. Aquests objectes es configuren abans de connectar-se amb el client JMS dins del servidor.

P # 19) Quines són les funcionalitats d'un proveïdor de JMS?

Resposta: El proveïdor JMS s’encarrega bàsicament de seguretat i dades.

És responsable d’assegurar-se que el missatge es lliura de forma segura, també s’encarrega dels estàndards de codificació i codificació de dades i és responsable d’invocar el missatge per al client que no és JMS.

P # 20) Què és una sessió JMS?

Resposta: Una sessió JMS és un estat que controla el flux total des de l’enviament fins a la recepció dels missatges JMS.

P # 21) Podem utilitzar JMS per enviar correus electrònics automatitzats?

com obrir un fitxer .air

Resposta: JMS no té cap API estàndard que admeti la funció, però podem utilitzar JavaMail per enviar correus electrònics automatitzats.

P # 22) Quina és la funcionalitat d'un oient de missatges en el context de JMS?

Resposta: L'escoltador de missatges s'utilitza normalment amb el consumidor de missatges en cas de lliurament asíncron. Per al lliurament asíncron es pot registrar un objecte de MessageListener amb messageConsumer.

P # 23) Què és el client JMS?

Resposta: El client JMS és bàsicament un component escrit en el llenguatge de programació Java que s’encarrega d’invocar i consumir cossos de missatges.

P # 24) Què és un missatge?

Resposta: Un missatge és un cos, més aviat un component que es comunica entre els clients JMS.

P # 25) Quina és la funcionalitat d'un productor de missatges JMS?

Resposta: Un productor de missatges és bàsicament un component que es crea mitjançant una sessió JMS per enviar un missatge a l’aplicació receptora.

Es pot crear una sessió i implementar la interfície MessageProducer per definir un objecte de destinació, un objecte de cua o un tema. Es pot declarar un productor com a no especificat assignant nul en el seu argument en lloc d'un objecte. Més endavant podem utilitzar la sobrecàrrega del mètode Java al mètode d'enviament per especificar una destinació, un missatge com a arguments o paràmetres.

P # 26) Quina és la funcionalitat dels consumidors de missatges JMS?

Resposta: Un consumidor de missatges és bàsicament un component que es crea mitjançant una sessió JMS per rebre un missatge per part de l'aplicació receptora. Es pot crear una sessió i implementar una interfície MessageConsumer per definir l'objecte de destinació, l'objecte de cua o l'objecte tema.

Es pot utilitzar createDurableSubscriber amb l'objecte de sessió per crear un subscriptor de tema durador, però es pot utilitzar per crear un tema per al model de publicació / subscripció i no per crear cues.

El consumidor es torna actiu un cop creat l'objecte de consum. Podem utilitzar l’objecte per rebre i enviar missatges. Per desactivar-lo, es pot utilitzar un mètode proper per a MessageConsumer.

P # 27) Quina és la funcionalitat d'un navegador de cues JMS?

Resposta: Com hem comentat anteriorment el concepte de cua, on s’emmagatzema el missatge fins que el receptor el rep. L'objecte QueueBrowser admet la funcionalitat de navegar pels missatges de la cua i mostrar els valors de la capçalera.

Es pot crear un objecte QueueBrowser mitjançant. Sessió JMS.

P # 28) Quina és la funcionalitat d'un selector de missatges JMS?

Resposta: El selector de missatges JMS és bàsicament una API que s’encarrega de filtrar els missatges que rep per a qualsevol aplicació en concret. Els Selectors de missatges realment assignen la feina al proveïdor JMS, que és el responsable de filtrar els missatges.

Un selector de missatges realment pren valors de tipus de cadena com a entrada.

WatchType = 'Titan' O WatchType = 'Rolex'

Els mètodes createConsumer i createDurableSubscriber permeten especificar un selector de missatges com a argument quan es crea un consumidor de missatges.

P # 29) Com gestionar l'excepció causada per JMS?

Resposta: La principal classe responsable de llançar excepcions relacionades amb JMS per l'API JMS és JMSException.

La captura de JMSException proporciona una manera genèrica de gestionar totes les excepcions relacionades amb l'API JMS.

La classe d'excepció JMS inclou les següents subclasses, que es descriuen a la documentació de l'API:

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

P # 30) Com gestionar les sessions no tractades respecte a JMS?

Resposta: En cas de sessions no tractades, els missatges es reconeixen sobre la base de l'argument aprovat mentre es crea un objecte de sessió del mètode QueueSession o TopicSession.

Les opcions següents s’utilitzen generalment segons els requisits empresarials:

• Sessió. RECONEIXEMENT AUTOMÀTIC: Si es passa aquest argument mentre es crea un objecte de sessió, llavors, si es produeix JMSException, un consumidor fiable espera uns segons i després truca al mètode MessageConsumer.receive per tornar a rebre els missatges. A causa de la migració per error, si no es lliura cap missatge, es tornarà a lliurar.

• Sessió. CLIENT_ACKNOWLEDGE: Si es passa aquest argument mentre es crea un objecte de sessió, aleshores, si es produeix JMSException, el consumidor truca a Session.recover abans de trucar a Message.aknowledge o MessageConsumer.receive, perquè Session.recover és responsable de recuperar i lliurar de nou missatges no reconeguts.

• Sessió. DUPS_OK_ACKNOWLEDGE: Si es passa aquest argument mentre es crea un objecte de sessió, llavors, si es produeix JMSException, un consumidor fiable espera uns segons i després truca al mètode MessageConsumer.receive per tornar a rebre els missatges. Però aquí es poden rebre missatges duplicats o els mateixos missatges que es tornen a lliurar que en aquest mode abans de la migració per error, els missatges reconeguts es poden tornar a lliurar.

Nota : Aquí, a l'exemple de codi, he utilitzat QueueSession, però es pot utilitzar TopicSession per passar aquests arguments.

P # 31) Quina és la funcionalitat del servidor Oracle Glassfish? Quin avantatge afegit té al servidor Apache Tomcat?

Resposta: El servidor Glassfish és en realitat un servidor d'aplicacions i també es pot utilitzar com a servidors web, cosa que significa que pot gestionar les sol·licituds HTTP dels navegadors web.

Com a servidor d'aplicacions, està desenvolupat per gestionar tot tipus d'aplicacions Java Enterprise en termes de servlets / JSP i també components EJB.

Mentre que, el servidor Tomcat és en realitat un contenidor de servlets que s'utilitza generalment per manipular components de servlet o JSP.

P # 32) Com es crea una sessió EJB per iniciar una connexió JMS?

Resposta: Podem crear una sessió EJB per a JMS tal com hem escrit al codi següent.

P # 33) Descriviu el concepte de clúster de mongetes impulsades per missatges.

Resposta: Si es desplega una aplicació basada en components EJB en qualsevol clúster de servidor d'aplicacions, es pot configurar per executar-se en qualsevol servidor del clúster per proporcionar disponibilitat i escalabilitat per a l'aplicació.

Si un EJB té la forma de Message Driven Bean (MDB), es pot executar a qualsevol servidor del clúster i es pot iniciar paral·lelament a diversos servidors d'aplicacions del clúster.

Conclusió

Espero que aquesta llista de les principals preguntes de les entrevistes de JMS hagués estat realment informativa i estic segur que podeu trencar qualsevol entrevista amb èxit amb un coneixement exhaustiu d’aquesta llista.

Amb sort, això us hauria ajudat molt !! Feliç aprenentatge !!

Lectura recomanada

• Preguntes i respostes de l’entrevista
• Algunes preguntes d’entrevistes de proves de programari interessants
• Preguntes i respostes de l'entrevista de proves ETL
• Top 12 de les preguntes sobre l'entrevista de Mockito (entrevista de Mocking Framework)
• Preguntes principals sobre les entrevistes sobre formularis i informes d'Oracle
• Preguntes d'entrevistes de proves manuals de programari per a professionals experimentats
• Desplegament de Java: creació i execució del fitxer JAR de Java
• Principals preguntes tècniques d’entrevistes d’Oracle Apps i Oracle SOA