Hi Hiranya, I have some ideas in my mind to improve the Pass through transport. Mainly it is to stream a single source to multiple targets. If you are planning to move it quickly I can start on these improvements.
Thanks, Supun.. On Tue, Apr 17, 2012 at 9:36 AM, indika kumara <indika.k...@gmail.com>wrote: > Thanks Hiranaya for the information. However, It may be a killer feature > if we can support the streaming with most of the mediation scenarios even > with some limitations. > > Thanks, > > Indika > > > On Tue, Apr 17, 2012 at 8:41 PM, Hiranya Jayathilaka <hiranya...@gmail.com > > wrote: > >> >> >> On Tue, Apr 17, 2012 at 3:45 PM, indika kumara <indika.k...@gmail.com>wrote: >> >>> Not sure that it is Impossible. Where are the limitations - ours, XSLT >>> engine, XSLT spec, etc.? >> >> >> It's not one thing Indika. It's many things. Synapse has to work with >> many WS-* modules, XSLT engines, XPath engines, XQuery and other >> transformation engines and much more. Our Axiom representation can work >> with most of these stuff and where that's not possible we can convert it >> into a standard model like DOM or SAX. But the bottom-line is we have to >> parse the message by some means to work with these libraries/APIs. Relay >> module basically keeps the message in a completely un-parsed state. None of >> the above APIs can work with such raw data. >> >> But I agree that for certain selected scenarios we might be able to work >> in the relay mode all the time. In fact I once wrote a STX mediator using >> Joost which can work withe binary representation provided by the message >> relay builder. >> >> Thanks, >> Hiranya >> >> >>> >>> 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 >>>> >>> >>> >> >> >> -- >> 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 >> > > -- Supun Kamburugamuva Member, Apache Software Foundation; http://www.apache.org E-mail: supu...@gmail.com <su...@wso2.com>; Mobile: +94 77 431 3585 Blog: http://supunk.blogspot.com
