Weiß jemand, ob es machbar ist, einen Generic JMS Client zu schreiben - dh. eine, die mit JMS von verschiedenen Anbietern (zB Sonic, IBM SIB, Jboss usw.) funktioniert?Generic JMS Client
Jedes Mal, wenn ich JMS-Client-Code geschrieben habe, ist es immer sehr implementierungsspezifisch mit abhängigen JARs und Kontextklassen.
Danke.
Nun, eine Best Practice (zumindest für mich) ist die Verwendung der Nicht-Arg InitialContext constructor und Anbieter spezifischen Sachen (wie die ursprüngliche Kontext Factory und die Provider-URL) in eine jndi.properties Datei auf dem Klassenpfad statt hart codieren diese dinge. Sie müssen auch die "richtigen" JMS-Provider-JARs in den Klassenpfad einfügen. Mit anderen Worten, Sie können haben generischen Code, aber Sie müssen immer noch die Laufzeitumgebung konfigurieren (es sei denn, Sie führen Ihren Client-Code in einem Container wie Spring).
Dies ist, was Spring ist für. Sie werden eine herstellerspezifische Implementierung haben, aber der Code sollte identisch sein. Siehe 19.6 JMS und 21. JMS (Java Message Service) der Spring 3.0 Reference.
2 gute Antworten bereits, aber ich möchte ein bisschen eine Erklärung hinzufügen. JMS ist ein API-Standard, es definiert nicht das Drahtprotokoll zum Server. Daher haben alle JMS-Implementierungen unterschiedliche Drahtprotokolle - daher benötigen Sie immer die herstellerspezifischen JARs. Es ist nicht möglich, eine JMS-Client-Bibliothek zu erstellen, die mit allen JMS-Providern kompatibel ist.
In Ihrem Quellcode sollten Sie herstellerspezifische Funktionen vermeiden (z. B. können Sie mit TIBCO EMS auf Ziele mit Nicht-JNDI, nativen Namen und benutzerdefinierten Bestätigungsmodi zugreifen). Wenn Sie immer JNDI-Lookups verwenden, sind nur der JNDI-URL und der ursprüngliche Name des Kontextfactorys für den Servertyp spezifisch.
Für alle, für eine generische Client in die Zukunft schauen, ausprobieren HermesJMS, die für die großen JMS-Provider mit Plugins kommt (ActiveMQ, WebSphere MQ, usw.)