[wildfly-dev] WFLY-2422 or simplifying the remote outbound connection configuration for server to server communication

Tomasz Adamski tadamski at redhat.com
Tue Jul 14 15:51:04 EDT 2015


I belive that we need to deal with two problems:
1. Moving away configuration from application developer to server administrator.
2. Simplify the configuration so that most common scenarios can be consise and easy to understand.  On the other hand we must assure that all valid use scenarios are still supported. 

My previous refactor dealt with the first point. Concept of profile was introduced which groups remote-outbound-connections and enables application developer to specify only the name of the profile. 
As Wolf mentioned the further things may to be improved: replication of configuration, cluster enabling and ability to use multiple profiles.


Connection groups

Regarding cluster configuration I believe that cluster properties should be moved from ejb-client-descriptor to remoting subsystem definition. Firstly, we will remove another part of server specific 
configuration from application deployer to server administrator. Secondly, it will allow to perform further simplifing configuration refactor.

Regarding the second point, I believe that the problem of replication should not be handled using profiles - we should have a different configuration element for that. 

One possible solution that we discussed with Wolf was to create a remote-outbound-connection-group element which will gather together all r-o-cs that share the same configuration.
Instead of:

<remote-outbound-connection name="remote-ejb-connection-1" outbound-socket-binding-ref="remote-ejb-1" username="quickuser" security-realm="ejb-security-realm" 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="quickuser" security-realm="ejb-security-realm" 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-3" outbound-socket-binding-ref="remote-ejb-3" username="quickuser" security-realm="ejb-security-realm" protocol="http-remoting">
    <properties>
        <property name="SASL_POLICY_NOANONYMOUS" value="false" />
        <property name="SSL_ENABLED" value="false" />
    </properties>
</remote-outbound-connection>

we would have:

<remote-outbound-connection-group username="quickuser" security-realm="ejb-security-realm" protocol="http-remoting"> 
    <connection outbound-socket-binding-ref="remote-ejb-1"/>
    <connection outbound-socket-binding-ref="remote-ejb-2"/>
    <connection outbound-socket-binding-ref="remote-ejb-3"/>
    <properties>
        <property name="SASL_POLICY_NOANONYMOUS" value="false" />
        <property name="SSL_ENABLED" value="false" />
    </properties>
<remote-outbound-connection-group/>

If user need to specify different configurations for different connections then he can still do it directly - that is create number of remote-outbound-connection not nested in any group.

What's more the group may be used to group connections of one cluster. If we decide to group nodes from the cluster together then it would require that the same properties are used when connecting to 
each node in the cluster. Let's suppose that those connections are three possible points of entry to a cluster called "ejb-cluster". Currently application deployer has to specify the following 
configuration:

<cluster name="ejb">
    <connection-creation-options>
        <property name="org.xnio.Options.SSL_ENABLED" value="false" />
        <property name="org.xnio.Options.SASL_POLICY_NOANONYMOUS" value="false" />
    </connection-creation-options>
</cluster>

According to Wolf it is a good practice for all nodes in the cluster to have the same configuration. If we can make an assumption than only such configuration is supported then we can use 
remote-outbound-connection-group to configure cluster as well.

An example configuration may be: 

<remote-outbound-connection-group username="quickuser" security-realm="ejb-security-realm" protocol="http-remoting" cluster="ejb-cluster">
(...)
<remote-outbound-connection-group/>


Profiles

Profile is an entity that can be understood by application deployer without need of knowing the configuration details. It would contain r-o-c and r-o-c groups (which can possibly represent a cluster).
Currently user can address only one profile from jboss-ejb-client descriptor. This should be changed too - users should be able to specify many profiles in jboss-ejb-client. Profiles can be combinded 
in different ways and we were also discussing the possibility to introduce dependencies between profiles, but it needs to be discussed wheter there are use cases that require introduction of such 
design which introduces additional complexity. In proposed design application deployers can combine different profiles in their ejb-client-descriptors.

Sample of proposed configuration:

Remoting subsystem:

<remote-outbound-connection-group name="group" username="quickuser" security-realm="ejb-security-realm" protocol="http-remoting"> 
    <connection outbound-socket-binding-ref="remote-ejb-1"/>
    <connection outbound-socket-binding-ref="remote-ejb-2"/>
    <connection outbound-socket-binding-ref="remote-ejb-3"/>
    <properties>
        <property name="SASL_POLICY_NOANONYMOUS" value="false" />
        <property name="SSL_ENABLED" value="false" />
    </properties>
<remote-outbound-connection-group/>

<remote-outbound-connection-group name="cluster" username="quickuser" security-realm="ejb-security-realm" protocol="http-remoting" cluster="ejb"> 
    <connection outbound-socket-binding-ref="remote-ejb-cluster-1"/>
    <connection outbound-socket-binding-ref="remote-ejb-cluster-2"/>
    <properties>
        <property name="SASL_POLICY_NOANONYMOUS" value="false" />
        <property name="SSL_ENABLED" value="false" />
    </properties>
<remote-outbound-connection-group/>

<remote-outbound-connection name="connection1" outbound-socket-binding-ref="remote-ejb-4" username="quickuser" security-realm="ejb-security-realm" 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="connection2" outbound-socket-binding-ref="remote-ejb-5" username="quickuser" security-realm="ejb-security-realm" protocol="http-remoting">
    <properties>
        <property name="SASL_POLICY_NOANONYMOUS" value="true" />
        <property name="SSL_ENABLED" value="true" />
    </properties>
</remote-outbound-connection>


<profile name="application A">
    <outbound-connection-group-ref="group"/>
</profile>

<profile name="application B">
    <outbound-connection-group-ref="cluster"/>
</profile>

<profile name="application C">
    <outbound-connection--ref="connection1"/>
    <outbound-connection--ref="connection2"/>
</profile>

Sample client configs:

<jboss-ejb-client xmlns="urn:jboss:ejb-client:1.3">
    <client-context>
        <profile name="application A" />
        <profile name="application B" />
    </client-context>
</jboss-ejb-client>

-- 
Tomasz Adamski
Software Engineer
JBoss by Red Hat 

----- Oryginalna wiadomość -----
> Od: "Wolf-Dieter Fink" <wfink at redhat.com>
> Do: "tadam >> Tomasz Adamski" <tadamski at redhat.com>, "WildFly Dev" <wildfly-dev at lists.jboss.org>
> DW: "Paul Ferraro" <paul.ferraro at redhat.com>, "David M. Lloyd" <david.lloyd at redhat.com>, "Brad Maxwell"
> <bmaxwell at redhat.com>, "Dennis Reed" <dereed at redhat.com>, "Shay Matasaro" <smatasar at redhat.com>
> Wysłane: poniedziałek, 9 marzec 2015 15:25:32
> Temat: WFLY-2422 or  simplifying the remote outbound connection configuration for server to server communication
> 
> 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"/>
>      </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
> 



More information about the wildfly-dev mailing list