9:51 p.m.
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(a)redhat.com>
Do: "tadam >> Tomasz Adamski" <tadamski(a)redhat.com>, "WildFly
Dev" <wildfly-dev(a)lists.jboss.org>
DW: "Paul Ferraro" <paul.ferraro(a)redhat.com>, "David M. Lloyd"
<david.lloyd(a)redhat.com>, "Brad Maxwell"
<bmaxwell(a)redhat.com>, "Dennis Reed" <dereed(a)redhat.com>,
"Shay Matasaro" <smatasar(a)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-ma...
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