| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Schedule the enquing of a messages using XMS |
« View previous topic :: View next topic » |
| Author |
Message
|
| DaeMoohn |
 Posted: Mon Mar 11, 2013 8:27 am Post subject: Schedule the enquing of a messages using XMS |
 |
|
Apprentice
Joined: 04 Jun 2010
Posts: 26
|
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Mar 11, 2013 10:17 am Post subject: Re: Schedule the enquing of a messages using XMS |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| DaeMoohn wrote: |
| Typically, it is capable of enquing the sending of a message after a some time has elapsed, at a minimum. |
No, and why would you want to? What's the business requirement here?
See also here,here & here
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| DaeMoohn |
| Posted: Mon Mar 11, 2013 12:30 pm Post subject: |
|
|
Apprentice
Joined: 04 Jun 2010
Posts: 26
|
I'm not developing a real business application, i'm building some proof of concepts with what technology is available (IBM software is free of charge).
Anyway, i was looking at a particular scenario: buying tickets for an event; here, you might have an allowed delay of 15 minutes let's say between ticket reservation and ticket payment; after this period, if you haven't bought the tickets, reservation is canceled and you go back to square one.
An implementation using Azure Service Bus would post a reservation expiration message on the bus with a 15-20 minutes delay during which the application might receive the payment completion message; if the payment confirmation is received first, the state machine reaches a state in which expiration message would be harmful; doing things this way would free the developer of spawning a thread with delay, it could even handle scenarios where you could send a message after several days, weeks, etc.; so they say.
I understand that by not having this feature in WMQ one must time-wait manually. The issue is that my own implementation of this must be at the same level of reliability as one provided by a queuing infrastructure. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Mar 11, 2013 12:41 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Some possible answers to your prepositions:
1. solidDb or MbCache can be used to store your transaction. A Java timer event can be used to trigger a read of the message when its time to process it.
2. IBM software is not free. There are licenses. And these licenses require compliance.
3. Manual time-wait is not the only solution.
4. A true ESB is stateless. Forcing a stateless entity to track state is square peg in round hole.
5. You are really trying to make an ESB be a workload management solution, as in Business Process Management. WMB is not that. WMB is a high-speed transformation engine. Use BPM for what you are trying to do, not a transformation engine.
6. I realize you posted this in WMQ forum; however, you referenced Microsoft's ServiceBus which is more equivalent to WMB+WMQ than it is WMQ alone.
7. You should develop your requirements in an agnostic way, then choose a tool to meet that requirement. Trying to say ServiceBus does XYZ, how do I do this in WMQ/WMB is not a viable exercise.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Mar 11, 2013 12:54 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| DaeMoohn wrote: |
| (IBM software is free of charge). |
I echo the comments of my associates, with particular reference to this comment. IBM's WMQ is not free, even if on your site there's no charge to your project. It's subject to a license typically based on amount of use, IBM enforce the use of licenses and that the level of license is appropriate to the level of use, and the IBM legal team travel in packs & have huge dorsal fins.
Just be sure that when you present the "proof of concept" this fact is brought clearly to the mind of the receipient. I know one site that was running a "production sized scale and load test" of an IBM based solution; IBM pointed out that they'd been running the test for 3 years, it contained real production data & they'd been told for the past 2 years to stop or buy more license.
It ended badly for all concerned. Except for IBM. And me. Always take hard copy of important emails.....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| DaeMoohn |
| Posted: Mon Mar 11, 2013 1:22 pm Post subject: |
|
|
Apprentice
Joined: 04 Jun 2010
Posts: 26
|
First, to clarify, I didn't say it's free, I said it's free of charge, that means that the conditions of the license that I use, which I am bound to respect it, make the software free to use. No piracy involved. Now, let's get on:
1. solidDb was already on my list as a caching solution. I'm not sure how it distributes, but distribution might not be a good idea. solidDb is owned by IBM, so it's even better, but I have no prior knowledge of use.
2. Solved.
3. I read some posts with setting the expiry time so that you get an inverse logic (the notification of expiration tells you something actually happened).
4. The entity that would hold state would be a Process Manager if you would use EAI terminology.
5. I don't plan using Websphere Message Broker at all because I don't need any transformation on the messages being sent. There would be no business logic inside the messaging infrastructure. I need the message infrastructure to scale in both dimensions easily, without tying my feet to databases. For more architecture related info, check Command Query Responsibility Separation (CQRS).
6. Azure Service Bus isn't an equal match of Websphere MQ, I know. I used it here because it has features that, shamefully, Azure Queues doesn't have, like publish/subscribe(!!!), which Websphere MQ does.
7. I'm not a nitpicker trying to find edge cases where something works and other stuff doesn't. I try to implement an "agnostic way" that my application would handle Websphere MQ or Azure Service Bus or MSMQ so that the core of it would remain un-poluted with this infrastructure stuff. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Mar 11, 2013 3:50 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| DaeMoohn wrote: |
| First, to clarify, I didn't say it's free, I said it's free of charge, that means that the conditions of the license that I use, which I am bound to respect it, make the software free to use. |
Echoing my point; fine for a proof of concept, subject to a license when used otherwise unless all your software has is the client, which then leaves you reliant on your customer to have (and configure correctly) the support you need.
| DaeMoohn wrote: |
| 1. solidDb was already on my list as a caching solution. I'm not sure how it distributes, but distribution might not be a good idea. solidDb is owned by IBM, so it's even better, but I have no prior knowledge of use. |
It distributes like all IBM software; see above.
| DaeMoohn wrote: |
| 2. Solved. |
Or at least clarified.
| DaeMoohn wrote: |
| 3. I read some posts with setting the expiry time so that you get an inverse logic (the notification of expiration tells you something actually happened). |
What you're describing are the WMQ report options, where one of the reports is that the message has expired. IMHO the problem with the use case you describe here is where you want to cancel the wait when another message shows up. Unless you can correlate the messages (in the technical sense) to find and consume the waiting message it will go off anyway. Even if you can correlate (with MsgId, JMS Selectors, etc) you could get in a tangle & not be performant.
| DaeMoohn wrote: |
| 4. The entity that would hold state would be a Process Manager if you would use EAI terminology. |
IBM makes one. It fully integrates with WMQ & WMB.
| DaeMoohn wrote: |
| 5. I don't plan using Websphere Message Broker at all because I don't need any transformation on the messages being sent. There would be no business logic inside the messaging infrastructure. I need the message infrastructure to scale in both dimensions easily, without tying my feet to databases. |
- WMB does much more than transform messages
- WMB does not tie your feet or any part of you to a database in v7 or later
- WMB scales in both directions very well
| DaeMoohn wrote: |
| 6. Azure Service Bus isn't an equal match of Websphere MQ, I know. I used it here because it has features that, shamefully, Azure Queues doesn't have, like publish/subscribe(!!!), which Websphere MQ does. |
Windoze.
| DaeMoohn wrote: |
| 7. I'm not a nitpicker trying to find edge cases where something works and other stuff doesn't. I try to implement an "agnostic way" that my application would handle Websphere MQ or Azure Service Bus or MSMQ so that the core of it would remain un-poluted with this infrastructure stuff. |
It's a noble ambition, but given the multitude of ways "this infrastructure stuff" exposes features it's a problem in the real world. Imagine you implement this wait feature with reporting (as I describe above), then you sell to a customer with Azure who wants to use scheduled messages.
I'm not nitpicking either. I'm just saying.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| DaeMoohn |
| Posted: Mon Mar 11, 2013 4:59 pm Post subject: |
|
|
Apprentice
Joined: 04 Jun 2010
Posts: 26
|
I never knew we also do BPM software  but i guess it's a bit too much. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Mar 12, 2013 3:48 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If you want to do it in a messaging infrastructure agnostic manner, then you must build to the lowest common denominator.
This means that you don't get to take unfair advantage of advanced features of specific technology.
This is what Vitor has pointed out.
If you want to compare MQ and Azure, you're really not comparing the same things. Azure is a service broker, that takes unfair advantage of features of WCF and MSMQ. IBM's service broker is Message Broker, which takes unfair advantage of features of WebSphere MQ.
Message Broker will let you send a message to a flow. This flow can then forward the message on to a backend service. At the same time, it can dispatch a timeout control message to cause a timeout notification node to fire 15 minutes later, which will start another message flow that can then do various things, including fire a cancellation message.
There are various ways you can construct both flows to share enough state such that you can cancel a specific request or cause a specific request not to actually get sent to the backend. |
|
| Back to top |
|
|
| DaeMoohn |
| Posted: Tue Mar 12, 2013 4:46 am Post subject: |
|
|
Apprentice
Joined: 04 Jun 2010
Posts: 26
|
Thanks, mqjeff, you made it clear now. I guess I'll target the least common denominator for the common cases. As this is just a proof of concept, the more advanced usages can be left out or introduced in a less delicate way. I use it as an exercise, an educational tool, so I don't want to delve into linking patterns into WMB. While it would be fun, adding too much complexity from the start would pollute the exercise. Thanks, guys!  |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
