Is it possible to use babbler as base library for an XMPP server?

[Zhanat S. Skokbayev]

Hi Christian,

Mon chapeau, and thank you for your work, it's amazing!

However, on your estimation is it possible to use babbler as base library for an XMPP server similar to, for example, Openfire or Tigase Server? Unfortunately, both these servers are based on Eclipse Jetty but we need an Apache Tomcat-compatible open-source implementation.(

As far as I can understand, in babbler you have realized full support for XMPP protocol and at the level of protocol it should not be differences between XMPP client and server. Also, in your Core module you already have the Server submodule providing several classes for streams and TLS negotiation.

If you think that such implementation is possible what would be your considerations / recommendations on how to implement an XMPP server with babbler correctly and efficiently?

Thank you in advance,

Zhanat.

28.4.2019

[Zhanat S. Skokbayev]

Well, after having crowling the web and reanalyzing the topic for several days I've found the following resources on the task of creating an XMPP open-source server within Jakarta EE (Java EE) container:

The most useful posts were made by the user CSH.

What’s the most simple xmpp server for transfer of simple IMs?
https://discourse.igniterealtime.org/t/whats-the-most-simple-xmpp-server-for-transfer-of-simple-ims/64006

Openfire’s source code: Restructuring + Java EE 7 support?
https://discourse.igniterealtime.org/t/openfires-source-code-restructuring-java-ee-7-support/76109

Very interesting crosscuts clarifying the topic can be found in the Babbler's project introduction:
http://babbler-xmpp.blogspot.com/2014/01/introducing-babbler-new-xmpp-client.html

All possible variants except for an implementation from scratch are listed by One Minute Distraction:

Developing XMPP Components – The Setup
https://oneminutedistraction.wordpress.com/2010/09/28/developing-xmpp-components-the-setup/

It seems that at the moment the only working decision is Apache Vysper that is part of Apache MINA framework:
https://mina.apache.org/vysper-project/documentation.html

Embedding a XMPP server inside your JSF Web Application using Vysper and PrimeFaces
https://www.ibm.com/developerworks/community/blogs/738b7897-cd38-4f24-9f05-48dd69116837/entry/embedding_a_xmpp_server_inside_your_jsf_web_application_using_vysper_and_primefaces?lang=en

[Christian Schudt]

Hi Zhanat,

actually that’s my vision, too. I.e. having a *.war file which is deployable in a Java EE container. My estimation: yes it’s possible, but it’s a hard and long way. I know it also from my own efforts to make this a reality.

In fact I already did a lot of work in the right direction, like introducing a Connection interface, a StreamFeatureNegotiator interface or a WebSocketConnection, which can be used by client and server alike. Also some new "client" packages, for client-only logic, or the MalformedJidclass, so that a server can reply with a malformed-jid error. Or e.g. moving AbstractIQHandlerto "common" and introducing EntityTimeHandlerfor both client and server.

I also have a private branch, where all these changes resulted from. It’s a somewhat deployable server, but with very few / experimental only functionality.

Next steps would be to move more client-only classes to another "client" package. Like XmppSession, rename it, and extract an interface from it, which can be used by both client and servers. Unfortunately, this will break existing code…

Btw: I am CSH

[Zhanat S. Skokbayev]

Christian,
many thanks for your explanation!

IMO it's a great pity that One Minute Distraction has left behind only a lot of words and not source codes. They definitely tried to implement XMPP on the level of JEE's web container, but all source codes of their projects Vorpal, Jabberwocky, and XMPP Container seem to be inaccessible after discontinuation of kenai.com and java.net.

We are a small team of Java developers who are sufficiently qualified in Java SE/EE but quite newbie in the field of XMPP. Currently we are developing an open-source project of MMORPG computer game called DGA and want to use XMPP as application protocol between game clients and servers, and for sure between servers. I agree that it's some kind of crazy idea to use XMPP and JEE for MMO servers, but we believe it can work out (5G networks are in a full march though :). Our project is strictly (A)GPL, that's why we are bound to F/LOSS components only and publish all our developments here on Bitbucket. You can find additional information about our project here:
https://bitbucket.org/fleissf_dga_team/dga_gc_prototype_rel/src/master/
http://www.fleissf.org/

Now I clearly understand that we do not want to implement a full-fledged XMPP server because it's out of our scope. On the other side, I am aware of we need of most of an XMPP server functionality. At the moment I see our target as to use/develop 1) some XMPP framework 2) providing XMPP client and server functionality and 3) letting easily implement an XMPP client/server 4) working within JEE's web/maybe EJB containers (Java SE for clients), and 5) permitting to create an XMPP-based application subprotocol suitable for MMO games 6) and that subprotocol in future can become an XMPP XEP for MMO games, for example, like XEP-0196.

I have played with Babbler for a couple of weeks and we are going to try it out in our game client. I am impressed with quality of Babbler and I'd liked your idea to use JAXB for XML processing, because my estimations on JAXB performance correspond to yours. Of course, we would be proud to contribute our developments to the master project.

We agree to deal with experimental functions, API instability, performance bottlenecks etc. In any case, you have already warned on that.

If you have an intention to open-source your deployable server we could play with it too and maybe contribute to it.

Frankly speaking, I don't like neither XMMP Server plugins nor XMPP components. Maybe these decisions are good for some special cases, but as a general solution they look to me as architecturally ugly. So the sole alternative I see is to EJB-envelop Apache Vysper and then trying to resolve problems with multi-threading.

Btw: I certainly guessed you might be CSH by matching the initials of your name and the crosscut reference to JAXB.

3.5.2019

[Christian Schudt]

I’ve pushed my work to the branch “server”. Be aware, it’s only very experimental work.

I’ve focused on Connection management first, written somewhat working BOSH manager, WebSocket endpoints and Netty Server for accepting inbound client connections.

I did as @ApplicationScoped CDI bean, although the preferred way would be to have a JCA module which accepts socket connections.

There’s no authentication, no message routing, actually not very much yet. Only a little bit stream feature negotiation.

Last time I worked on it, you could start run the EAR in Wildfly, it started the CDI bean and WebSocket endpoints and BOSH (REST API) and you could connect with all three methods.

Streams were negotiated, and clients could ask for the server time

There’s also a standalone server, which starts an embedded Glassfish. I think on some other private branch I did some tests with Payara server, too.

I also did some Entity classes and code logic for Roster Management.

It’s really a lot of work to do.

Maybe you guys have some ideas, especially on the authentication issue. Last time I’ve tried to combine “Java SASL API” with “JSR 196: Java Authentication Service Provider Interface for Containers”, so that you can plugin different auth backends.

[Zhanat S. Skokbayev]

Christian,
thank you very much for sharing your server project!

Now we are going to work all our findings out. We will draw special attention to all the points you have mentioned above. Thanks a lot for your help and see you soon!

Macht's gut!

4.5.2019