Re: [jakarta.ee-community] About Profiles / Servlet API

[Mark Little <mlittle@xxxxxxxxxx>]

I could argue this either way given how I've seen customers and
community use JBossAS over the years but putting my "no JAX-RS or
friends in the Core" hat on for a second, you could always say that no
matter what we do there's always implicitly the low level UDP/TCP
stacks provided by the JVM available to the Core developer should they
somehow feel they only want to use it, e.g., if there's a need for a
bootstrapping/handshake effort within whatever application they're
building.

Mark.

On Wed, May 23, 2018 at 6:56 AM, Ondrej Mihályi
<ondrej.mihalyi@xxxxxxxxxxx> wrote:
> To be honest, no, I don't think that any network API should be part of the
> core, at least not initially. I think that the core should be used in any
> usecase therefore I suggest including only cross-concern functionality
> (config, security, etc.) I see the core profile as just a common base for
> other profiles and not as a separate profile for building applications.
>
> Best regards,
> Ondrej Mihályi
> Senior Payara Service Engineer
> Payara Server – Robust. Reliable. Supported.
> E: ondrej.mihalyi@xxxxxxxxxxx | T: +1 415 523 0175 | M: +421 902 079 891
>
>
>
> Od: Guillermo González de Agüero
> Odoslané: utorok 22. mája, 21:38
> Predmet: Re: [jakarta.ee-community] About Profiles / Servlet API
> Komu: Jakarta EE community discussions
>
>
> This sounds pretty balanced. Do you see space on that core for a low level
> network api like Markus suggests? Or could it eventually interfere with e.g.
> a serverless profile?
>
> El mar., 22 may. 2018 16:25, Ondrej Mihályi <ondrej.mihalyi@xxxxxxxxxxx>
> escribió:
>
> I agree that it makes sense to define what's Core and Complete profiles,
> though it may not make sense to use just Core or all of Complete to build
> and run applications. Rather, I think about them as a reference to be used
> for other profiles. All profiles should share core principles (Core
> profile). The Complete profile would define how all individual components
> should integrate, e.g. in case we want to combine 2 or more profiles or
> assemble a custom profile.
>
> The Core should really be just core, with only general-purpose components
> like DI (a subset of CDI), Config, Security, Testing, Logging, etc. There's
> no point in adding Servlets or JAX-RS or even asynchronous processing into
> the Core as it may not fit all use cases.
>
> On the other side, the Complete profile wouldn't be meant to be used in
> production and maybe only the RI would implement all of it. Most of the
> other implementations would be of a specific profile or multiple profiles
> for the usecases they aim at.
>
> Cheers,
> Ondrej Mihályi
> Senior Payara Service Engineer
> Payara Server – Robust. Reliable. Supported.
> E: ondrej.mihalyi@xxxxxxxxxxx | T: +1 415 523 0175 | M: +421 902 079 891
> ----------------------------------------------------------------------------------------------------------------------
> Payara Services Limited, Registered office: Unit 11, Malvern Hills Science
> Park, Geraldine Road, Malvern, WR14 3SZ
> Registered in England and Wales: 09998946 | www.payara.fish |
> info@xxxxxxxxxxx | @Payara_Fish
> From: jakarta.ee-community-bounces@xxxxxxxxxxx
> <jakarta.ee-community-bounces@xxxxxxxxxxx> on behalf of Richard
> Monson-Haefel <rmonson@xxxxxxxxxxxxx>
> Sent: 22 May 2018 13:54:56
>
> To: Jakarta EE community discussions
> Subject: Re: [jakarta.ee-community] About Profiles / Servlet API
> I can see profiles that would not benefit from the Core, whatever that is,
> but then what is the platform we are defining?  Is it simply a collection of
> specifications for which there is no common foundation (other than Java SE)?
> I don’t think that could be called a platform, do you?  What is a platform?
>
> The other side of this coin is the “Full” or “Complete” profile.  It has
> been suggested that the Complete Profile be a specification that bundles all
> of the specifications together and defines how they interoperate - all of
> them together.  At first I thought this was over kill, but it’s actually
> another way to define the platform.
>
> Imagine that there was no Core and there was no Complete profiles. Instead
> their is a “Legacy” profile that captures the legacy Java EE platform and
> then a bunch of independent profiles like Reactive Streams, Web, REST, IoT,
> etc.
>
> Now, as a user or a vendor I want a Reactive Streams profile combined with a
> Legacy Profile.  How are cross cutting concerned handled if security and
> transactions, for example, are not defined consistently across Reactive
> Streams and EJB, JMS or CDI?  How do I use them in combination in a way that
> is portable?
>
> The argument for a Complete Profile is that: any new specification should
> automatically be compatable and be included in the next version of the
> Complete profile, so that portability when combining different
> specifications isn’t an issue.  The argument for a Complete Profile makes
> sense if you want to ensure portability across the entire Jakarta EE
> ecosystem.
>
> The Complete Profile other side of the platform coin from Core.  I don’t
> know if you can have a platform without one or the other, but I’m very open
> to hearing otherwise.
>
>
> On Tue, May 22, 2018 at 5:45 AM Ian Robinson <ian_robinson@xxxxxxxxxx>
> wrote:
>
> If we're going to set up JakartaEE to be a platform for the next 20 years
> then we're going to have to do some wildly different things alongside
> supporting what got us here in the first place. Profiles may be a way to
> help with that but not (in my opinion) if we restrict the way we think about
> them as being simple concentric circles around a single core. Different
> style of programming are going to need  different profiles (defined sets) of
> technologies that may share some in common without necessarily having to
> have a single common minimum set of core technologies in all profiles.
> Reactive streams are a good example. The servlet spec (for example) is
> important to JakartaEE full and web profiles but doesn't need to be part of
> some future JakartaEE ReactiveStreams profile (if we worked on such a
> thing). It would still be part of the profiles for which its relevant
> including the full profile.
>
> I see near universal agreement that the the JakartaEE full profile will
> remain important, and it will grow. If we get new and smaller profiles right
> then they can support platform innovation without having to drag everything
> forward at the pace of the oldest. So I agree with James' final sentiment by
> thinking about it without the 4-letter c word.
>
>> I think a cloud native Jakarta EE is one that treats servlets as an option
>> chosen for the right use cases, not as a default in the core.
>
> Regards,
> Ian
>
> Ian Robinson
>
>
>
> From:        James Roper <james@xxxxxxxxxxxxx>
> To:        jakarta.ee-community@xxxxxxxxxxx
> Date:        22/05/2018 03:54
> Subject:        Re: [jakarta.ee-community] About Profiles / Servlet API
> Sent by:        jakarta.ee-community-bounces@xxxxxxxxxxx
>
>
>
> Not sure where to put this reply since the thread seems to have split a
> couple of times, but to clarify my original suggestion.
>
> When I say synchronous communication, I'm not referring to IO. Whether the
> servlet API is blocking or not is not a consideration to me at least in
> whether it should be part of the core. Rather, the question is whether
> synchronous communication - ie, request/response, where both parties in the
> communication need to be actively participating in the communication for it
> to succeed, where one party being down leads to the other unable to proceed,
> synchronous communication is what I don't think should be in the core. The
> servlet API is inherently synchronous, if a client tries to send a message
> to a servlet, and the servlet isn't running, is overloaded, or is failing,
> the servlet won't get that message later when the problem is fixed, this is
> because it is based on synchronous (dictionary definition "at the same
> time", ie, both parties active at the same time) communication, whether it's
> using non blocking IO or not.
>
> The alternative, asynchronous communication, which typically uses message
> brokers as an intermediary transport, does not require both parties to be
> participating at the same time, so the sender can send the message
> regardless of whether the receiver is able to receive it at that time. In a
> world where deployments now consist of tens, hundreds even thousands of
> services, requiring all services to be running at the same time, which
> synchronous communication does, leads to a system that is fragile and far
> worse than a monolith. Hence, asynchronous communication is imperative in
> this world of cloud native services.
>
> I'm quite aware that Servlets aren't tied to HTTP, but they are tied to
> request/response, and this is the issue.
>
> I anticipate that in 5 years, most backend services will primarily just use
> asynchronous communication - the primary places that will use synchronous
> communication will be services that directly face users, where users need a
> timely response to their requests. In many architectures today, this is
> already the case.
>
> That's not to say Servlets are ever going to go away - it's not an either
> or, both synchronous and asynchronous communication are needed in all
> systems. But the current situation, where synchronous is the primary means
> of communication, reflected by the fact that the servlet spec is in the
> core, is coming to an end, and it's cloud native that is signalling the end
> of that. I think a cloud native Jakarta EE is one that treats servlets as an
> option chosen for the right use cases, not as a default in the core.
>
> On Tue, 22 May 2018 at 04:15, Werner Keil <werner.keil@xxxxxxxxx> wrote:
> You are aware that each of these standards are defined elsewhere (e.g.
> OASIS) therefore it is important to separate the specs (if you propose
> something underneath MQTT or AMQP this is simply the wrong place) and
> implementing solutions (this is what can be shaped or influenced here)
>
> Werner
>
>
> On Mon, May 21, 2018 at 8:05 PM, Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:
> JMS is for applications accessing MOMs, which in turn use AMQP/MMQT.
> What I proposed is a layer UNDERNEATH AMQP/MMQT.
> -Markus
>
> From: jakarta.ee-community-bounces@xxxxxxxxxxx
> [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx] On Behalf Of Werner Keil
> Sent: Montag, 21. Mai 2018 19:47
>
> To: Jakarta EE community discussions
> Subject: Re: [jakarta.ee-community] About Profiles / Servlet API
> Of course   AMQP / MMQT are message-based, so they are by nature closer to
> e.g. JMS.
> I can't say, what the just forming EE4J Messaging/JMS project might like to
> do about this, but having worked in a cross-cut between MQTT and JMS for
> major clients, I see potential for synergies between EE4J and IoT especially
> now they are both under the Eclipse umbrella
>
> Werner
>
>
> On Mon, May 21, 2018 at 7:37 PM, Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:
> I also thought so but in fact Servlet API only works for request-response
> communication models, which is not given for at least UDP, AMQP and MMQT.
> IMHO you cannot implement AMQP / MMQT ontop of Servlet API.
>
> -Markus
>
> From: jakarta.ee-community-bounces@xxxxxxxxxxx
> [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx] On Behalf Of Richard
> Monson-Haefel
> Sent: Montag, 21. Mai 2018 18:23
> To: Jakarta EE community discussions
> Subject: Re: [jakarta.ee-community] About Profiles / Servlet API
> I’m not up to speed on everything Servlet, but I do like the idea of
> breaking it up so that you have an HTTP specific Servlet and a more general
> Servlet programming model that can be extended to the semantics of other
> application protocols.  I think, to some degree, this already exists its
> just a matter of the Servlet provider supporting the stack desired (e.g.
> UDP/TCP/SCTP) and then having a higher level programming model for each
> application protocol (e.g. HTTP, AMQP).
> On Mon, May 21, 2018 at 11:07 AM Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:
> I'd like to extend this idea by a new API for the UDP/TCP/SCTP layer: It
> might be useful to build the HTTP API layer (= former Servlet API) ontop of
> a new UDP/TCP/SCTP API layer which allows Servlet engines to replace the
> underlying transport technology easily. That API could wrap micro-servers
> dealing solely with data packets instead of application protocols. So not
> only HTTP would run ontop of that, but also AMQP or MQTT or even FTP. The
> bean driven by such a system would be a "Stream-let" or "Protocol-let" for
> example. So re-implementing the Servlet API would mean to write a
> "HttpProtocolLet", AMQP would use an "AmqpProtocolLet" etc. In the
> IoT-Environment this could be beneficial, and it would simply re-use the
> technical platform already existing e. g. in Grizzly.
>
> -Markus
>
>
> From: jakarta.ee-community-bounces@xxxxxxxxxxx
> [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx] On Behalf Of arjan tijms
> Sent: Montag, 21. Mai 2018 17:58
> To: Jakarta EE community discussions
> Subject: Re: [jakarta.ee-community] About Profiles
>
> Hi,
>
> On Mon, May 21, 2018 at 3:12 PM, Ondrej Mihályi <ondrej.mihalyi@xxxxxxxxxxx>
> wrote:
> I think that James didn't mean to toss out HTTP processing but that the
> servlet API isn't well suited for reactive processing. The Servlet spec is
> also huge, comparable to EJB and could be designed and split into multiple
> specs. Or even obsoleted by another more modern spec in a similar way as CDI
> is now obsoleting much of the EJB spec.
> I don't quite see the Servlet spec being deprecated / obsoleted, like EJB
> was.
> I do like the suggestion of splitting out the Servlet spec in parts.
> Specifically we could potentially have a core HTTP engine (like Netty,
> Grizzly, and Coyote), a "bare" Servlet API layer, and something like a
> higher level CDI based layer (making a simpler Servlet that's a proper CDI
> bean).
>
> Kind regards,
> Arjan
>
>
>
>
>
> Cheers,
> Ondrej Mihályi
> Senior Payara Service Engineer
> Payara Server – Robust. Reliable. Supported.
> E: ondrej.mihalyi@xxxxxxxxxxx | T: +1 415 523 0175 | M: +421 902 079 891
> ----------------------------------------------------------------------------------------------------------------------
> Payara Services Limited, Registered office: Unit 11, Malvern Hills Science
> Park, Geraldine Road, Malvern, WR14 3SZ
> Registered in England and Wales: 09998946 | www.payara.fish |
> info@xxxxxxxxxxx | @Payara_Fish
> From: jakarta.ee-community-bounces@xxxxxxxxxxx
> <jakarta.ee-community-bounces@xxxxxxxxxxx> on behalf of Richard
> Monson-Haefel <rmonson@xxxxxxxxxxxxx>
> Sent: 21 May 2018 16:03:00
> To: Jakarta EE community discussions
> Subject: Re: [jakarta.ee-community] About Profiles
>
> James,
>
> I think you have missed something in the Servlet programming model. While
> its primarily used for HTTP requests its not bound to that model or even
> synchronous request/response messaging.  Reactive Streams could work well
> within the Servlet model or form another programming model.  If I’m wrong
> than Serlvets have changed more than I thought since I used them for pure
> TCP/IP processing back in 1998.
> I’m an advocate of Reactive Streams as a new
> programming/processing/messaging model, but it would be premature to toss
> out HTTP processing and Servlets in order to embrace Reactive Streams as the
> “one true” model.  Having been around for a long time I can tell you that
> today’s silver bullet often becomes tomorrows legacy nightmare.  I’ve lived
> through that transition at least a dozen times.  There is no “one true”
> model. There is only those options that most useful now.
> I don’t believe that is the fate of Reactive Streams to become legacy, but
> at this point its not a widely adopted programming model and I think we need
> to serve the needs of the mass majority of developers who use HTTP and
> Servlets IN ADDITION TO introducing and supporting new methods like Reactive
> Streams.
> I would not make Reactive Streams a required part of the Core at this point,
> but as Reza pointed out the Core can evolve over time just as well as any
> profile.  If Reactive Streams is introduced as a Specification and wrapped
> into a Profile on top of the Core, it could remain very lightweight while
> providing a powerful programming model for those interested in that
> paradigm.
> On Sun, May 20, 2018 at 9:18 PM James Roper <james@xxxxxxxxxxxxx> wrote:
> Are servlets really necessary in the core? Yes, they may have been central
> to Java EE for as long as Java EE has existed, but things are changing,
> systems can no longer be seen is a big static state store that can just be
> queried and updated with synchronous communication, rather they are being
> build using streams, where the current state is in a constant state of
> converging, but never actually getting there, and communication is primarily
> asynchronous. Look at things like Kafka Streams and AWS Lambda and Azure
> Event Grid - event based systems that are only concerned with asynchronous
> messaging are rising rapidly in popularity at the moment. And this isn't
> even that new, almost 10 years ago Heroku had both web dynos and worker
> dynos - worker dynos had no HTTP interface, and you could argue that
> deploying something that started an HTTP server to a worker dyno was
> overkill. Now is a perfect opportunity to realign Jakarta EE with current
> industry trends.
> And even for technologies that use synchronous communication, look at the
> rise of things like gRPC - this does use HTTP, but not on top of servlets.
> No one wants to deploy both a servlet HTTP server and a gRPC server, that's
> too heavyweight. Other things like gRPC may well surface, do we want the
> servlet API to get in the way of people using these new technologies with
> Java EE?
> As a counter point against requiring servlets, the MicroProfile messaging
> spec currently being developed will have no dependence on servlets, and I
> anticipate that there will be many use cases where you'll deploy services
> that use nothing but MicroProfile messaging for communication, plus a
> database.
> Perhaps as little as 2 years ago, I would have agreed, servlets are core.
> But I think there's a big shift at the moment, and a decision to make
> servlets core today could leave Jakarta EE behind.
> On Mon, 21 May 2018 at 01:16, reza_rahman <reza_rahman@xxxxxxxxx> wrote:
> You know I have a tremendous amount of respect for you, but as I suggested
> the truth is that none of this is about technical merit. Sometimes we really
> do need to just bow to where the market is driving us and not fight it. Once
> we have the technology on firmer footing is the time to explain to the
> marker why we are right. That's not now.
> The market demand from where I clearly have seen again and again is allowing
> people to start with Java EE with nothing more than Servlet and a la carte
> let them add whatever else on top. In addition there is a viable smaller
> market for one or two sensible profiles. Right now people also want fat jars
> and hollow uber jars.
> Giving people basically what we've been trying to push for years plus some
> ability to remove things or define things is yet another road to fighting
> another uphill battle that's honestly tiresome. The end result of where we
> are today should be telling us loud and clear we need to be thinking about
> these things differently going forward.
> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>
> -------- Original message --------
> From: arjan tijms <arjan.tijms@xxxxxxxxx>
> Date: 5/20/18 4:40 PM (GMT+01:00)
> To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
> Subject: Re: [jakarta.ee-community] About Profiles
>
> Hi,
>
> On Fri, May 18, 2018 at 11:30 PM, reza_rahman <reza_rahman@xxxxxxxxx> wrote:
> I am totally with Mark on these particular issues. Whatever the actual
> merits of the argument that we can argue endlessly, the reality is that
> customers cite Java EE "weight" as a reason to not adopt it with
> Docker/Cloud/Microservices, etc.
> It's true that this is being cited, although it's indeed "weight' between
> quotes. With only a few exceptions I've seen the actual weight (startup time
> / memory size / footprint on disk) of the supposedly lighter weight solution
> actually been approximately the same size or even bigger.
> People arguing that they use e.g. Tomcat because it starts in 500ms and is
> only 7MB in size, but then they add 50MB worth of libraries to /lib and an
> other 40MB of libraries to WEB-INF/lib. The combined whole being just under
> 100MB in disk space.
> As a second point, a (standard) static config + pruning tool would again
> address this concern, and I argue it can do even better than any profile
> ever can.
>
> Kind regards,
> Arjan
>
>
>
> Additionally I believe other than minimizing endless conflict with Spring
> folks over CDI, making clear what Java EE is and how well adopted/not it is,
> a Servlet only core is also the right answer to combat the criticism that
> Java EE is fat.
> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>
> -------- Original message --------
> From: Mark Little <mlittle@xxxxxxxxxx>
> Date: 5/18/18 3:47 PM (GMT+01:00)
> To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
> Subject: Re: [jakarta.ee-community] About Profiles
>
> On 18 May 2018, at 14:40, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
>
> Hi,
>
> On Thu, May 17, 2018 at 1:46 PM, Mark Little <mlittle@xxxxxxxxxx> wrote:
> This isn’t just about vendor choice. You are certainly not alone in being
> happy with the full profile option. However, there are other classes of
> users/developers that aren’t and these have existed since the dawn of J2EE.
> For example, some people want to deploy their favour app server on to
> constrained devices which may be running on the cloud where an additional
> 50MB costs real money when run for hours or days or weeks or longer.
> I wonder, is there in practice any service / device where a mere 50MB of
> disk space makes all the difference?
> You mean apart from cloud (yes, those 1 cent costs do add up, and there’s
> private cloud deployments of which you may be unaware and have some funky
> architectural choices behind them), IoT? Oh and maybe it’s not just 50MB but
> some modern implementations can still be a bit “plump” in some areas ;)
>
> Some developers want to reduce the maintenance complexity or boot time of
> their favourite app server by stripping out those capabilities they don’t
> want.
>
>
>
>
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
>