Hi,
On Sat, Jan 24, 2015 at 11:48 AM, Antonio Goncalves
<antonio.goncalves_at_gmail.com> wrote:
> We can't keep on saying "Java EE is just for fat *real*
> application, use something else for your IoT developments".
I strongly agree with this.
This comes up often in discussions about Java EE; the idea about
*real* applications or the *one and only right way*.
In that vision, which originated in J2EE, there's always a somewhat
untrusted team of developers and a trusted team of Ops. The
Application Server is installed once, and developers are not even
allowed near it. The Ops team maintains the server and all
"resources", such as data sources, JMS destinations, thread pools and
security modules. The developers are not allowed to create any of
those resources themselves, and *at most* are allowed to put a comment
or readme.txt somewhere, which the Ops team is then to interpret in
some way (which is a often brittle) and if the team is lucky, create
the resource in the right way (and if the team is unlucky, weeks or
even months of creating tickets can be needed to get a trivial task to
be done).
Nothing can ever be upgraded in this vision, since there are always at
least 10 totally different applications running on said AS, and it's
always impossible to update or test at least a few of those. IMHO the
idea that "Java EE can't be upgraded" has its roots in this vision.
The vision also talks about roles like bean providers, application
assemblers, application deployers etc.
Even if there are indeed places that work like this, it's by far not
the only way. Indeed, for IoT deployments, where I have a lightweight
AS with a small app for home automation deployed to a raspberry pi,
this somewhat mandatory assumed division of roles does not make any
sense at all. In that case there is no untrusted developer and trusted
ops, since there's only me. There's no need to define a data source
outside the application and provision a database for which the
password needs to be hidden from the untrusted developer, since
there's only a tiny embedded H2 database, etc.
It's funny perhaps that IBM, which is maybe most known for its very
large WebSphere installations and its many tools for supporting the
mentioned old J2EE vision, is also the one creating a lightweight Java
EE runtime (Liberty) that does focus greatly on being suitable for
IoT. See e.g.
https://developer.ibm.com/wasdev/blog/tag/raspberrypi
But even for somewhat more traditional usages of Java EE, such as a
web app, the strict dev/ops division and the single installed AS is
not a given at all. At zeef.com and before that m4n.nl the AS is
basically just a library to us. We keep its source in our git repo,
and whenever anything changes to it we can deploy it just as we would
deploy an application archive (war/ear). Since we have a strict rule
of 1 application per AS and can trivially deploy a new or modified
version of the AS, it's essentially the app that owns the AS, instead
of the other way around.
Long story short; having a "java -jar javax.enterprise.Container
command" deployment model would fit a lot of alternative use cases. A
fixed monolithic installed AS that's shielded from developers is
absolutely not the only viable model.
Kind regards,
Arjan Tijms
>
>
>> On the other hand, note that the Java EE specification is composed of a
>> large number of other specifications, most of which are defined to work on
>> Java SE with few dependencies on the others. You can build a runtime by
>> combining implementations of many of these specifications. You might be
>> missing many of the common facilities defined by the Java EE platform
>> specification, but for simple applications that might be good enough.
>
>
>
> Java SE modularization is a bet on the future (create your own JVM with your
> needed modules) we must do the same for Java EE. I know it's a huge effort
> for implementors, but it's the only exit for Java EE if we want it to be
> alive in 10 years (and when I say alive, it's not about keeping old
> applications up and running, it's thinking about Java EE everywhere, in a
> Linux environment, in a mobile phone, in a fridge...). "Java EE
> specification is composed of a large number of other specifications".
> Exactly, that's why we must go further. The Java EE contract should be
> "bundle the specs you need, we make sure they all work together, link them
> all together, build your own app server, and deploy it in a chip in your
> fridge with just a java -jar javax.enterprise.Container command".
>
>
>> Obviously this will be an interesting discussion to have when we get to
>> Java EE 9. We'll be especially interested in what the Java EE vendors have
>> to say since they will bear the burden of whatever we decide.
>
>
>
> Yes, I would like to ear what vendors say. Java EE lost its momentum years
> ago, still hasn't recover from it, we must look into the future. I think
> Java EE 8 should start making some steps toward its own modularization (at
> least imposing SPIs and making sure it works in Java SE, and an umbrella
> Container API). Profiles are also a first step, but their are not enough.
>
> My 2 cents
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France