Tag Archives: java ee


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

Setting the endpoint for web services

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

Things that make me facepalm on JEE development

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

Implementing JASPIC in the application

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

JPA annotation processing

Previously I had defined how I would design domain objects with JPA. One of the things I had noted was the notion of a table model that encapsulates persistence operations. The table model is pretty much common and although some things can be done by generics, some things such as named queries cannot and require the use of strings. However, a pattern can be followed for the names combines with Java annotation processor be used to create code that would reduce the use of strings for users of the class.

This post discusses how I would build an annotation processor that takes advantage of JPA entity definitions to create support classes that avoid strings in user code.
Continue reading JPA annotation processing