-
15. Re: EPR format for JMS
Good question.
Durability seems to have sense for pub-sub chanels in general: http://www.eaipatterns.com/DurableSubscription.html
When it comes to the semantics of the ESB itself, this would mean that the bus should be able to accumulate messages and deliver them later when a particular subscriber re-connects to the bus.
This might be already covered by other semantic concepts. Or this might make no sense at all at the bus level ;-) -
16. Re: EPR format for JMS
OK, so I'd suggest that is covered under the send-reliable heading. We've got that in the current architecture. Basically there are different variants of send: send (best effort) and send-reliable; the semantics of reliability are defined by the sender and the ESB must either match them up with some transport or indicate to the sender that it can't and in which case the sender can either try again with slightly less strict requirements or fault higher up the application stack. How reliability is achieved (e.g., durable save messages until they can be delivered) is up to the underlying messaging implementation. Obviously that implementation may impose restrictions on how long it takes to deliver a message (potentially infinite time) and that would need to form part of the contract between the sender and the ESB, e.g., "reliably deliver my message but if it's going to take more than 60 minutes to do so, come back to me and I'll take alternative action".
I think it does make sense at the bus level. But does this match what you were after? -
17. Re: EPR format for JMS
I was expecting reliability to come to play here, though the semantics of durability is consumer oriented instead of producer oriented.
With durability, the consumer says to the bus: "I do not want to miss any message from this endpoint, keep them for me until they are X Y old, then discard them" (I added the time constraint to mimic yours).
Of course, this implies reliability between the consumer and the bus, else it would not be possible to surely discriminate sucessful and failed deliveries thus it would not be possible to decide if a message should be kept or not.
We will enter into this kind of problematic when asynchronous JMS based services will be connected to the bus. These services post events and results in topics. We intend to use the bus to allow non-JMS capable consumers to be informed events/results posted in particular topics.
The idea would be to have a topology where messages published on the topic would be forwarded to specific web service endpoints. When these web service would be down or if they fail to ACK a post, the idea would be to have the bus replay the message later.
Thus our idea of being able to establish a particular "routing" as "durable".
Of course, this need may be be covered by a more elegant and appropriate solution that we ignore but you might already know! -
18. Re: EPR format for JMS
"ddossot" wrote:
I was expecting reliability to come to play here, though the semantics of durability is consumer oriented instead of producer oriented.
With durability, the consumer says to the bus: "I do not want to miss any message from this endpoint, keep them for me until they are X Y old, then discard them" (I added the time constraint to mimic yours).
Remembering that we're abstracting transport away from the application (we don't want to tie ourselves to JMS any more than we want to be tied to SOAP/HTTP), I think this is something that gets defined in the contract between service and ESB in just the same way I described between client and ESB. Whether the underlying messaging implementation can provide the desired QoS is a deployment problem, but we should be able to abstract the requirement sufficiently that it doesn't imply JMS.
Of course, this implies reliability between the consumer and the bus, else it would not be possible to surely discriminate sucessful and failed deliveries thus it would not be possible to decide if a message should be kept or not.
We will enter into this kind of problematic when asynchronous JMS based services will be connected to the bus. These services post events and results in topics. We intend to use the bus to allow non-JMS capable consumers to be informed events/results posted in particular topics.
The idea would be to have a topology where messages published on the topic would be forwarded to specific web service endpoints. When these web service would be down or if they fail to ACK a post, the idea would be to have the bus replay the message later.
Thus our idea of being able to establish a particular "routing" as "durable".
Of course, this need may be be covered by a more elegant and appropriate solution that we ignore but you might already know!
We should support the requirement. How we enable that requirement to be manifest within the contract definition is open to debate at the moment. How that contract definition is then catered for by implementations should be an implementation specific choice (JMS, WS-RX, roll-your-own, etc.) -
-
20. Re: EPR format for JMS
Unfortunately :-( I'm struggling with time in general right now and on http://jira.jboss.org/jira/browse/JBMESSAGING-26, I should have more 'jboss' time in the comming weeks/from next week, but if anyone else wants to continue/mod whats on the wiki currently - http://wiki.jboss.org/wiki/Wiki.jsp?page=JmsEndPoint
Right now all I can offer is that I will gather my thoughts on the following and post it here & on the wiki.CommonEndPointDefinition.xsd JMSEndPointDefintion.xsd extends CommonEndPointDefinition.xsd so <Protocol>EndPointDefintion.xsd extends CommonEndPointDefinition.xsd
:-( -
21. Re: EPR format for JMS
Mark, can you create a jira task for the creation of epr (jms) schemas and
assign it to me? I have some xsd fragments to check into svn, then thye can be used as a skeleton for the rest of the supported protocols etc -
-
23. Re: EPR format for JMS
Just glanced at the wiki page.
If you're going to support jms durable subscriptions then won't you need the subscription name and client id to identify it?
Also what about noLocal, ack modes and delivery modes? -
-
25. Re: EPR format for JMS
"timfox" wrote:
Just glanced at the wiki page.
If you're going to support jms durable subscriptions then won't you need the subscription name and client id to identify it?
Also what about noLocal, ack modes and delivery modes?
Hi Tim, You're probably right, although I have yet to look into that
in more detail. Adding these extra fields into the xsd should be no problem,
i'm guessing things will become clearer once there is some backing
code.