Asynchronous service transport?

[synclpz]

Is there any possibility to pass messages between SwitchYard services asynchronously, except HornetQ?

At the moment we are using JCA binding with HornetQ to receive messages at each "macro-service" and a special facility which orchestrates macro-service invocations sending messages to appropriate queues. But there's much pain using hornetq to achieve reliable messaging in case of server failure and we hav not yet achieved it. So, I'm wondering if there any other way to orchestrate service-flow using some asynchronous transport.

[kcbabo]

Is asynchronous the only requirement?  It sounds like you want delivery QoS, failure recovery, etc. as well.   Messaging provider is your best best for those requirements (HornetQ, ActiveMQ, etc.).  Sorry to hear that you've had issues with HornetQ.  Have you asked about the specific issues you've hit in the HornetQ forum?  Those guys are friendly and helpful. :-)

[synclpz]

Yes, messaging is the solution, but if there's another type of transport we can do QoS, high-availability, failover and clustering using other or custom facilities

Still no responses in HornetQ forum for my questions, and according to bug tracker there are still many issues with implementing REAL high-availability and reliable failover... But I'm trying to start SY1.0.0.Final on EAP6.2.Beta1, may be some issues will be fixed.

At the moment our solution is to disable hornetq clustering and rely on single server surviving after a crash... At least if server is restarted hornetq redelivers all messages held in journal.

[synclpz]

No luck with EAP6.2 Beta, SY 1.0/1.1 is not going to work seamlessy, there are some weird deployment problems. Even tried to install latest HornetQ (2.4.0Beta) on EAP6.1, but it still does not work as expected.

For me it seems quite strange that no one before us ever tried to set up such system: reliable component integration over asynchronous transport with persistence and fail-tolerance. May be we are implementing a wrong concept.

Anyway, it seems that implementing our own custom "message bus" is the easiest solution.

[synclpz]

We have finally achieved success with HornetQ as service integration bus. The proper setup + latest libraries allowed us to make it:

* load balance incoming requests between cluster nodes with SY apps deployed

* fail-over upon server crash, deliver ongoing messages in queue and redeliver messages which had not yet been processed successfully

* re-deliver message to service after configurable delay in case of exception thrown in service

for orchestration a special application was made which supports run-time orchestration sequence configuration, scheduling and some other specific features.