Skip to main content

Should I use EJB3 as web-services?

Posted by felipegaucho on June 2, 2008 at 1:49 AM PDT

More than a community and business event, href=''>Jazoon'08 offers you a chance to
discuss technology free of pressure. You can meet the top evangelists
and share with international developers your technical issues and
questions - a pervasive brain storm about the Java platform. Excellent
opportunity to validate your ideas on how to do better software - and
if they don't survive the community's scrutiny, you can always blame
the beers and back home with good learned lessons :).

I have my own set of (Not
So) Stupid Questions
, and the first one I want to discuss with you is
about web-services and EJB3.


Is it a good design to expose EJB3 Session Facade as

Reading href=''>patterns
and examples
on the Internet, href=''>EJB3
+ @WebService seem to be a fast and furious way to go straight to SOA
with few lines of code and a
good container
. Despite the simplicity of annotations, I
started designing an Open
Source Classifieds system
based on J2EE technologies and I have some
observations about that.

Instead of replicating here all discussions about web-services
design and its technology support, I prefer to bring you a few design
options and get your feedback live during Jazoon.

  1. Web Client -> JAXWS SOAP web-services -> Session Facade ->
    Domain Model Facade -> @Entities
  2. Web Client -> @WebService Session Facade -> Domain Model
    Facade -> @Entities
  3. Web Client -> @WebService Session Facade -> @Entities

Some considerations about the above design options:

  • If I use annotations, I am assuming SOAP web-services, right?
    And what about REST?
  • If I do expose my Session Facade directly, how can I change
    later my interface from SOAP web-service to something else ?
  • What about validation and security? My business component
    should care about data input validation and authorization and
  • Load balance and orchestration. Can I use a web server (Tomcat?) to expose the service interface and a j2ee container to do the business? What about service collaboration? The session beans will have references one to each other?

Using a same class to expose services interface and realizing
business use cases seems a bit overlapped to me, but eventually I am
missing some point here. It is up to you, see you in Z


EJB ease two interesting features to your web-service application:

  1. transactional operations
  2. interceptors - that help you to monitor your operations without using AOP

Of course you can have this features without EJBs, but it is much easier to do that through annotated beans than programatically.

well, roles are automatically cascaded between web-applications and J2EE applications in the same container, so I guess Seam does the same as the standard j2ee application does. Seam is fantastic, but regarding this detail about security, I can't see great advantage of Seam...

I will be in Zurich to discuss this in person (if we manage to find each other) but I would also like to post one insight now while it is on my mind. To answer your question regarding security, I highly recommend that you check out Seam's approach to this problem. Seam combines a security interceptor with its conversation model to create a stateful web service. The initial call establishes your credentials and any number of followup calls can use that session to execute business services with an active UserPrincipal. The nice part is all this is done with standard Java EE with Seam's solution layered on top of it. Dan Allen Author of Seam in Action

I'm interested in the answer to the questions, but unable to go to Zurich to find out. Will you post your results sometime afterward? My company is just heading toward SOA, and we have not adopted EJBs (any flavor/version) yet, but with the latest JEE it's looking more like an option, especially with web services on top of EJBs to enable multiple interfaces in the SOA. Thanks!