3) Eliminate jars, both to save filesystem footprint and to reduce any theoretical attack surface.
4) Reduce configuration clutter and unnecessary services.
Given that I suggest we have the following layers:
1) ejb3-lite. This is like what we provide in standalone.xml, but without the MDB instance pool or the remote connector resource. (A webservices layer would depend on this.)
2) ejb3. Builds (i.e. depends) on ejb3-lite and adds the discovery subsystem, the MDB pool and the remote connector resource. This looks what we provide in standalone-full.xml, except no IIOP integration.
3) ejb3-iiop. Builds (i.e. depends) on *ejb3-lite* and adds the iiop subsystem plus the integration resource in the EJB3 subsystem. This *could* depend on *ejb3* instead, but that means EJB is unnecessarily exposed over the HTTP interface and a lot of dependencies are brought in for messaging integration.
A user could provision ejb3 + ejb3-iiop and get the equivalent to what's in standalone-full.xml.
There'd be a couple ancillary layers as well:
4) ejb-local-cache. This provides the infinispan subsystem resources related to local ejb caching (i.e. the ones in standalone.xml and standalone-full.xml.) The ejb3-lite layer *optionally* depends on this. It's an optional dependency because the user when provisioning can *exclude* this layer and instead provision...
5) ejb-dist-cache. This provides the infinispan subsystem resources related to distributed ejb caching (i.e. the ones in standalone0ha.xml and standalone-full-ha.xml.)
This pattern of "exclude an optional local caching layer and add a distributed variant" is how web session and jpa caching are handled in the layers for those features.
I think the main work here (besides testing) would be examining what if any module dependencies in the org.jboss.as.ejb3 module could be made optional.
TBH I don't see big FS footprint improvements coming out of these permutations. Big EJB dependencies include (in no particular order.)
a) IIOP. But the TM uses IIOP libs so they will be there regardless.
b) Remoting. It would be nice to be able to eliminate the need for remoting, e.g. for ejb3-lite if the user app isn't a remote ejb client. But that doesn't seem trivial and if a server is manageable remoting will be there anyway to support the CLI.
c) JCA stuff. But if there's a datasource it's there anyway.
d) Infinispan. A benefit of a future SLSB-only layer would be this dep could be eliminated. (But it might be used for web caching etc anyway.)
e) Remote artemis integration. This we do save if ejb3-lite is used.
The general testing strategy we've been doing as we've developed layers is in testsuite/integration/smoke and basic we provision a server with a particular set of layers and then add a surefire execution that runs a subset of the tests that can work against the features in that server. That hasn't been too painful.
WDYT?
- Brian