In 4.6, the SOAPProxy class was added, which is an easy mechanism to proxy an external web service via the bus. All that is required is the original wsdl location, whose endpoints get transformed so consumers go through the bus. Further wsdl transformation can be configured via Smooks, and you can also optionally transform the soap envelope before and after the proxying, via the new XsltAction, or via the SmooksAction. Also, for soap-over-http, any of the HttpRouter properties can be set as properties on the SOAPProxy. For 4.7, I would like to propose a few enhancements: a) Support Basic Auth. This was an oversight on my part, and is documented in this Jira: https://jira.jboss.org/jira/browse/JBESB-2759 b) (a) is the minimal requirement. I'm wondering if we might want to do more with this, maybe introduce the notion of a "runAs"? c) HttpRouter property overrides per endpoint address. Currently, any HttpRouter properties can be set as properties on the SOAPProxy, since SOAPProxy (actually HttpSOAPProxyTransport) wraps usage of HttpRouter, setting sensible HttpRouter defaults. A distinct HttpSOAPProxyTransport is created per endpoint address, however any HttpRouter overrides set at the SOAPProxy level are shared for each endpoint address. This is a bad assumption, as what if you wanted different overrides per endpoint address? I propose keeping having the notion of a 3-tier property configuration: 1. If no HttpRouter properties are set on SOAPProxy, the default HttpRouter properties coded inside HttpSOAPProxyTransport take effect. This is current behavior and would remain. 2. If HttpRouter properties are set on SOAPProxy, they can override those coded inside HttpSOAPProxyTransport, however across all wsdl-defined endpoint addresses. This supercedes #1. This is also current behavior and would remain. 3. NEW: Add the ability to override HttpRouter properties per endpoint address, as nested properties. This supercedes #2 and #1. The question is, "What should the property names be / how can they be distinguished?" I thought of a couple options, first being the binding QName: <property name="{http://foo/oof}FooBinding"> second, being the actual soap:address location: <property name="http://host1/foo/FooWS"> I like the second option best, as that is really most about the transport itself, so here's what it would look like: <action name="..." class="...SOAPProxy"> | <property name="wsdl" value="...?wsdl"/> | <!-- per-wsdl (global) HttpRouter overrides are at this level (tier 2) --> | <property name="method" value="POST"/> | <property name="http://host1/foo/FooWS"> | <!-- per-endpoint HttpRouter overrides are at this level (tier 3) --> | <property name="responseType" value="STRING"/> | </property> | <property name="http://host2/bar/BarWS"> | <!-- per-endpoint HttpRouter overrides are at this level (tier 3) --> | <property name="responseType" value="BYTES"/> | </property> | </action> In code, I would just find all properties starting with "http" to give to the HttpSOAPProxyTransport for it's HttpRouter overrides. In the future (when a JmsSOAPProxyTransport gets added, for example), I might look for properties starting with "jms" for overrides. Or SmtpSOAPProxyTransport... Also note the tier 3 elements are still called "property". This is a free-form content section (xsd:any), so this could have been "transport-property" or similar, however I would prefer just "property" for consistency at either tier. Thoughts? Opinions? Questions? Concerns? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245387#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...