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:[email protected]: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:[email protected]: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:[email protected]: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:
    - <b>It violates the MVC paradigm</b> 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).
    - <b>Doesn't carry its own weight.</b> 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 ??
    - <b>Unnecessarily complicates error handling</b>. 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 !
    - <b>Produces unnecessary DCs</b>. 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 ?
    - <b>Not a typical application of the Command pattern</b>. 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

Maybe you are looking for

  • Some of my pictures do not show up in the organizer

    Some of my pictures do not show up in the organizer. The folders are all there but no thumbnails appear in the organizer. If I do a search for them they are shown but I cannot find them in the organizer.

  • Can there be more than one initiator in a shared review?

    We use Acrobat X Pro to do shared reviews of pdf documents. At times, the initiator will be out of the office when someone needs to take action on the document and it would make it more convenient if there was more than one person with access. Is it

  • Can't format ipod classic it's read only

    Can't format my ipod classic because hard drive is read only.

  • Security with password to edit

    How can I secure the pdf with password so that none can edit the pdf form with liveCycle? Also is it possible to do password protect with javaScript? If possible how?

  • IPhone disconnected at the end of backing up?

    Hi! I have tried everything that I could have thought of but no luck. iPhone back up via manual back up keep giving me error message of iPhone being disconnected at the end. Methods I tried:- Moving to different USB port. Reinstalling iTunes. Reboot