[wildfly-dev] Galleon layers for EJB3

[Brian Stansberry]

On Wed, May 6, 2020 at 9:26 AM Cheng Fang <cfang at redhat.com> wrote:

> This is what we (ejb team) think after discussion.  Brian's analysis in
> this thread seems pretty comprehensive and well thought out, and covers the
> majority of use cases of customized ejb subsystem. We are new to Galleon
> but will be working on it as per the above analysis.  Also given that we
> are close to code freeze, we don't have an accurate estimate of what can be
> done in this release.
>

Apologies for taking so long to write that up. It's quite late for 20 (tbh
later than I realized) and I don't want to create pressure to add things in
a rush. My first post here wasn't worded well re that, so please don't
worry about cramming things in.

Please feel free to ping Yeray Borges or I if you have questions.


> Richard mentioned that a few places in ejb3 subsystem will need to be
> improved to use capabilities to declare external dependencies, and he will
> be working on that to prepare for Galleon configuration.
>

I found the old branch I mentioned to Ondra, and I see it had a bit of
capability stuff in there related to EJB-IIOP. (I believe because the
JTS<->IIOP stuff involved capabilities and I probably tossed in EJB-IIOP as
a thought experiment:

Anyway, here's that branch:

https://github.com/bstansberry/wildfly/commits/jts-iiop

It's fairly out of date.


>
>
> On Mon, May 4, 2020 at 1:20 PM Cheng Fang <cfang at redhat.com> wrote:
>
>> 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
>>>
>>
BTW, I didn't complete this sentence: I meant to say "Eliminate unnecessary
exposure over shared sockets."  Typically with WF that would mean 8080.

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

-- 
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/20200506/ee3c77a5/attachment.html