> To me it makes the most sense in the scenario of exposing the back-end
> service layer directly instead of getting yet another layer involved
> (I'm not sure WebBeans would be use for service tier implementations).
It depends of what exactly you mean with "back-end service layer". Exposing
JPA entities or JDBC ResultSets wouldn't make much sense, since those are
much more fine-grained than a relativeley coarse RESTful interface (JPA/JDBC
deal with entities a.k.a tables, while REST deals with views on [possible
combinations of] them). But if you mean "one session bean is one resource",
then I would agree.
> I think for most EJB 3 users, the CORBA interoperability part is just a
> historical curiosity, although I am sure a lot of effort is spent on
> this on the vendor end.
Actually I would not select services, but instead just say that a SB *is* a
JAX-RS resource -- with ALL its functionality. That means, if somebody wants
to use CORBA (yes, there are people still doing that), they can do it,
still. Actually from an architectural view, it looks like this: The session
bean's implementation class is triggered via three possible interfaces: The
remote interface by IIOP or JRMP, the local interface by simple Java
invocation, and the REST interface, by simple HTTP invocation). In fact, the
JAX-RS resource itself should be the SB, while the annotations will create a
servlet "around" it dealing with HTTP.
Regards
Markus