[Dev] Creating A Custom Mediator For XSLT Transfomation : Binary Relay Enabled ESB

[Andun Sameera]

Hi All,

My requirement is $Subject. Purpose of this is avoid using AXIOM to to XSLT
transformation. Our plan was to do all the transformation using Input,
Output Streams. javax.xml.transform.Transformer is used to do
the transformation using streams. I developed the mediator using
the following logic,


   - In the Binary Relay We get the Message as a Data Handler in a Dummy
   SOAP Message. From that we can get a Input Stream for the SOAP message
   which needs to be transformed using XSLT.
   - We can Get the input Stream for the XSLT file, which is in registry or
   local.
   - Using those two we can do the XSLT transformation. As a result we get
   a stream for the transformed SOAP message.
   - Finally I create a DataHandler using the stream and attached it to the
   Relay's Dummy SOAP message replacing existing one.

The output of the mediator follows this logic is given below. I used the Sample
8of
ESB. I replaced the XSLT mediator with my custom mediator in the
Binary
Relay.
But there is a major problem here. Because of the logic we used the
original SOAP message,

http://schemas.xmlsoap.org/soap/envelope/";>http://www.w3.org/2005/08/addressing";>
http://localhost:9000/services/SimpleStockQuoteServiceurn:uuid:0f7403b4-c5bc-4347-8921-562f2736a2aburn:getQuotehttp://services.samples
">IBM

 is now converted to.

http://services.samples";>
   
  IBM
   


At the end Binary Relay Formatter will read the DataHandler and above SOAP
message will be sent to the AXIS2 Server and It will crash, because this is
not a valid SOAP message.
This problem occurs because we are not using AXIOM anymore. In the normal
XSLT mediator it uses org.apache.synapse.util.xpath.SourceXPathSupport
class to find the part of the message which transformed using XSLT. So it
can replace the transformed part of the original message. But here we cant
use that kind of a logic. Because we use only streams. We cant build
OMElements or etc.

Need help to solve this problem. The custom mediator java files are
attached here.

Thanks
AndunSLG

References :

[1] -
http://wso2.org/project/esb/java/4.0.3/docs/samples/message_mediation_samples.html#Sample8


Console Output for the Custom Mediator :

.Original SOAP Envelop..
http://www.w3.org/2003/05/soap-envelope";>http://ws.apache.org/commons/ns/payload
">PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0nVVRGLTgnPz48c29hcGVudjpFbnZlbG9wZSB4bWxuczpzb2FwZW52PSJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy9zb2FwL2VudmVsb3BlLyI+PHNvYXBlbnY6SGVhZGVyIHhtbG5zOndzYT0iaHR0cDovL3d3dy53My5vcmcvMjAwNS8wOC9hZGRyZXNzaW5nIj48d3NhOlRvPmh0dHA6Ly9sb2NhbGhvc3Q6OTAwMC9zZXJ2aWNlcy9TaW1wbGVTdG9ja1F1b3RlU2VydmljZTwvd3NhOlRvPjx3c2E6TWVzc2FnZUlEPnVybjp1dWlkOjBmNzQwM2I0LWM1YmMtNDM0Ny04OTIxLTU2MmYyNzM2YTJhYjwvd3NhOk1lc3NhZ2VJRD48d3NhOkFjdGlvbj51cm46Z2V0UXVvdGU8L3dzYTpBY3Rpb24+PC9zb2FwZW52OkhlYWRlcj48c29hcGVudjpCb2R5PjxtMDpDaGVja1ByaWNlUmVxdWVzdCB4bWxuczptMD0iaHR0cDovL3NlcnZpY2VzLnNhbXBsZXMiPjxtMDpDb2RlPklCTTwvbTA6Q29kZT48L20wOkNoZWNrUHJpY2VSZXF1ZXN0Pjwvc29hcGVudjpCb2R5Pjwvc29hcGVudjpFbnZlbG9wZT4=


.Original SOAP Message
http://schemas.xmlsoap.org/soap/envelope/";>http://www.w3.org/2005/08/addressing";>
http://localhost:9000/services/SimpleStockQuoteServiceurn:uuid:0f7403b4-c5bc-4347-8921-562f2736a2aburn:getQuotehttp://services.samples
">IBM


Transforming On Progress.

...Transformed SOAP Message...
http://services.samples";>
   
  IBM
   

..

...Transformed SOAP Envelop..
http://www.w3.org/2003/05/soap-envelope";>http://ws.apache.org/commons/ns/payload
">PG06Z2V0UXVvdGUgeG1sbnM6bT0iaHR0cDovL3NlcnZpY2VzLnNhbXBsZXMiPgogICA8bTpyZXF1ZXN0PgogICAgICA8bTpzeW1ib2w+SUJNPC9tOnN5bWJvbD4KICAgPC9tOnJlcXVlc3Q+CjwvbTpnZXRRdW90ZT4K
..


MessageDataSource.java
Description: Binary data


MessageOMDataSource.java
Description: Binary data


XMLConvertor.java
Description: Binary data


transform.xslt
Description: Binary data
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Creating A Custom Mediator For XSLT Transfomation : Binary Relay Enabled ESB

[Amila Suriarachchi]

Does xslt engine supports xml stream level transformations?

After xslt transformations users may want to do further processing with the
message. So in that case we can avoid building request Axiom object but may
required to create the transformed Axiom object.

thanks,
Amila.

On Sat, Sep 15, 2012 at 4:16 PM, Andun Sameera  wrote:

> Hi All,
>
> My requirement is $Subject. Purpose of this is avoid using AXIOM to to
> XSLT transformation. Our plan was to do all the transformation using Input,
> Output Streams. javax.xml.transform.Transformer is used to do
> the transformation using streams. I developed the mediator using
> the following logic,
>
>
>- In the Binary Relay We get the Message as a Data Handler in a Dummy
>SOAP Message. From that we can get a Input Stream for the SOAP message
>which needs to be transformed using XSLT.
>- We can Get the input Stream for the XSLT file, which is in registry
>or local.
>- Using those two we can do the XSLT transformation. As a result we
>get a stream for the transformed SOAP message.
>- Finally I create a DataHandler using the stream and attached it to
>the Relay's Dummy SOAP message replacing existing one.
>
> The output of the mediator follows this logic is given below. I used the 
> Sample
> 8of
>  ESB. I replaced the XSLT mediator with my custom mediator in the Binary
> Relay.
> But there is a major problem here. Because of the logic we used the
> original SOAP message,
>
>  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";> xmlns:wsa="http://www.w3.org/2005/08/addressing";>
> http://localhost:9000/services/SimpleStockQuoteServiceurn:uuid:0f7403b4-c5bc-4347-8921-562f2736a2aburn:getQuote xmlns:m0="http://services.samples
> ">IBM
>
>  is now converted to.
>
> http://services.samples";>
>
>   IBM
>
> 
>
> At the end Binary Relay Formatter will read the DataHandler and above SOAP
> message will be sent to the AXIS2 Server and It will crash, because this is
> not a valid SOAP message.
> This problem occurs because we are not using AXIOM anymore. In the normal
> XSLT mediator it uses org.apache.synapse.util.xpath.SourceXPathSupport
> class to find the part of the message which transformed using XSLT. So it
> can replace the transformed part of the original message. But here we cant
> use that kind of a logic. Because we use only streams. We cant build
> OMElements or etc.
>
> Need help to solve this problem. The custom mediator java files are
> attached here.
>
> Thanks
> AndunSLG
>
> References :
>
> [1] -
> http://wso2.org/project/esb/java/4.0.3/docs/samples/message_mediation_samples.html#Sample8
>
>
> Console Output for the Custom Mediator :
>
> .Original SOAP Envelop..
> http://www.w3.org/2003/05/soap-envelope";> xmlns:ns="http://ws.apache.org/commons/ns/payload
> ">PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0nVVRGLTgnPz48c29hcGVudjpFbnZlbG9wZSB4bWxuczpzb2FwZW52PSJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy9zb2FwL2VudmVsb3BlLyI+PHNvYXBlbnY6SGVhZGVyIHhtbG5zOndzYT0iaHR0cDovL3d3dy53My5vcmcvMjAwNS8wOC9hZGRyZXNzaW5nIj48d3NhOlRvPmh0dHA6Ly9sb2NhbGhvc3Q6OTAwMC9zZXJ2aWNlcy9TaW1wbGVTdG9ja1F1b3RlU2VydmljZTwvd3NhOlRvPjx3c2E6TWVzc2FnZUlEPnVybjp1dWlkOjBmNzQwM2I0LWM1YmMtNDM0Ny04OTIxLTU2MmYyNzM2YTJhYjwvd3NhOk1lc3NhZ2VJRD48d3NhOkFjdGlvbj51cm46Z2V0UXVvdGU8L3dzYTpBY3Rpb24+PC9zb2FwZW52OkhlYWRlcj48c29hcGVudjpCb2R5PjxtMDpDaGVja1ByaWNlUmVxdWVzdCB4bWxuczptMD0iaHR0cDovL3NlcnZpY2VzLnNhbXBsZXMiPjxtMDpDb2RlPklCTTwvbTA6Q29kZT48L20wOkNoZWNrUHJpY2VSZXF1ZXN0Pjwvc29hcGVudjpCb2R5Pjwvc29hcGVudjpFbnZlbG9wZT4=
>
> 
>
> .Original SOAP Message
>  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";> xmlns:wsa="http://www.w3.org/2005/08/addressing";>
> http://localhost:9000/services/SimpleStockQuoteServiceurn:uuid:0f7403b4-c5bc-4347-8921-562f2736a2aburn:getQuote xmlns:m0="http://services.samples
> ">IBM
>
> 
>
> Transforming On Progress.
>
> ...Transformed SOAP Message...
> http://services.samples";>
>
>   IBM
>
> 
>
> ..
>
> ...Transformed SOAP Envelop..
> http://www.w3.org/2003/05/soap-envelope";> xmlns:ns="http://ws.apache.org/commons/ns/payload
> ">PG06Z2V0UXVvdGUgeG1sbnM6bT0iaHR0cDovL3NlcnZpY2VzLnNhbXBsZXMiPgogICA8bTpyZXF1ZXN0PgogICAgICA8bTpzeW1ib2w+SUJNPC9tOnN5bWJvbD4KICAgPC9tOnJlcXVlc3Q+CjwvbTpnZXRRdW90ZT4K
>
> ..
>
>


-- 
*Amila Suriarachchi*

Software Architect
WSO2 Inc. ; http://wso2.com
lean . enterprise . middleware

phone : +94 71 3082805

Re: [Dev] Creating A Custom Mediator For XSLT Transfomation : Binary Relay Enabled ESB

[Andun Sameera]

Hi Amila,

On Sat, Sep 15, 2012 at 9:22 PM, Amila Suriarachchi  wrote:

> Does xslt engine supports xml stream level transformations?


Yes. But not 100% streams, but we can transform StreamSource object to
a StreamResult using the Transformer.


> After xslt transformations users may want to do further processing with
> the message. So in that case we can avoid building request Axiom object but
> may required to create the transformed Axiom object.
>

Yes your argument is correct, sometimes we have to create the result
message. But I got in to trouble even before. In the present scenario, XSLT
mediator  read some parameters from the request using AXIOM. It read
weather transformation is happening to SOAP body or SOAP envelop etc. Based
on those parameters after the transformation mediator reform the message.
You can fine that logic in
[1]
.

But here I have no such parameters, I have only a input stream and
I transform it using the XSLT file. After transformation I have no clue
to reform the message. What I do is set the output stream to
the data-handler in binary relay dummy message. So some parts of the
original message get dropped and everything crashes here after.


> thanks,
> Amila.
>
>
> On Sat, Sep 15, 2012 at 4:16 PM, Andun Sameera  wrote:
>
>> Hi All,
>>
>> My requirement is $Subject. Purpose of this is avoid using AXIOM to to
>> XSLT transformation. Our plan was to do all the transformation using Input,
>> Output Streams. javax.xml.transform.Transformer is used to do
>> the transformation using streams. I developed the mediator using
>> the following logic,
>>
>>
>>- In the Binary Relay We get the Message as a Data Handler in a Dummy
>>SOAP Message. From that we can get a Input Stream for the SOAP message
>>which needs to be transformed using XSLT.
>>- We can Get the input Stream for the XSLT file, which is in registry
>>or local.
>>- Using those two we can do the XSLT transformation. As a result we
>>get a stream for the transformed SOAP message.
>>- Finally I create a DataHandler using the stream and attached it to
>>the Relay's Dummy SOAP message replacing existing one.
>>
>> The output of the mediator follows this logic is given below. I used the 
>> Sample
>> 8of
>>  ESB. I replaced the XSLT mediator with my custom mediator in the Binary
>> Relay.
>> But there is a major problem here. Because of the logic we used the
>> original SOAP message,
>>
>> http://schemas.xmlsoap.org/soap/envelope/";>http://www.w3.org/2005/08/addressing";>
>> http://localhost:9000/services/SimpleStockQuoteServiceurn:uuid:0f7403b4-c5bc-4347-8921-562f2736a2aburn:getQuote> xmlns:m0="http://services.samples
>> ">IBM
>>
>>  is now converted to.
>>
>> http://services.samples";>
>>
>>   IBM
>>
>> 
>>
>> At the end Binary Relay Formatter will read the DataHandler and above
>> SOAP message will be sent to the AXIS2 Server and It will crash, because
>> this is not a valid SOAP message.
>> This problem occurs because we are not using AXIOM anymore. In the normal
>> XSLT mediator it uses org.apache.synapse.util.xpath.SourceXPathSupport
>> class to find the part of the message which transformed using XSLT. So it
>> can replace the transformed part of the original message. But here we cant
>> use that kind of a logic. Because we use only streams. We cant build
>> OMElements or etc.
>>
>> Need help to solve this problem. The custom mediator java files are
>> attached here.
>>
>> Thanks
>> AndunSLG
>>
>> References :
>>
>> [1] -
>> http://wso2.org/project/esb/java/4.0.3/docs/samples/message_mediation_samples.html#Sample8
>>
>>
>> Console Output for the Custom Mediator :
>>
>> .Original SOAP Envelop..
>> http://www.w3.org/2003/05/soap-envelope";>> xmlns:ns="http://ws.apache.org/commons/ns/payload
>> ">PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0nVVRGLTgnPz48c29hcGVudjpFbnZlbG9wZSB4bWxuczpzb2FwZW52PSJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy9zb2FwL2VudmVsb3BlLyI+PHNvYXBlbnY6SGVhZGVyIHhtbG5zOndzYT0iaHR0cDovL3d3dy53My5vcmcvMjAwNS8wOC9hZGRyZXNzaW5nIj48d3NhOlRvPmh0dHA6Ly9sb2NhbGhvc3Q6OTAwMC9zZXJ2aWNlcy9TaW1wbGVTdG9ja1F1b3RlU2VydmljZTwvd3NhOlRvPjx3c2E6TWVzc2FnZUlEPnVybjp1dWlkOjBmNzQwM2I0LWM1YmMtNDM0Ny04OTIxLTU2MmYyNzM2YTJhYjwvd3NhOk1lc3NhZ2VJRD48d3NhOkFjdGlvbj51cm46Z2V0UXVvdGU8L3dzYTpBY3Rpb24+PC9zb2FwZW52OkhlYWRlcj48c29hcGVudjpCb2R5PjxtMDpDaGVja1ByaWNlUmVxdWVzdCB4bWxuczptMD0iaHR0cDovL3NlcnZpY2VzLnNhbXBsZXMiPjxtMDpDb2RlPklCTTwvbTA6Q29kZT48L20wOkNoZWNrUHJpY2VSZXF1ZXN0Pjwvc29hcGVudjpCb2R5Pjwvc29hcGVudjpFbnZlbG9wZT4=
>>
>> 
>>
>> .Original SOAP Message
>> http

Re: [Dev] Creating A Custom Mediator For XSLT Transfomation : Binary Relay Enabled ESB

[Hiranya Jayathilaka]

I don't know for sure whether this problem can be solved. But sometime back
I wrote a custom mediator to do XSLT transformations using the StAX support
available in the Java TrAX API. It showed a fairly good performance
improvement against the existing implementation too.

Solving the problem mentioned in this thread will be pretty hard. Perhaps
we can relax the conditions a bit. We can wrap the output of the
transformation in a SOAP envelope and put that back in the data handler. We
will use any information in the original SOAP headers, but that won't be an
issue for most practical scenarios.

Thanks,
Hiranya

On Sat, Sep 15, 2012 at 9:23 AM, Andun Sameera  wrote:

> Hi Amila,
>
> On Sat, Sep 15, 2012 at 9:22 PM, Amila Suriarachchi wrote:
>
>> Does xslt engine supports xml stream level transformations?
>
>
> Yes. But not 100% streams, but we can transform StreamSource object to
> a StreamResult using the Transformer.
>
>
>> After xslt transformations users may want to do further processing with
>> the message. So in that case we can avoid building request Axiom object but
>> may required to create the transformed Axiom object.
>>
>
> Yes your argument is correct, sometimes we have to create the result
> message. But I got in to trouble even before. In the present scenario, XSLT
> mediator  read some parameters from the request using AXIOM. It read
> weather transformation is happening to SOAP body or SOAP envelop etc. Based
> on those parameters after the transformation mediator reform the message.
> You can fine that logic in 
> [1]
> .
>
> But here I have no such parameters, I have only a input stream and
> I transform it using the XSLT file. After transformation I have no clue
> to reform the message. What I do is set the output stream to
> the data-handler in binary relay dummy message. So some parts of the
> original message get dropped and everything crashes here after.
>
>
>> thanks,
>> Amila.
>>
>>
>> On Sat, Sep 15, 2012 at 4:16 PM, Andun Sameera  wrote:
>>
>>> Hi All,
>>>
>>> My requirement is $Subject. Purpose of this is avoid using AXIOM to to
>>> XSLT transformation. Our plan was to do all the transformation using Input,
>>> Output Streams. javax.xml.transform.Transformer is used to do
>>> the transformation using streams. I developed the mediator using
>>> the following logic,
>>>
>>>
>>>- In the Binary Relay We get the Message as a Data Handler in a
>>>Dummy SOAP Message. From that we can get a Input Stream for the SOAP
>>>message which needs to be transformed using XSLT.
>>>- We can Get the input Stream for the XSLT file, which is in
>>>registry or local.
>>>- Using those two we can do the XSLT transformation. As a result we
>>>get a stream for the transformed SOAP message.
>>>- Finally I create a DataHandler using the stream and attached it to
>>>the Relay's Dummy SOAP message replacing existing one.
>>>
>>> The output of the mediator follows this logic is given below. I used the 
>>> Sample
>>> 8of
>>>  ESB. I replaced the XSLT mediator with my custom mediator in the Binary
>>> Relay.
>>> But there is a major problem here. Because of the logic we used the
>>> original SOAP message,
>>>
>>> http://schemas.xmlsoap.org/soap/envelope/";>http://www.w3.org/2005/08/addressing";>
>>> http://localhost:9000/services/SimpleStockQuoteServiceurn:uuid:0f7403b4-c5bc-4347-8921-562f2736a2aburn:getQuote>> xmlns:m0="http://services.samples
>>> ">IBM
>>>
>>>  is now converted to.
>>>
>>> http://services.samples";>
>>>
>>>   IBM
>>>
>>> 
>>>
>>> At the end Binary Relay Formatter will read the DataHandler and above
>>> SOAP message will be sent to the AXIS2 Server and It will crash, because
>>> this is not a valid SOAP message.
>>> This problem occurs because we are not using AXIOM anymore. In the
>>> normal XSLT mediator it
>>> uses org.apache.synapse.util.xpath.SourceXPathSupport class to find the
>>> part of the message which transformed using XSLT. So it can replace
>>> the transformed part of the original message. But here we cant use that
>>> kind of a logic. Because we use only streams. We cant build OMElements or
>>> etc.
>>>
>>> Need help to solve this problem. The custom mediator java files are
>>> attached here.
>>>
>>> Thanks
>>> AndunSLG
>>>
>>> References :
>>>
>>> [1] -
>>> http://wso2.org/project/esb/java/4.0.3/docs/samples/message_mediation_samples.html#Sample8
>>>
>>>
>>> Console Output for the Custom Mediator :
>>>
>>> .Original SOAP Envelop..
>>> http://www.w3.org/2003/05/soap-envelope";>>> xmlns:ns="http://ws.apache.org/commons/ns/payload
>>> ">PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0nVVRGLTgnPz48c29hcGVudjpFbnZlbG9wZS

Re: [Dev] Creating A Custom Mediator For XSLT Transfomation : Binary Relay Enabled ESB

[Hiranya Jayathilaka]

On Sat, Sep 15, 2012 at 5:19 PM, Hiranya Jayathilaka
wrote:

> I don't know for sure whether this problem can be solved. But sometime
> back I wrote a custom mediator to do XSLT transformations using the StAX
> support available in the Java TrAX API. It showed a fairly good performance
> improvement against the existing implementation too.
>
> Solving the problem mentioned in this thread will be pretty hard. Perhaps
> we can relax the conditions a bit. We can wrap the output of the
> transformation in a SOAP envelope and put that back in the data handler. We
> will use
>

s/use/loose/


> any information in the original SOAP headers, but that won't be an issue
> for most practical scenarios.
>
> Thanks,
> Hiranya
>
> On Sat, Sep 15, 2012 at 9:23 AM, Andun Sameera  wrote:
>
>> Hi Amila,
>>
>> On Sat, Sep 15, 2012 at 9:22 PM, Amila Suriarachchi wrote:
>>
>>> Does xslt engine supports xml stream level transformations?
>>
>>
>> Yes. But not 100% streams, but we can transform StreamSource object to
>> a StreamResult using the Transformer.
>>
>>
>>> After xslt transformations users may want to do further processing with
>>> the message. So in that case we can avoid building request Axiom object but
>>> may required to create the transformed Axiom object.
>>>
>>
>> Yes your argument is correct, sometimes we have to create the result
>> message. But I got in to trouble even before. In the present scenario, XSLT
>> mediator  read some parameters from the request using AXIOM. It read
>> weather transformation is happening to SOAP body or SOAP envelop etc. Based
>> on those parameters after the transformation mediator reform the message.
>> You can fine that logic in 
>> [1]
>> .
>>
>> But here I have no such parameters, I have only a input stream and
>> I transform it using the XSLT file. After transformation I have no clue
>> to reform the message. What I do is set the output stream to
>> the data-handler in binary relay dummy message. So some parts of the
>> original message get dropped and everything crashes here after.
>>
>>
>>> thanks,
>>> Amila.
>>>
>>>
>>> On Sat, Sep 15, 2012 at 4:16 PM, Andun Sameera  wrote:
>>>
 Hi All,

 My requirement is $Subject. Purpose of this is avoid using AXIOM to to
 XSLT transformation. Our plan was to do all the transformation using Input,
 Output Streams. javax.xml.transform.Transformer is used to do
 the transformation using streams. I developed the mediator using
 the following logic,


- In the Binary Relay We get the Message as a Data Handler in a
Dummy SOAP Message. From that we can get a Input Stream for the SOAP
message which needs to be transformed using XSLT.
- We can Get the input Stream for the XSLT file, which is in
registry or local.
- Using those two we can do the XSLT transformation. As a result we
get a stream for the transformed SOAP message.
- Finally I create a DataHandler using the stream and attached it
to the Relay's Dummy SOAP message replacing existing one.

 The output of the mediator follows this logic is given below. I used
 the Sample 
 8of
  ESB. I replaced the XSLT mediator with my custom mediator in the Binary
 Relay.
 But there is a major problem here. Because of the logic we used the
 original SOAP message,

 http://schemas.xmlsoap.org/soap/envelope/";>http://www.w3.org/2005/08/addressing";>
 http://localhost:9000/services/SimpleStockQuoteServiceurn:uuid:0f7403b4-c5bc-4347-8921-562f2736a2aburn:getQuote>>> xmlns:m0="http://services.samples
 ">IBM

  is now converted to.

 http://services.samples";>

   IBM

 

 At the end Binary Relay Formatter will read the DataHandler and above
 SOAP message will be sent to the AXIS2 Server and It will crash, because
 this is not a valid SOAP message.
 This problem occurs because we are not using AXIOM anymore. In the
 normal XSLT mediator it
 uses org.apache.synapse.util.xpath.SourceXPathSupport class to find the
 part of the message which transformed using XSLT. So it can replace
 the transformed part of the original message. But here we cant use that
 kind of a logic. Because we use only streams. We cant build OMElements or
 etc.

 Need help to solve this problem. The custom mediator java files are
 attached here.

 Thanks
 AndunSLG

 References :

 [1] -
 http://wso2.org/project/esb/java/4.0.3/docs/samples/message_mediation_samples.html#Sample8


 Console Output for the Custom Mediator :

 .Original SOAP 

Re: [Dev] Creating A Custom Mediator For XSLT Transfomation : Binary Relay Enabled ESB

[Amila Suriarachchi]

On Sun, Sep 16, 2012 at 5:49 AM, Hiranya Jayathilaka
wrote:

> I don't know for sure whether this problem can be solved. But sometime
> back I wrote a custom mediator to do XSLT transformations using the StAX
> support available in the Java TrAX API. It showed a fairly good performance
> improvement against the existing implementation too.


if there is a Transformer with xml stream API, I think this is the way to
proceed. At the synapse level we can not deal with the row streams. We can
get the underline xml stream from the soap envelop and use that as an input
the to transfromer. Then we can implement an xmlstream writter which builds
an OM element for further processing.

So I think it is better to look at the Hiranyas code and improve from there.

thanks,
Amila.


>
> Solving the problem mentioned in this thread will be pretty hard. Perhaps
> we can relax the conditions a bit. We can wrap the output of the
> transformation in a SOAP envelope and put that back in the data handler. We
> will use any information in the original SOAP headers, but that won't be an
> issue for most practical scenarios.
>
> Thanks,
> Hiranya
>
> On Sat, Sep 15, 2012 at 9:23 AM, Andun Sameera  wrote:
>
>> Hi Amila,
>>
>> On Sat, Sep 15, 2012 at 9:22 PM, Amila Suriarachchi wrote:
>>
>>> Does xslt engine supports xml stream level transformations?
>>
>>
>> Yes. But not 100% streams, but we can transform StreamSource object to
>> a StreamResult using the Transformer.
>>
>>
>>> After xslt transformations users may want to do further processing with
>>> the message. So in that case we can avoid building request Axiom object but
>>> may required to create the transformed Axiom object.
>>>
>>
>> Yes your argument is correct, sometimes we have to create the result
>> message. But I got in to trouble even before. In the present scenario, XSLT
>> mediator  read some parameters from the request using AXIOM. It read
>> weather transformation is happening to SOAP body or SOAP envelop etc. Based
>> on those parameters after the transformation mediator reform the message.
>> You can fine that logic in 
>> [1]
>> .
>>
>> But here I have no such parameters, I have only a input stream and
>> I transform it using the XSLT file. After transformation I have no clue
>> to reform the message. What I do is set the output stream to
>> the data-handler in binary relay dummy message. So some parts of the
>> original message get dropped and everything crashes here after.
>>
>>
>>> thanks,
>>> Amila.
>>>
>>>
>>> On Sat, Sep 15, 2012 at 4:16 PM, Andun Sameera  wrote:
>>>
 Hi All,

 My requirement is $Subject. Purpose of this is avoid using AXIOM to to
 XSLT transformation. Our plan was to do all the transformation using Input,
 Output Streams. javax.xml.transform.Transformer is used to do
 the transformation using streams. I developed the mediator using
 the following logic,


- In the Binary Relay We get the Message as a Data Handler in a
Dummy SOAP Message. From that we can get a Input Stream for the SOAP
message which needs to be transformed using XSLT.
- We can Get the input Stream for the XSLT file, which is in
registry or local.
- Using those two we can do the XSLT transformation. As a result we
get a stream for the transformed SOAP message.
- Finally I create a DataHandler using the stream and attached it
to the Relay's Dummy SOAP message replacing existing one.

 The output of the mediator follows this logic is given below. I used
 the Sample 
 8of
  ESB. I replaced the XSLT mediator with my custom mediator in the Binary
 Relay.
 But there is a major problem here. Because of the logic we used the
 original SOAP message,

 http://schemas.xmlsoap.org/soap/envelope/";>http://www.w3.org/2005/08/addressing";>
 http://localhost:9000/services/SimpleStockQuoteServiceurn:uuid:0f7403b4-c5bc-4347-8921-562f2736a2aburn:getQuote>>> xmlns:m0="http://services.samples
 ">IBM

  is now converted to.

 http://services.samples";>

   IBM

 

 At the end Binary Relay Formatter will read the DataHandler and above
 SOAP message will be sent to the AXIS2 Server and It will crash, because
 this is not a valid SOAP message.
 This problem occurs because we are not using AXIOM anymore. In the
 normal XSLT mediator it
 uses org.apache.synapse.util.xpath.SourceXPathSupport class to find the
 part of the message which transformed using XSLT. So it can replace
 the transformed part of the original message. But here we cant use that
 kind of a logic. Because we use 

Re: [Dev] Creating A Custom Mediator For XSLT Transfomation : Binary Relay Enabled ESB

[Andun Sameera]

On Sun, Sep 16, 2012 at 5:50 AM, Hiranya Jayathilaka
wrote:

>
>
> On Sat, Sep 15, 2012 at 5:19 PM, Hiranya Jayathilaka  > wrote:
>
>> I don't know for sure whether this problem can be solved. But sometime
>> back I wrote a custom mediator to do XSLT transformations using the StAX
>> support available in the Java TrAX API. It showed a fairly good performance
>> improvement against the existing implementation too.
>>
>> Solving the problem mentioned in this thread will be pretty hard. Perhaps
>> we can relax the conditions a bit. We can wrap the output of the
>> transformation in a SOAP envelope and put that back in the data handler. We
>> will use
>>
>
> s/use/loose/
>
>
>> any information in the original SOAP headers, but that won't be an issue
>> for most practical scenarios.
>>
>
Hi Hiranya,

Your argument is correct Hirnaya. But I am also blocked while doing "wrap
the output of the transformation in a SOAP envelope", because I don't know
which part of the message is transformed. I blindly pass the input
stream to transformer, because of the requirement of avoid opening the
input stream using AXIOM. So without knowing which part of the message
is transformed and given back, how can I find the place to replace in the
newly created SOAP envelop. Sometimes it can be Envelop,Body, element etc.
So any solution ?

Thanks
AndunSLG


>> Thanks,
>> Hiranya
>>
>> On Sat, Sep 15, 2012 at 9:23 AM, Andun Sameera  wrote:
>>
>>> Hi Amila,
>>>
>>> On Sat, Sep 15, 2012 at 9:22 PM, Amila Suriarachchi wrote:
>>>
 Does xslt engine supports xml stream level transformations?
>>>
>>>
>>> Yes. But not 100% streams, but we can transform StreamSource object to
>>> a StreamResult using the Transformer.
>>>
>>>
 After xslt transformations users may want to do further processing with
 the message. So in that case we can avoid building request Axiom object but
 may required to create the transformed Axiom object.

>>>
>>> Yes your argument is correct, sometimes we have to create the result
>>> message. But I got in to trouble even before. In the present scenario, XSLT
>>> mediator  read some parameters from the request using AXIOM. It read
>>> weather transformation is happening to SOAP body or SOAP envelop etc. Based
>>> on those parameters after the transformation mediator reform the message.
>>> You can fine that logic in 
>>> [1]
>>> .
>>>
>>> But here I have no such parameters, I have only a input stream and
>>> I transform it using the XSLT file. After transformation I have no clue
>>> to reform the message. What I do is set the output stream to
>>> the data-handler in binary relay dummy message. So some parts of the
>>> original message get dropped and everything crashes here after.
>>>
>>>
 thanks,
 Amila.


 On Sat, Sep 15, 2012 at 4:16 PM, Andun Sameera  wrote:

> Hi All,
>
> My requirement is $Subject. Purpose of this is avoid using AXIOM to to
> XSLT transformation. Our plan was to do all the transformation using 
> Input,
> Output Streams. javax.xml.transform.Transformer is used to do
> the transformation using streams. I developed the mediator using
> the following logic,
>
>
>- In the Binary Relay We get the Message as a Data Handler in a
>Dummy SOAP Message. From that we can get a Input Stream for the SOAP
>message which needs to be transformed using XSLT.
>- We can Get the input Stream for the XSLT file, which is in
>registry or local.
>- Using those two we can do the XSLT transformation. As a result
>we get a stream for the transformed SOAP message.
>- Finally I create a DataHandler using the stream and attached it
>to the Relay's Dummy SOAP message replacing existing one.
>
> The output of the mediator follows this logic is given below. I used
> the Sample 
> 8of
>  ESB. I replaced the XSLT mediator with my custom mediator in the Binary
> Relay.
> But there is a major problem here. Because of the logic we used the
> original SOAP message,
>
> http://schemas.xmlsoap.org/soap/envelope/";>http://www.w3.org/2005/08/addressing";>
> http://localhost:9000/services/SimpleStockQuoteServiceurn:uuid:0f7403b4-c5bc-4347-8921-562f2736a2aburn:getQuote xmlns:m0="http://services.samples
> ">IBM
>
>  is now converted to.
>
> http://services.samples";>
>
>   IBM
>
> 
>
> At the end Binary Relay Formatter will read the DataHandler and above
> SOAP message will be sent to the AXIS2 Server and It will crash, because
> this is not a valid SOAP message.
> This problem occurs because we are 

Re: [Dev] Creating A Custom Mediator For XSLT Transfomation : Binary Relay Enabled ESB

[Sanjiva Weerawarana]

IIRC the old xslt mediator had a "source" parameter to indicate what should
be sent in. Without that, its correct that we send in the entire message -
if its SOAP its the whole envelope etc.. If the transform should produce a
SOAP message that's up to the person to generate it.

So IMO we should call this new high perf XSLT mediator a "raw xslt"
mediator or something like that and make clear what the responsibility of
the person writing the transform is.

We could also (later) write an extension that supports a few source
parameters - e.g. "body" and then do some byte level parsing (a very basic
xml parser) that strips out the other stuff and passes the body thru.

IMO we don't need that - we have a high perf one that requires you to
process the whole message and we have the current one which gives you a lot
more flexibility at a performance tradeoff.

So in other words, lets finish this and ship it!

Sanjiva.

On Sun, Sep 16, 2012 at 10:35 AM, Andun Sameera  wrote:

>
>
> On Sun, Sep 16, 2012 at 5:50 AM, Hiranya Jayathilaka  > wrote:
>
>>
>>
>> On Sat, Sep 15, 2012 at 5:19 PM, Hiranya Jayathilaka <
>> hiranya...@gmail.com> wrote:
>>
>>> I don't know for sure whether this problem can be solved. But sometime
>>> back I wrote a custom mediator to do XSLT transformations using the StAX
>>> support available in the Java TrAX API. It showed a fairly good performance
>>> improvement against the existing implementation too.
>>>
>>> Solving the problem mentioned in this thread will be pretty hard.
>>> Perhaps we can relax the conditions a bit. We can wrap the output of the
>>> transformation in a SOAP envelope and put that back in the data handler. We
>>> will use
>>>
>>
>> s/use/loose/
>>
>>
>>> any information in the original SOAP headers, but that won't be an issue
>>> for most practical scenarios.
>>>
>>
> Hi Hiranya,
>
> Your argument is correct Hirnaya. But I am also blocked while doing "wrap
> the output of the transformation in a SOAP envelope", because I don't know
> which part of the message is transformed. I blindly pass the input
> stream to transformer, because of the requirement of avoid opening the
> input stream using AXIOM. So without knowing which part of the message
> is transformed and given back, how can I find the place to replace in the
> newly created SOAP envelop. Sometimes it can be Envelop,Body, element etc.
> So any solution ?
>
> Thanks
> AndunSLG
>
>
>>> Thanks,
>>> Hiranya
>>>
>>> On Sat, Sep 15, 2012 at 9:23 AM, Andun Sameera  wrote:
>>>
 Hi Amila,

 On Sat, Sep 15, 2012 at 9:22 PM, Amila Suriarachchi wrote:

> Does xslt engine supports xml stream level transformations?


 Yes. But not 100% streams, but we can transform StreamSource object to
 a StreamResult using the Transformer.


> After xslt transformations users may want to do further processing
> with the message. So in that case we can avoid building request Axiom
> object but may required to create the transformed Axiom object.
>

 Yes your argument is correct, sometimes we have to create the result
 message. But I got in to trouble even before. In the present scenario, XSLT
 mediator  read some parameters from the request using AXIOM. It read
 weather transformation is happening to SOAP body or SOAP envelop etc. Based
 on those parameters after the transformation mediator reform the message.
 You can fine that logic in 
 [1]
 .

 But here I have no such parameters, I have only a input stream and
 I transform it using the XSLT file. After transformation I have no clue
 to reform the message. What I do is set the output stream to
 the data-handler in binary relay dummy message. So some parts of the
 original message get dropped and everything crashes here after.


> thanks,
> Amila.
>
>
> On Sat, Sep 15, 2012 at 4:16 PM, Andun Sameera  wrote:
>
>> Hi All,
>>
>> My requirement is $Subject. Purpose of this is avoid using AXIOM to
>> to XSLT transformation. Our plan was to do all the transformation using
>> Input, Output Streams. javax.xml.transform.Transformer is used to do
>> the transformation using streams. I developed the mediator using
>> the following logic,
>>
>>
>>- In the Binary Relay We get the Message as a Data Handler in a
>>Dummy SOAP Message. From that we can get a Input Stream for the SOAP
>>message which needs to be transformed using XSLT.
>>- We can Get the input Stream for the XSLT file, which is in
>>registry or local.
>>- Using those two we can do the XSLT transformation. As a result
>>we get a stream for the transformed SOAP message.
>>- Finally I create a DataHandler u

Re: [Dev] Creating A Custom Mediator For XSLT Transfomation : Binary Relay Enabled ESB

[Andun Sameera]

Hi,

+1 For the idea about the trade-off between Performance and Flexibility.
This will solve the problem I think. Because here I used a XSLT which
will transform and give a element of the message. So If we give the
responsibility to the person who write the transformation to preserve the
SOAP message, It will solve all the issues.
Also will try to find a way to  write a extension which will give some more
flexibility to user.

Thanks
AndunSLG

On Sun, Sep 16, 2012 at 12:45 PM, Sanjiva Weerawarana wrote:

> IIRC the old xslt mediator had a "source" parameter to indicate what
> should be sent in. Without that, its correct that we send in the entire
> message - if its SOAP its the whole envelope etc.. If the transform should
> produce a SOAP message that's up to the person to generate it.
>
> So IMO we should call this new high perf XSLT mediator a "raw xslt"
> mediator or something like that and make clear what the responsibility of
> the person writing the transform is.
>
> We could also (later) write an extension that supports a few source
> parameters - e.g. "body" and then do some byte level parsing (a very basic
> xml parser) that strips out the other stuff and passes the body thru.
>
> IMO we don't need that - we have a high perf one that requires you to
> process the whole message and we have the current one which gives you a lot
> more flexibility at a performance tradeoff.
>
> So in other words, lets finish this and ship it!
>
> Sanjiva.
>
> On Sun, Sep 16, 2012 at 10:35 AM, Andun Sameera  wrote:
>
>>
>>
>> On Sun, Sep 16, 2012 at 5:50 AM, Hiranya Jayathilaka <
>> hiranya...@gmail.com> wrote:
>>
>>>
>>>
>>> On Sat, Sep 15, 2012 at 5:19 PM, Hiranya Jayathilaka <
>>> hiranya...@gmail.com> wrote:
>>>
 I don't know for sure whether this problem can be solved. But sometime
 back I wrote a custom mediator to do XSLT transformations using the StAX
 support available in the Java TrAX API. It showed a fairly good performance
 improvement against the existing implementation too.

 Solving the problem mentioned in this thread will be pretty hard.
 Perhaps we can relax the conditions a bit. We can wrap the output of the
 transformation in a SOAP envelope and put that back in the data handler. We
 will use

>>>
>>> s/use/loose/
>>>
>>>
 any information in the original SOAP headers, but that won't be an
 issue for most practical scenarios.

>>>
>> Hi Hiranya,
>>
>> Your argument is correct Hirnaya. But I am also blocked while doing "wrap
>> the output of the transformation in a SOAP envelope", because I don't know
>> which part of the message is transformed. I blindly pass the input
>> stream to transformer, because of the requirement of avoid opening the
>> input stream using AXIOM. So without knowing which part of the message
>> is transformed and given back, how can I find the place to replace in the
>> newly created SOAP envelop. Sometimes it can be Envelop,Body, element etc.
>> So any solution ?
>>
>> Thanks
>> AndunSLG
>>
>>
 Thanks,
 Hiranya

 On Sat, Sep 15, 2012 at 9:23 AM, Andun Sameera  wrote:

> Hi Amila,
>
> On Sat, Sep 15, 2012 at 9:22 PM, Amila Suriarachchi wrote:
>
>> Does xslt engine supports xml stream level transformations?
>
>
> Yes. But not 100% streams, but we can transform StreamSource object to
> a StreamResult using the Transformer.
>
>
>> After xslt transformations users may want to do further processing
>> with the message. So in that case we can avoid building request Axiom
>> object but may required to create the transformed Axiom object.
>>
>
> Yes your argument is correct, sometimes we have to create the result
> message. But I got in to trouble even before. In the present scenario, 
> XSLT
> mediator  read some parameters from the request using AXIOM. It read
> weather transformation is happening to SOAP body or SOAP envelop etc. 
> Based
> on those parameters after the transformation mediator reform the message.
> You can fine that logic in 
> [1]
> .
>
> But here I have no such parameters, I have only a input stream and
> I transform it using the XSLT file. After transformation I have no clue
> to reform the message. What I do is set the output stream to
> the data-handler in binary relay dummy message. So some parts of the
> original message get dropped and everything crashes here after.
>
>
>> thanks,
>> Amila.
>>
>>
>> On Sat, Sep 15, 2012 at 4:16 PM, Andun Sameera wrote:
>>
>>> Hi All,
>>>
>>> My requirement is $Subject. Purpose of this is avoid using AXIOM to
>>> to XSLT transformation. Our plan was to do all the transformation using
>>

Re: [Dev] Creating A Custom Mediator For XSLT Transfomation : Binary Relay Enabled ESB

[Paul Fremantle]

Also presumably this approach would work very simply if someone didn't use
SOAP but simply wanted to transform Plain Ole XML.

Paul

On 16 September 2012 09:37, Andun Sameera  wrote:

> Hi,
>
> +1 For the idea about the trade-off between Performance and Flexibility.
> This will solve the problem I think. Because here I used a XSLT which
> will transform and give a element of the message. So If we give the
> responsibility to the person who write the transformation to preserve the
> SOAP message, It will solve all the issues.
> Also will try to find a way to  write a extension which will give some
> more flexibility to user.
>
> Thanks
> AndunSLG
>
>
> On Sun, Sep 16, 2012 at 12:45 PM, Sanjiva Weerawarana wrote:
>
>> IIRC the old xslt mediator had a "source" parameter to indicate what
>> should be sent in. Without that, its correct that we send in the entire
>> message - if its SOAP its the whole envelope etc.. If the transform should
>> produce a SOAP message that's up to the person to generate it.
>>
>> So IMO we should call this new high perf XSLT mediator a "raw xslt"
>> mediator or something like that and make clear what the responsibility of
>> the person writing the transform is.
>>
>> We could also (later) write an extension that supports a few source
>> parameters - e.g. "body" and then do some byte level parsing (a very basic
>> xml parser) that strips out the other stuff and passes the body thru.
>>
>> IMO we don't need that - we have a high perf one that requires you to
>> process the whole message and we have the current one which gives you a lot
>> more flexibility at a performance tradeoff.
>>
>> So in other words, lets finish this and ship it!
>>
>> Sanjiva.
>>
>> On Sun, Sep 16, 2012 at 10:35 AM, Andun Sameera  wrote:
>>
>>>
>>>
>>> On Sun, Sep 16, 2012 at 5:50 AM, Hiranya Jayathilaka <
>>> hiranya...@gmail.com> wrote:
>>>


 On Sat, Sep 15, 2012 at 5:19 PM, Hiranya Jayathilaka <
 hiranya...@gmail.com> wrote:

> I don't know for sure whether this problem can be solved. But sometime
> back I wrote a custom mediator to do XSLT transformations using the StAX
> support available in the Java TrAX API. It showed a fairly good 
> performance
> improvement against the existing implementation too.
>
> Solving the problem mentioned in this thread will be pretty hard.
> Perhaps we can relax the conditions a bit. We can wrap the output of the
> transformation in a SOAP envelope and put that back in the data handler. 
> We
> will use
>

 s/use/loose/


> any information in the original SOAP headers, but that won't be an
> issue for most practical scenarios.
>

>>> Hi Hiranya,
>>>
>>> Your argument is correct Hirnaya. But I am also blocked while doing
>>> "wrap the output of the transformation in a SOAP envelope", because
>>> I don't know which part of the message is transformed. I blindly pass
>>> the input stream to transformer, because of the requirement of avoid
>>> opening the input stream using AXIOM. So without knowing which part of the
>>> message is transformed and given back, how can I find the place to replace
>>> in the newly created SOAP envelop. Sometimes it can be Envelop,Body,
>>> element etc.
>>> So any solution ?
>>>
>>> Thanks
>>> AndunSLG
>>>
>>>
> Thanks,
> Hiranya
>
> On Sat, Sep 15, 2012 at 9:23 AM, Andun Sameera  wrote:
>
>> Hi Amila,
>>
>> On Sat, Sep 15, 2012 at 9:22 PM, Amila Suriarachchi 
>> wrote:
>>
>>> Does xslt engine supports xml stream level transformations?
>>
>>
>> Yes. But not 100% streams, but we can transform StreamSource object
>> to a StreamResult using the Transformer.
>>
>>
>>> After xslt transformations users may want to do further processing
>>> with the message. So in that case we can avoid building request Axiom
>>> object but may required to create the transformed Axiom object.
>>>
>>
>> Yes your argument is correct, sometimes we have to create the result
>> message. But I got in to trouble even before. In the present scenario, 
>> XSLT
>> mediator  read some parameters from the request using AXIOM. It read
>> weather transformation is happening to SOAP body or SOAP envelop etc. 
>> Based
>> on those parameters after the transformation mediator reform the message.
>> You can fine that logic in 
>> [1]
>> .
>>
>> But here I have no such parameters, I have only a input stream and
>> I transform it using the XSLT file. After transformation I have no clue
>> to reform the message. What I do is set the output stream to
>> the data-handler in binary relay dummy message. So some parts of the
>> original message get dropped and

Re: [Dev] Creating A Custom Mediator For XSLT Transfomation : Binary Relay Enabled ESB

[Andun Sameera]

Hi All,

I have developed the custom mediator AKA RawXSLTMediator to transform
streams in binary relay mood. Samisa suggested some further improvements
after looking at the code and currently I am working on those. With the
existing implementation I did some test with ESB. The results of those
tests are given below. For large message sizes, it has
improved nearly twice.

8k Message Raw XSLT Mediator Normal XSLT Mediator

Request Per Second Time Taken Request Per Second Time Taken

n=100, c=1 55.97 1.786816 55.89 1.789259
n=100, c=5 295.55 1.691735 158.39 3.156814
n=100, c=10 298.41 3.351045 162.28 6.162070
n=100, c=20 177.38 11.275533 168.38 11.877941
n=100, c=40 226.15 17.687198 170.03 23.524984
n=100, c=80 187.01 42.778756 165.54 48.325473
n=100, c=160 168.49 94.962065 165.00 96.969543
n=100, c=320 169.63 188.643735 164.23 194.848353
n=100, c=640 165.60 386.484129 122.07 524.308358

100k Message  Raw XSLT Mediator Normal XSLT Mediator

Reuest Per Second Time Taken Request Per Second Time Taken
n=100, c=1 49.85 2.005901 12.48 8.012235
n=100, c=5 233.87 2.137914 105.34 4.746719
n=100, c=10 297.86 3.357259 135.02 7.406090
n=100, c=20 294.79 6.784513 159.66 12.526382
n=100, c=40 263.21 15.196750 177.38 22.550458
n=100, c=80 228.47 35.015699 154.64 51.731678
n=100, c=160 230.33 69.465916 132.66 120.606647
n=100, c=320 232.24 137.787760 119.52 267.728523
n=100, c=640 243.97 262.322362 122.07 524.308358

Thanks
AndunSLG

On Sun, Sep 16, 2012 at 3:13 PM, Paul Fremantle  wrote:

> Also presumably this approach would work very simply if someone didn't use
> SOAP but simply wanted to transform Plain Ole XML.
>
> Paul
>
> On 16 September 2012 09:37, Andun Sameera  wrote:
>
>> Hi,
>>
>> +1 For the idea about the trade-off between Performance and Flexibility.
>> This will solve the problem I think. Because here I used a XSLT which
>> will transform and give a element of the message. So If we give the
>> responsibility to the person who write the transformation to preserve the
>> SOAP message, It will solve all the issues.
>> Also will try to find a way to  write a extension which will give some
>> more flexibility to user.
>>
>> Thanks
>> AndunSLG
>>
>>
>> On Sun, Sep 16, 2012 at 12:45 PM, Sanjiva Weerawarana 
>> wrote:
>>
>>> IIRC the old xslt mediator had a "source" parameter to indicate what
>>> should be sent in. Without that, its correct that we send in the entire
>>> message - if its SOAP its the whole envelope etc.. If the transform should
>>> produce a SOAP message that's up to the person to generate it.
>>>
>>> So IMO we should call this new high perf XSLT mediator a "raw xslt"
>>> mediator or something like that and make clear what the responsibility of
>>> the person writing the transform is.
>>>
>>> We could also (later) write an extension that supports a few source
>>> parameters - e.g. "body" and then do some byte level parsing (a very basic
>>> xml parser) that strips out the other stuff and passes the body thru.
>>>
>>> IMO we don't need that - we have a high perf one that requires you to
>>> process the whole message and we have the current one which gives you a lot
>>> more flexibility at a performance tradeoff.
>>>
>>> So in other words, lets finish this and ship it!
>>>
>>> Sanjiva.
>>>
>>> On Sun, Sep 16, 2012 at 10:35 AM, Andun Sameera  wrote:
>>>


 On Sun, Sep 16, 2012 at 5:50 AM, Hiranya Jayathilaka <
 hiranya...@gmail.com> wrote:

>
>
> On Sat, Sep 15, 2012 at 5:19 PM, Hiranya Jayathilaka <
> hiranya...@gmail.com> wrote:
>
>> I don't know for sure whether this problem can be solved. But
>> sometime back I wrote a custom mediator to do XSLT transformations using
>> the StAX support available in the Java TrAX API. It showed a fairly good
>> performance improvement against the existing implementation too.
>>
>> Solving the problem mentioned in this thread will be pretty hard.
>> Perhaps we can relax the conditions a bit. We can wrap the output of the
>> transformation in a SOAP envelope and put that back in the data handler. 
>> We
>> will use
>>
>
> s/use/loose/
>
>
>> any information in the original SOAP headers, but that won't be an
>> issue for most practical scenarios.
>>
>
 Hi Hiranya,

 Your argument is correct Hirnaya. But I am also blocked while doing
 "wrap the output of the transformation in a SOAP envelope", because
 I don't know which part of the message is transformed. I blindly pass
 the input stream to transformer, because of the requirement of avoid
 opening the input stream using AXIOM. So without knowing which part of the
 message is transformed and given back, how can I find the place to replace
 in the newly created SOAP envelop. Sometimes it can be Envelop,Body,
 element etc.
 So any solution ?

 Thanks
 AndunSLG


>> Thanks,
>> Hiranya
>>
>> On Sat,

Re: [Dev] Creating A Custom Mediator For XSLT Transfomation : Binary Relay Enabled ESB

[Amila Suriarachchi]

On Mon, Sep 17, 2012 at 6:11 PM, Andun Sameera  wrote:

> Hi All,
>
> I have developed the custom mediator AKA RawXSLTMediator to transform
> streams in binary relay mood. Samisa suggested some further improvements
> after looking at the code and currently I am working on those. With the
> existing implementation I did some test with ESB. The results of those
> tests are given below. For large message sizes, it has
> improved nearly twice.
>

great.

BTW did you warm up the server before taking the readings. For lower
concurrencies you are not sending enough messages. Better to vary both
concurrency and messags so that total would be around 50,000.

thanks,
Amila.

>
> 8k Message Raw XSLT Mediator Normal XSLT Mediator
>
> Request Per Second Time Taken Request Per Second Time Taken
>
> n=100, c=1 55.97 1.786816 55.89 1.789259
> n=100, c=5 295.55 1.691735 158.39 3.156814
> n=100, c=10 298.41 3.351045 162.28 6.162070
> n=100, c=20 177.38 11.275533 168.38 11.877941
> n=100, c=40 226.15 17.687198 170.03 23.524984
> n=100, c=80 187.01 42.778756 165.54 48.325473
> n=100, c=160 168.49 94.962065 165.00 96.969543
> n=100, c=320 169.63 188.643735 164.23 194.848353
> n=100, c=640 165.60 386.484129 122.07 524.308358
>
> 100k Message  Raw XSLT Mediator Normal XSLT Mediator
>
>  Reuest Per Second Time Taken Request Per Second Time Taken
> n=100, c=1 49.85 2.005901 12.48 8.012235
> n=100, c=5 233.87 2.137914 105.34 4.746719
> n=100, c=10 297.86 3.357259 135.02 7.406090
> n=100, c=20 294.79 6.784513 159.66 12.526382
> n=100, c=40 263.21 15.196750 177.38 22.550458
> n=100, c=80 228.47 35.015699 154.64 51.731678
> n=100, c=160 230.33 69.465916 132.66 120.606647
> n=100, c=320 232.24 137.787760 119.52 267.728523
> n=100, c=640 243.97 262.322362 122.07 524.308358
>
> Thanks
> AndunSLG
>
> On Sun, Sep 16, 2012 at 3:13 PM, Paul Fremantle  wrote:
>
>> Also presumably this approach would work very simply if someone didn't
>> use SOAP but simply wanted to transform Plain Ole XML.
>>
>> Paul
>>
>> On 16 September 2012 09:37, Andun Sameera  wrote:
>>
>>> Hi,
>>>
>>> +1 For the idea about the trade-off between Performance and Flexibility.
>>> This will solve the problem I think. Because here I used a XSLT which
>>> will transform and give a element of the message. So If we give the
>>> responsibility to the person who write the transformation to preserve the
>>> SOAP message, It will solve all the issues.
>>> Also will try to find a way to  write a extension which will give some
>>> more flexibility to user.
>>>
>>> Thanks
>>> AndunSLG
>>>
>>>
>>> On Sun, Sep 16, 2012 at 12:45 PM, Sanjiva Weerawarana 
>>> wrote:
>>>
 IIRC the old xslt mediator had a "source" parameter to indicate what
 should be sent in. Without that, its correct that we send in the entire
 message - if its SOAP its the whole envelope etc.. If the transform should
 produce a SOAP message that's up to the person to generate it.

 So IMO we should call this new high perf XSLT mediator a "raw xslt"
 mediator or something like that and make clear what the responsibility of
 the person writing the transform is.

 We could also (later) write an extension that supports a few source
 parameters - e.g. "body" and then do some byte level parsing (a very basic
 xml parser) that strips out the other stuff and passes the body thru.

 IMO we don't need that - we have a high perf one that requires you to
 process the whole message and we have the current one which gives you a lot
 more flexibility at a performance tradeoff.

 So in other words, lets finish this and ship it!

 Sanjiva.

 On Sun, Sep 16, 2012 at 10:35 AM, Andun Sameera  wrote:

>
>
> On Sun, Sep 16, 2012 at 5:50 AM, Hiranya Jayathilaka <
> hiranya...@gmail.com> wrote:
>
>>
>>
>> On Sat, Sep 15, 2012 at 5:19 PM, Hiranya Jayathilaka <
>> hiranya...@gmail.com> wrote:
>>
>>> I don't know for sure whether this problem can be solved. But
>>> sometime back I wrote a custom mediator to do XSLT transformations using
>>> the StAX support available in the Java TrAX API. It showed a fairly good
>>> performance improvement against the existing implementation too.
>>>
>>> Solving the problem mentioned in this thread will be pretty hard.
>>> Perhaps we can relax the conditions a bit. We can wrap the output of the
>>> transformation in a SOAP envelope and put that back in the data 
>>> handler. We
>>> will use
>>>
>>
>> s/use/loose/
>>
>>
>>> any information in the original SOAP headers, but that won't be an
>>> issue for most practical scenarios.
>>>
>>
> Hi Hiranya,
>
> Your argument is correct Hirnaya. But I am also blocked while doing
> "wrap the output of the transformation in a SOAP envelope", because
> I don't know which part of the message is transformed. I blindly pass

Re: [Dev] Creating A Custom Mediator For XSLT Transfomation : Binary Relay Enabled ESB

[Andun Sameera]

Hi Amila,

Agree with you, I did with this way because I ran all these in my PC for
have an abstract idea. No perf testing environment was setup. But will do
a exact test with the XPATH optimization changes.

Thanks
AndunSLG


On Mon, Sep 17, 2012 at 6:38 PM, Amila Suriarachchi  wrote:

>
>
> On Mon, Sep 17, 2012 at 6:11 PM, Andun Sameera  wrote:
>
>> Hi All,
>>
>> I have developed the custom mediator AKA RawXSLTMediator to transform
>> streams in binary relay mood. Samisa suggested some further improvements
>> after looking at the code and currently I am working on those. With the
>> existing implementation I did some test with ESB. The results of those
>> tests are given below. For large message sizes, it has
>> improved nearly twice.
>>
>
> great.
>
> BTW did you warm up the server before taking the readings. For lower
> concurrencies you are not sending enough messages. Better to vary both
> concurrency and messags so that total would be around 50,000.
>
> thanks,
> Amila.
>
>>
>> 8k Message Raw XSLT Mediator Normal XSLT Mediator
>>
>> Request Per Second Time Taken Request Per Second Time Taken
>>
>> n=100, c=1 55.97 1.786816 55.89 1.789259
>> n=100, c=5 295.55 1.691735 158.39 3.156814
>> n=100, c=10 298.41 3.351045 162.28 6.162070
>> n=100, c=20 177.38 11.275533 168.38 11.877941
>> n=100, c=40 226.15 17.687198 170.03 23.524984
>> n=100, c=80 187.01 42.778756 165.54 48.325473
>> n=100, c=160 168.49 94.962065 165.00 96.969543
>> n=100, c=320 169.63 188.643735 164.23 194.848353
>> n=100, c=640 165.60 386.484129 122.07 524.308358
>>
>> 100k Message  Raw XSLT Mediator Normal XSLT Mediator
>>
>>  Reuest Per Second Time Taken Request Per Second Time Taken
>> n=100, c=1 49.85 2.005901 12.48 8.012235
>> n=100, c=5 233.87 2.137914 105.34 4.746719
>> n=100, c=10 297.86 3.357259 135.02 7.406090
>> n=100, c=20 294.79 6.784513 159.66 12.526382
>> n=100, c=40 263.21 15.196750 177.38 22.550458
>> n=100, c=80 228.47 35.015699 154.64 51.731678
>> n=100, c=160 230.33 69.465916 132.66 120.606647
>> n=100, c=320 232.24 137.787760 119.52 267.728523
>> n=100, c=640 243.97 262.322362 122.07 524.308358
>>
>> Thanks
>> AndunSLG
>>
>> On Sun, Sep 16, 2012 at 3:13 PM, Paul Fremantle  wrote:
>>
>>> Also presumably this approach would work very simply if someone didn't
>>> use SOAP but simply wanted to transform Plain Ole XML.
>>>
>>> Paul
>>>
>>> On 16 September 2012 09:37, Andun Sameera  wrote:
>>>
 Hi,

 +1 For the idea about
 the trade-off between Performance and Flexibility. This will solve
 the problem I think. Because here I used a XSLT which will transform and
 give a element of the message. So If we give the responsibility to the
 person who write the transformation to preserve the SOAP message, It will
 solve all the issues.
 Also will try to find a way to  write a extension which will give some
 more flexibility to user.

 Thanks
 AndunSLG


 On Sun, Sep 16, 2012 at 12:45 PM, Sanjiva Weerawarana >>> > wrote:

> IIRC the old xslt mediator had a "source" parameter to indicate what
> should be sent in. Without that, its correct that we send in the entire
> message - if its SOAP its the whole envelope etc.. If the transform should
> produce a SOAP message that's up to the person to generate it.
>
> So IMO we should call this new high perf XSLT mediator a "raw xslt"
> mediator or something like that and make clear what the responsibility of
> the person writing the transform is.
>
> We could also (later) write an extension that supports a few source
> parameters - e.g. "body" and then do some byte level parsing (a very basic
> xml parser) that strips out the other stuff and passes the body thru.
>
> IMO we don't need that - we have a high perf one that requires you to
> process the whole message and we have the current one which gives you a 
> lot
> more flexibility at a performance tradeoff.
>
> So in other words, lets finish this and ship it!
>
> Sanjiva.
>
> On Sun, Sep 16, 2012 at 10:35 AM, Andun Sameera wrote:
>
>>
>>
>> On Sun, Sep 16, 2012 at 5:50 AM, Hiranya Jayathilaka <
>> hiranya...@gmail.com> wrote:
>>
>>>
>>>
>>> On Sat, Sep 15, 2012 at 5:19 PM, Hiranya Jayathilaka <
>>> hiranya...@gmail.com> wrote:
>>>
 I don't know for sure whether this problem can be solved. But
 sometime back I wrote a custom mediator to do XSLT transformations 
 using
 the StAX support available in the Java TrAX API. It showed a fairly 
 good
 performance improvement against the existing implementation too.

 Solving the problem mentioned in this thread will be pretty hard.
 Perhaps we can relax the conditions a bit. We can wrap the output of 
 the
 transformation in a SOAP envelope and put that back in the data