[wildfly-dev] Galleon layers for EJB3

[Ondra Chaloupka]

On Mon, May 4, 2020 at 10:44 AM Ondra Chaloupka <ochaloup at redhat.com> wrote:

> On Mon, May 4, 2020 at 2:11 AM 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.
>>
>
> 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?
>

I'm sorry for using a misleading word here. I meant "layered into".
My point is to split the transaction module for not bundling all the
functionality under one module and for it providing options for more
granular dependency management.



> 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20200504/b1c44b73/attachment.html