Lean service architectures with Java EE 6 - And EJB 3 in particular
My article about Java EE 6, and EJB 3.X in particular was published at JavaWorld. This article is one of the reasons, why this blog became so fluffy - I don't like duplication :-). The second part is almost completed.
I just read your article and can agree in all your conclusions.
But one thing I don't cache is the naming. Why you call components on the business logic layer "service"?
This seams to lead to some confusions.
E.g. Figure 3 shows the OrderService as boundary (aka facade). But there is a ShipmentService as a control.
So there it seams that you have two times used the postfix "Service" for two completely different components.
What exactly is now a "Service"?
Posted by Simon Martinelli on April 17, 2009 at 04:40 PM CEST #
Like the article and find it helpful and substantial.
I'd be interested in hearing more about best practices in the era of super-cheap memory and very fast multi-core processors.
Specifically, Sun defined EJB's in the era of 300 mhz servers. It made sense then to separate out the ejb server from the web server.
Now, in the era of 3ghz quad-core servers and 12gb of memory for $200, does this separation still make sense? i.e. why would anyone want to incur the overhead of network traffic and serialization and put their ejb's on a different server from the servlet container?
Is the best practice now multiple instances of integrated servlet-container/ejb-container (e.g. jboss) fronted by a load balancer (mod_jk?)?
And what about distributed caches,data grids, etc? How do these fit in with "what works best"?
Posted by billmil on April 21, 2009 at 06:57 PM CEST #
I'm using an architecture like this from almost 2 years in my projects. I'm happy to see it in an article from Adam.
BTW, I saw something like this in a code generated buy Sybase's PoweDesiner 12.
The most interesting for me was QueryParameter class - my implementation is not so good :(.
Posted by Emil Hurmuzov on April 22, 2009 at 08:16 PM CEST #
@Emil, @Bill, @Simon
the article is actually an excerpt from a book I'm currently working on. I will answer all your questions in upcoming posts. Now I'm a bit overloaded - but will return to blog (from StarBucks) more frequently soon. In meantime I tweet a bit as well: twitter.com/AdamBien
Thanks for the nice comments,
Posted by Adam Bien on April 26, 2009 at 12:06 AM CEST #
I thought your article was great, however it does not address how data is passed to the client and passed back to the server via the service layer. On updates how is the client data merged onto the persisted EJB and how is the client refreshed? How is concurrency best dealt with?
So I think there are two approaches either pass the EJB itself to the client and let the client make changes, then pass it back via the service layer for updating, or create transfer objects and pass those around.
Both these approaches require that the updated data is merged onto the persisted instance of the EJB and the version of the instance needs to be taken into account to avoid concurrency issues.
What do you think is the best approach?
Posted by Cedric Franz on May 05, 2009 at 06:35 PM CEST #