How can one prevent passing exceptions over an EJB-Webservice?

Question

Hello,
I would appreciate if someone could give me some advice on the following. I tried to google it/use the search function, however, it was quite hard finding a precise search term.
Let me try to explain the setting conceptionally without much code first.
Three stateless session beans - let's call them BeanA, BeanB and BeanC - perform some specific tasks. Especially, they are using JPA to create and manipulate persistent entities. Clients like graphical user interfaces access these beans. I call them internal clients because they belong the same company like BeanA, BeanB and BeanC. Internal clients can know how to handle exceptions which are thrown in the beans.
However, the functionality of these beans is also relevant to external clients, for example another company. A webservice (WebserviceBean) combines the functionality of the three beans and communicates with the external client. The latter one must not receive any exceptions thrown in my EJB application as this could leak implementation details but they must be informed, that the task could not be performed (some kind of "Please try again later"). As far as I understood (also tested it), JAX-WS takes exceptions and turns them into SOAP-Faults.
My first (naive) approach was to do something like this
Webmethod of the WebserviceBean (
public ReturnType doWebserviceFunctionality(ParameterType parameter) {
   try {
      beanAinstance.doWork();
      beanBinstance.doMoreWork();
      beanCinstance.doFinalWork();
   catch(SpecificException se) {
   // Map specific exception to ReturnType.specificError
   } catch(Exception e) {  // Bad practice, I know
   // Map general exception to ReturnType.encounteredInternalError
}In every bean's method as well as in the webservice, I am using Container Managed Transactions (default setting REQUIRED).
The problem is, that doMoreWork() uses an entity with a versioning attribute (@version) in order to support optimistic locking. This works quite well, however, whenever an OptimisticLockException is thrown, it does not get caught in WebserviceBean and is passed on to the client. I think this is because the complete transaction is commited at the end of doWebserviceFunctionality. I am aware that I could use EntityManager's flush method in bean B in order to catch the OptimisticLockException. However, I am trying not to interfere with transaction commiting as far as possible and furthermore, I am not quite sure, if there could be other exceptions (for example JPA exceptions) which could get thrown in a similar way and are passed on to the client.
Does anybody know a possibility to solve this problem? Do I have to use bean managed transactions? Or mark doWebserviceFunctionality as not part of an transaction and put the bean method calls in a seperate method which commits at the end and allows me to handle exceptions? Or is there a completely different approach necessary?
Any help is appreciated, thanks in advance,
BKelso

Answer 1

Hello to all,
thanks again for your suggestions which proved to be valueable hints!
I'll tell you so far the lessons I've learned.
1) Using interceptors (suggested by malrawi)
This would have been a very nice solution, however, it turns out that the problem remains - the exception thrown by the container after the commit is not caught. Here is the code I used
    @AroundInvoke
    public Object convertException(InvocationContext ctx) throws InternalErrorException {
      try {
         return ctx.proceed();
      } catch(Exception e) {
         // just tried to throw another exception here in order to see if it works
         throw new InternalErrorException("Internal Error occured. Please try again later.");
    }2) Using bean managed transcations (suggested by zsom)
This worked out as I thought it would. The webservice starts and commits the transactions, beanA, B and C can still keep the default CMT Attribute. However, when ut.rollback() is called, an IllegalStateException is always thrown. Don't know why so far, the transaction seems to be set back anyways.
@Resource SessionContext ctx;
public ReturnType doWebserviceFunctionality(ParameterType parameter) {
UserTransaction ut = null;
      ut = ctx.getUserTransaction();
      try {
         ut.begin();
         ut.commit();
     } catch (Exception e) {
         try {
            ut.rollback();
            // map exception...
         } catch (Exception rollbackException) {
            // also map exception to return type
}3) Upon the suggestion by malrawi using NotSupported transaction attribute in order to force a commit, I came up with the following: The webservice method uses this transaction attribute while simply calling another local stateless session bean (beanZ), which does the actual work (calling beans A, B, C). It uses the default transaction attribute (Required). This works out perfectly at the cost of an additional bean. But maybe you see some other downsides? Essentially it's the same as the idea with the internalMethod made public and using another transaction attribute.
// web service class
public ReturnType doWebserviceFunctionality(ParameterType parameter) {
   try {
        beanZinstance.doActualWork();
   catch(Exception e) {  // Map exceptions here
// bean Z class
public ReturnType doActualWork(ParameterType parameter) {
       beanAinstance.doWork();
      beanBinstance.doMoreWork();
      beanCinstance.doFinalWork();
}4) Using soaphandler (suggested by zsom)
This seems like a good idea but it is also the most complicated and a bit more low-level. But I will check it out in more detail, I think.
Thanks again for your efforts and I still appreciate any feedback!
BobKelso