yes that is what they are there for.
Also you don't even need to code the "local" stuff just access the remote and JBoss optimizes away under the covers.
ah really . that's good to know then , thanks , this will save me time from writting too many interfaces
As JBoss optimises the calls anyway I would also reccomend using the remote interfaces so that if you want to seperate the layers of your application onto different machines you can without having to change the code in the future.
Yes , thanks , I have started changing all my interfaces to be Remote interfaces . Does this mean that I could code as if I would be calling a Local interface through JNDI without having to use PortableRemoteObject ?
I would still recommend using only local interfaces for entity beans and only letting EJBs access them to ensure several things:
- They cannot be accessed by remote machines (security).
- You'll have the ability to use CMR with CMP beans.
- You create proper design where the Web tier is oblivious to data sources and operations. The EJB tier, likewise, should focus on data and business functionality, oblivious to client presentation. This design encourages modularity and reuse, among other things.
Keep in mind that remote interfaces are accessable anywhere on the network that is reachable. Local interfaces are not accessible outside the container.
I personally never access local interfaces from outside an EJB module to ensure that the remote session interfaces correctly spec the requirements of the web modules, no more, no less, so web modules can be safely distributed in any container while EJB modules truly encapsulate the "how" of the business process.
An example is an EJB module that authenticates users. The client can call it oblivious to how users are authenticated. They do not need to know that LDAP even exists, let alone if it is being used. At the same time, the remote interface methods are limited enough to ensure that it is impossible to obtain a valid session token without proper credentials.
I wish that local interfaces weren't accessible outside the EJB module because it is unnecesarily challenging to secure an EJB module from rogue or compromised processes in the same container.
If classes can have private and protected members, then why can't local interfaces have some sort of intrinsic protection?
Yes sorry forgot to specify which type of EJB I was discussing.
I had assumed that by EJB session beans were being discussed not entity beans.
I believe that the web tier should only access session beans and then by using remote interfaces.
The session beans should then access the entity beans - in this case using local interfaces as is also required for CMR.
heh yes , I should have specified that I'm trying to access Entity beans from JSP .
The particular "component" I was trying to code by using JSP - CMP Entity was a simple forum . I found that it would be the easiest to have the Forum Entities called by the JSP's so that the JSP's could also use them as their data objects . Sending them through Session EJB's would require me to writte an extra bean and probably a few data storage objects that would contain data identical to the one in the Entities , only to be passed and used by the JSP .
My initial ( but incomplete ) question was if I could use Local Interfaces to CMP Entity beans from JSP , this way saving time one some unecesary coding , and still having my data kept locally within the JBoss enviroenment as I'm using the Tomcat that's integrated with JBoss 3.2.2 .
I would suggest you think again before tying your Entity bean to your JSP code. The decision you take should depend on what you are trying to achieve here. If you are just looking at creating a 'make and throw away' kind of code..please go ahead with this approach.
On the other hand if you are planning to use this application extensively I would recommend that you re-think this strategy. Once used any application will need updates and enhancements. By following your idea you are creating a strong coupling between the business tier and web tier which is a bad design. Any change in your datasource or business obj will ripple across tiers...
Implement a business delegate layer to provide a clean separation of tiers
And additionally what are the transactional implications of tying your Entity to your JSP!
the tasks i'm trying to achieve are rather simple . On top of that i'm really new at JSP , so i'm going to concentrate my time on learning that , rather than developing a business delegate layer .
I don't suspect i'll reuse this code , or i'd really need to change the presentation layer later on , but the moment this would happen , my first action would be to go by the book and implement sessionbeans .
Of course I'm not worried about transactions , even security is low . I am using EJB's for this , because i'm trying to develop a quick and simple aplication and JBoss CMP + XDoclet are giving me just that .
Last thing ... this is a little project of mine , it's not some project i've been hired for , otherwise i'd stay closer to best practices
thanks all for your input