[Design of JBoss ESB] - SOAPProxy Enhancements
by dward
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#4245387
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245387
16 years, 8 months
[Design of Messaging on JBoss (Messaging/JBoss)] - MessagingXAResourceRecovery configuration
by jmesnil
related to https://jira.jboss.org/jira/browse/JBMESSAGING-1506
currently, the MessagingXAResourceRecovery depends on JMS and JNDI to retrieve the JMS XASession used to recover.
The information is passed as a String in jbossts-properties.xml:
| <property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGING1"
| value="org.jboss.messaging.jms.server.recovery.MessagingXAResourceRecovery;$jndi,$user,$password" />
|
where $jndi is the JNDI lookup for the XAConnectionFactory and $user and $pass are the (optional) user credentials.
We can get rid of the dependencies to JMS and JNDI as JBoss Messaging Core API exposes its ClientSession as a XAResource directly.
In order to use a ClientSession we need to create a ClientSessionFactory from inside the MessagingXAResourceRecovery.
The only constraint is that the single input we have to this class is the String passed to its initialise() method.
There are 2 possibilites:
1. Pass all the informations required to create the ClientSessionFactory under a serialized form directly in the String
2. Put all the information in a configuration file and pass the file configuration name to the MessagingXAResourceRecovery and read the content from there
#1 is simpler. If we constraint to only support a connection to a single live server, the initialization string would be:
"$connectorFactoryClassName, $user, $pass, key1=val1, key2=val2"
This would be enough to create a TransportConfiguration with the class name and the parameters.
Then we could create a ClientSessionFactory and a ClientSession (with the optional user credentials)
However this limits the type of connection supported by the recovery to a single server.
Does it make sense for JBM 2 to have the TM recover from something else than the Messaging Server embedded in the same server instance than the TM?
If that's the case, we could put the client session factory in a separate configuration file (with the support of whole stuff, discovery, live and backup servers, etc.) and read this config file from the MessagingXAResource.
The cons is that it means yet another configuration file and it may be too complex for 80% (99%?) of the case where the TM will recover the messaging resources from the same server.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245306#4245306
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245306
16 years, 8 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Transaction management in JCA adapter is screwed up
by ataylor
Ive implemented this with the following changes.
anonymous wrote : 2) CMT, tx=NOT_SUPPORTED, local_optimisation = true
|
| MDB should be *non transacted* - it should use the ack mode as specified in the meta data
Ive made this option so that it uses the a local tx, this is to allow the user to run with *only* a single local tx. see next.
anonymous wrote : 4) CMT, REQUIRED, local_optimisation = true
|
| MDB should create a *** local tx *** *before delivery* and commit at completion of onMessage
When 'REQUIRED' is chosen then the container will always create a global tx no matter what. This happens when the call is made to endpoint..onMessage(message) method (endpoint is a proxy and creates the tx before the actual call to the MDB's onMessage). This means that there would be a local proxy and a global proxy. I've left this configurable and i'll explain fully in the docs how local optimization works.
anonymous wrote : 5) BMT, local_optimisation = false:
|
| MDB should be *non transacted* - it should use the ack mode as specified in the meta data (unless a user transaction is started)
The ack mode is always used. The outcome of a user transaction when used in an MDB has no effect on the actual delivery.
anonymous wrote : 6) BMT, local_optimisation = true
|
| MDB should be *non transacted* - it should use the ack mode as specified in the meta data (unless a user transaction is started)
I've allowed the user to be able to use local tx's if they want. because of the reason mentioned for 5). This means that if an exception is thrown from inside the MDb the user can have the message redelivered.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245305#4245305
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245305
16 years, 8 months