Jeff, What you are looking to do i.e backing a CXF_BC with EIP's headed to different SE's can be done by Servicemix and is pretty standard.
For example you can set the target service of a CXF-BC to be a routing slip and put the CXF-SE somewhere along the way to change the direction of the flow, thereby getting the effect of other service endpoints behaving like interceptors/transformers mediating between the CXF-BC and CXF-SE. This however is offered in addition to existing capability offered by the CXF-BC. The notion of going overboard with the above approach/capability to the point where we take away the rationale for payload validation and/or standards compliance/enforcement at the Binding component is misguided.There are several practical problems in enforcing such an approach. a> It goes against the idea of separation of concerns. Service engines are designed to be simple business data processing entities in the context of a flow. Bringing in WS-* specific behavior at this layer is inappropriate. An interceptor is not the same as a processing entity such as a service engine. b> All requests from the non-JBI universe (SCA based Web Services for example Axis, CXF etc) must be handled by a binding component (per JBI spec) in the role of service provider or consumer. A pass-through binding component would be nothing but a message listener/invoker and therefore be of no inherent value at all. c> A Service engine has no direct interface to the non-JBI world and only talks to the NMR and only deals with Message Exchanges. Service Engines do not care about WS-* specs (and nor should they) since, there may be receive alternate payload combinations such as XML/JMS, HTML/HTTP payloads etc which have no notion of WS-*. d> Trying to handle all combinations of such payloads+associated specifications will only create layers of complexity at the Service Engines which are pretty much blind business data processing entities. e> Specifications like JAX-WS and its notion of handlers/ interceptors on the CXF BC will have no meaning. The implication is that specifications such as WS-Security etc will break since the security token will be invalidated as soon as the binding component inspects the payloadto create a Message exchange. The SE backing the BC will not be able to process the security token unless it is forwarded unprocessed as raw XML. Same will be the case with WS-RM where the responsibility for handling control message will now rest with an entity somewhere in the middle of a flow. Sorry about the long winded answer. I hope, however, this highlights some of the reasons/rationale behind the design of BC's the way they are. I do see your point about some degree of code duplication in different BC's but nothing that cannot be solved by code re-use via libraries, I hope... Cheers, Ashwin... Jeff Peterson-3 wrote: > > 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. >> >> > > -- View this message in context: http://www.nabble.com/SOAP-Header-Processing-tp20510704p20522629.html Sent from the ServiceMix - User mailing list archive at Nabble.com.
