Hi all!
Has anyone actually tried using EntireX Communicator as MOM provider for JMS?
(Only Point-to-Point model 
)
In order to support asynchronous process in our SOA, we would like to combine the functionality of XML Mediator with Communicator in a J2EE Application Server context (Ej.JBoss).
Thanks in advance!
Can you be more specific as to what you need to achieve, requirements etc…?
I am not sure where for example the JMS fits into your scenario, or the J2EE for that matter.
For instance, I can say that you definitely can achieve asynchronous processing with Mediator and Communicator. This would be regardless of J2EE App Server.
First of all, thank you to confirm me the use of Mediator + Communicator outside the J2EE Application Server. This can be a solution for us.
But the initial question is about the use Message Driven Beans as consumers of persistent messages stored in the communicator queues(as end result of XML requests made to Mediator), in the same machine, in order to create a transacted session under the Application Server transactional services. A generic MDB can act as facade to another part of XML Mediator Sequence, and in this way we can describe and run asynchronous process with Mediator. I dont know if this is posible.
Sorry for my terrible english
Thank you again, arp. 
I think you will have to try and explain it a different way; I still am not sure what you are trying to achieve, and i thinkg a level of misunderstanding about how our products work (together) makes your description hard to analyze. the english is fine - maybe we can hire you for our documentation team 
Maybe you can describe, without reference to any of our products, what it is you need to achieve:
i.e. I want to make a call from a MBean to system X; the call needs to be asynchronous; etc…
FYI the ‘end result’ of a request to the mediator is a response from the mediator. mediator uses HTTP for transport, so when calling a mediator sequence, you in effect are making a synchronous call.
mediator can integrate many different types of systems / interfaces; one of them is communicator. any messages that mediator sends to communicator are not the ‘end result’ of the mediator sequence.
This said, there are ways to overcome the inherent synchronous nature of Mediator. No matter which way you do it, it will involve some form of logic in the application calling mediator; i.e. the calling application itself can receive a call (via HTTP, FTP, email, SOAP, communicator etc…) or the client application can make subsequent calls to ‘poll’ for the asynchrounous result to it’s initial Mediator request.
If you can spell out in as much detail as possible what you need to achieve, we will happily suggest possible solutions using EntireX products.
I think you are already on the right track; I believe you suggest that one Mbean will originate the request, while a different ‘generic’ MBean will receive the response.
The question is the use of EntireX Communicator as true MOM provider for JMS.
If I can do this, I could use Communicator as middleware between heterogeneus systems and also between differents components of the same system, in a J2EE application server context(could be the same JVM, for example).
We could use the messaging services that provides Jboss, but JbossMQ is not the best product in this area.
I know that the true value of EntireX Communicator is other, but we have some scenarios with strong presence of EJBs, and JMS over Communicator can be a fast, secure and reliable integration solution.
This, in combination with EntireXML Mediator(coarse grained services implementation) would provide us with the needed infraestructure of a Enterprise Service Bus and the foundation of a Service Oriented Architecture(synchronous and asynchronous services)…
You can definitely use EntireX as a JMS provider as you describe; Be aware of some limitations: the current version only does point-point (queue) and not publish/subscribe (topic).
I don’t think you can or should directly combine other EntireX applications and JMS applications that use EntireX as JMS provider (i.e. you cannot use the JMS interface to communicate with an ACI / RPC application); while I have succeeded in sending a text message to a JMS listener from a normal ACI client, I am not sure whether this will break the JMS rules, most notably delivery order. While you can register an ACI server as JMS/???/QUEUE, it will not receive any messages from JMS clients, but will receive messages from ACI clients…
So for all intents and purposes, the JMS portion of EntireX is separate from the rest - much in the same way ACI and RPC are separate.
Of course, there is no reason why a JMS application cannot also make EntireX ACI and/or RPC calls…
sorry if this is confusing!
regards,
- arp
Arp, how did you do this without getting a JMSException ?
Kind regards,
Rolf
Sorry, please disregard that bit. Too much australian sun. I just tried again, and I cannot reproduce sending to a JMS listener from an ACI client.
I can however register an ACI server as JMS/TEST/QUEUE and send it messages from an ACI client; even if I have two JMS apps communicating on JMS/TEST/QUEUE.
This can be confusing because one may think it’s possible to send an ACI message to JMS listener; the ACI client will not get any error, conversational or not, regardless of an ACI server being registered or not. So, to the ACI client, it seems that the message is delivered (indeed it is - waiting for an ACI server).
I was sure I saw my ACI message pop up in the JMS listener, but you know how mondays are…
Thanks as always for clearing this up Rolf.
regards,
- arp
[This message was edited by arp on 08 Jun 2004 at 0:22.]
The JMS implementation is actually build on top of the ACI using UnitofWorks. However, it is using a certain protocol how to send/receive UOW messages and an internal (binary) message layout.
So, yes, you can send a message from an ACI client to a JMS queue - but with limited success :D. The JMS listener will detect that the message from an ACI client is not a valid JMS message and will throw a JMSException (you should see this exception in the JMS consumer application). Note that we are doing asnychronous communication here, so the ACI client which is doing the send will never get an error response because the send processing is completed once the message is stored in the Brokers message queue.
You can also register an ACI server with a JMS queue (but again this is not a good idea). Once you receive a message from a JMS producer: good luck to handle the binary crap :rolleyes:
Kind regards,
Rolf