|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Choosing between Mapping Node and XSLTransform node |
« View previous topic :: View next topic » |
Author |
Message
|
ethirajesh |
Posted: Tue Jun 14, 2011 1:42 am Post subject: Choosing between Mapping Node and XSLTransform node |
|
|
Apprentice
Joined: 04 Oct 2010 Posts: 46
|
Hi,
I need to do XML transformation after receiving the response from a webservice. My client wants the Transformation to be handled using XSLT(they dont want that transformation in ESQL), but I read that using XSLT will have performance issues. By using Mapping node can we overcome this?
And also what is the advantage of using XSLT instead of mapping, I guess they are insisting to use XSLT cos it ll be easier for the new person to change the mappings in the future. Can someone please explain the advantages and disadvantages of Mapping node and XSLT node?
Thanks |
|
Back to top |
|
 |
Vitor |
Posted: Tue Jun 14, 2011 4:09 am Post subject: Re: Choosing between Mapping Node and XSLTransform node |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
ethirajesh wrote: |
I read that using XSLT will have performance issues. |
Read where? Post the link.
AFAIK it's true that XSLT doesn't perform as well as the other nodes because WMB uses an off-the-shelf XSLT engine rather than the tuned & optimised ESQL (which the Mapping node does use - the node's just a way of graphically producing simple ESQL). But I think "performance issues" is a little strong, unless you have very higg volumes or small SLAs. In which case you need handwritten ESQL & your client needs to live with it.
Do you have high volumes and/or small SLAs?
ethirajesh wrote: |
I guess they are insisting to use XSLT cos it ll be easier for the new person to change the mappings in the future. Can someone please explain the advantages and disadvantages of Mapping node and XSLT node? |
That's one of the key advantages there - more people know XSLT than know how to work the Mapping node. It's the same reasoning that allows Compute nodes to use Java as well as ESQL.
One of the key disadvantages - using XSLT you're not getting the full benefit of the very expensive WMB license. The XSLT node is principlally intended for sites transitioning into WMB that have a large base of XSLT in use. You don't want to blow all that development investment, nor do you want to big bang convert all the XSLT into ESQL so you can use the existing XSLT under the WMB architecture and convert incrementally.
Others will have other and possibly better points to make. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
NealM |
Posted: Wed Jun 15, 2011 2:28 pm Post subject: |
|
|
 Master
Joined: 22 Feb 2011 Posts: 230 Location: NC or Utah (depends)
|
Some pretty neat WMB projects have been done via using the XSLTransform Node, with which XSLT to be applied in the Node as a variable. If for instance you have many possible message types to be transformed but the rest of the flow logic is the same, you might find that a very simple flow with one XSLT Node could do the work of multiple flows/subflows with multiple Mapping or Compute Nodes.
Aside from that, XSLT isn't inherently slow, as witness its use in the DataPower appliances. Sometimes it's a matter of bugging IBM about upgrading the engine being used. |
|
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
|
|
|
|