One of the major advantages of Java EE is standards support, Unfortunately, let’s face it, the reality of implementations out there especially the ones that are in the “free for casual development” zone are piss poor.
I wrote up a Java EE application that tries to test as many standards as possible to see how well the following servers will fare:
- WebSphere Classic
- WebSphere Liberty Profile
Continue reading Java EE Standards my foot
The TL;DR version: JAX-WS is meant for XML based web services such as SOAP. JAX-RS does not have the same restriction.
JAX-WS is generally geared towards server to server interactions with well defined contracts (WSDLs) and usually when the service and client side are from separate groups. It is very resource intensive so it isn’t feasible for client-to-server interactions where the network or client device capability is less than optimal.
JAX-RS is geared towards client to server interactions, although server-to-server is okay. As it has little service obligations, it can be tuned to whatever the client needs are.
Continue reading JAX-WS vs JAX-RS
When developing using web services, we tend have different endpoint URLs for development, test and production. When developing Java EE apps, the best practice is to separate environment configuration from the application to the deployment process (a pattern I rarely see in practice unless already architected in like Curam).
In terms of facepalm moments is when I see an application try to manage the connections to the web services rather than letting the container do it.
Continue reading Setting the endpoint for web services
Java EE 6 has been around since Dec 10, 2009 and has been supported by one of the slowest-to-implement-standards application servers, WebSphere since version 8 on 17 Jun 2011. That’s a good few years now and it is established even in the slowest to change enterprises. Every iteration of Java EE promotes the movement of code away from the application to the container to reduce the amount of code that needs to be managed by your development team.
Unfortunately, changing things around does take effort so for the most part I don’t really agree with taking advantage of the latest unless it’s a clear rewrite from scratch. However, that does not prevent people from still doing the same mistakes over and over again which will make me facepalm when I see things, here’s a compilation of them.
Continue reading Things that make me facepalm on JEE development
One of the nice things about JASPIC is it does not have to be limited to just a container installation, but can be put as part of the application. One of the key advantages of this over web tier solutions such as Shiro-Web is the authentication subject can be passed all the way down to the EJB tier via
@Inject Principal .
However to do this is a bit tricky, JASPIC isn’t really as straight forward and one key information is buried deep inside the specs and not immediately visible in the Javadocs.
This blog post assumes the reader to have gone through the motions of creating a ServerAuthModule. The purpose of this is to somehow call the initialize() method with the settings.
Continue reading Implementing JASPIC in the application