JMS vs Webservices

Question

Quali sono i grandi vantaggi di JMS rispetto ai servizi Web o viceversa?

(sono webservices gonfio è JMS nel complesso meglio per la fornitura di interfacce??)

Answer 1

modificato dopo la correzione da Erickson:

JMS è necessario disporre di un provider JMS, una classe Java che implementa l'interfaccia MessageListener per elaborazione dei messaggi e un client che sappia come connettersi alla coda JMS. JMS significa elaborazione asincrona: il client invia il messaggio e non attende necessariamente una risposta. JMS può essere utilizzato in modalità coda punto-punto o pubblicare/sottoscrivere.

"Servizio" è un termine fluido. Penso ad un servizio come componente che vive su una rete e pubblicizza un contratto: "Se mi mandi X, eseguirò questo compito per te e restituirò Y."

I componenti distribuiti sono in circolazione da molto tempo. Ognuno comunicava usando un protocollo diverso (ad es. COM, Corba, RMI, ecc.) Ed esponeva il loro contratto in modi diversi.

I servizi Web rappresentano l'ultima tendenza nei servizi distribuiti. Usano HTTP come loro protocollo e possono interagire con qualsiasi client che possa connettersi via TCP/IP e fare una richiesta HTTP.

È possibile utilizzare gli stili SOAP o RPC-XML o REST o "primo contratto", ma l'idea di base di un componente distribuito che utilizza HTTP come protocollo rimane.

Se si accetta tutto ciò, i servizi Web sono di solito chiamate sincrone. Non devono essere gonfiati, ma è possibile scrivere componenti difettosi in qualsiasi stile o linguaggio.

È possibile iniziare a progettare qualsiasi componente distribuito progettando prima la richiesta e le risposte. Detto ciò, si sceglie JMS o servizi Web in base al tipo di client che si desidera avere e indipendentemente dal fatto che la comunicazione sia sincrona o asincrona.

Answer 2

Da quelli che ho fatto qui sono le differenze che ho trovato: JMS - Sono legato al provider JMS - tuttavia ho scelte di tipo di implementazione (pub/sub, punto a punto) Web Service - più facile da gestire/architetto - tuttavia è più una comunicazione diretta tra le scatole. Un sacco di strumenti da utilizzare per lo sviluppo e un'interfaccia pulita (WSDL) in modo che l'implementatore e il chiamante possano essere indipendenti.

Quale usare? Dipende da quale sia il problema.

Answer 3

Direi che la più grande distinzione è che JMS è orientato ai messaggi, piuttosto che orientato su RPC. La maggior parte dei provider JMS supporta i protocolli di alto livello che eseguono tentativi, prevengono duplicati e supportano le transazioni.

Esistono molte applicazioni in cui queste funzionalità non sono necessarie. Ma dove sono necessari, costruirli da soli su un meccanismo RPC è complicato, costoso e soggetto a errori.

Answer 4

I sistemi basati su messaggi, incluso JMS, offrono la possibilità di essere "disaccoppiati cronologicamente" dall'altra parte. Un messaggio può essere inviato senza che l'altra estremità sia disponibile.

Tutti gli altri approcci A2A comuni richiedono che il partner sia in grado di rispondere immediatamente, richiedendo che siano in grado di gestire carichi di picco, con scarsa capacità di diffusione dell'elaborazione.

Answer 5

Vorrei aggiungere questo come commento al post di dyffymo, ma non ho ancora il rappresentante.

Citando la risposta:..

"servizi Web sono l'ultima tendenza in servizi distribuiti Usano HTTP come protocollo e possono interoperare con qualsiasi client in grado di connettersi tramite TCP/IP e fare una richiesta HTTP

È possibile utilizzare gli stili SOAP o RPC-XML o REST o "primo contratto", ma l'idea di base di un componente distribuito che utilizza HTTP come protocollo rimane. "

---

Suppongo che per servizi Web si intenda il set WS- * di protocolli, WSDL e SOAP. Se è così, nessuno di questi richiede l'uso di HTTP come protocollo "trasporto". Il set di protocolli SOA è stato progettato per essere indipendente dai protocolli di trasmissione utilizzati, quindi è possibile utilizzare HTTP, NamedPipes, TCP raw e persino JMS come mezzo per trasmettere messaggi da e verso un servizio Web.

Quindi, nel caso dell'uso diretto di JMS rispetto all'utilizzo di "servizi Web", penso che si riduca principalmente a strumenti, livello di comfort e se sia veramente necessario l'accesso diretto ad alcune funzionalità specifiche JMS (che utilizzano WS- * si nasconderebbe a te). A questo punto penserei che solo applicazioni abbastanza specializzate richiederebbero l'accesso JMS non elaborato.

Answer 6

lasciatemi parlare w.r.t implementazione del protocollo SOAP di servizi Web ... che è meglio JMS vs webservices .... JMS fornisce il protocollo di trasporto ed è il provider di messaggistica sottostante che descrive quanto è buono o cattivo il proprio provider JMS per es. MQ è un potente provider JMS affidabile in cui il protocollo SOAP può essere considerato sia un protocollo a livello di applicazione che può anche essere trattato come un protocollo di trasporto (in senso SOAP/HTTP) ... il supporto di SOAP è a supporto dello standard basato su XML. ... come protocollo a livello di applicazione, consideriamo SOAP come un messaggio da passare da un sistema a un altro su qualsiasi protocollo di trasporto in cui, come protocollo di trasporto, SOAP può essere considerato un contenitore per il trasporto di un carico utile (dati del messaggio) ... SOAP/HTTP può anche essere considerato come provider di meesaging JMS .... ma in quest'ultima forma, HTTP ha problemi di affidabilità, poiché invloves errori relativi a networking, connessioni socket, larghezza di banda ecc ... quindi, per farla breve, JMS con Il fornitore di messaggi affidabile lo rende un buon standard per l'interazione con un buon protocollo di trasporto dove webservice come un protocollo a livello di applicazione rende l'applicazione disparata per comunicare usando il protocollo SOAP XML-like ... spero che questo chiarisca ...

Answer 7

Tutto dipende dalle vostre esigenze, da quali framework utilizzerete e dal vostro ambiente e comportamento delle vostre applicazioni. Se puoi dare una visione d'insieme, allora puoi ottenere una risposta rigida.

Ora è come paragonare un camion con una berlina, devi sapere per che cosa lo utilizzerai e su quale strada decidere quale è meglio.

Answer 8

I servizi Web sono un'implementazione di Services Oriented Architectures (SOA). Una SOA ha tre parti: un fornitore, un broker e un richiedente, che sono liberamente accoppiati. Il provider offre un servizio aziendale che rappresenta un'implementazione particolare, che non è direttamente visibile al richiedente. Il richiedente impara dal broker la struttura delle informazioni che deve inviare e ricevere dal provider e quale protocollo utilizzare per accedere a quel servizio. Il richiedente non è a conoscenza del modo in cui il fornitore implementa il servizio aziendale.

I servizi Web sono definiti come interfacce di business richieste tra un richiedente e un provider e non come una conduttura comune per tutte le richieste aziendali.Esistono diverse variabili che possono caratterizzare i servizi Web, tra cui:

• Possono essere strettamente accoppiati e la loro implementazione può essere basata sull'uso di framework di invocazione.
• Possono eseguire in modalità sincrona richiesta/risposta o in modalità asincrona.
• Possono essere esposti dai provider J2EE o non J2EE.
• Potrebbero o potrebbero non offrire supporto per transazioni e sicurezza.

---

JMS è un'interfaccia basata su messaggi asincroni. È inoltre possibile utilizzare JMS per accedere alla logica aziendale distribuita tra sistemi eterogenei. Avere un'interfaccia basata sui messaggi abilita le seguenti funzioni:

Punto a punto e meccanismi di pubblicazione/sottoscrizione. I framework basati su messaggi possono inviare informazioni ad altre applicazioni senza che vengano richieste esplicitamente. Le stesse informazioni possono essere fornite a molti abbonati in parallelo.

Indipendenza dal ritmo. I framework JMS funzionano in modalità asincrona ma offrono anche la possibilità di simulare una modalità di richiesta/risposta sincrona. Ciò consente ai sistemi di origine e di destinazione di funzionare contemporaneamente senza dover attendere l'un l'altro.

Consegna di informazioni garantita. I framework JMS possono gestire i messaggi in modalità transazionale e garantire la consegna dei messaggi (ma senza alcuna garanzia di tempestività di consegna).

Interoperabilità tra quadri eterogenei. Le applicazioni di origine e destinazione possono operare in ambienti eterogenei senza dover gestire problemi di comunicazione ed esecuzione relativi ai rispettivi framework.

Fare scambi più fluidi. Il passaggio alla modalità messaggio consente uno scambio di informazioni a grana fine.

Source

Answer 9

JMS e WS entrambi consentono distribuire applicazioni. La differenza è asincrona (JMS) vs sincrona (servizi Web). I servizi Web possono essere implementati in stili SOAP o REST. JMS è una API che supporta la comunicazione in due modalità: point-to-point e publish-subscribe. Apache ActiveMQ, RabitMQ sono alcuni dei molti implementatori JMS.