File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

HF EJB, question about page 86

 
Hanna Habashy
Ranch Hand
Posts: 532
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi:
In HF EJB page 86, There is an alternative pattern to implement an EJB.
I am confused about RemoteException.
first I have to make this clear:
1- The methods in the bean must not throw RemoteException.
2- The methods in the component interface must throw RemoteException.

In the book, BookCartBean and BookCart(component interface) implement BookCartBusiness(interface). Now where can I declear the RemoteException?
BookCart(component interface) has no methods. If I declear them in BookCartBusiness interface, then I have to throw them in the bean (wrong).

Anything I don't see here?
any help is appreciated.
 
alzamabar
Ranch Hand
Posts: 379
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Hanna Habashy:
hi:
In HF EJB page 86, There is an alternative pattern to implement an EJB.
I am confused about RemoteException.
first I have to make this clear:
1- The methods in the bean must not throw RemoteException.
2- The methods in the component interface must throw RemoteException.

In the book, BookCartBean and BookCart(component interface) implement BookCartBusiness(interface). Now where can I declear the RemoteException?
BookCart(component interface) has no methods. If I declear them in BookCartBusiness interface, then I have to throw them in the bean (wrong).

Anything I don't see here?
any help is appreciated.


The RemoteException should never be declared in the bean class. There is a reason for it. Just think what would be of local clients if the bean would declare the RemoteException...

You can declare the RemoteException in the super-interface. Although RemoteException is a checked exception, it's an exception, as in the EJB 2.0 specification is considered as a system exception (in few words when something the client didn't expect occurred). So you don't have to declare the RemoteException in your bean, it's enough if it's declared in the superinterface.

To complete the little discussion on RemoteException, this is thrown by the Container to a remote client when a RuntimeException occurred on the server. If the client is local, it gets an EJBException (which, this time, is unchecked).

HTH,

Marco
 
Manzoor M
Greenhorn
Posts: 17
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I m also studing HFEB, in my understanding

The Bean cannot invoked directly by the Client and it is not Remote and therefore should not throw any RemoteException.
 
Hanna Habashy
Ranch Hand
Posts: 532
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi:
I totally understand that the bean must not throw any RemoteExceptions. In the diagram in page 86, the bean implements BookCartBusiness, and the remot component interface extends the same interface. so, if the BookCartBusiness methods throw RemoteException to satisfy thr requirement of the component interface, then the bean must throw RemoteException as well, which violate the bean law. And if the BookCartBusiness doesn't throw any RemoteException, then the remote componont interface will not throw RemoteException, which violate the componot interface law.

I hope I made it clearer this time, you need to look at the HF EJB page 86 to understand what I mean.
 
Valentin Crettaz
Gold Digger
Sheriff
Posts: 7610
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Very good point Hanna !!

Actually, the bean class is not required to implement the component interface (7.10.2). My personal preference is to not make the bean class implement the component interface because of the following reasons:
- The component interface extends the EJB(Local)Object interface which is intended for the remote/local (container-specific) interface implementation and not the bean instance itself
- Some method calls on EJB(Local)Object are delegated to the container and not to the bean instance
- The responsibilities of EJB(Local)Object is very different from the bean ones
- If the bean implements EJB(Local)Object, you are potentially opening a security hole because you can pass a reference to the bean instance (typed as an EJB(Local)Object!!!) to another client bean. This would boil down to pass "this" to the client bean which is not allowed by the spec.
 
Hanna Habashy
Ranch Hand
Posts: 532
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Valentin,
Thank you very much for the infomative reply.
I understand your point. However, HF EJB provides this alternative model for those who are not comfortable,yet- I am one of them- with the bean not implementing the business interface.
It is just hard for me to agree with implementing the bean, which has the same methods as the component interface without implementing the interface.
I want to use an additional (replica) interface of the component interface, that doesn't throw RemoteException, and I can implement it in the bean, just to make sure that I don't forget to implement any mehtods in the component interface. However, it will be redundant work.
Any other suggestions?? Does any one have used any other models?
 
Dan T
Ranch Hand
Posts: 66
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Maybe this will be more clear.

Page 86, is an alternative way to design the architechre. Normally, we dont have a BookCartBusiness, we just put all our business methods in our BookCart. They added the BookCartBusiness because some ppl ask why the bean doesnt implement the remote componont interface (for it being Remote).

Hence, having said that, BookCartBusiness is NOT a remote interface, because it doesnt extend EJBObject, thus, does not extend the Remote Interface.
 
Valentin Crettaz
Gold Digger
Sheriff
Posts: 7610
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is just hard for me to agree with implementing the bean, which has the same methods as the component interface without implementing the interfac.

I understand but you have to remember that we are talking about component-based software engineering (CBSE) and not object-oriented software engineering (OOSE). Briefly, an EJB is a component that just happens to be implemented by using a conventional OO (as in Java) class. In CBSE, components are coarse-grained reusable artifacts that you assemble together to do some work. Components usually do not inherit from each other as it is commonly done with classes in the OOSE world. While it is natural for components to provide interfaces to the outside world, it is not always the case that the component explicitely has to "implement" (in the OO, Java sense) that interface. In EJBs, the component interface is the interface the bean provides to the outside world but it does/should not have to "implement" it explicitely. The way the component interface is implemented by the bean itself is more under the responsibility of the container that will integrate the bean and its interfaces into a whole.

I want to use an additional (replica) interface of the component interface, that doesn't throw RemoteException, and I can implement it in the bean, just to make sure that I don't forget to implement any mehtods in the component interface.
Your issue is more related to the way the EJB architecture is currently organized and to the way we develop EJBs today. If you have a quick look at JSR 220 you will see that when the EJB 3.0 specification will come out, we will not have to write those interfaces anymore, so your problem will not be a problem anymore. I agree that having to do what you do is not confortable at all but the EJB expert group has recognized that and is working on it. If you feel like doing it, please go ahead but know that this is just a yet another workaround for a technological limitation whose days are counted
 
Hanna Habashy
Ranch Hand
Posts: 532
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Valentin,
Excelente explination. Thank you very much
 
Eusebio Floriano
Ranch Hand
Posts: 237
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Hanna,
Even if your component interface extends one interface and the bean implents it just for your guarantee that the compile will check if in your bean had implemented the Business method you do not need to declare an RemoteException on bean�s methods.
It�s not just because the interface declares an exception that your implemetation must declare it.

Regards,
 
Geert Krekelberg
Greenhorn
Posts: 5
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Notwithstanding all the interesting (and fully agreeable) discussions on why not to use it, this:

It�s not just because the interface declares an exception that your implemetation must declare it.


is the answer to the original question, which I was looking for.

Thanks, Geert.
 
Valentin Crettaz
Gold Digger
Sheriff
Posts: 7610
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Like this for instance:

 
Geert Krekelberg
Greenhorn
Posts: 5
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
More like this:


Geert.
[ August 11, 2004: Message edited by: Geert Krekelberg ]
 
Valentin Crettaz
Gold Digger
Sheriff
Posts: 7610
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Either way is fine but RemoteException really belongs to the ComponentInterface and not to the Common interface.
 
alzamabar
Ranch Hand
Posts: 379
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Geert Krekelberg:
Notwithstanding all the interesting (and fully agreeable) discussions on why not to use it, this:



is the answer to the original question, which I was looking for.

Thanks, Geert.


This is what I was trying to say in my first answer. Just because the super-interface declares an exception your implementation class doesn't have to. The only limitation is that it cannot declare any exceptions not declared in the super-interface
 
Valentin Crettaz
Gold Digger
Sheriff
Posts: 7610
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is because the throws clause is not part of the method signature which is composed of (only) the method name and the ordered parameter list.
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic