[wildfly-dev] Galleon layers for EJB3

[Cheng Fang]

Hi Brian,

We'll discuss it with the ejb team and get back to you.

Cheng

On Sun, May 3, 2020 at 8:10 PM Brian Stansberry <brian.stansberry at redhat.com>
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.
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20200504/197d4a9c/attachment.html