I think there is a misunderstanding here. If you want to send the SOAP request inside the NMR for other components to actually receive a SOAP request, the BC does not have to create a SOAP message. It will just pass the incoming one.
Also, normalizing in this case just means creating an xml Source. When the servicemix-http does not create a SOAP message, it can simply forward the HTTP stream to the next component, so normalizing has quite a low overhead in this case. What happens in the next component (i.e. WS security, SOAP message enrichment ...) is really up to the component. The only mandatory thing is to create the MessageExchange and NormalizedMessages, which are just java objects, so again the overhead is really low. However most of the processing is caused by parsing / transforming the xml Source, which can be optimized on the components, depending on how it needs to process the XML. So usually, the overhead comes from xml parsing / transformation, and the only way to minimize it is to: * reduce the number of steps that needs to parse / transform the xml * use a more optimized xml Source / xml processing inside the component For example, if you have a simple HTTP consumer -> HTTP provider route, both HTTP endpoints can use the incoming HTTP stream and just pass it along in the NMR, so there would be a single parse/write using Stax which should be quite fast. However, if you put an XSLT transformation in between, you'd need to parse from Stax into DOM, do the XSLT transformation on the DOM, then write the DOM to HTTP. So if you want to minimize the overhead of the whole route, you need to carefully design your route and your steps. In your case, I think using a DOM document might be the best thing if you need to manipulate the xml data in multiple steps. Parsing the xml into a DOM might cause a big initial overhead, but if you send the DOM document inside the NMR, it will be already parsed so you don't need to parse it again on the next step. Also, and FWIW, sending a message exhcange in the NMR has quite a low overhead, as it is mainly about putting it into a memory queue in most of the cases and wait for a thread to process it. On Sat, Sep 12, 2009 at 12:20, vikas kumar <[email protected]> wrote: > Hi, > > I guess what a developer might be bothered about can be highlighted if we > see the the following steps (assuming it is SOAP over HTTP): > > - Request reaches BC over HTTP > 1. BC processes the stream, creates the SOAP Message > 2. Opens an exchange to the next component (Component which will > identity the requestor from message) > 3. Places the data in exchange and pass it via NMR (NMR would > normalize the context related and other data) > - Request/Exchange reaches Identity related component > 1. It denormalizes the normalized message > 2. Processes the request > 3. Send the data to next component - At this point the data is > normalized to a generic format > - Next Component > 1. It denormalizes the normalized message > 2. Processes the request > 3. Send the data to next component - At this point the data is > normalized to a generic format > > .... > .... > .... > > What is the overhead imposed during the denormalization and normalization > that happens before/after a component processes the request? > > ~Vikas > > On Sat, Sep 12, 2009 at 2:05 PM, Guillaume Nodet <[email protected]> wrote: > >> Ok, I understand your routing. Now what's the problem with that ? >> The only thing I'm not sure about is that you say your BCs are soap >> enabled, which sounds weird if you want the soap envelope to be sent >> to the SEs. >> From what I see, you don't really want your BCs to be soap enabled, so >> you just need to use plain endpoints and not soap-enabled endpoints. >> >> On Sat, Sep 12, 2009 at 09:03, Soumadeep Sen <[email protected]> >> wrote: >> > Guillaume, >> > >> > Think of it this way: >> > >> > There are 3 Binding Components - 1. http/SOAP 2. JMS/SOAP 3.SMTP/SOAP >> > >> > There are 5 Service Components - 1. Identifying the Requester from SOAP >> > message 2.WS Security 3.SOAP Message Enrichment 4.Logging 5. Router >> > >> > The service components will need to only deal with the SOAP message >> > The BCs will be protocol based >> > >> > Now given the situation what would you suggest. >> > >> > -Soumadeep >> > >> > >> > >> > On Fri, Sep 11, 2009 at 11:20 PM, Guillaume Nodet <[email protected]> >> wrote: >> > >> >> I still don't understand where your problem is. >> >> If you don't want soap processing because of the overhead, you can >> >> pass the whole message and by pass soap. If you want soap processing, >> >> there will be an overhead. You can't have both at the same time. >> >> Could you be a bit more explicit in what you're looking for ? >> >> >> >> On Fri, Sep 11, 2009 at 19:44, Soumadeep Sen <[email protected]> >> wrote: >> >> > yeah, I remember that... but it was more of a hack. >> >> > Guillaume, any thoughts? >> >> > >> >> > -Soumadeep >> >> > Bizsensors >> >> > >> >> > On Fri, Sep 11, 2009 at 11:10 PM, vikas kumar < >> [email protected] >> >> >wrote: >> >> > >> >> >> Hi Soumadeep, >> >> >> >> >> >> We had used Servicemix-3.0 for something similar. What you can do is >> >> >> >> >> >> 1. Leave the normalized message empty (or add some dummy content to >> >> it) >> >> >> 2. Set the SOAP and other objects as properties in the exchange >> itself >> >> >> 3. Copy the exchange's properties to every other exchange you >> create >> >> (to >> >> >> talk to other components) >> >> >> >> >> >> This saves the system from repeated marshaling and un-marshaling (it >> >> >> atleast >> >> >> did in the earlier versions), not sure if that is the case now. >> >> >> >> >> >> Best regards, >> >> >> ~Vikas >> >> >> >> >> >> On Fri, Sep 11, 2009 at 9:50 PM, Guillaume Nodet <[email protected]> >> >> wrote: >> >> >> >> >> >> > So if you want it to be processed, it has some extra overhead. Not >> >> >> > sure what we can really do about it but trying to optimize it if >> >> >> > possible. Usually only the beginning of the message will be parsed >> and >> >> >> > the body will not be read until requested by the next component. >> >> >> > >> >> >> > On Fri, Sep 11, 2009 at 18:08, Soumadeep Sen <[email protected]> >> >> >> wrote: >> >> >> > > As a Binding Component... >> >> >> > > >> >> >> > > On Fri, Sep 11, 2009 at 9:16 PM, Guillaume Nodet < >> [email protected]> >> >> >> > wrote: >> >> >> > > >> >> >> > >> I don't really understand. >> >> >> > >> Do you want to process the SOAP envelope at the BC level or let >> it >> >> go >> >> >> > >> through the NMR ? >> >> >> > >> >> >> >> > >> On Fri, Sep 11, 2009 at 16:55, Soumadeep Sen < >> [email protected]> >> >> >> > wrote: >> >> >> > >> > Well the key here is to process the SOAP message as the >> >> intermediary >> >> >> > is >> >> >> > >> > completely dependent on it. So I think given the context and >> >> >> > ServiceMIX >> >> >> > >> > being a proper implementation of the JBI Specification it >> won't >> >> be >> >> >> the >> >> >> > >> right >> >> >> > >> > approach. >> >> >> > >> > >> >> >> > >> > But I would like to know if there is anyone who is using it to >> >> only >> >> >> > >> process >> >> >> > >> > SOAP - from a SOA standpoint. >> >> >> > >> > >> >> >> > >> > Best regards >> >> >> > >> > Soumadeep >> >> >> > >> > >> >> >> > >> > On Fri, Sep 11, 2009 at 7:59 PM, Guillaume Nodet < >> >> [email protected]> >> >> >> > >> wrote: >> >> >> > >> > >> >> >> > >> >> I think it depends on the components you're using. >> >> >> > >> >> I think both servicemix-http and servicemix-cxf-bc can be >> >> >> configured >> >> >> > >> >> to pass the whole payload without any soap processing at all. >> >> >> > >> >> For servicemix-http, if you use a <http:consumer/> endpoint, >> you >> >> >> > could >> >> >> > >> >> have access to the underlying stream directly and bypass the >> >> whole >> >> >> > >> >> soap processing. >> >> >> > >> >> >> >> >> > >> >> On Fri, Sep 11, 2009 at 14:41, Soumadeep Sen < >> >> >> > [email protected]> >> >> >> > >> >> wrote: >> >> >> > >> >> > Hi Guillaume, >> >> >> > >> >> > >> >> >> > >> >> > We are working on a WS Intermediary using ServiceMix but >> the >> >> >> > problem >> >> >> > >> is >> >> >> > >> >> that >> >> >> > >> >> > SMX assumes that components are heterogeneous and talk in >> >> >> different >> >> >> > >> data >> >> >> > >> >> > format and SMX converts the message from native to jbi and >> jbi >> >> to >> >> >> > >> native >> >> >> > >> >> . >> >> >> > >> >> > This is causing a huge performance issue. >> >> >> > >> >> > >> >> >> > >> >> > I fully understand that the purpose of JBI was to exactly >> do >> >> this >> >> >> > but >> >> >> > >> >> then >> >> >> > >> >> > in the given context where all components talk SOAP its >> >> becoming >> >> >> a >> >> >> > >> >> bottle >> >> >> > >> >> > neck. >> >> >> > >> >> > >> >> >> > >> >> > Can we have some kind of a work around? >> >> >> > >> >> > >> >> >> > >> >> > Best regards >> >> >> > >> >> > Soumadeep >> >> >> > >> >> > >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> -- >> >> >> > >> >> Cheers, >> >> >> > >> >> Guillaume Nodet >> >> >> > >> >> ------------------------ >> >> >> > >> >> Blog: http://gnodet.blogspot.com/ >> >> >> > >> >> ------------------------ >> >> >> > >> >> Open Source SOA >> >> >> > >> >> http://fusesource.com >> >> >> > >> >> >> >> >> > >> > >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> -- >> >> >> > >> Cheers, >> >> >> > >> Guillaume Nodet >> >> >> > >> ------------------------ >> >> >> > >> Blog: http://gnodet.blogspot.com/ >> >> >> > >> ------------------------ >> >> >> > >> Open Source SOA >> >> >> > >> http://fusesource.com >> >> >> > >> >> >> >> > > >> >> >> > >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > Cheers, >> >> >> > Guillaume Nodet >> >> >> > ------------------------ >> >> >> > Blog: http://gnodet.blogspot.com/ >> >> >> > ------------------------ >> >> >> > Open Source SOA >> >> >> > http://fusesource.com >> >> >> > >> >> >> >> >> > >> >> >> >> >> >> >> >> -- >> >> Cheers, >> >> Guillaume Nodet >> >> ------------------------ >> >> Blog: http://gnodet.blogspot.com/ >> >> ------------------------ >> >> Open Source SOA >> >> http://fusesource.com >> >> >> > >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
