Use EJB or not?

Hello,
A client of ours wants us to develop their intranet using the J2EE platform. This system involves the following areas:
1. HR (leave, salary, attendance etc.)
2. Training (identifying training needs, training schedules, feedback etc)
3. Asset management
4. Recruitment (selecting channels, entire recruitment process till the time the candidate is hired etc.)
5. Finance (claims processing, voucher handling etc.)
6. Resource allocation (conference rooms, company accomodation, transport systems)
This system needs to interface with an existing SAP implementation. At the moment it will be deployed in one city, but may also be implemented in another city as well.
Is EJB overkill for this? Should I just use the usual JSP/servlet approach?
Thanks
Luanne

To help you decide the most appropriate architecture, you need to ask yourself the following questions.
Do you want the app to be scaleable ?
Will the system be used by many concurrent users ?
Could you envisage distributing the business tier to reside on another host to the web container ? From what you have mentioned this seems like a possibility.
From the type of requirements you have mentioned, I would say that this system will be a full on enterprise scale system that could benefit from transaction management/ security that the EJB container can provide you.

Similar Messages

POJO in the EJB module : To EJB or Not

Hi All,
We are preparing the architecture of a new system in J2EE. As usual we have come across the question "To Use EJB or NOT". And we have decided to use EJB when there are transactions involved. ie., If the are multiple updates or inserts involved in a single call. Otherwise - for simple 'selects' just use POJO business service to avoid EJB overhead. These simple classes are placed in same module where EJB is placed. With the module reference delegate will directly create instance of POJO and get the Value Objects.
Is this approach acceptable? Second question is can I use �Local EJB� invocation when I am sure that I am NOT going to distribute my application components?
Please help.

You mention 3 times that you are a "creative person" in a way that seems to indicate you think programming (or perhaps more properly: software engineering) isn't a creative activity.
Now, I'm sure there are many types of programming that are repetitive, boring and not creative at all, but in my experience, implementing a new concept is a highly creative and intellectually stimulating activity, especially if you have a big influence on the final architecture and design of the system (i.e. it's not "programming to spec").
As an aside: I'm sure your idea is very innovative and new, but if you haven't been able to get anyone (including yourself) to create even the start of an actual working version in 10 years, it doesn't speak well of your ability to enthuse people and actually get something done. The dot-com fiasco has shown the industry the dangers of "great ideas" without anything to back it up.

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

When not using EJBs can I make BD a Singleton and cache facade instances?

Hi,
In an application which does not use EJBs can I make BD(Business Delegate) a singleton?
I was very sure about doing this but when I tried Google on the same subject the answers were'nt supportive of this but that was in the context of applications which used EJBs. And also item 4 in Effective Java isnt very supportive of caching Objects at the drop of a hat.
When not using EJBs would it be an unnecessary thing to make BD a singleton and cahce Facade instances in a BD and DAO instances in a Facade? I am planning to use a array based blocking bounded buffer for the purposes of caching. Or would it be better to make both BD and a facade as SIngletons and just cache DAOs in a Facade?
Any suggestion would be of good help to me.
Thanks a lot.

Not sure I understand all your design, but you seem
to describe an architecture where requests are queued
and handled serially.Sorry if I messed up while explaining it. No, it will not be handled serially. Since the BD is a singleton multiple threads can pass messages to it simulteanously, a bit like an object of the Action class in Struts. Since I dont see having any synchronized methods in a BD requests will be handled simulteanously.
The impact on throughput of handling requests
serially (as opposed to parallelizing them) probably
outweights by far the cost of instantiating one more
object per request...Yes, I understand that but as I explained above the reqests wont be handled serially.
To be more clear, I am thinking of using any one of these two things:
1) BD(Singleton)-->Facade(Singleton, caches DAOs in a thread safe data structure)
2)1) BD(Singleton, caches Facade instances in a thread safe data structure)-->Facade(caches DAOs in a thread safe data structure).
the thread safe data structure I am planning to have is a array based bounded buffer which blocks using wait and notify mechanism.
Thank you for the reply.

A Tip for using EJB 3.0 with WebLogic Ant Tasks

I started out writing this up as a problem, but then I found the answer so I'm, posting a tip instead.
When I tried to write an EJB [stateless] using EJB 3.0 in my legacy Weblogic ear project I started getting this error:
<pre>
No EJBs found in the ejb-jar file 'test'. Please ensure the ejb-jar contains EJB declarations via an ejb-jar.xml deployment descriptor or at least one class annotated with the @Stateless, @Stateful or @MessageDriven EJB annotation.
</pre>
This is why: wlcompile will put the class files in the App-Inf/classes directory unless it finds an ejb-jar.xml file in the META-INF directory for the module it is working on. With EJB 3.0, I wasn't using an ejb-jar.xml file because it was unnecessary. Later, Appc runs and it complains because there are no classes module directory, they went into the shared ear folder instead.
Here's I how it working again: Use javac [not wlcompile] to compile the EJB 3.0 module and make sure that the class files go into the correct module directory. Then you can use wlappc to generate all the associated files for the EJB. I have sucessfully deployed an ear file that uses both EJB 2.x and EJB 3.0 with this approach.
I wish Weblogic's own ejb3.0 sample application used their split directory deployment.
Good Luck.
John Aronson

Hi John,
I am working on development an enterprise application using EJB 3.0 on Weblogic 10.
While developing, I am keeping all my classes (from ejb's as well as web) into APP-INF/classes directory. It is working fine for Web and ejb 2.0 packages, but ejb 3.0 packages, I get the following error when I keep my ejb 3.0 beans classes in APP-INF/classes directory.
No EJBs found in the ejb-jar file 'customer'. Please ensure the ejb-jar contains EJB declarations via an ejb-jar.xml deployment descriptor or at least one class annotated with the @Stateless, @Stateful or @MessageDriven EJB annotation.
One solution is to keep the classes under customer ejb directory, but I wan tto keep all the classes in APP-INF/classes directory so that when using Eclipse IDE I can output all compiled sources into APP-INF/classes directory.
Has anyone faced this situation? Any suggestions to fix this issue?

Error while retreiving data from oracle using EJB.

HII All,
I m getting this error while trying to retreive data from oracle DB using EJB.
An error has occurred. Maybe the request is not accepted by the server:
Exception in method empName.
HTTP/1.1 500 Internal Server Error
Connection: close
Server: SAP J2EE Engine/6.40
Content-Type: text/xml; charset=UTF-8
Set-Cookie: <value is hidden>
Date: Mon, 24 Jul 2006 10:50:11 GMT
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ><SOAP-ENV:Body><SOAP-ENV:Fault><faultcode>SOAP-ENV:Client</faultcode><faultstring>Exception in method empName.</faultstring><detail><ns1:com.sap.engine.services.ejb.exceptions.BaseEJBException xmlns:ns1='http://sap-j2ee-engine/client-runtime-error'>Exception in method empName.</ns1:com.sap.engine.services.ejb.exceptions.BaseEJBException></detail></SOAP-ENV:Fault></SOAP-ENV:Body></SOAP-ENV:Envelope>
Thanks in advance
Devendra Phate.

Hi Devendra,
this error message does not tell me much. Pleas either start debugging or watch your logs for more detailed messages.
Regards,
Benny

Error encountered while trying to use EJB control in a Platform Domain

Hi,
I've configured a Weblogic Platform domain and installed all the application EJB's
thru a JAR file. When I try to access these EJB's from within Web Logic Workshop
using the EJB Control, I am able to find the Home and the Remote interfaces and
those boxes are populated correctly when I select the JNDI name from the Browse
button. But when I click on the "Create" button in EJB Control dialog box, I get
the following error
"The EJB Home interface selected in Step 3 cannot be loaded. The client interfaces
for the selected EJB must be present as individual classes in the WEB-INF\classes
directory of this project or the EJB's client JAR file must be present in the
WEB-INF\lib directory".
I copied my EJB Jar file to the WEB-INF\lib folder also. But still it gives the
same error message. Please let me know if I am missing something. Your help is
greatly appreciated.
Thanks
Vikram

Hi Pat,
I've restarted the complete Platform Domain Weblogic instance and it worked.
Thanks for your help.
Vikram
"Pat Bumpus" <[email protected]> wrote:
>
Hi,
I'm using a workshop domain from WebLogic Platform 7.0 SP1.
When you move the EJB classes (as a jar file) into the WEB-INF/lib directory,
then you need to redeploy the web application. In your last note you
mentioned
redeploying the EJB, but not the web app. Have you tried redeploying
the web
app, after you move the EJB jar file into WEB-INF/lib?
pat
"Vikram" <[email protected]> wrote:
Hi Pat,
Thanks for replying back immediately. I tried to redeploy the EJB and
copy the
client EJB classes to the WEB-INF\lib folder but still it doesn't work.
I've also
tried using some of the standard EJB's like "BEA_commerce.CategoryManager"
which
are part of the Platform domain and I am still getting the same error.
Are you working on a Weblogic Platform Domain or Weblogic workshop domain.
Just
wanted to confirm. Appreciate your help.
Thanks
Vikram
"Pat Bumpus" <[email protected]> wrote:
Hi,
After you copied the EJB into the WEB-INF/lib directory, did you redeploy
the
web application? I got a similar thing to work. Instead of movingthe
whole
EJB into WEB-INF/lib, I had ejbc create an EJB client jar and I moved
that into
my WEB-INF/lib directory. Then I redeployed the web application toload
the classes
and it worked.
pat
"Vikram" <[email protected]> wrote:
Hi,
I've configured a Weblogic Platform domain and installed all the application
EJB's
thru a JAR file. When I try to access these EJB's from within Web
Logic
Workshop
using the EJB Control, I am able to find the Home and the Remote interfaces
and
those boxes are populated correctly when I select the JNDI name from
the Browse
button. But when I click on the "Create" button in EJB Control dialog
box, I get
the following error
"The EJB Home interface selected in Step 3 cannot be loaded. The client
interfaces
for the selected EJB must be present as individual classes in theWEB-INF\classes
directory of this project or the EJB's client JAR file must be present
in the
WEB-INF\lib directory".
I copied my EJB Jar file to the WEB-INF\lib folder also. But stillit
gives the
same error message. Please let me know if I am missing something.
Your
help is
greatly appreciated.
Thanks
Vikram

Error during deployment of stateless session EJB using EJB 3.0

having trouble deploying a stateless session bean to app server 10.1.3.1 oc4j container.
deceided to go through oracles demo: How-To Develop a Stateless Session EJB using EJB 3.0 (http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/how-to-ejb30-stateless-ejb/doc/how-to-ejb30-stateless-ejb.html).
the demo encounters the same issue. so i assume there is something wrong with the app server set up, and not my source code.
here is the deployment log:
[Jul 1, 2009 11:59:25 AM] Application Deployer for test_ws STARTS.
[Jul 1, 2009 11:59:25 AM] Copy the archive to C:\product\10.1.3.1\OracleAS_1\j2ee\home\applications\test_ws.ear
[Jul 1, 2009 11:59:25 AM] Initialize C:\product\10.1.3.1\OracleAS_1\j2ee\home\applications\test_ws.ear begins...
[Jul 1, 2009 11:59:25 AM] Unpacking test_ws.ear
[Jul 1, 2009 11:59:25 AM] Done unpacking test_ws.ear
[Jul 1, 2009 11:59:25 AM] Initialize C:\product\10.1.3.1\OracleAS_1\j2ee\home\applications\test_ws.ear ends...
[Jul 1, 2009 11:59:25 AM] Starting application : test_ws
[Jul 1, 2009 11:59:25 AM] Initializing ClassLoader(s)
[Jul 1, 2009 11:59:25 AM] Initializing EJB container
[Jul 1, 2009 11:59:25 AM] Loading connector(s)
[Jul 1, 2009 11:59:26 AM] Starting up resource adapters
[Jul 1, 2009 11:59:26 AM] Processing EJB module: ejb30ws-ejb.jar
[Jul 1, 2009 11:59:26 AM] application : test_ws is in failed state
[Jul 1, 2009 11:59:26 AM] Operation failed with error: java.lang.NoClassDefFoundError
the opmn log reveals the same error, but no more detail.
any ideas???
/stuck

I am having exactly the same issue. Was this issue resolved? If so, please share the resolution and if not can someone please suggest what could be wrong.
Thanks

Using local session bean interface from web container using EJB 3.0

Hi,
How can you use a local session bean interface from Java (rather than data controls) in a web container using EJB 3.0?
I can use a remote interface by looking up InitialContext, but I can't find a local interface this way (even from another session EJB). I can use a local interface from an EJB using annotation "EJB", but as I understand, this is not available in the web container.
If I try to add an ejb-jar.xml file, these seems to mess up by project...
Hope you can help.
Roger

The portable way to retrieve an EJB reference in Java EE is to either inject it or look it up via the
component's private naming environment. The simplest way is :
@EJB
private DocumentManager dm;
The global JNDI name is only used as an implementation specific way to uniquely assign an
identifier to a specific Remote EJB. It's best for this not to appear directly in the source code.
There's more on global JNDI names in our EJB FAQ :
https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html
The alternative to annotations is to use an ejb-ref to declare the ejb dependency. The ejb-ref
is declared in the standard deployment descriptor corresponding to the component doing the
lookup. Each ejb-ref has an ejb-ref-name, e.g. <ejb-ref-name>DM_ref</ejb-ref-name>
The code looks up the ejb-ref-name relative to the java:comp/env namespace to retrieve the
EJB reference.
DocumentManager dm = (DocumentManager)
new InitialContext().lookup("java:comp/env/DM_ref");

How to load data in plain-text file into database by using EJB?

Hi,
We need to develop an on-line application which requires us to load input data
from a selected plain-text file on the Web server (iplanet server) into the backend
oracle database. How could I use EJB to make it happen? it seems like using Entity
EJB is not feasible.
Really appreciate your help!
Corona

Hi Corona,
"Corona Fang" <[email protected]> wrote in message
news:3f3b0ea3$[email protected]..
We need to develop an on-line application which requires us to load inputdata
from a selected plain-text file on the Web server (iplanet server) intothe backend
oracle database. How could I use EJB to make it happen? it seems likeusing Entity
EJB is not feasible.If you are talking about loading thousands of records,
the preferable way is using plain JDBC calls utilizing
batch methods.
Regards,
Slava Imeshev

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

Using EJBs in Web Dynpro Applications

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 Applications</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 ?

Hi Romeo,
You would be disappointed, this reply ain't anywhere nearby to what you are talking about...
I wanted to mail you, but you have not mentioned your email in your profile.
I am really impressed by your flair for writing. It would be far better had you written a blog on this topic. Believe me, it would really be better. There is a much wider audience waiting out there to read your views rather than on the forums. This is what I believe. To top it, you would be rewarded for writing something like this from SDN. On the blogs too, people can comment and all, difference being there you would be rewarded by SDN, here people who reply to you would be rewarded by you. Doesn't make much a difference.
Anyways the ball is still in your court
As far as I am concerned, it has still not been much time since I have started working on Web Dynpro. So can't really comment on the issue...
Bye
Ankur

Problem in invoking LiveCycle using EJB

Hi All,
I am trying to invoke LC using EJB protocol. I referred the code example from the link http://help.adobe.com/en_US/livecycle/9.0/programLC/help/index.htm?content=001001.html#154 8359
But I am facing the problem in the same code. Here is the stack trace for the same:
Error Occurred: Exception thrown is NOT a
DSCException : UnExpected From DSC
com.adobe.idp.um.api.UMException
| [com.adobe.livecycle.usermanager.client.AuthenticationManagerServiceClient] errorCode:16385 errorCodeHEX:0x4001 message:Exception thrown is NOT a DSCException : UnExpected From DSC chainedException:java.lang.IllegalStateExceptionchainedExceptionMessage:null chainedException trace:java.lang.IllegalStateException
at com.adobe.idp.dsc.clientsdk.ServiceClientFactory$1.handleThrowable(
ServiceClientFactory.java:69)at com.adobe.idp.dsc.clientsdk.ServiceClient.invoke(
ServiceClient.java:220)at com.adobe.livecycle.usermanager.client.AuthenticationManagerServiceClient.authenticate(
AuthenticationManagerServiceClient.java:109)at in.gov.ebiz.eforms.invocation.AuthenticateUsersTest.main(
AuthenticateUsersTest.java:47)Caused by: java.lang.NoClassDefFoundError:
javax/ejb/EJBException
at com.adobe.idp.dsc.clientsdk.ServiceClientFactory.evaluateMessageDispatcher(
ServiceClientFactory.java:587)at com.adobe.idp.dsc.clientsdk.ServiceClient.invoke(
ServiceClient.java:215)... 2 more
Caused by:
java.lang.ClassNotFoundException: javax.ejb.EJBException
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(
Native Method)at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
... 4 more
at com.adobe.livecycle.usermanager.client.ManagerServiceClient.throwNonUMExceptionAsUMExcept ion(
ManagerServiceClient.java:53)at com.adobe.livecycle.usermanager.client.ManagerServiceClient.handleException(
ManagerServiceClient.java:95)at com.adobe.livecycle.usermanager.client.AuthenticationManagerServiceClient.authenticate(
AuthenticationManagerServiceClient.java:113)at in.gov.ebiz.eforms.invocation.AuthenticateUsersTest.main(
AuthenticateUsersTest.java:47)
Please advice me. Am I missing some jar? or Do I need to configure some settings at the server end?
Regards,
Ambika

The .xml and code looks ok. Using java:comp/env is the right approach. How does getInitialContext() instantiate the InitialContext()? Make sure it's using the no-arg "new InitialContext" Also try running the $APS_HOME/bin/verifier on your .ear. Please also post the full stack trace. Thanks.
--ken

How to use EJB in JSP...urgent!!!

hello,
i am novice programmer in EJB.
i am using weblogic 6.1 ...
my problem is how to use EJB in jsp page.
my code is as follow..but its not displaying any result.
<%@ page import="javax.naming.InitialContext,
javax.naming.Context,
java.util.Properties,
firstEJB.First,
firstEJB.FirstHome"%>
<%
 long t1 = System.currentTimeMillis();
 System.out.println(t1);
 Properties props = new Properties();
 p.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.TengahInitialContextFactory");
 props.put(Context.PROVIDER_URL, "localhost:7001");
 Context ctx = new InitialContext(props);
 FirstHome home = (FirstHome)ctx.lookup("FirstEJB");
 First bean = home.create();
 String time = bean.getTime();
 bean.remove();
 ctx.close();
 long t2 = System.currentTimeMillis();
%>
<html>
 <head>
 <style>p { font-family:Verdana;font-size:12px; }</style>
 </head>
 <body>
 Message received from bean = "<%= time %>". Time taken :
 <%= (t2 - t1) %> ms.
 </body>
</html>
please tell me the solution.

Hi, I don't know if it may be the cuase of your problems, but you should narrow the Object obtained doing the lookup, like this:
FirstHome home = (FirstHome) PortableRemoteObject.narrow(ctx.lookup("FirstEJB"), FirstHome.class);

[J2EE:160167] uses ejb-links but no EJB modules

Dear All
Seeking support/assistance to resolve the below problem. I'm using laster Jdeveloper 11g software publish in 2011.
weblogic.deployment.EnvironmentException: [J2EE:160167]The module abc-ViewController-context-root in application abc_Project1_abc uses ejb-links but no EJB modules were found for this application
Please provide guidelines why this appears and how to resolve it.
Best Regards
Shahebaz Shaikh

The module abc-ViewController-context-root in application abc_Project1_abc uses ejb-links but no EJB modules were found for this application
Is the application deployed as an EAR application with web and ejb modules? If not, deploy as an EAR application.

Use EJB or not?

Similar Messages

Maybe you are looking for