[wildfly-dev] WFLY-2422 or simplifying the remote outbound connection configuration for server to server communication
Wolf-Dieter Fink
wfink at redhat.com
Thu Mar 19 05:11:47 EDT 2015
Any thoughts on this about the best/simplest/reasonable approach?
On 09/03/15 15:25, Wolf-Dieter Fink wrote:
> I start a request for simplifying the configuration for "in EE
> application" clients and get rid of extra cluster configuration and
> repeat properties many times.
> Also the client should not need to have knowledge about the server
> topology, there is no need to know how many servers there are or whether
> they are clustered or not.
>
> Starting point in EAP6/WF8 is a application configuration like this:
> https://github.com/wildfly/quickstart/blob/master/ejb-multi-server/app-main/ear/src/main/application/META-INF/jboss-ejb-client.xml?
>
> and a server side configuration like this:
> <subsystem xmlns="urn:jboss:domain:remoting:3.0">
> <endpoint worker="default"/>
> <http-connector name="http-remoting-connector"
> connector-ref="default" security-realm="ApplicationRealm"/>
> <outbound-connections>
> <remote-outbound-connection
> name="remote-ejb-connection-1"
> outbound-socket-binding-ref="remote-ejb-1" username="quickuser1"
> security-realm="ejb-security-realm-1" protocol="http-remoting">
> <properties>
> <property name="SASL_POLICY_NOANONYMOUS"
> value="false"/>
> <property name="SSL_ENABLED" value="false"/>
> </properties>
> </remote-outbound-connection>
> <remote-outbound-connection
> name="remote-ejb-connection-2"
> outbound-socket-binding-ref="remote-ejb-2" username="quickuser2"
> security-realm="ejb-security-realm-2" protocol="http-remoting">
> <properties>
> <property name="SASL_POLICY_NOANONYMOUS"
> value="false"/>
> <property name="SSL_ENABLED" value="false"/>
> </properties>
> </remote-outbound-connection>
> </outbound-connections>
> </subsystem>
>
>
>
> Tomasz did some refactoring (WF9) to use a profile from the application
> perspective. The configuration is like this:
>
> jboss-ejb-client.xml
> <client-context>
> <profile name="main-app"/>
>
>
>
> --
>
> Email: wfink at redhat.com
>
> Red Hat Customer Portal http://bit.ly/accessRH
> Twitter http://bit.ly/RHsupport
> Facebook - http://bit.ly/RHsupportFB
> Google+ http://bit.ly/RHsupportG
> ________________________________________________________________________
> Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
>
>
> </client-context>
>
> server profile:
> <remote connector-ref="http-remoting-connector"
> thread-pool-name="default">
> <profiles>
> <profile name="main-app">
> <remoting-ejb-receiver name="AppOneA"
> outbound-connection-ref="remote-ejb-connection-1"/>
> <remoting-ejb-receiver name="AppTwoA"
> outbound-connection-ref="remote-ejb-connection-2"/>
> </profile>
> </profiles>
> </remote>
> ....
> <subsystem xmlns="urn:jboss:domain:remoting:3.0">
> <outbound-connections>
> <remote-outbound-connection
> name="remote-ejb-connection-1"
> outbound-socket-binding-ref="remote-ejb-1" username="quickuser1"
> security-realm="ejb-security-realm-1" protocol="http-remoting">
> <properties>
> <property name="SASL_POLICY_NOANONYMOUS"
> value="false"/>
> <property name="SSL_ENABLED" value="false"/>
> </properties>
> </remote-outbound-connection>
> <remote-outbound-connection
> name="remote-ejb-connection-2"
> outbound-socket-binding-ref="remote-ejb-2" username="quickuser2"
> security-realm="ejb-security-realm-2" protocol="http-remoting">
> <properties>
> <property name="SASL_POLICY_NOANONYMOUS"
> value="false"/>
> <property name="SSL_ENABLED" value="false"/>
> </properties>
> </remote-outbound-connection>
> </outbound-connections>
> </subsystem>
>
>
> With the current implementation there are some issues or
> concerns/enhancements
> - profile does not work with clusters
> - not possible to have multiple profiles
> - the properties/user must be still repeated
>
>
>
> From my point of view
> - a cluster need to have the same property configuration, also different
> users make no sense. Might work, but at least the cluster view will use
> the same user
> - a similar group of servers for the same application should not have
> different properties/users as this will be error prone
> - configuration should be as small and intuitive as possible
>
> My initial idea was to have a jboss-ejb-client.xml which reference
> 'applications' to connect, that is similar to profiles
> The server side as followed (don't care about the exact XML elements or
> names)
>
> <subsystem xmlns="urn:jboss:domain:remoting:3.0">
> <outbound-connections>
> <profile name="App1" username="quickuser1"
> security-realm="ejb-security-realm-1" protocol="http-remoting">
> <properties>
> <property name="SASL_POLICY_NOANONYMOUS"
> value="false"/>
> <property name="SSL_ENABLED" value="false"/>
> </properties>
> <outbound-sockets>remote-ejb-1,remote-ejb2</outbound-sockets> <!--
> repeated elements seems better -->
> </remote-outbound-connection>
> <remote-outbound-connection
> name="remote-ejb-connection-X"
> outbound-socket-binding-ref="remote-ejb-X" username="quickuser2"
> security-realm="ejb-security-realm-2" protocol="http-remoting">
> <properties>
> <property name="SASL_POLICY_NOANONYMOUS"
> value="false"/>
> <property name="SSL_ENABLED" value="false"/>
> </properties>
> </remote-outbound-connection>
> </outbound-connections>
> </subsystem>
>
> In this case the profile use the user/security and properties for all
> connections and the cluster as well. In this it is necessary to have the
> same configuration for all the servers in the profile-bunch.
> Another option I thought about is to use the user/properties in
> <profile> as default and have the possibility to use a inner element
> remote-outbound-connection, or a reference to remote-outbound-connection
> which can override these, but I'm not sure whether this is needed.
>
> We (Tomasz Adamski and me) had a discussion about this and, technically
> there is no problem with each approach.
>
> But ...
>
> I know that all the ejb-client stuff is subject to change and to prevent
> from incompatible changes which are changed in every version
> and from unnecessary work if the code will be changed before it will be
> used at all
> I think it will need to be discussed with others because of this.
>
> cheers
> Wolf
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
More information about the wildfly-dev
mailing list