Hi Guillaume, Thanks for the detailed reply... Currently we implemented it the way you have suggested... I guess the problem is that instead of using a large number of service components we need to reduce it down to a handful.
Will keep you in the loop... Best regards Soumadeep Bizsensors On Mon, Sep 14, 2009 at 12:48 PM, Guillaume Nodet <[email protected]> wrote: > 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 >
