Why to use EJB Reference

hi all,
when i have an enterprise application with a session bean and a webapp,
i can access the session bean either over an ejb-reference in the webapp or directly access the jndi entry. what is the advantage of using ejb references? here an example of what i mean (both from within a webapp):
ctx.lookup("myBean"); // without ejb ref
ctx.lookup("java:comp/env/ejb/myRef"); // with ejb ref
I get back the same, so whats the difference?
rgds

With ejb-reference a container optimizes access to collocated beans. For example, say you have a deployment where beans A and B are both replicated in two different containers, for performance and/or availability reasons. For optimal use every instance of A in container would use instances of B also in container one. Likewise for container two. An EJB container can enforce this locality constraint using ejb-links, but not always using direct JNDI names.

Similar Messages

Why to Use EJB rather then Direct Connection To Oracle Thru webDynpro?

Hi
Experts,
I want to know that why to use EJB to connect to oracle rather then direct connection via WebDynpro.
Please Give Me References to how to connect to oracle with EJB or WebDynpro.I want to tell you that i know JDBC,JAVA and basic web Dynpro.
Please Reply Me Dear Friends...ASAP.

EJB are better for a project beacuse the application is scalable, have less maintainence and have better performance.
Have you gone throght these:
Connect Oracle 9.2 DB to Web AS 6.40
web dynpro - database connection
web Dynpro application connecting to oracle
/people/ramesh.jandhyala/blog/2007/01/02/webdynpro-and-oracle-using-dtos
Regards,
Ashwani Kr Sharma

Could not lookup PortalManagerHome in the JNDI tree using EJB reference java:comp/env/ejb/PortalManager

Hi
I am just a starter on WLPortal.
I have created a barebone Application from scratch. I have synchronized it properly
from EBCC to WLP. But When I am trying to access the home page of my application,
I am getting from stack trace -
<Nov 6, 2002 5:37:59 PM IST> <Error> <PortalAppflow> <Could not lookup PortalManagerHome
in the JNDI tree using EJB reference java:comp/env/ejb/PortalManager.
javax.naming.NameNotFoundException: Unable to resolve comp/env/ejb/PortalManager
Resolved: 'comp/env' Unresolved:'ejb' ; remaining name 'PortalManager'
at weblogic.jndi.internal.BasicNamingNode.newNameNotFoundException(BasicNamingNode.java:802)
at weblogic.jndi.internal.BasicNamingNode.lookupHere(BasicNamingNode.java:209)
at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:173)
at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:181)
at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:181)
at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:323)
at weblogic.jndi.factories.java.ReadOnlyContextWrapper.lookup(ReadOnlyContextWrapper.java:36)
at weblogic.jndi.internal.AbstractURLContext.lookup(AbstractURLContext.java:124)
at javax.naming.InitialContext.lookup(InitialContext.java:350)
at com.bea.p13n.util.JndiHelper.lookupNarrow(JndiHelper.java:96)
at com.bea.portal.appflow.PortalAppflowHelper.<clinit>(PortalAppflowHelper.java:64)
at com.bea.portal.appflow.servlets.internal.PortalWebflowServlet.init(PortalWebflowServlet.java:78)
at javax.servlet.GenericServlet.init(GenericServlet.java:258)
at weblogic.servlet.internal.ServletStubImpl.createServlet(ServletStubImpl.java:700)
at weblogic.servlet.internal.ServletStubImpl.createInstances(ServletStubImpl.java:643)
at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.java:588)
at weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl.java:368)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:242)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:215)
at weblogic.servlet.jsp.PageContextImpl.forward(PageContextImpl.java:112)
at jsp_servlet.__index._jspService(__index.java:92)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:304)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2459)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2039)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
>
<Nov 6, 2002 5:37:59 PM IST> <Error> <HTTP> <[WebAppServletContext(19695286,FirstWebApp,/FirstWebApp)]
Servlet failed with Exception
java.lang.NullPointerException:
at com.bea.portal.appflow.PortalAppflowHelper.createPortalManager(PortalAppflowHelper.java:82)
at com.bea.portal.appflow.servlets.internal.PortalWebflowServlet.setupPortalRequest(PortalWebflowServlet.java:187)
at com.bea.portal.appflow.servlets.internal.PortalWebflowServlet.doGet(PortalWebflowServlet.java:99)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:215)
at weblogic.servlet.jsp.PageContextImpl.forward(PageContextImpl.java:112)
at jsp_servlet.__index._jspService(__index.java:92)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:304)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2459)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2039)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
When I decompiled the class PortalAppflowHelper, I found a static block in it,
which was as under-
static
debug = Debug.getInstance(com.bea.portal.appflow.PortalAppflowHelper.class);
try
if(debug.ON)
debug.out("Looking up PortalManagerHome using EJB reference java:comp/env/ejb/PortalManager");
portalManagerHome = (PortalManagerHome)JndiHelper.lookupNarrow("java:comp/env/ejb/PortalManager",
com.bea.portal.manager.ejb.PortalManagerHome.class);
if(debug.ON)
debug.out("Successfully retrieved PortalManagerHome " + portalManagerHome);
catch(Exception e)
PortalAppflowLogger.errorFindingPortalManagerHome("java:comp/env/ejb/PortalManager",
e);
I have checked the PortalManager's JNDI name on WLConsole. Its ${APPNAME}.BEA_portal.PortalManager.
Should I change it?
When I tried to change it, I started getting other weird errors.
Thanks
Neeraj Hans

Neeraj -
The Portal framework code (including PortalAppflowHelper) uses ejb
references to find the PortalManager (and other EJBs) from servlets and
taglibs; that is what is signified by the java:comp/env/... name.
Since you built your webapp from scratch (instead of using the portal
wizard), you will need to make sure the you have the appropriate
<ejb-ref> entries in your web.xml, and the corresponding
<ejb-reference-description> entries in your weblogic.xml. By default,
you will need at least mappings for:
- ejb/PortalManager
- ejb/UserManager
- ejb/GroupManager
- ejb/PipelineExecutor
- ejb/EventService
See either the resulting webapp from using the portal wizard or
BEA_HOME/weblogic700/samples/portal/sampleportalDomain/beaApps/sampleportal/sampleportal/WEB-INF
for example syntax.
Greg
Neeraj Hans wrote:
Hi
I am just a starter on WLPortal.
I have created a barebone Application from scratch. I have
synchronized it properly
from EBCC to WLP. But When I am trying to access the home page of my
application,
I am getting from stack trace -
<Nov 6, 2002 5:37:59 PM IST> <Error> <PortalAppflow> <Could not lookup
PortalManagerHome
in the JNDI tree using EJB reference java:comp/env/ejb/PortalManager.
javax.naming.NameNotFoundException: Unable to resolve
comp/env/ejb/PortalManager
Resolved: 'comp/env' Unresolved:'ejb' ; remaining name 'PortalManager'
at <stack trace lines snipped>
When I decompiled the class PortalAppflowHelper, I found a static
block in it,
which was as under-
static
debug =
Debug.getInstance(com.bea.portal.appflow.PortalAppflowHelper.class);
try
if(debug.ON)
debug.out("Looking up PortalManagerHome using EJB
reference java:comp/env/ejb/PortalManager");
portalManagerHome =
(PortalManagerHome)JndiHelper.lookupNarrow("java:comp/env/ejb/PortalManager",
com.bea.portal.manager.ejb.PortalManagerHome.class);
if(debug.ON)
debug.out("Successfully retrieved PortalManagerHome "
+ portalManagerHome);
catch(Exception e)
PortalAppflowLogger.errorFindingPortalManagerHome("java:comp/env/ejb/PortalManager",
e);
I have checked the PortalManager's JNDI name on WLConsole. Its
${APPNAME}.BEA_portal.PortalManager.
Should I change it?
When I tried to change it, I started getting other weird errors.
Thanks
Neeraj Hans

Why we use EJB

please tell me that , why we use EJB , i searched it on google but didn't find the answer .
Please help me out
Thanks in advance ...

http://en.wikipedia.org/wiki/Ejb
http://en.wikipedia.org/wiki/Enterprise_JavaBean
http://www.developer.com/java/ejb/article.php/1434371/Introduction-to-EJBs.htm
http://www.roseindia.net/ejb/
http://openejb.apache.org/hello-world.html

Help needed - why we use ejb-ref element in ejb-jar.xml

hi all
can anyone tell me what is the purpose of this element in the ejb deploy descriptor? thanks

Suppose u have bean A, which needs to look up another bean B. Normally you wud need to use the jndi lookup using the initial context to access the bean B's home interface. If you use ejb-ref element you dont need to know the JNDI name of bean B. You can use ejb-ref-name instead. So you can say this is a short cut method of looking up and getting a reference to a bean's home object.

EJB reference

I try to a write a sample EJB to show HelloWorld
I finish EJB
but when I run the client
and it always can't find my EJB?
for example my EJB name is "hrApp"
in my ejb-jar.xml file, it contains <ejb-ref>
I try to create a file called application-client.xml
I add <ejb-ref> inside
but it's still fail
Can somebody help me where to set EJB reference?

Specify a t3 <jndi-name>
t3://<hostName_with_EJB>:<port_number>/JndiNameofEjb
For example:
<jndi-name>t3://localhost:7001/JndiNameofEjb</jndi-name>
[email protected] (xuang) wrote:
I have 2 ejb's , one CALLERejb and another CALLEDejb . Both of them is
deployed in difft weblogic server instances (no cluster , no admin
managed relation) , how can I use "ejb-reference-description" tag in
weblogic-ejb-jar.xml file to call the CALLEDejb from CALLERejb?
further I know that using rmi-iiop one can use the below .
<reference-descriptor>
<ejb-reference-description>
<ejb-ref-name>someRefName</ejb-ref-name>
<jndi-name>corbaname:iiop:1.2@localhost:8001#JndiNameofEjb</jndi-name>
</ejb-reference-description>
</reference-descriptor>
But how do you do the same thing on plain t3?

Ejb-reference-description question

I have 2 ejb's , one CALLERejb and another CALLEDejb . Both of them is
deployed in difft weblogic server instances (no cluster , no admin
managed relation) , how can I use "ejb-reference-description" tag in
weblogic-ejb-jar.xml file to call the CALLEDejb from CALLERejb?
further I know that using rmi-iiop one can use the below .
<reference-descriptor>
<ejb-reference-description>
<ejb-ref-name>someRefName</ejb-ref-name>
<jndi-name>corbaname:iiop:1.2@localhost:8001#JndiNameofEjb</jndi-name>
</ejb-reference-description>
</reference-descriptor>
But how do you do the same thing on plain t3?

Specify a t3 <jndi-name>
t3://<hostName_with_EJB>:<port_number>/JndiNameofEjb
For example:
<jndi-name>t3://localhost:7001/JndiNameofEjb</jndi-name>
[email protected] (xuang) wrote:
I have 2 ejb's , one CALLERejb and another CALLEDejb . Both of them is
deployed in difft weblogic server instances (no cluster , no admin
managed relation) , how can I use "ejb-reference-description" tag in
weblogic-ejb-jar.xml file to call the CALLEDejb from CALLERejb?
further I know that using rmi-iiop one can use the below .
<reference-descriptor>
<ejb-reference-description>
<ejb-ref-name>someRefName</ejb-ref-name>
<jndi-name>corbaname:iiop:1.2@localhost:8001#JndiNameofEjb</jndi-name>
</ejb-reference-description>
</reference-descriptor>
But how do you do the same thing on plain t3?

Why do we use EJBs?

Hi all,
I am a student and trying my Hands on J2EE. The only question i have is why do we use EJBs when similar kind of functions can be done using Servlets also ...
I may be sounding dumb, but i really wanna know when to use EJBs and when not to use them.
Thanks,
Raghuveer

rags_raghuveer wrote:
Hi all,
I am a student and trying my Hands on J2EE. The only question i have is why do we use EJBs when similar kind of functions can be done using Servlets also ...
Wrong. Servlets handle HTTP requests. There are four flavors of EJBs. Are you saying that servlets duplicate all that functionality? You understand neither servlets nor EJBs.
I may be sounding dumb, Yes.
but i really wanna know when to use EJBs and when not to use them.That's actually a very good question. Here's one person's answer:
http://www.amazon.com/Expert-One-One-Development-without/dp/0764558315/ref=sr_1_1/104-2273680-6808730?ie=UTF8&s=books&qid=1192283013&sr=8-1
%

Why use EJB?

I am somewhat new to Enterprise Computing and I am a little unclear about these technologies.
Could someone please let me know why should we use EJB classes in web applications instead of normal classes for executing business logic?
Thanks and regards.
Soham

While I agree that most people using EJB's could have
built a better solution, I think both of the above
posters are completely wrong.
Not at all... You just don't get the point...
Most problems to which EJBs are applied are not problems to which EJBs should ever have been applied at all.
Before answering your question though, keep in mind
there are at least 3 types of EJB's, and all are
completely different. So I can only answer your
question at a high level. Here are the reasons people
might use EJB's:
And according to the specs you use them all or you don't use EJB...
They are container managed.Granted
They offer transactional awareness in your app.So can other solutions.
They are secure.Only as secure as you make them.
And you then tie yourself into a security system that may not be at all compatible with the ones you have already requiring expensive work to link several disparate systems together.
They are pooled, which makes them fast and eliminates
excessive object creation/deletion.There's many other things that are pooled.
They scale well in clustered/distributed environments
(as mentioned above).Clustered environments are indeed the only places where EJB have a definite advantage.
They abstract you from database access (yeah!).So do other technologies
They decouple you from the database so you can switch
from Oracle to MySQL with little or no impact and/or
changes to code (only driver changes).
That's exactly the same reason as above.
I've written my own abstraction layer once which worked faster and simpler than EJB.
We're now using another abstraction layer which does the same.
Use any ORM tool and you have an abstraction layer that's a lot easier to use than EJB, and a lot better performant.
I could go on and on, but don't have time. :-)You don't have a clue you mean. You're just spouting the party line as presented by the EJB priests.

Ejb-link is still required when using local references?

Hi!
In BEA's link (http://e-docs.bea.com/wls/docs81/ejb/DDreference-ejb-jar.html#1114738) there is the following comment for weblogic-ejb-jar.xml element 'jndi-name':
"Assigning a JNDI name to a bean is not recommended. Global JNDI names generate heavy multicast traffic during clustered server startup. See Using EJB Links for the better practice."
Since we're using local references (local-jndi-name) to access our ejbs instead of remote references, is this still recommendation still pertinent?
Thanks
Christianne

It is enough if you add the ejb-ref & ejb-link in the session bean. The
session will look up relative to java:comp/env
The following doc shows an example of accessing an ejb from a web app using
ejb-link.
http://e-docs.bea.com/wls/docs81/webapp/components.html#146848
--Sathish
<Christianne Carvalho> wrote in message news:[email protected]..
I'm not getting very well how the ejb-link is used. In my case I have
entity beans that are referenced in session beans.
In my entity beans I have the following XDoclet tag.
* @ejb.bean
* name="ProductDescription"
* display-name="ProductDescription"
* jndi-name="ejb/ProductDescription"
* local-jndi-name="ejb/ProductDescriptionLocal"
* view-type="local"
* type="CMP"
In my session bean I'm currently getting the reference for the entity bean
using the following code:
productDescriptionLocalHome=(ProductDescriptionLocalHome)
lookupLocalHome(ProductDescriptionLocalHome.JNDI_NAME);
If I add the following XDoclet tag to my session bean, in ejb-jar.xml a
<ejb-link> is created inside <ejb-local_ref> tag.
* @ejb.ejb-ref ejb-name="ProductDescription" view-type="local"
Considering the info above:
1) In the entity bean, is there any extra tag to define the ejb-link or is
the ejb-link only defined in the session bean?
2) Re session bean, only adding the @ejb-ref xdoclet tag is enough for
using the ejb-link or do I also have to change my lookup? If I do, what do
I have to search for in the lookup?
Thanks!

Why should I use EJB

Hi,
My name is Gandharv Sirohi. I am a student, and new to EJB. I want to know why should I use EJB, before I can start learning it if every thing can be done using Java Servlets and JSP.
I tried to find out the answer to this question in books but there is no satisfactory answer.
Can some body help me understand this simple question. I will be thankfull

Hi gandharv,
It's true there are a lot of services available to both the web tier and the EJB tier. One of the
real strengths of EJB is support for transactional business logic. Web components can
explicitly demarcate transactions via UserTransaction, but container-managed transaction
support in EJB components at the business method level offers a much simpler approach
for developing and maintaining such applications. An example of some EJB services not available
in the web tier are : method-level security, RMI-IIOP access, message-driven beans,
transactional/persistent timer service, stateful components, extended container-managed
persistence contexts, guaranteed single-threaded execution, and interceptors.
Of course there are many services available to the web tier that are not in EJB. It's not
about picking one of the two that should always be used. Like any tool/technology, each has its strengths, weaknesses, and design center.
--ken

Question about using ejb remote home vs ejb reference

hi guys
i am new to EJB and want to understand the difference between these two. i notice that the ejb reference is declared in the ejb-jar.xml so that the calling ejb can get the home object by using
initCtx.lookup("java:comp/env/ejb/CabinHome");which is declared in
<ejb-ref>
<description>Cruise ship cabin</description>
<ejb-ref-name>ejb/CabinHome</ejb-ref-name>
<ejb-ref-type>Entity</ejb-ref-type>
<home>com.titan.cabin.CabinHome</home>
<remote>com.titan.cabin.Cabin</remote>
<ejb-link>CabinBean</ejb-link>
</ejb-ref>how does this differ from using the JNDI to get the home interface. which one is preferred?
thanks for your help.

Right, portable Java EE applications always access resources via their component environment rather than doing a direct global JNDI lookup. Declaring the ejb dependency provides a level of indirection that allows it to be mapped to the appropriate target ejb in each application server without requiring any code changes. The same principle is used for other kinds of component dependencies such as data sources, queues, etc.
The downside to this in J2EE 1.4 and earlier was the overhead/complexity of declaring the ejb-ref/ejb-local-ref in the deployment descriptor. Java EE 5 improves this by introducing environment annotations such as @EJB that make it easy to declare the dependencies. In Java EE 5, @EJB is equivalent to ejb-ref/ejb-local-ref but doesn't require the use of .xml.
The bottom line is if you're writing code that's running within a Java EE component, always access Java EE resources/dependencies through your component environment or use an environment annotation.
--ken

Using ejb-ref tag for EJB toEJB reference

Hello all respected members,
I am using weblogic 5.1 (sp 9).
I have two Session EJBs - a client and another is the referenced by
the client.
The client is using services of the referenced EJB.
The two EJBs are in two very different packages.
Now say I am trying to deploy the client EJB first, without deploying
the referenced EJB.
What I expect (rather, want)is, when the client EJB is being deloyed,
it should give a notification somehow (let's say, by throwing an
exception) that the referenced EJB is not yet deployed.
First of all, is this possible ?
Secondly, I am aware of the of the <ejb-ref> tag. In order to meet my
requirement, I have added the same tag in the client's ejb-jar.xml and
corresponding <ejb-reference-description> tag in the
weblogic-ejb-jar.xml file.
When I start the weblogic server, I can see that the referenced EJB is
not deployed. But the client EJB is being deployed, it does not give
any notification that the referenced EJB is not yet deployed and gets
deployed successfully.
In other words, I expect <ejb-ref> tag to let me know that the
referenced EJB is not yet deployed. Is my understanding of <ejb-ref>
tag correct ?
It is clear to me that when the client EJB tries to instantiate the
referenced EJB to use its services, it would throw an exception
(during the lookup) since the referenced EJB is not deployed. But I
want to avoid this exception at this stage. I want to get a
notification of this, much before i.e. when the weblogic is deploying
my client EJB. I think the <ejb-ref> tag does this. Hence I am using
it.
If I am going in wrong direction, is there any other way to fulfil my
requirement ?
Please advise.
Neelesh.

The <ejb-ref> element is used at deployment to map the bean references.
The beans referred to should already be deployed.
Neelesh wrote:
Hello all respected members,
I am using weblogic 5.1 (sp 9).
I have two Session EJBs - a client and another is the referenced by
the client.
The client is using services of the referenced EJB.
The two EJBs are in two very different packages.
Now say I am trying to deploy the client EJB first, without deploying
the referenced EJB.
What I expect (rather, want)is, when the client EJB is being deloyed,
it should give a notification somehow (let's say, by throwing an
exception) that the referenced EJB is not yet deployed.
First of all, is this possible ?
Secondly, I am aware of the of the <ejb-ref> tag. In order to meet my
requirement, I have added the same tag in the client's ejb-jar.xml and
corresponding <ejb-reference-description> tag in the
weblogic-ejb-jar.xml file.
When I start the weblogic server, I can see that the referenced EJB is
not deployed. But the client EJB is being deployed, it does not give
any notification that the referenced EJB is not yet deployed and gets
deployed successfully.
In other words, I expect <ejb-ref> tag to let me know that the
referenced EJB is not yet deployed. Is my understanding of <ejb-ref>
tag correct ?
It is clear to me that when the client EJB tries to instantiate the
referenced EJB to use its services, it would throw an exception
(during the lookup) since the referenced EJB is not deployed. But I
want to avoid this exception at this stage. I want to get a
notification of this, much before i.e. when the weblogic is deploying
my client EJB. I think the <ejb-ref> tag does this. Hence I am using
it.
If I am going in wrong direction, is there any other way to fulfil my
requirement ?
Please advise.
Neelesh.

Why using EJB when we have BC4J ?

Hello everybody
When I heared about EJB two years ago, I read couple of articles about it and found it useful. Now, when I read about BC4J and the ability they give us, a question pops up into my mind. Why should we use EJB ?
We can simple use BC4J and they are very good. I think there is something about EJBs that I dont know and thats why I think this way.
I'll appriciate any help.
Thanx in adnvace.

BC4J is a J2EE framework that lets you get down to business and focus on building your application.
It then gives you a choice of deploying your application using simple Java classes, or using an EJB Session Bean if you want to take advantage of EJB Session Bean's container-managed transaction (for example, to particpate in a transaction with another bean you didn't write), or method-level security.
The key points are that it saves J2EE developers tons of time by allowing them to not waste their time on writing application plumbing code to implement the many J2EE Design Patterns that all real-world applications need.
Around 800 Oracle Applications developers inside Oracle are using the BC4J framework to get their self-service web applications to market with better features in faster time than their competitors. The framework is filled with nuts-and-bolts application-building features that our own developers have told us are the boring, mundane, plumbing-kinda code that they don't WANT to write, debug, and test themselves.
It gives you a big advantage and allows you do decide whether or not to use EJB at deployment time instead of forcing you to make that decision up front.

Using EJBs in Web Dynpro

I have recently started to develop Web applications using the Web Dynpro framework. Coming from a pure J2EE world, I must admit that Web Dynpro has a few innovative features that I find interesting for user interface development. The use of component & view contexts, for example, is not unlike the ActionForms that one may find in a Struts application, but pushed a bit further. No complaints here.
What I do have some problems with is the whole CommandBean paradigm that is put forth by SAP (refer to the document <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/webdynpro/using%20ejbs%20in%20web%20dynpro%20applications.pdf">Using EJBs in Web Dynpro</a>).
I do understand the usefulness of defining a model that will be used to generate and eventually bind to Context data structures. That's fine. What I do object to is the use of a so-called CommandBean to play that role. Again, coming from a J2EE world, I am familiar with the BusinessDelegate pattern - which would typically be used by a client application to invoke business logic on the server side. I would propose that a better, cleaner way of integrating EJBs with the Web Dynpro framework would be to use a BusinessDelegate for invoking business logic, and importing a separate and distinct ModelBean (instead of a CommandBean) to be used for defining and binding to Context data.
I have built one Web Dynpro application thus far. Instead of using a CommandBean, I created a ModelBean that extends my business object DTO (Data Transfer Object) (which is quite appropriate for that role, given that it implements all the get & set methods that are required for the business data that I need to model). My Web Dynpro application also makes use of an independant BusinessDelegate that is packaged with my EJB DC - this is a standard best practice on J2EE projects. I have been asked by the people working with me to modify this architecture to bring it more in line with the SAP way of doing things. I am open-minded and willing to learn and accept new ways of thinking and doing things. However, I fail to understand the usefulness of merging structure and behaviour by resorting to CommandBeans:
- It violates the MVC paradigm by having one object (the CommandBean) serve as both model AND controller as far as the Web Dynpro application is concerned. The CommandBean is obviously a model - since it is literally imported as such into the Web Dynpro application. It is ALSO a controller from the Web Dynpro's application perspective, since all calls to the back-end go thru the CommandBean via one or more of its execute_xxx methods. In contrast, the use of a business delegate by the Web Dynpro application clearly separates the model (the CommandBean... or rather, a more suitably named ModelBean) from the controller (BusinessDelegate).
- Doesn't carry its own weight. In other words, I haven't yet been provided with any valid justification for going thru the extra effort of coding the CommandBean's execute methods. It's been proposed to me that it somehow serves as an abstraction layer between the Web Dynpro application and the business logic. I would argue that it is the BusinessDelegate's role to abstract away the back-end logic from clients. If one does have a BusinessDelegate available, I would argue there's no need to code execute methods in a separate CommandBean. To prove my point, I would simply point out that all of the CommandBean examples that I have seen so far, either in How-To documents, or in production code, all follow the same pattern....
CommandBean.execute_doSomething() calls BusinessDelegate.doSomething()
Not a heck of an "abstraction" layer... I would in fact argue that it is worse than useless. If some major change occurs in the business logic that requires changing the doSomething() operation, we expect of course to modify the BusinessDelegate. The Web Dynpro client will also presumably need to be modified - that's to be expected, and unavoidable. But then, we'll also need to go about and change the CommandBean's execute_doSomething() method - again, extra work for no apparent benefit. Adding and removing business methods has the same implication. All this for an layer that simply adds the prefix execute_ in front of all business method calls... Is this "abstraction layer" worth the cost of creating and maintaining it ??
- Unnecessarily complicates error handling. I have been told that for technical reasons, it is recommended that all exceptions thrown by the CommandBean be of type WDException or WDRuntimException. But what if the client application needs to react differently to different failure scenarios ? When I create a business object, I might wish to provide the user with an error messages if connection is lost to the backend, and with a different error message if an object already exists in the database with the same attributes. In order to do that, I will have to catch the WDException, extract the cause, and continue processing from there... possible, yes, but clearly less standard and more labor intensive than the classical try/catch mechanism.
To say nothing about the fact that SAP's own API documentation clearly states that applications using Web Dynpro can reference and catch WDExceptions, but THEY MUST NOT THROW OR EXTEND IT !
- Produces unnecessary DCs. Page 6 of the aforementioned document presents an architectural view of a Web Dynpro project that uses a CommandBean. Why an extra DC for the CommandBean ?? I created my ModelBean class right inside the Web Dynpro project (in the Package view). That, to me, is where this class should reside, because it is created for no other reason that to be used by this particular Web Dynpro application. What is the benefit of placing it in its own independant DC ?
- Not a typical application of the Command pattern. The well-documented command pattern (Design Patterns - Gang of Four) has been devised mainly to enable encapsulation of request as objects, thereby making it possible to:
- specify, queue and execute requests at different times
- decouple execution of a command from its invoker
- support undo operations
- support logging changes so that they can be reapplied in case of system crash making it possible to assemble commands into composite commands (macros), thereby structuring a system around high-level operations built on primitive operations.
None of this applies to the way the SAP CommandBeans are being used. Not that much of an issue to people new to J2EE and/or OO development... but quite confusing for those already familiar with the classic Command pattern.
At this point, I fail to understand the advantage of merging structure (model) and behaviour (execute methods) through the use of a unique CommandBean object. Am I missing something ?

Thanks for your reply and your suggestion. I have posted in the Web Dynpro Java forum... and suggest those wishing to participate in this thread to refer to the Web Dynpro Java forum.
As for your answer, I'm afraid it doesn't satisfy me.
Reuse is hardly an issue, since the CommandBean is specifically tailor-made for the Web Dynpro application that needs to use it. I could hardly imagine building another application that would just happen to have the exact same needs as far as data structure and processing is concerned...
As for the right Eclipse environment... the CommandBean is not an EJB artifact - it is an EJB client. The aforementioned tutorial in fact suggests creating it in the Java perspective.
But thanks anyway for your time and suggestion

Why to use EJB Reference

Similar Messages

Maybe you are looking for