I love this sentence "*it's essentially the app that owns the AS*"
Antonio
On Sat, Jan 24, 2015 at 6:00 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> 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
>
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>