Should I use EJB?

Hi-
I was wondering if anyone could offer some architectural advice. I need to create a service that does the following:
1.take a plain text file provided by a client
2.run some non-java executables on that file
3.return the binary output file to the client (could be anywhere from 2-60 meg)
Would it be appropriate to use a stateless session bean for this purpose? Is it not wise to transfer large, serialized binary files over the RMI protocol used in EJB?
Thanks

I dont see any reason to use EJB for something so simple. I don't see any reason not to use RMI for something so simple.

Similar Messages

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

New to j2ee...should i use ejbs?

read on coz this can be interesting.....
I am an inexperienced web developer. i am looking to develop a web application where tickets can be sold over the net.
one of my immediate goals is to develop a web application where users can book tickets only not purchase them.currently the web app needs to facilitate for a max of 200 users-people who can book tickets, think of them as admin.
in the long term the web app will evolve and cater for all users, internet users and admin.i think i need to use ejbs.i want to start with the immediate goal(facility for admin) and build on that to facilitate internet users.the web app will be huge when complete.
now, the problem is that i have only developed a tiny j2ee project prior to this and that wasn't a web app-it was just a normal application. i don't have the experience(OBVIOUSLY).i don't even know how to deploy a web app or which app server to use(i have downloaded the sdk1.4)!
i am thinking about developing the admin facility with just using javabeans,servlets,html,jsp and tomcat4.1.30-all of which i am comfortable with.
what is a feasible solution to my problem considering that the longterm will only be achieved after a period of 2-3 years???(hopefully, by then i will have the experience :-)).
How should i go about it?
you know this can be a forum on its own!!!!
Don't be shy to contribute....
regards
Ushanta

EJB are certainly not needed.
I've worked on creating an e-commerce site which runs successfully without any EJB and am now working on a very large web application (intranet style) which is selling well and doesn't use EJB (this app has over 500 JSPs and nearly a thousand classes by now and is still growing, to give an idea of scale).
EJB are often overblown. There was a study (Gartner I think) in 2001 which calculated that in the US alone there had been $2 billion wasted on EJB projects that didn't need EJB (projects either failed because EJB were used or would have been cheaper implemented without them).
That was before EJB REALLY took off as a hype...
Start without. If you find yourself in a situation where you have a definite business requirement for them you can always implement some for the limited use you do find.

SHOULD I USE EJBS?

read on coz this can be interesting.....
I am an inexperienced web developer. i am looking to develop a web application where tickets can be sold over the net.
one of my immediate goals is to develop a web application where users can book tickets only not purchase them.currently the web app needs to facilitate for a max of 200 users-people who can book tickets, think of them as admin.
in the long term the web app will evolve and cater for all users, internet users and admin.i think i need to use ejbs.i want to start with the immediate goal(facility for admin) and build on that to facilitate internet users.the web app will be huge when complete.
now, the problem is that i have only developed a tiny j2ee project prior to this and that wasn't a web app-it was just a normal application. i don't have the experience(OBVIOUSLY).i don't even know how to deploy a web app or which app server to use(i have downloaded the sdk1.4)!
i am thinking about developing the admin facility with just using javabeans,servlets,html,jsp and tomcat4.1.30-all of which i am comfortable with.
what is a feasible solution to my problem considering that the longterm will only be achieved after a period of 2-3 years???(hopefully, by then i will have the experience :-)).
How should i go about it?
you know this can be a forum on its own!!!!
Don't be shy to contribute....
regards
Ushanta

There has been no rebuttal because I don't go looking
for arguments on forums. As much as you detest people
"hawking their wares" on forums, I detest people using
developer forums as soapboxes.My dear, if I wanted to use fora as a soapbox, I'd certainly pick a better and more trafficked spot than this one. And, if you'd bother checking my posting history, you'd see that I do quite a bit more than beat up on poor defenseless vendors. Your posting history is quite easy to see: 1 - pitch a product, 2 - try to play bait-and-switch.
The developer I was trying to help stated:
I am an inexperienced web developer. i am lookingto develop a web application where tickets can be sold
over the net.
"Inexperienced" is the key word here. The developer
can go out and try to learn EJB or whatever other
technology they think they can use to solve the
problem at hand. Then months later after they are
capable of writing the scalable applications you
describe, they can begin development. Or, they can
download MyProduct and build their application in
a week or two.See the post by PinkyDead. He/she sums it all up in the first senence. Quicker != better
You are obviously unfamiliar with MyProduct but
are arguing its usefulness and abilities. I suggest
you try it before you criticize.I've used more RAD tools than I can even remember. Probably more than you can even name. And you know what? In every situation, in every circumstance, in every scenario, in every job, all those nice little point-and-click apps had to be fixed by hand because the RAD tool simply could not take all the variables of a given UseCase into account. I still use RAD tools, but I know what I'm doing and am able to overcome the short-comings of the tool. I use code generators, diagrammers, GUI builders, etc. -- but I am in no way fooled into thinking that just because I have some functionality working that my job is done.
MyProduct does not eliminate the need for expert
J2EE developers. Your job is safe.I'm not worried about my job - I'm worried that I may be trusting some portion of my private data to some "clever" CIO who has bought into the whole Silver Bullet concept and is using inexperienced programmers and NameOfProductHere to build the apps that keep my data safe. I cringe at the very thought that some of the infrastructure governing the world's business, both governmental and financial, is predicated on the exact premise you stated above. I would much rather believe that there was significant time, money, and expertise employed with a bit of foresight applied, not some quick-and-dirty approach that kinda sorta works like it's supposed to.
I'm sure your product does exactly as advertised - what I'm saying is that it is not the "best" way to build a fully-capable Enterprise application that can handle thousands of transactions per hour. It might be a good place to start, but you have to know what you're doing to make it work good -- "good enough" is not enough.

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.

EJB3 newbie - when to use EJB?

If I just want to build a reusable module that does not have any business critical actions, such as a login module, or a blog module, should I use EJB?
Also, am I correct that only EJBs can run on distributed servers, and that all other non-EJB components in a web applications can only run on a single server?

If I just want to build a reusable module that does
not have any business critical actions, such as a
login module, or a blog module, should I use EJB?
No. Any Java module can be made to be reusable, if designed to be so. Actually, by using EJBs, you'll be limiting the reusability of your modules, since those would need to run inside an EJB container.
Also, am I correct that only EJBs can run on
distributed servers, No, they can run in distributed as well as non-distributed environments.
and that all other non-EJB
components in a web applications can only run on a
single server?No. Not sure where you got that idea from. I think you're confusing multiple server environment (clusters) with distributed[i] business objects. You can cluster applications that collocate all their components in a single JVM.
There are actually very few cases where the use of EJB is to be considered (roughly 10% of cases):
- if you really need object distribution - this is not the norm
- if you need to use IIOP as the protocol for communication
- MDBs are a good solution for some applications heavily based on messaging

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.

I need a clarification : Can I use EJBs instead of helper classes for better performance and less network traffic?

My application was designed based on MVC Architecture. But I made some changes to HMV base on my requirements. Servlet invoke helper classes, helper class uses EJBs to communicate with the database. Jsps also uses EJBs to backtrack the results.
I have two EJBs(Stateless), one Servlet, nearly 70 helperclasses, and nearly 800 jsps. Servlet acts as Controler and all database transactions done through EJBs only. Helper classes are having business logic. Based on the request relevant helper classed is invoked by the Servlet, and all database transactions are done through EJBs. Session scope is 'Page' only.
Now I am planning to use EJBs(for business logic) instead on Helper Classes. But before going to do that I need some clarification regarding Network traffic and for better usage of Container resources.
Please suggest me which method (is Helper classes or Using EJBs) is perferable
1) to get better performance and.
2) for less network traffic
3) for better container resource utilization
I thought if I use EJBs, then the network traffic will increase. Because every time it make a remote call to EJBs.
Please give detailed explanation.
thank you,
sudheer

Please suggest me which method (is Helper classes or Using EJBs) is perferable :
1) to get better performance
EJB's have quite a lot of overhead associated with them to support transactions and remoteability. A non-EJB helper class will almost always outperform an EJB. Often considerably. If you plan on making your 70 helper classes EJB's you should expect to see a dramatic decrease in maximum throughput.
2) for less network traffic
There should be no difference. Both architectures will probably make the exact same JDBC calls from the RDBMS's perspective. And since the EJB's and JSP's are co-located there won't be any other additional overhead there either. (You are co-locating your JSP's and EJB's, aren't you?)
3) for better container resource utilization
Again, the EJB version will consume a lot more container resources.

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

What XA JDBC driver should I use with Oracle 8i 8.1.6

I need to use an XA JDBC driver for Oracle 8i 8.1.6. I am using the driver in
a ConnectionPool in a TxDataSource for use by some entity beans using EJB 2.0.
I'm running WebLogic Server 6.0 sp2, EJB 2.0, Java 2 SDK 1.3.1 Server VM, Solaris
2.7, and Oracle 8i 8.1.6.
I know of three different Oracle XA drivers: WebLogic jDriver for Oracle XA, Oracle
OCI type 2 driver XA, and Oracle Thin tyoe 2 XA. Are there any other drivers
that I can use for Oracle 8.1.6? Which driver and which version should I use?
For example, can I use the Oracle 8.1.7 JDBC drivers with the Oracle 8.1.6 server,
or would the Oracle 9i drivers work with the Oracle 8i server? Which drivers
are faster, and which support more features? I assume that I should not use the
type 4 driver since I am not using an applet, but I don't know if there are bugs
in the OCI C library for Solaris or in the JDBC drivers that use it that prevent
XA from woking. Which version of the Oracle C OCI library should I use if I use
a type 2 driver?
Thanks,
Ross Goldberg

Hi,
I think you can't use the 8.1.6 thin driver for XA, you would have to
use the OCI driver or 2PC-enable your datasource. AFAIK this has been
changed for 8.1.7
Check http://e-docs.bea.com/wls/docs61/////jta/thirdpartytx.html.
Daniel
-----Original Message-----
From: Gene Chuang [mailto:[email protected]]
Posted At: Thursday, August 30, 2001 2:04 AM
Posted To: jdbc
Conversation: What XA JDBC driver should I use with Oracle 8i 8.1.6
Subject: Re: What XA JDBC driver should I use with Oracle 8i 8.1.6
I've asked this question before. This is the reply from Joe
Weinstein:
For reliability and JDBC 2.0 compliance, I recommend the
Oracle thin driver.
If not that driver, you should verify that a type-2 driver
actually does
deliver better performance, but then I would not have a
strong preference
between their type-2 and ours. Theirs may be faster, and JDBC
2.0 compliant.
Both are succeptible to OCI bugs, some of which only they can
fix, but we
listen.
Gene
"Ross Goldberg" <[email protected]> wrote in message
news:[email protected]...
>
I need to use an XA JDBC driver for Oracle 8i 8.1.6. I am using thedriver in
a ConnectionPool in a TxDataSource for use by some entity beans usingEJB 2.0.
I'm running WebLogic Server 6.0 sp2, EJB 2.0, Java 2 SDK 1.3.1 ServerVM, Solaris
2.7, and Oracle 8i 8.1.6.
I know of three different Oracle XA drivers: WebLogic jDriver forOracle XA, Oracle
OCI type 2 driver XA, and Oracle Thin tyoe 2 XA. Are there any otherdrivers
that I can use for Oracle 8.1.6? Which driver and which versionshould I use?
For example, can I use the Oracle 8.1.7 JDBC drivers with the Oracle8.1.6 server,
or would the Oracle 9i drivers work with the Oracle 8i server? Whichdrivers
are faster, and which support more features? I assume that I shouldnot use the
type 4 driver since I am not using an applet, but I don't know ifthere are bugs
in the OCI C library for Solaris or in the JDBC drivers that use itthat prevent
XA from woking. Which version of the Oracle C OCI library should Iuse if I use
a type 2 driver?
Thanks,
Ross Goldberg

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

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);

Need help in storing XML data in SQL server using EJB

Hi all...
i have one XML file and i need to store the data of XML in one of the table of SQL server ..i want to do this using EJB..
like this
Example :
Data i XML :
========
<Employee>
<Details>
<empid> 101 </empid>
<name> Ajitha </name>
</Details>
</Employee>
Table i have Created in SQL SERVER:
==============================
Empid || name
Final output should be :
=================
Empid || name
101 || Ajitha

HI,
Please check your settings as per following.
Goto T code> DC20>Define data carrier type "server, front end"---> Then check the setting as per below
Type Description Path Online
PC give descriptio maintain path Tick
Then Select this entry and click on " Define servers and files or folders"--->Then check the setting as per below
Data Carrier Type Description
DEFAULT PC default
Then Select this entry and click on "Identify front computer"--> Then check the setting as per below
Data Carrrier Type Net. address Description
Default PC DEFAULT Default for local PC
I have explained above so that u can co relate your settings with above..
I hope this will help you.
Thanks
Yogesh

Inject EJB using @EJB in Servlet Filter on Weblogic 11g

Hi All,
I want to inject the EJB (Local interface) into the Servlet Filter and the EAR is deployed on Weblogic 11g.
My question is:
Shall the @EJB Annotation work on Weblogic 11g or it will be ignored in case of Servlet or Servlet Filter?
OR
I have to do look up as below and mention the references in web.xml and weblogic xml file:
I know below code should be used when you have remote interface.
Hashtable env = new Hashtable();
env.put( Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory" );
Context ctx = new InitialContext( env );
ctx.lookup( "myejb" );
Thanks

Hi,
It should work in 11g.
Regards,
Kal

Should I use EJB?

Similar Messages

Maybe you are looking for