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. > >
