There are many options to solve this problem :
1. Implement a interface to JMS can work, but this will be a lot of work.
2. I think is simpler to create a WebService who runs on JBoss and use the Delphi client to connect to this webservice. This webservice can then put the data on a message queue.
3. Another idea is to create a simple server (as a MBean) who listen socket connections from the Delphi client using a proprietary protocol. It will then put the message on the queue.
4. There another solution to this problem. Use a proprietary products who does the same than option 3. In this case you will have a more consistent and well tested solution.
I am from Brazil like you (Florianopolis-SC), so if you want to talk more about this send me a e-mail. I did some things like this before and I think I can help you.
if you are feeling adventurous, check out the XIL, it is a wire protocol for JBossMQ.
I understand that you are coding XIL, so I would like to ask some questions in order to present this solution on the company I work:
Does this project have any stable version?
Does it adds too much overhead on communications?
Would we have some help concerning protocol descriptions if needed in order to produce some Delphi client for XIL?
Would XIL work with JBoss 2.4.6? If not why and could we do something about it besides upgrading the server?
Thanks in advance
Glad to hear you are interested.
Currently, I am trying to get XIL integrated into the jboss3.2 distro. I've submitted a patch, and I am waiting to hear back from the project lead. I've just released a source package on sourceforge that you can try, but I wouldn't consider the XIL for production use until it is in the Jboss source tree.
There is obviously additional overhead for encoding/decoding in xml. You can decide for yourself by looking at the test results posted on csil.sourceforge.net. In my use, I have found the xml to be a small impact. The real effect comes from multiplexing the streams into one socket. So I have been comparing my test result times to the UIL times, and I find them to be very close.
I would be eager to give you as much info as I can, and I am trying to keep the protocol page at csil.sourceforge.net up to date. We've also written schemas to describe each interaction with the server, which will aid in your development. The hard part of the package is in multiplexing. There are now java and C# multiplexing packages which will serve well as guides, but you need to be prepared to work extensively with threads.
I'm sorry, I really don't know much about the 2.4.6 version. For exception handling we encode the stack trace using the new jdk1.4.1 exception model, so I think the limiting factor is the jdk compatibility of jboss2.4.6.
I'm far from an expert on the jboss versions, but I would consider upgrading anyway. The XIL is LGPL'd so if you really want jboss2.4.6 to have it, you can always port it!
I am very hapy to hear from you and your project ...
It seems to approach the problems I have here, and what makes me happier is to know that XIL can be incorporated in JBoss source ... no matter the version ...
I am using JDK 1.4.1 here with Jboss 2.4.6 and so far we had no problem, although we have not patched it yet. Here we are very new to JBoss and there is a lot to learn ...
I am glad to know that we can have your help to develop this client ... and I think this would be our best choice ...
Please, when your patch is integrated with Jboss 3.2 ... tell me ... I will be looking around a lot, but I may miss it ... and I don't want to miss it ...
About upgrading, is Jboss 3.2 stable?
An associate of mine tried JBoss 3.??? and had a lot of problems with data persisting .. but he was doing JBoss for his first time and Jboss 3.x was just released ... on my company they are very afraid of unknown bugs ... and Jboss 2.4.6 being one step below the last release (3.x) has most of its bugs known ... what can oyu tell be about 3.2 ?
thanks a lot,
3.2 isn't yet available from jboss.org, but you can look at the release notes on sourceforge
You should definitely look through bug lists and mailarchive.
I tend to be aggressive in upgrading, particularly with JBoss, which has such a well-managed codebase. To be honest, my primary factor in deciding which platform to work against is how well the unit tests for my own app run on the platform. By running your own tests, you can usually see any jboss bugs that you have to worry about (assuming you have thorough unit tests).
Bear in mind, my current project has only ever had to look at 3.x versions, so this approach may not work over bigger revisions. Also, if you find a bug, submitting a good bug report yields very good response from the core developers.
If you have more questions on this topic, you should post to installation&config, where you may find more knowledgeable readers/respondents.