I thouhgt of JCA but in researching it it seemed to me that JCA was more "pooling" focused and the nature of my application is that I will have 1000s of socket end points that will be opened, used then closed (maybe only once in a day). So JCA seems like overkill. Am I missing something?
I suppose that your app is stateless, so every call via socket is independent.
That is exact what JCA is for. You open only a bunch of sockets and such connection will be reused.
You can ensure that a socket is not reused if the transaction is running, that is a implementation detail of the JCA connector.
At the moment it is still unclear to me how it works.
- a external client know internal host names?
- open and close sockets might have a bad performance (ok, maybe not if it is not very frequent)
Do you mean by 'logical transaction' that this Tx spans more than one external request? But in this case I'm not sure how you work with the socket ... stateful beans?
So in fact there is no technical restriction that stop you handle sockets.
But I would think about the architecture .... (but I have not the complete picture, so it's on you)
I have been experimenting today and you are definately correct: JCA is the correct way to do this. I have created a JCA datasource for the connections my app needs and a RESTFul service front ends the whole thing. Pretty cool!!!
For clarity, we have a legacy app that needs to get digital signature from a Verifone device. The legacy app knows the ip address of the device associated with the terminal where the legacy app is running so the legacy app makes a RESTFul service call passing the ip address/port of the device. The app I am developing must then, now using a JCA, connect to the proper device over a socket connection. The logical process of signing takes a couple of requests back and forth between my app and the device. Once done, the connection is closed, and the RESTFul service returns the results.
Thanks for you help!!!