As Gordon noted, the JMS client can't act as a server for incoming connections. Its only a client and must connect out, but the other side can be a broker/router/toaster/other.
The 'reactor' impl which proton-j includes can accept, and there is a very basic/incomplete/naive 'recv' example which does show that, however I wouldn't suggest you try it, and I'm not aware of anyone who actually uses it that way. Proton was originally envisaged as purely a protocol engine others would use in creating their own clients/servers etc, and thats how proton-j continues to see most of its use. One instance of that which you might want to look at would be over at Vert.x, https://github.com/vert-x3/vertx-proton/blob/master/src/main/java/io/vertx/proton/ProtonServer.java. There isnt much in docs for sever side beyond the API javadoc, but theres a very basic example at https://github.com/vert-x3/vertx-proton/tree/master/src/test/java/io/vertx/proton/example, and lots of use in the tests one dir up. Robbie On 14 March 2018 at 12:19, Cyril Micoud <cmic...@vitechnology.com> wrote: > Hi Gordon, > > Thanks for your answer... > > We are agree with your first point and we look to try it as soon as possible. > But we have also a 3rd system in Java and we need a direct access Java=>Java > without any broker. > I think the solution is your second point? > In that case, how each system knew the dispatch router? > Have you an other proposal without dispatch router? > > Thanks by advance, > Bets regards, > > Cyril > > > -----Message d'origine----- > De : Gordon Sim <g...@redhat.com> > Envoyé : mercredi 14 mars 2018 11:02 > À : users@qpid.apache.org > Objet : Re: Qpid JMS 0.30.0 or Qpid Proton-J 0.26.0 to point-to-point message > exchange? > > On 14/03/18 08:40, Cyril Micoud wrote: >> Hi everybody, >> >> We are working with Qpid to set up interoperability between 2 systems, >> one in Java, the other in C ++. >> >> On the C ++ side, we use Qpid Proton 0.17.0 (not the last update due >> to system constraints) to use the AMQP 1.0 standard. >> >> In Java, we started on Qpid JMS 0.30.0 for the simplicity of JMS and >> compatibility with 1.0 of AMQP. >> >> In the nominal case, we use a Broker, but we also need point-to-point >> access to transfer information from one system to another such as the >> broker's address and the queues on which we can exchange. >> >> However, connection and exchange with the broker is simple to >> configure, but the point to point in JMS seems compromised (or so we >> have not yet find the right documentation). >> >> We are considering the use of Qpid Proton-J 0.26.0 but again, we do >> not find much example of implementation ... >> >> What is the best way to use both communication broker and point-to-point? >> >> Anybody can provide us a quick sample of Proton-J usage with and >> without broker? or a JMS sample to point-to-point usage? > > If by point-to-point you mean one system connects to the other directly, then > the first thing is to decide which direction that connection happens in. The > JMS client, as far as I know, does not let you accept incoming connections. > Therefore it would be easier to have the c++ part open a listener on a > particular port, and have the JMS client simply connect to that as if it were > a broker. That does mean there is some extra stuff the c++ side needs to do > to correctly handle the direct connections. You can have a look at the broker > example to get some > ideas: > https://git1-us-west.apache.org/repos/asf/qpid-proton/repo?p=qpid-proton.git;a=blob;f=examples/cpp/broker.cpp;h=f48fb376f65dbeeed9fae71092168de732b19356;hb=HEAD > > However, one other thing to consider, is to use the dispatch router between > the systems. This way the two systems connect out, as if to a broker, but can > send each other messages that are acknowledged end-to-end with no > store-and-forward between them. You can also have the links propagated if you > need to. I think it often makes the overall system simpler. It depends of > course on the reasons and detailed use cases for the point-to-point > communication channel. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional > commands, e-mail: users-h...@qpid.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
