| Author |
Message
|
| fromkrishna |
 Posted: Tue May 19, 2009 12:32 am Post subject: Design Suggestion |
 |
|
Newbie
Joined: 19 May 2009
Posts: 3
|
Hello,
Appreciate if someone clarify the below points on usage of XSL transformation node. We are using MQ/WMB 6.1 in our project.
1. How XSL transformation node is better than normal mapping/compute node? Which approach is advisible? develop XSLTs & use XSL transformation node for transformation or use compute node for transformation?
2. Is there any limitations using XSL transformation node than using simple compute node for mapping ?
3. Is there any issues will face later on using XSL transformation node during migration / Production Support ?
Please advise. Thanks in Advance.
Krishna |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue May 19, 2009 12:38 am Post subject: Re: Design Suggestion |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fromkrishna wrote: |
| 1. How XSL transformation node is better than normal mapping/compute node? Which approach is advisible? develop XSLTs & use XSL transformation node for transformation or use compute node for transformation? |
It's not "better"; it's intended for use where you have a large number of XSLT transformations from your pre-WMB days. These can be used in WMB, gaining you immediate benefit while allowing future development using other methods.
| fromkrishna wrote: |
| 2. Is there any limitations using XSL transformation node than using simple compute node for mapping ? |
Yes - the XSLT by it's nature can't do everything a compute node can do. The compute nodes are also faster and lighter than the XSLT, though how much you notice this depends on your situation.
| fromkrishna wrote: |
| 3. Is there any issues will face later on using XSL transformation node during migration / Production Support ? |
Such as? It's the same as deploying any other flow.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fromkrishna |
| Posted: Tue May 19, 2009 1:06 am Post subject: |
|
|
Newbie
Joined: 19 May 2009
Posts: 3
|
Vittor, thanks for your quick response.
Our project doesnt have any complex transformation logics involved. The requirement are mostly simple transformations at ESB level.
I can define one main message flow having XSL transformation node at
enterprise level, dynamically access XSL's at different project level in main message flow.
In this case, defining multiple compute node at project level can be avoided right? |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue May 19, 2009 1:31 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fromkrishna wrote: |
I can define one main message flow having XSL transformation node at
enterprise level, dynamically access XSL's at different project level in main message flow. |
I don't understand what you mean by enterprise and project level; flows are functional.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Tue May 19, 2009 1:51 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| Vitor wrote: |
| fromkrishna wrote: |
I can define one main message flow having XSL transformation node at
enterprise level, dynamically access XSL's at different project level in main message flow. |
I don't understand what you mean by enterprise and project level; flows are functional. |
Vitor,
I think he means that he will have one flow that applies a stylesheet (based on some lookup criteria) to XML and as projects come along they will deliver new stylesheets to this flow (well the stylesheet repository of it anyway).
| Quote: |
| n this case, defining multiple compute node at project level can be avoided right? |
Correct, this should be doable. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue May 19, 2009 1:57 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| WMBDEV1 wrote: |
| I think he means that he will have one flow that applies a stylesheet (based on some lookup criteria) to XML and as projects come along they will deliver new stylesheets to this flow (well the stylesheet repository of it anyway). |
Then save the license fee for WMB and install a copy of Xalan. 
Seriously, WMB is a large, expensive and heavyweight way of running XSLT, if that's all you're doing and as you clearly intend to continue developing XSLT rather than move to compute nodes.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fromkrishna |
| Posted: Tue May 19, 2009 2:26 am Post subject: |
|
|
Newbie
Joined: 19 May 2009
Posts: 3
|
Yes Devi, you are correct. I can define one main flow & have a dynamic lookup for Stylesheets, Queue & QMgr names at project level. For any new projects, no need to create a new message flow, rather I can develop a simple style sheet itself.
Is this approach is advisible?
If Compute node has advantage of being only a light weight component, I can prefer XSL for transformations ryt? If NFR is the only trouble factor on usage of XSL transformation node than Compute, anyway through this approach, I'll be avoiding creating individual message flows for every projects right? |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue May 19, 2009 2:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fromkrishna wrote: |
| If Compute node has advantage of being only a light weight component, I can prefer XSL for transformations ryt? |
I think you may have misunderstood me. The Compute node has more facilities than the XSLT, and is "lightweight" in the sense it uses less resource like-for-like doing the work.
The point I was driving at is that if you're running an entire WMB setup just to run XSLT transformations, there are simpler and more lightweight ways of obtaining this. If you plan to leverage WMB to use some of it's other features, then Compute nodes are the way to go.
| fromkrishna wrote: |
| I'll be avoiding creating individual message flows for every projects right? |
I'm also slightly concerned that the transformations are at project rather than functional level. You also seem to be placing a lot of control outside of WMB here; you write one single flow that spends it's day running XSLTs which are updated by individual projects, rather than co-ordinating like functions into flow. That's a lot to leave to other, and may prove to be a rod for your own back.
But you know your situation best. It's not how I'd do it, but I'm not doing it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Tue May 19, 2009 2:36 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
I think the approach is sound for both existing XSLT transformations and future transformations that are not too complex.
I see this type of service complementing the other flows in your infrastructure rather than being the be all and end all.
For more complex stuff I'd definatly look at using the compute node as suggested by Vitor. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue May 19, 2009 3:06 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| WMBDEV1 wrote: |
I see this type of service complementing the other flows in your infrastructure rather than being the be all and end all.
|
My fear here is that the poster is talking either / or, and may find they're locked in to an XSLT methodology.
But as I said, I don't know the whole story.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
