Remoting in domain.xml

[dmlloyd]

These are the primary tasks for Remoting 3 container configuration in domain.xml.

1. Connector configuration.  This includes an SSL section - the SSL config should be merged with the web container.  It should probably be a separate domain concept altogether which can be referenced from the container config(s).  Maybe combined with socket config, maybe not.
2. Server authentication configuration.  This will probably amount to some integration into our authentication subsystem.  I talked to Anil about this about 6 months ago.  I have absolutely no memory of what we decided.  So for now I'll represent a simple authentication provider only until I discover what API is available for us to leverage.

These are the primary tasks for R3 deployment descriptors:

1. Deploying services.  This means, adding services in to the R3 endpoint registry.  This can happen implicitly (i.e. because of an EJB deployment with remote interfaces) or explicitly (i.e. a custom application service).

Here's what the domain container fragment could look like:

    <remoting xmlns="urn:jboss:remoting:3.1"> <!-- xs:all, I guess? -->
        <connector name="SomeSSLConnectorName"> <!-- xs:all -->
            <!-- Ports and SSL are configured via central management point -->
            <sasl> <!-- optional xs:all -->
                <include-mechanisms value="EXTERNAL DIGEST-MD5 PLAIN"/> <!-- optional -->
                <qop value="auth"/> <!-- optional; other possible values are "auth-int", "auth-conf" -->
                <strength value="high"/> <!-- optional; other possible values are "low", "medium" -->
                <reuse-session value="false"/> <!-- optional boolean -->
                <server-auth value="false"/> <!-- optional boolean -->
                <policy> <!-- optional xs:all -->
                    <forward-secrecy value="true"/> <!-- optional boolean -->
                    <no-active value="true"/> <!-- optional boolean -->
                    <no-anonymous value="true"/> <!-- optional boolean -->
                    <no-dictionary value="true"/> <!-- optional boolean -->
                    <no-plain-text value="true"/> <!-- optional boolean -->
                    <pass-credentials value="true"/> <!-- optional boolean -->
                </policy>
                <properties/> <!-- optional properties list -->
           </sasl>
           <simple-authentication-provider keystore="SomeKeyStore"> <!-- optional xs:all -->
               <properties/> <!-- optional properties list -->
           </simple-authentication-provider>
           <properties/> <!-- optional properties list -->
        </connector>
    </remoting>

The deployment-time thing might be something we can implement via Weld perhaps: an annotation which marks a class as a Remoting service.  The other Remoting pieces (i.e. the Endpoint) would certainly be injectable using MSC or Weld injection.

[dmlloyd]

Perhaps a better namespace would be:

    <remoting xmlns="urn:jboss:domain:remoting:1.0">

or:

    <remoting xmlns="urn:jboss:as:remoting:7.0">

or whatever.

[brian.stansberry]

<!-- Ports and SSL are configured via central management point -->

You'd still need some sort of ref to what socket(s) to use though.

[dmlloyd]

Brian Stansberry wrote:

<!-- Ports and SSL are configured via central management point -->

You'd still need some sort of ref to what socket(s) to use though.

Do we reference the socket from the connector, or do we reference the connector from the socket def?

[brian.stansberry]

The approach discussed in https://community.jboss.org/thread/153975?tstart=0 references the socket from the connector def. How would you do it the other way, with IDREF?  Let's discuss on that other thread though; this is a general issue; your XML fragment here just gave me an opening to raise it.

[dmlloyd]

    <remoting-container xmlns="urn:jboss:remoting:3.1" thread-pool="ThreadPool"> <!-- xs:choice, unbounded -->
        <connector name="SomeSSLConnectorName" socket-binding="RemotingSSL"> <!-- xs:all -->
            <!-- Ports and SSL are configured via central management point -->
            <sasl> <!-- optional xs:all -->
                <include-mechanisms value="EXTERNAL DIGEST-MD5 PLAIN"/> <!-- optional simple list of string -->
                <qop value="auth-conf auth-int auth"/> <!-- optional simple list of enumeration -->
                <strength value="high"/> <!-- optional; other possible values are "low", "medium" -->
                <reuse-session value="false"/> <!-- optional boolean -->
                <server-auth value="false"/> <!-- optional boolean -->
                <policy> <!-- optional xs:all -->
                    <forward-secrecy value="true"/> <!-- optional boolean -->
                    <no-active value="true"/> <!-- optional boolean -->
                    <no-anonymous value="true"/> <!-- optional boolean -->
                    <no-dictionary value="true"/> <!-- optional boolean -->
                    <no-plain-text value="true"/> <!-- optional boolean -->
                    <pass-credentials value="true"/> <!-- optional boolean -->
                </policy>
                <properties/> <!-- optional properties list -->
            </sasl>
            <simple-authentication-provider keystore="SomeKeyStore"> <!-- optional xs:all -->
                <properties/> <!-- optional properties list -->
            </simple-authentication-provider>
            <properties/> <!-- optional properties list -->
        </connector>
    </remoting-container>

This is with a socket-binding element, also changing the name of the root element to be more consistent with other stuff.

As a general comment on container elements, rather than have an xs:all with <web-containers>, <remoting-containers>, etc., I think we should just have a single <containers> element under <domain> with an unbounded xs:choice which allows you to intermix containers in any order.  This also makes the object model somewhat simpler because extension writers won't need to deal with an intermediate concept to represent the superfluous wrapper element.

Message was edited by: David Lloyd (corrections to the XML)

[aloubyansky]

Haven't we agreed to use the same namespace for everything in the domain and host xml?

[brian.stansberry]

We keep going back and forth on that. The current trend is that major non-core subsystems where projects may want to release new versions at a different cadence than the AS can have a separate namespace.

Can you hang out in #jboss-as7 on freenode? I'd like to get your input on things like this in a more interactive mode.

[brian.stansberry]

Is this a container?

I don't see where else it fits though. We could have a domain-level element for connectorish-things, but that means http(s) connectors, messaging connectors etc should all go there.

[dmlloyd]

Alexey Loubyansky wrote:

Haven't we agreed to use the same namespace for everything in the domain and host xml?

Well I'm not talking about XML namespaces (I see now that it was a bit ambiguous!).  I'm talking about the namespace of the service created for a container with some given name.

But as far as XML namespaces go - yeah Jason and I had a "vigorous" discussion about it and I think the conclusion we came to is that we probably should have multiple XML namespaces but they should be divided up by subsystem not by file type.  In other words, host.xml domain.xml and friends will still use the same root XML namespace, but subsystems like web, HornetQ, remoting, etc. should each get their own namespace.  This lets users upgrade individual subsystems.

[dmlloyd]

Brian Stansberry wrote:

Is this a container?

I don't see where else it fits though. We could have a domain-level element for connectorish-things, but that means http(s) connectors, messaging connectors etc should all go there.

I'll comment on this in the other thread.

[brian.stansberry]

Just to clarify a bit -- we don't want to go too far. Core infrastructure stuff (e.g. threads, logging) should remain in the core namespace.

[dmlloyd]

Brian Stansberry wrote:

Just to clarify a bit -- we don't want to go too far. Core infrastructure stuff (e.g. threads, logging) should remain in the core namespace.

Do we even want to have a containers element at all?  Maybe that should just be directly at the domain level...

[brian.stansberry]

Aren't the children of <containers/> xs:any ##other? Do we want such a thing at the root level?

[dmlloyd]

Brian Stansberry wrote:

Aren't the children of <containers/> xs:any ##other? Do we want such a thing at the root level?

I dunno, it doesn't seem completely unreasonable to me.  We could say that such elements must correspond to one of a fixed set of Java types.  Or maybe they must all be containers of some sort; that allows us to use the same base class for core stuff like threads & logging, which could be a good thing.

On the other hand, I'm not quite sure what other kinds of things we'll want to stick in there.  It could get out of hand fast.

I think the main rationale for using <containers> is to have the root <domain> and <host> elements be xs:all, but I think we probably already broke that with <extension> (not unfixable though) and the "core stuff" you mentioned.  Though it's also reasonable to stipulate one each of logging and threads configs - but again we'll have this mapping-to-server-groups issue.

Another idea is to ditch <containers> and bring back the per-container-type collection elements and have them at the root level.  But of course you can't have an xs:any inside an xs:all, so that wouldn't help with that problem.  We'd be back to an unbounded xs:choice plus an extra level of programmatic validation.

This is one of those cases where you want an xs:all that supports repeating certain elements, which is basically the one construct not supported by schema.  I think this corresponds to what JBossXB used to call "unordered sequence", which is a bit of an oxymoron

So my answer is: ?????