| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Minimizing Compute Nodes - Design |
« View previous topic :: View next topic » |
| Author |
Message
|
| Devasis.Sahu |
 Posted: Wed Mar 30, 2005 7:13 pm Post subject: Minimizing Compute Nodes - Design |
 |
|
Apprentice
Joined: 22 Feb 2003
Posts: 43
Location: India
|
Hello Team,
I was contemplating as to how we can reduce the number of compute nodes in the following scenrio:
1. Input is XML.
2. Standard subflow routing happens based on some unique system ID.
3. Main subflow consists of MQInput --> Compute --> Route to Label nodes.
4. The subflows consist of Label--> Compute / Database /Mapping node --> MQOutput node.
5. The functionality is such that lot of resuability can happen as the XML elements would be common in the Input XML and mapping/transformation of input elements to output XML would also be similar.
Given the requirement,
1. Is there a way we can see and reduce the number of compute nodes in the Subflow.
2. Is there a way where we can write any function where we can just pass the XML file name ?
3. What could be the best alternative to the above design ?
Do let me know in case more clarity is required.
Regds. |
|
| Back to top |
|
 |
| jfluitsm |
| Posted: Wed Mar 30, 2005 11:25 pm Post subject: |
|
|
Disciple
Joined: 24 Feb 2002
Posts: 160
Location: The Netherlands
|
At first sight you don't use that much of compute nodes.
What you do in a database or mapping node can also be done in a compute node, depending your situation this might render more code as reusable.
You can also create a seperate ESQL file (or more files) containing reusable procedures/functions, the (Input/Output)Root and (Local)Environment correlation names are global, so you don't need to pass them as argument.
Place these files in a seperate project and add this project as a Project reference to your messageflow projects (project properties).
_________________
Jan Fluitsma
IBM Certified Solution Designer WebSphere MQ V6
IBM Certified Solution Developer WebSphere Message Broker V6 |
|
| Back to top |
|
|
| Devasis.Sahu |
| Posted: Wed Mar 30, 2005 11:52 pm Post subject: |
|
|
Apprentice
Joined: 22 Feb 2003
Posts: 43
Location: India
|
Well...That solution is already in place ...and we are gonna implement that as well. But i was trying to find out if there is any better way to implement the same.
Please do let me know if there are any other ways to do the same.
Regds |
|
| Back to top |
|
|
| hopsala |
| Posted: Wed Mar 30, 2005 11:56 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
a bit difficult to give design advice from afar and with so little info...
However, I can give you two tips from my own experience:
First, Instead of using label nodes for internal routing in your flows, use WMQ queues as your internal routing system. This has many advantages - less computation time per flow, easier administration, if you wish to make a small change to some logic in your prog you only need to deploy one flow, easier testing and more. In short, more modular, with all the derived advantages.
Second, if you have the skills, use XSL. Seems to me that if one uses XML and is in touch with the XML world, it is better to use the manipulation tools designed for this specific purpose by the people who defined XML as it is, than use the proprietary ESQL code. Also, XSL, if written correctly, can be quite efficient, and there are things that cannot be accomplished using ESQL.
(In case you don't know, depending on which version you have, there's an XSL node in IBM support pacs or within the product) |
|
| Back to top |
|
|
| JLRowe |
| Posted: Thu Mar 31, 2005 3:52 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
From my experience, XSL is not as efficient as ESQL.
ESQL manipulates the WBIMB message tree directly.
The XSL node cannot operate directly on the WBIMB message tree as it is written in java and operates on a DOM message tree.
So, the XSL node performs the following operations:
1 - serialize the WBIMB message tree
2 - parse using DOM
3 - apply transformation
4 - serialize from DOM
5 - parse back into a WBIMB message tree
If you do not manipulate the tree using ESQL prior to the XSL node, then step (1) may be skipped as the XSL node can read the bitstream directly. |
|
| Back to top |
|
|
| Tibor |
| Posted: Thu Mar 31, 2005 7:19 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
| hopsala wrote: |
| First, Instead of using label nodes for internal routing in your flows, use WMQ queues as your internal routing system. |
It seems strange for me - how can be faster a transactional MQPUT() than stepping to a new node (however I don't know the broker internal).
| hopsala wrote: |
| Second, if you have the skills, use XSL. |
Timna may be right about the the processing time, but when the messages arrive in XML format, the development can be simpler using XSLT. There is a lot of people developing in XML/XSLT - just compare how many understanding understanding ESQL and MessageTree...
Tibor |
|
| Back to top |
|
|
| JLRowe |
| Posted: Thu Mar 31, 2005 8:44 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
Tibor, I agree totally that XSL is a very portable skill. Also, the #1 sin in development is premature optimisation - i.e. improving the performance of code that actually performs adequately by tweaking it and perhaps making it less maintainable.
However, serialisation is very expensive. That's why connecting flows via queues gives crap performance, and why people need to be aware of what goes on under the covers in the XSL node. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Mar 31, 2005 5:39 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I'd just like to weigh in with the thought that "reducing the number of compute nodes" is a silly one.
It is the same thought as "We can make our MQ network simpler by reducing the number of queues we have".
Your message flow should be like any other program - it should be modular enough to be maintainable and it should be EXPLICIT in what it does, not IMPLICIT.
It should only be as simple as it needs to be and no simpler.
There are some minor performance gains that can be had by using fewer nodes in a message flow. But first you need to measure the performance, and to do that you need to understand what you are measuring and before that you need to understand WHY you are measuring.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| hopsala |
| Posted: Sat Apr 02, 2005 12:37 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Well, naturally both XSL and using WMQ queues will be slower, much much slower. However, look at it this way:
The only thing that matters is cost, in the most abstract and general sense of the term. If you use label nodes and ESQL you shall indeed have faster running message flows, but difficult maintenance, a less modular design, and you shall have to keep teaching your team ESQL skills and other WBI proprietary (yes, WBI is proprietary!) skills instead of using portable skills such as XSL.
So, instead of investing money on skill-learning and maintenance, have a system which costs far less in maintenance and invest what you saved on faster machines. In my experience, a-totale this yields better results, with smaller costs.
(As silly as it may sound, paying more for a faster machine has no moral effect on a team's spirit, but having to dive through a huge code each time you need a small change does)
The only problem with this is that the costs "saved" by building a better system are almost impossible to evaluate, only through experience and foresight can one know that such a strategy actually works.
Sometimes only 3 years into production I suddenly thank yourself for some small design concept I insisted upon when I first built the system. These are such concepts. |
|
| Back to top |
|
|
| javaforvivek |
| Posted: Sun Apr 03, 2005 10:01 pm Post subject: |
|
|
Master
Joined: 14 Jun 2002
Posts: 282
Location: Pune,India
|
Well,
The main question was,
| Quote: |
| How to reduce number of Compute Nodes in the design? |
I think, the answer to this question will vary from Project to Project depending on the requirements.
Another point raised was the performance of XSL v/s compute nodes.
So you gotta use either XSLT or Compute nodes.
If I were to make these decisions, I would certainly go for Compute Nodes for message manipulation, but there are some peculiar functionality like sorting the XML based on some value in tag, etc, are not furnished by ESQL. There u gotta have XSLT nodes.
As far as ESQL learning curve goes, I don't think it's that difficult especially if your people are familiar with SQL syntax. And you have to think about the learning costs, etc, before buying the product. As everybody here has saad that ESQL is proprietey lingo, you should be aware of it.
Its absurd that after purchasing WBIMB, if you say that learning curve for this product is too long..
I agree with jefflowrey when he says tht
| Quote: |
| your msg flow should be modular enough for you to maintain it, and it should be explicit in what it does, and not implicit |
You can not start the project on WBIMB (rather on any new technology) before you have trained staff for it.
And if you find that Training costs are too high for WBIMB, then you could have evaluated it before purchasing it.
Again if you are trying to use other technology like XSL instead of Compute nodes, then you are not utilizing the true potential of WBIMB, and hence defeating the purpose of buying it.. In other words you are wasting your money on its purchase, where you could have done everything using pure Java Code or pure XSL transformations or both of them togather..
Coming back to the original question,
You have to identify what functionality is catered by mapping,database and compute nodes. If it's just a message mapping along with the database interaction, you may use mapping nodes. If its just database interaction, use Database nodes. If its generating entirely new message using data from old message along with some database interaction, use Compute node . Compute nodes can be used in the other two scenarios as well. If you are using CSD4, it gives the facility of calling external Java methods, which you can only use in Compute Nodes (Experts here - correct me if I'm worng in saying this).
_________________
Vivek
------------------------------------------------------
...when you have eliminated the impossible, whatever remains, however improbable, must be the truth. |
|
| Back to top |
|
|
| mgk |
| Posted: Mon Apr 04, 2005 12:47 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
You can actually call Java methods in any ESQL node as of V5 CSD4.
Cheers,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| 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
|
|
|
|
