Re: [wildfly-dev] Galleon layers for EJB3

On Mon, May 4, 2020 at 2:11 AM Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > Hi Cheng and Tomek and anyone else on wildfly-dev, > > > One of the main things I'm hoping we can do for WildFly 20 is get a > first-cut (perhaps tech preview) implementation of bootable jar support. A > big part of the bootable jar story is the user using Galleon during the > build of their application + server jar to produce a server customized to > their requirements. The key thing that makes that usable is having Galleon > layers for the functionality they want. > > EJB is a big part of our functionality and we don't have layers for it > yet, so I'd like to get started on adding some. I've been thinking some > about what that might look like. > > A bit of context: a layer is a form of API, in that once we support a > layer, if users use it to get some functionality, in the future they should > be able to continue to use that layer and get that same functionality. So > before introducing a layer we should be sure it does what we want, and also > that it doesn't by mistake do 'extra' things that we couldn't remove in the > future. > > Our EJB subsystem provides a wide variety of features, and I can think of > a great number of use cases where users might want just some of them (say > local SLSBs only) and would like a slimmer server without the rest. It > would be great if in the future we could provide a number of layers to help > with that. But for the first cut at this I think we should keep it simple. > > (Also, the more layers we have the more testing permutations we need to > deal with, which is doable but takes time.) > > If a user is trying to slim their server I think of four key things they > want to do in descending order of importance: > > 1) Eliminate unnecessary open ports. > > 2) Eliminate unnecessary exposure > > 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. > > https://github.com/bstansberry/wildfly/commits/ejb-layers2 illustrates > what the layer-specs could look like. (There's no effort there to adapt the > subsystem to require fewer deps; it's just illustrating the config > generation aspects.) > > 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. > Hi Brian, I'm thinking longer about making the transaction manager module more granular and especially to make it possible to split the JTA in-VM non-IIOP operations from the IIOP version. I assume this could be quite beneficial for the footprint improvements especially in connection to these EJB changes, right? I need to investigate more on technical details but I think transactions could be stripped of at least three modules of JTA (non IIOP), JTS (JTA + IIOP) and CDI transactional handling. How beneficial would you consider such stripping of the transaction subsystem?

Ondra > 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? > > Best regards, > > - Brian > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev