Calling in/through ESB without Messaging

[bernd.koecke]

Hello,

is it possible to call a service without using message queues? Some colleagues of mine are using ServiceMix and want to migrate to JBossESB. They told me, that it is possible in ServiceMix to call it directly with a normal method-call without any message queues involved. They use it to lower the latency. I know this is not the typical use case for an ESB and that a well configured messaging is expected to add only little latency. But it would help them with the migration when the calling implementation changes as little as possible.

I found only the listener for messaging, scheduler with polling the filesystem etc. But these listeners always generate messages and send them to the service.

Thanks a lot,
Bernd

[marklittle]

Do you mean in-process, i.e., where the sender and receiver reside within the same VM? If so, that's not possible in the current codebase, though the work is done in a separate branch.

Otherwise, you can always use other transports than JMS, e.g., FTP, DB, email ...

[bernd.koecke]

Yes I meant in-process. They want to reduce the latency of the explicit/implicit JMS-Queues. You say that there is work done in another branch. Is there something runable, maybe in a very early stage, with which I can play around a little bit?

[marklittle]

Check out the bramley branch. As I've mentioned before though, there is no support for this at all even on the forums. We don't have the time at the moment. But it should work (tm).

[bernd.koecke]

Thanks a lot! I will have a look at it.

[bernd.koecke]

I had a look at the branch and see that the changes have a deep impact on the code. You said, that there is not enough time to go on with this EPR. If we say that we would like to contribute to this with testing and/or developing, is there a chance to bring it into the main trunk?

If there is no possibility to bring it in the main trunk, i could try to use a non persistent JMS-Queue or using Hypersonic as an In-Memory-DB to cut off the DB-access. Because the brunch implementation uses an In-Memory-Queue with a workerthread without a direct methodcall to the destination, this seems to be similar.

[marklittle]

The InVM EPR will be making it into trunk at some point in the future, but I can't say when. It will be in the FP01 release for the SOA Platform in April.

[bernd.koecke]

Thanks a lot, I will have a look into the repository from time to time for FP01.

[marklittle]

You're welcome.