Java EE in Embedded and Micro Avatars
Java EE in Embedded and Micro Avatars
Payara Micro allows you to launch an instance from the command line without really setting up an application server.
Join the DZone community and get the full member experience.Join For Free
I was reading up on Payara in general and was pleased to see them release a Micro version – which essentially enables you to launch Payara from command line [ java -jar payara-micro.jar ] without really setting up the entire application server. Basically, the payara-micro.jar IS your application server – it’s just that it can now fit in your pocket! More details on the Payara blog
Payara also offers embedded versions, both, Full Java EE 7 profile as well as the Web Profile.
I was wondering about …..
The Differences b/w Payara Micro and Payara Embedded
Payara Micro can be run in both embedded mode as well a CLI [ fat JAR from command line ] mode but the embedded versions need to be invoked from within another Java class .
I think the the micro version is cool but the embedded version also allows for some flexibility in terms of being able to bootstrap some configurations .. (and several other use cases maybe ?). Payara Micro is supposed to be implementing Java EE Web Profile with some additional functionality on top of it (as per blog post content). From what I observed, it offers Concurrency Utilities and Java EE Batch API as well (these are not required as part of Java EE Web Profile spec). Are there other differences? When should I use micro over Embedded Java EE Web Profile version ? Not quite sure
What positives can one extract out of these embedded and micro Java EE avatars?
I know micro services are all the rage today but I am not knowledgeable to comment regarding them. Think of it this way – you have been itching to use Java EE 7 and found it to be perfect fit for that project at your workplace. But as usual, the sticking point is considering things like getting hold of a compliant application server (the runtime/container) – you might not be allowed to use that fancy piece of technology called Java EE 7 yet ! Your ideas crash [true story ;-)].
I think that’s about to change now. If you want to build that app where you can leverage all the Java EE goodies starting from EJB, CDI, REST to fancy stuff like Web Sockets and SSE, well just keep calm and build you WAR ! Don’t worry about the container – you need not procure an Application server and convince the entire management/architects etc. Now, the compliant runtime / container is just a simple JAR. Its more about creating the functionality and making it available for consumers rather than debating about app servers, compatibility, certification matrices etc.
Cloud…? What About Cloud!
Not that tough! Imagine this – if you wanted to deploy a Java EE 7 application on cloud, you would need a PaaS provider which has support for Java EE 7 container (e.g. OpenShift). That’s fine. But do you realize that with a JAR as your application server, you do not really need to worry about a PaaS? Actually, all you need is IaaS (the infrastructure) e.g. a linux box with adequate RAM, disk etc should be enough to install Java and fire java -jar myappserver.jar … right ?
Testing and Rapid Prototyping
This one is a no brainer. Just like Embedded EJB containers made it simpler to test EJBs in isolation, having a pocket sized app server JAR should ease testing as well as rapid development/prototyping. Open up an IDE (preferably Netbeans), write your business logic, build your WAR and your are ready to rock
java -jar payara-micro.jar –deploy /home/abhi/Netbeans/MyJavaEE7App/dist/MyJavaEE7App.war
I am probably being optimistic right now. There will definitely be issues, caveats and cons when it comes to embedded/micro Java EE approach [I am sure the experts are at it right now !], but hey, guess I am too excited to think about them. I will discover some when I play around a little more :-)
Don't Forget Wildfly Swarm!
Until next time…
Published at DZone with permission of Abhishek Gupta , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.