[wildfly-dev] Galleon layers for EJB3

Mon May 4 09:45:21 EDT 2020

On Mon, May 4, 2020 at 3: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?
>

It would be nice.  If I provision a webserver with datasource support and
remote management capability, the disk footprint is ~ 74MB. Of that about
4-4.5 MB looks to be due to the ORB-related modules, primarily
javax.orb.api.

So cutting that out doesn't change the world but it's one of the bigger
chunks and probably the biggest that has no intuitive relationship to what
the server's intended feature set.

Semi-tangent -- about 18 months ago I did some subsystem work related to
configuring use of JTS using a management resource instead of just an
attribute. That kind of thing would be needed to allow Galleon to know to
provision JTS-related modules, as resources can provide that kind of wiring
info to Galleon but attributes don't.  It was no big deal except some
compatibility code so the old 'attribute' style config still works. I put
that on the shelf because there was no practical use on the horizon and we
had many other priorities.  I'll dig that up and send you a link.

>
> 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
>
>

-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20200504/6f5b2b04/attachment-0001.html 