Hi Jeff, There is a little bit of Servicemix history here that leads to the confusion you have articulated. The CXF-BC and CXF-SE are more recent and JAX-WS compliant way of creating and web service fronts in JBI.
The pre-cursor used to be the HTTP-BC and JSR-181 SE combination. The JSR-181 component was based on Jetty and not fully JAXB compilant and has been deprecated since then. As for HTTP-BC, it supports SOAP as well as non-SOAP based XML payloads (HTML, Raw XML etc). However since it has no Interceptor/Handler chain associated with it (implemented using JAX-WS in CXF-BC) there is no good way to implement WS-* capabilities (Security, Policy, RM etc). The HTTP_BC is a very versatile component and can be put to good use in Web Service and non-WSscenarios as HTTP-BC --> CXF-SE combo in case there is no WS-* requirement involved. I am sure this is an area has tripped up many developers/users including yours truly. Hope this helps. Cheers, Ashwin... Jeff Peterson-3 wrote: > > Ashwin, > > Thanks for the response. I am just trying to understand and I meant > no disrespect. As I use servicemix and develop service > engines/binding components I just want to make sure I am > conceptualizing the different components correctly. > > To date I have been thinking about binding components as a means to > separate the concerns of the different transport protocols > (HTTP/JMS/SMTP/FTP/etc). I have been asking myself, if SOAP is the > envelope protocol used across all of those transport protocols, where > is the most efficient place to perform SOAP processing (including the > header)? > > If I understand your response correctly, you are saying that SOAP > (including its multitude of transport protocols), is best modeled as a > single binding component. I assume this is the goal of the CXF-BC. > That seems like a reasonable approach to me. > > If that is the case, are you then also saying that the HTTP and JMS > binding components should only be used when the messages do not > involve SOAP? > > Thanks, > > Jeff > > On Sat, Nov 15, 2008 at 9:39 PM, Ashwin Karpe <[EMAIL PROTECTED]> > wrote: >> >> 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. >> >> > > -- View this message in context: http://www.nabble.com/SOAP-Header-Processing-tp20510704p20544642.html Sent from the ServiceMix - User mailing list archive at Nabble.com.
