Ashwin, Thanks for the info.
I've been looking at the HTTP and JMS binding components as well and they seem to work similarly. Unless I am misunderstanding some part of this approach, there seems to be the potential for a lot of duplication. Meaning, each binding component is pretty much on its own with respect to implementing the WS-* specs. I understand that you can break the capability out into shared java libraries but that somehow just doesn't seem very SOA to me. It seems like there should be a better way. What about, for example, encapsulating the logic for each WS-* spec into individual Service Engines? Then, depending upon need, the SE's could be strung together using an EIP static routing slip or something. The goal would be to recreate the same "interceptor chain" model from the CXF-BC but without tieing it to any specific binding component implementation. Thoughts? Thanks, Jeff On Sat, Nov 15, 2008 at 12:03 PM, Ashwin Karpe <[EMAIL PROTECTED]> wrote: > > Hi Jeff, > > You are right. The CXF-BC is responsible for processing all SOAP packages > and interpreting SOAP Headers, etc. In fact, the Message exchange that the > Binding Component forwards to the CXF-SE is a <jbi:Message> with the SOAP > Body placed in a <jbi:part>. > > The CXF-BC has interceptor chains (JAX-WS handlers) that are used by the > CXF-BC component to process WS-* spec requirements before the payload is > placed in a Message Exchange and forwarded to the CXF-SE. Also at this point > the SOAP Header is stripped and copied into a JBI property for access any > other JBI endpoints. > > Hope this helps. > > Cheers, > > Ashwin... > > > Jeff Peterson-3 wrote: >> >> Hello, >> >> I have a question about SOAP processing (specifically related to the >> SOAP header). I've been using ServiceMix lightly for over a year now >> and my experience has been that SOAP processing appears to occur >> exclusively at the binding components. That is to say, if a binding >> component (consumer) like servicemix-http or servicemix-jms receives a >> SOAP message it is responsible for processing all of the SOAP headers >> (WS-A, WS-Sec, etc), extracting the body, and passing it all along as >> a NormalizedMessage. The reverse seems to be true for provider >> binding components. Is that correct? Am I missing something? >> >> I am trying to wrap my head around the message processing model used >> here. Theoretically, if I were going to develop a new binding >> component which used an entirely new transport protocol but still used >> SOAP message envelopes, what would I need to do to support the WS-* >> specifications? Would I have to embed all of that logic into the new >> binding component or is there some set of services on the bus that >> encapsulate that functionality? >> >> Thanks, >> >> Jeff >> >> > > -- > View this message in context: > http://www.nabble.com/SOAP-Header-Processing-tp20510704p20519000.html > Sent from the ServiceMix - User mailing list archive at Nabble.com. > >
