| Author |
Message
|
| PeterPotkay |
 Posted: Thu Aug 11, 2011 1:43 pm Post subject: So what do you say.... |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
....to the application team that says " Gee, we have this nice farm of WMB Brokers in house, and there is capacity on them, so why don't we just use WMB to run our entire set off application logic including business logic for this new app we are building. Its easy enough for us to handle with ESQL and/or Java Compute nodes."
I've bounced this off of a couple of people and gotten all sorts of view points. What's yours?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Thu Aug 11, 2011 1:53 pm Post subject: Re: So what do you say.... |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| PeterPotkay wrote: |
....to the application team that says " Gee, we have this nice farm of WMB Brokers in house, and there is capacity on them, so why don't we just use WMB to run our entire set off application logic including business logic for this new app we are building. Its easy enough for us to handle with ESQL and/or Java Compute nodes."
I've bounced this off of a couple of people and gotten all sorts of view points. What's yours? |
Are they crazy? If they want to segregate the business rules into a repository, have them use ILog. That is what ILog was built for...
If they need additional logic such as orchestration, state machine, etc... WPS can help.
Reserve WMB for what it does best: stateless traffic: routing, transformation, protocol switching, etc...
That's my $0.02 worth 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mapa |
| Posted: Thu Aug 11, 2011 2:15 pm Post subject: |
|
|
Master
Joined: 09 Aug 2001
Posts: 257
Location: Malmö, Sweden
|
I agree with fjp_saper to use the WMB what it is good at.
I every now and then have to fight hard to keep business logic out of the broker.
When I was new into integration in late 90's I didn't know better and that was a hard lesson. SAP consultants tricking the team into that it wasn't possible to implement in SAP and so easy in the integration broker we had then (non-IBM). That was until we hired a freelance SAP guru who could help our team against such claims.
It is often easy and very fast to implement in the broker, but a nightmare to maintain.
_________________
Brgds, Magnus Palmér
Enfo Zystems |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 11, 2011 4:55 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
I add my voice to this. Trying to keep state information inside WMB is a nightmare matched only by trying to remember where all the business logic is buried.
Use WMB for what it's good for. Use WPS, WAS or something else for the rest.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Aug 11, 2011 5:00 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
FJ, WMB does do those thing you listed very well. But you did not give a reason why you couldn't add business logic into the compute nodes.
mapa, the one reason you listed is its a nightmare to maintain. What's so difficult about making the change to the ESQL or Java compute node and redeploying the bar file every release cycle?
I am with you guys. Ever since I was an MQ noob its been drilled into my head the Broker is for message transformation, content based routing, switching protocols between disparate apps (MQ in, HTTP out for example) - and don't you even think about adding business logic in there. But exactly why can't you, or I guess more correctly why shouldn't you, drop some business logic in there?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Aug 11, 2011 7:41 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| PeterPotkay wrote: |
FJ, WMB does do those thing you listed very well. But you did not give a reason why you couldn't add business logic into the compute nodes.
mapa, the one reason you listed is its a nightmare to maintain. What's so difficult about making the change to the ESQL or Java compute node and redeploying the bar file every release cycle?
I am with you guys. Ever since I was an MQ noob its been drilled into my head the Broker is for message transformation, content based routing, switching protocols between disparate apps (MQ in, HTTP out for example) - and don't you even think about adding business logic in there. But exactly why can't you, or I guess more correctly why shouldn't you, drop some business logic in there? |
Business logic is by design very fluid and prone to a lot of changes. You do not want to be constantly deploying and testing new code.
The business logic should go into a repository like ILog, which will enable the business people to maintain it. WMB, WAS, WPS and whatever other alphabet soup you use should then just query the ILog rules server and use the result to drive their processes. ILog also allows you to simulate changes and the impact it would / could have on your business decisions...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mapa |
| Posted: Thu Aug 11, 2011 9:58 pm Post subject: |
|
|
Master
Joined: 09 Aug 2001
Posts: 257
Location: Malmö, Sweden
|
Once again I agree with fjb_saper, apart from the ILog which I have no knowledge of.
Also it is often only some business logic they want in the broker, not all.
Maybe if all of the main business logic were handled by the broker but I can't see such a scenario. Then again, I listened to an architect from Skype at a conference and he claimed that ALL backend business rules were kept in the stored procedures...
http://www.infoq.com/articles/learnings-five-years-skype-architect
Also advanced business logic often requires state and correlation with other business events.
Do to conclude I don't say never, but can't see a case were the limitations for doing it is fulfilled.
_________________
Brgds, Magnus Palmér
Enfo Zystems |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Aug 11, 2011 10:05 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| mapa wrote: |
Also advanced business logic often requires state and correlation with other business events.
|
And that (for very good reasons) is why Broker is a bad bad bad choice for holding your business logic.
When I were a lad and apprentice, I quickly learned that I should always use the right tool for the job.
Broker is not the right tool for business logic. If you have complicated state dependant logic that requires human interaction use Process Server not a transformation engine.
However,
I still open paint tins with a large flat bladed screwdriver...
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| marko.pitkanen |
| Posted: Thu Aug 11, 2011 10:15 pm Post subject: |
|
|
Chevalier
Joined: 23 Jul 2008
Posts: 440
Location: Jamsa, Finland
|
Hi,
As mentioned before there are a lot of reasons why you should avoid business logic at the broker: Broker's main purpose is to do message driven, stateless message content or protocol conversion fast and reliable (there are nowadays also built-in nodes that enables broker function like ESB end-point container (product specific EIS -nodes)). Broker professionals are rare than for example J2EE -professionals. There are products that are designed to do process control, maintain states and do business decisions.
The decision is perhaps political: At decision phase you should fight as much as possible to use products that are designed to solve certain business needs.
You can do a lot of things also at broker. You need perhaps extra home made solutions to enable broker function as dynamic business decision rule or state engine which you need to maintain and develop (need to evaluate life cycle cost, ensure that the competent is available for whole life cycle and so on).
After decision you should document, publish and market the decision (and responsibilities) and it's causes all over you organisation.
--
Marko |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Aug 12, 2011 4:20 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Disclaimer: I am not a developer. My WMB flows were always extremely simple affairs used for my own purposes and not to support business. Yes I took training, but the last time was at version WB-IMB 5.0 and if your not working with flows regularly.... Plus I've never built any apps that run on application servers. I'm just that MQ guy.
This is why I need your help.
| fjb_saper wrote: |
| Business logic is by design very fluid and prone to a lot of changes. You do not want to be constantly deploying and testing new code. |
If the business requirements change, somebody somewhere needs to deploy and test code. I don't see why its any more difficult in WMB. And maybe other shops are different, but it seems here that very often (but not always), when the app areas are changing their apps, there are corresponding WMB changes required anyway to insure the mapping between the new versions of the app(s) works.
| smdavies99 wrote: |
mapa wrote:
Also advanced business logic often requires state and correlation with other business events.
And that (for very good reasons) is why Broker is a bad bad bad choice for holding your business logic.
|
state and correlation with other business events - what about Collector Nodes and Database Nodes?
I still feel its technically possible to do what you need to in WMB. Can I get a specific example that shows why its a bad idea? Is it getting more difficult to make this argument with every release of WMB as it becomes more and more capable with all the bells and whistles and performance each release brings?
One thing I can think of is that WMB is a very expensive sledge hammer approach to be running business logic. Why burn up CPU cycles and memory and chew up your spare capacity doing business logic when that should be executed on a more cost effective platform? Leave the WMB capacity to allow WMB to scream at the things WMB is best at - routing, transformation and protocol switching.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Aug 12, 2011 4:34 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Had this same question yesterday with a system designer. She said she had some files that needed to be moved from one folder to another folder, could we use Broker to do it? Her rationale was, we should use Broker for everything, its a "bus", right?.
I explained that Broker has a finite capacity, not unlimited. Yes, you could use Broker to do this, but Broker does not add any value to the process over what cron and a pojo could do. So, if we did this on Broker, we are choosing the most expensive way to do what free could have done.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Aug 12, 2011 5:10 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| lancelotlinc wrote: |
| ...but Broker does not add any value to the process over what cron and a pojo could do. So, if we did this on Broker, we are choosing the most expensive way to do what free could have done. |
Ah, I like that argument. That goes into the toolbox.
Notice how I phrased my initial question though. The problem scenario has a new app that will need to run somewhere, and they're greedily eying that sweet WMB Farm that runs so well from everything they've heard. Why bother getting our own app servers, just give us an Execution Group!
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Aug 12, 2011 5:49 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| The problem scenario has a new app that will need to run somewhere, and they're greedily eying that sweet WMB Farm that runs so well from everything they've heard. Why bother getting our own app servers, just give us an Execution Group! |
I think the valid point made can be extended further; by writing the application to run in ESQL or JCN, the code is inside a large and fairly complex framework. It's this that I'm talking about when I discuss business logic being "buried" inside broker.
Contrast that with a set of MDBs or similar running inside an app server. Easy to see without WMB training, quick to change and test (even if the WMB is under CI) and quick to deploy.
Also you can keep state inside WMB with a database and correlation. It's a sledgehammer to crack a nut and surprisingly easy to tie up in knots; having tried it once (having lost a game of "who has the most influentical manager" with the WPS team) a lot of stuff crawls out of the woodwork, especially when state changes due to time expiry or other non-service causes.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| dilse |
| Posted: Fri Aug 12, 2011 5:56 am Post subject: |
|
|
Master
Joined: 24 Jun 2004
Posts: 270
|
| Quote: |
| One thing I can think of is that WMB is a very expensive sledge hammer approach to be running business logic. Why burn up CPU cycles and memory and chew up your spare capacity doing business logic when that should be executed on a more cost effective platform? |
I definitely agree with the above statement. I implemented the bus using WMB in different places with different principles based on type of business that the customer is and based differentent Architect's idealogies.
But in my opinion, as a long as broker is not being used for business process orchestration or for long-running transactions, it may make sense to implement the business logic in Message broker.
But I also see the advantage behind restricting the stateless transformation, routing, enrichment and protocol transfer as thats where you need Broker's major help and the product was designed to start with. This restriction not only makes quick and easy implementation of middlware logic but also makes a new person to take on either modifying an existing interface or a new interface quickly without needing to know what the busimess knowledge involved.
My 2 cents..
_________________
DilSe..
Take life as it comes.. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Aug 12, 2011 9:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| PeterPotkay wrote: |
| The problem scenario has a new app that will need to run somewhere, and they're greedily eying that sweet WMB Farm that runs so well from everything they've heard. Why bother getting our own app servers, just give us an Execution Group! |
I think the valid point made can be extended further; by writing the application to run in ESQL or JCN, the code is inside a large and fairly complex framework. It's this that I'm talking about when I discuss business logic being "buried" inside broker.
Contrast that with a set of MDBs or similar running inside an app server. Easy to see without WMB training, quick to change and test (even if the WMB is under CI) and quick to deploy. |
Okay, I completely disagree with most of this.
Broker is *just* fine for business logic, provided it is indeed a stateless business logic that needs to be run.
And the difference between an ESQL compute node and an MDB - the code in either case is "buried" in a large and complex framework! In fact, JEE is a significantly more complex and significantly larger framework than the Broker runtime is. And the amount of code needed to actually PARSE a message in JEE is significantly uglier than in Broker.
The amount of *user written* code is going to be *much* larger to do the same task with an MDB than with a Broker flow with an MQInput node, a compute node, and an MQOutput node.
And it's the user written code that holds all of the bugs!
Unless you have to deal with state, there's no reason not to do *everything* in Message Broker. It's at least as reliable as WAS from a runtime perspective, significantly faster to develop code with, just as easy to automate the compile/build/deploy/test cycle to ensure quality code, and etc. etc. etc. |
|
| Back to top |
|
|
|
|
