Not sure that it is Impossible. Where are the limitations - ours, XSLT engine, XSLT spec, etc.?
I believe it should be possible. One way may be identifying XML fragments and transform them on the fly by fragment by fragment - read one fragment from input, transform it, and write it to output...I did my self a case study for a specific customer when I was at WSO2. He was happy. Of course, it is just a case study for one user. But, someone should be able to come up with a more generalized and improved solution. I can see some research on this topic. There should be some interesting ideas. http://www.springerlink.com/content/l156j0255347k356/ http://www.sciencedirect.com/science/article/pii/S0167642304001194 http://dl.acm.org/citation.cfm?id=1042051 On Tue, Apr 17, 2012 at 6:38 PM, Hiranya Jayathilaka <hiranya...@gmail.com>wrote: > > > On Tue, Apr 17, 2012 at 10:49 AM, indika kumara <indika.k...@gmail.com>wrote: > >> Ohh... I thought we have a solution to get >> or preserve the benefits offered by the binary relay when it is used for >> other mediation scenarios - for example, with some kind of >> on-demand streaming transformation. > > > That's not practically possible. For security to work, Rampart should be > able to find the necessary headers in the SOAP infoset. For XSLT to work > the XSLT engine should be able to parse the given XML infoset. So for these > cases we have to build the message as usual and let the normal processing > take place. What we have implemented is kind of a compiler optimization for > Synapse language, where by looking at the configuration provided we insert > the build instruction to the sequence. > > Thanks, > Hiranya > > >> >> >> ~ Indika >> >> On Tue, Apr 17, 2012 at 2:24 PM, Hiranya Jayathilaka < >> hiranya...@gmail.com> wrote: >> >>> Hi Folks, >>> >>> Just to briefly explain how other messaging scenarios are made to work >>> with the relay: >>> >>> 1. A special handler checks whether security or some other content aware >>> module is engaged on the target service and builds the messages if >>> necessary. >>> 2. Each mediator knows whether they should build the message or not >>> (depending on their configuration). If necessary, mediators will build the >>> message. >>> >>> As a result a sequence such as the following will run in the pure pass >>> through mode: >>> >>> <sequence> >>> <log/> >>> <send/> >>> </sequence> >>> >>> Something like the following will cause the message to be built at the >>> log mediator: >>> >>> <sequence> >>> <log level="full"/> >>> <send/> >>> </sequence> >>> >>> In the following proxy service, the in-sequence will be in the pass >>> through mode. The out-sequence will build the message at the xslt mediator: >>> >>> <proxy name="foo"> >>> <target endpoint="bar"> >>> <inSequence> >>> <log/> >>> </inSequence> >>> <outSequence> >>> <log/> >>> <xslt key="baz"/> >>> <send/> >>> </outSequence> >>> </target> >>> </proxy> >>> >>> Thanks, >>> Hiranya >>> >>> On Tue, Apr 17, 2012 at 9:32 AM, indika kumara <indika.k...@gmail.com>wrote: >>> >>>> +1 great donation! Would love to see the support for any mediation >>>> scenario with it too. >>>> >>>> Regards, >>>> >>>> Indika >>>> >>>> >>>> On Mon, Apr 16, 2012 at 4:17 PM, Hiranya Jayathilaka < >>>> hiranya...@gmail.com> wrote: >>>> >>>>> Hi Folks, >>>>> >>>>> Message relay is a performance enhancer we have developed for WSO2 >>>>> ESB. We are now thinking about contributing this code to Synapse. There >>>>> are >>>>> two main components for this: >>>>> >>>>> 1. A builder-formatter pair for mediating messages without building >>>>> the Axiom infoset >>>>> 2. A new HTTP transport (pass through transport) >>>>> >>>>> These can be used independently of each other. One of the existing >>>>> limitations of this code is that it restricts the scenarios that we can >>>>> run >>>>> on Synapse to pass through scenarios. But I've been working on making this >>>>> code work with any mediation scenario (transformation, security etc). So >>>>> that way we will be able to run Synapse with these optimizers by default >>>>> and still all the messaging scenarios would work out of the box. >>>>> >>>>> A performance comparison of the current NHTTP transport and the above >>>>> optimizers can be found at [1]. >>>>> >>>>> Appreciate your feedback on this. >>>>> >>>>> Thanks, >>>>> Hiranya >>>>> >>>>> [1] - >>>>> http://wso2.org/library/articles/2012/03/performance-benchmarking-wso2-esb-different-message-transfer-mechanisms >>>>> >>>>> -- >>>>> Hiranya Jayathilaka >>>>> Associate Technical Lead; >>>>> WSO2 Inc.; http://wso2.org >>>>> E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 >>>>> Blog: http://techfeast-hiranya.blogspot.com >>>>> >>>> >>>> >>> >>> >>> -- >>> Hiranya Jayathilaka >>> Associate Technical Lead; >>> WSO2 Inc.; http://wso2.org >>> E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 >>> Blog: http://techfeast-hiranya.blogspot.com >>> >> >> > > > -- > Hiranya Jayathilaka > Associate Technical Lead; > WSO2 Inc.; http://wso2.org > E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 > Blog: http://techfeast-hiranya.blogspot.com >
