Bean advantage!

Hi!
What is the advantage of using a javabean?Am new to JSP and I feel that I can use an include file in a JSP page rather than using a bean.May I know the advantage pl!Can anybody help?Thanks.

Try it
http://www.devshed.com/Server_Side/Java/JSP/JSP7/page6.html
Hope it helps.
Hafizur Rahman
SCJP

Similar Messages

Need advise on selecting the IDE for swing UI development

Hi,
I'm looking for a best IDE for developing swing application.
Our application is a Rich Desktop Client Application which will have more than one hunderd screens. And all the business logics will be J2EE EJB services.
At the initial stage, we thought of using the .net winform technology as Desktop Rich GUI for its best look & feel and productivity perspective, by invoking the business services thru webservices.
But later, we decided to use swing components which are somewhat promising now-a-days. This will avoid the multi-platform issues, maintainability and perfomance difficulties.
I would be so much grateful, if somebody could share me their experience on deciding the IDE which would be the best for Swing development currently.
If any one has the list of different swing UI builder IDE and the feedback list correspondingly, could you post them?
..Thiruppathy.R

Thanks All!!
I experienced both NetBeans and Eclipse recently. I did not work in-depth in any of these IDEs for swing application. All the observations are from my first impression on them.
Please find the below are my feedback on both of these IDEs from my experience in the swing application development perspective :
Net Beans
Advantages:
1. Palette Manager option is good -> I can add the custom components to the palette very easily and make them available to use them readily.
2. IDE Layout / Framework is impressive -> In the swing design mode, the palette, properties, inspector and source all are evenly arranged in a way that things can be managed smoothly. It's very impressive.
3. Swing Components Alignment options are good -> IDE is very smart in arranging the swing components in the Panel or Frame. Even it helps the user by showing the alignment lines in the background. So we can definitely say that Net Beans has come in much better shape.
Disadvantages:
1. I am not allowed to change the generated code in the IDE.
2. I can't change the component name or event method name, other than the IDE generated one.
3. Additional Design codes will be reflected only at the runtime, but not at the design time. Here the developer is loosing the flexibility of using the code changes that impact the design.
Eclipse - Visual Editor
Advantages:
1. Source and Design mode, both can be viewed simultaneously.
2. Source and design, both are in sync all the time. The user have the complete control with the code.
3. As everyone knows, the IDE is very powerful and ease of use.
Disadvantages:
1. I can't add any custom components to the palette to make it available for ready use. Only option is 'Choose Bean' to add the custom components. So I should remember the component name everytime while adding in the panel / frame.
I also tried few commercial plugins with Eclipse. Given below is my feedback from my experience,
1. Eclipse - JFormDesigner
Advantage:
1. It provides Palette Manager option and very smart in the swing components alignment settings.
DisAdvantages:
1. For the design mode, it uses JFD file and later java code will be generated from this JFD file. So what you are seeing in the design mode is JFD file, not our java source. Developer have no option to see the source changes in the design mode.
2. It is a commercial product.
2. Eclipse -> Jigloo
Advantage:
1. Easy to use.
2. Custom swing components can be added the Palette.
Disadvantage:
1. It is similar to Eclipse - Visual Editor, but the difference is in the look and feel of the palette and event handlings.
2. For commercial purpose, you have to purchase it.
I also tried the JBuilder, but seems that it provides the Eclipse - Visual Editor for Swing Application development.
I didn't try the IntelliJ IDE yet, for swing application development. Some of the forum responses tells that IntelliJ IDE is very powerful, but not recommended for swing application development.
Eclipse - Visual Editor is promissing and it's open source. As I'm beginner to the swing development, I might have some short vision on some of the above said items.
If somebody have a better comparison sheet and could share with us, I would be grateful.
..Thiruppathy.R

Can anyone explain the advantage of entity beans

Hi All,
I was wondering if anyone can explain the advantage of entity beans versus session beans. We argue that session beans can perform retrival/storage more efficiently than having an extra layer of entity beans. Basically we can't see any advantage entity beans have to offer except caching a row in a database table. I'd like to see the other side of the argument. So please if someone is an expert in this field, please advise us.
Thanks in advance for any argument
Regards,
Di

-Caching the data is one.
-Seperation of logical layer. Entity beans are used to represent the data layer, while session beans hold the business rules. This is some what nebulous as some business rules are often best implement directly in the database, although they might be replicated at a different level as well.
-Mapping a logical layout to a physical layout. For example 'customer' might have a 'fax' and 'voice' line which is represented as a Customer class with two TN classes hanging off of it. The database might represent this in one of two ways: two tables (customer and TN) or one table (customer with two tn fields).
Both of the above are more readily apparent when dealing with distributed data. If one database holds the customer and another holds the TNs, then caching of data is more relevant and dealing with the actual CRUD stuff is much more complicated. This is likely to lead to a session bean offloading the logic to another class anyways - and it becomes a defacto bean.
And a really excellent example is when the entity bean represents data that isn't accessed via normal database calls. For example the customer record might be on a legacy system which can only be accessed via screen scrapping and batch input. That single customer entity is now the front end for a large sub-system.
All such answers are usually pretty wishy-washy anyways. Why should one use java over C++? Most decisions of this nature are made because developers want to use something rather than because there is any strong technical reason to do so. And even though keeping the data layer seperate for the rules layer seems like a good idea, compromises are always required and adding layers adds complexity.

I can not fine the Entity Bean's advantage than Java Bean?

I can not fine the Entity Bean's advantage than Java Bean,
can you tell me, thanks a lot?

I can not fine the Entity Bean's advantage than Java
Bean,
can you tell me, thanks a lot?I think you should read more of the EJB Spec. You'll find your answer there. But mainly with entities you can have the container manage all the lifecyle of the Bean (transactions, caching, creation, etc...). But entities are not only to map columns in the database, they are supposed to have business code. See more by reading the spec.
MSB

What are the advantages stateful session beans takes over than HttpSession

Hi
We can use HttpSession to maintain the conversational state with the client.
Then why we need to go for stateful session beans to maintain conversational state with the client.
What are advantages we can have while using stateful session beans ratherthan HttpSession????.
Regards
Dhinesh kumar R

I think we can use the magic word in the software development "seperation of concerns" ;-)
HttpSession is in the Servlet/JSP tier and is mainly used in the presentation logic tier (UI, page flows, navigation etc..)
where the stateful session bean's concern is to maintain a conversational state in a business logic tier.
Through this seperation its possible, that the business tier's state is undependant from the HttpSession and you dont create a hardlink that could cause problems later. Imagine having a desktop client accessing your business logic etc. not every client needs to be a web client ;-)
I hope that the answer helps you understanding the topic :-)
Brgds,
Nail

To use Entity Bean or Oracle stored Package?

Currently, in my project, Weblogic8.1 and Oracle is used, but lots of business logic is implemented using Oracle stored Packages, many of these packages have a package level readonly lookup table(like index-by table or nested table), which is populated with data from database, once the package is called, and is accessed very often in subsequent calls of stored procedures.
Since, in Weblogic server, a connection pool is maintained, and those package level lookup tables would be stored as session data in oracle PGA, I'm afraid this might cause oracle database server to be overloaded.
to fully take advantage of middleware cache service that weblogic provide, should I move those business logic out of oracle and implement them using like read only entity bean?
any help appreciated!

Its very hard to say without knowing the usage patterns of the data. It sounds like you have a lot of read-only entities. These could be spread around a WLS cluster, therefore there is more scalability and performance with this option. However, I would not neccessarily rewrite business logic from SP into EJB just for middle-tier caching.
If its a DB intensive app with lots of SQL, then if the calls are within SP's, there is only 1 call from WLS and the DBA ought o be able to tune the DB usin read-ahead and other DBA semantics. If there is locality of reference in the data, again, DB can use read-ahead better than WLS, although RO cache in middle is more scalable than DBMS.
I wouldnt rewrite business logic from SP to EJB/Entity beans to take advantage of cache, especially if there is no locality of read-only reference to data. Oracle could do this better in my opinion, especially if SP's already exist
Need for information on the usage patterns of the data - how is it CRUD'd.
I would use-case the steel threads and put them under test load to see if the SP's really are an issue, since this is an architecture decision. What state is the project at? Live/Dev? Inception?

Java Bean Connectivity and Closing Connections (XI 3.0)

Hi guys,
We have existing Java Beans that we would like to use with Crystal Reports. Our current Java beans return a disconnected GridModel and explicitly close the connection immediately after so that they can be returned to the connection pool (Oracle).
Once we modified these beans to return ResultSets we found that closing the connection also closes all the associated ResultSets and Statements.
What is the best practice here?
Modify the Java bean to close the connection in the finally block?
Will Crystal clean up after itself?
I also see there is something called a CachedRowSet which is disconnected:
http://java.sun.com/j2se/1.5.0/docs/api/javax/sql/rowset/CachedRowSet.html
Is this supported by Crystal?
Thanks,
Kevin D Lee =)

Hello Kevin,
Enterprise XI 3.0 CRConfig.xml points to Java JRE 1.5 provided with the install, so you should be ok with the CachedRowSet.
It's used by other customers for disconnected operation.
Since you're going to Oracle, you'd likely encounter issues mapping Oracle fields to POJO property types.
Furthermore, POJO Factory libraries that were shipped with Crystal Reports XI Release 2 aren't shipped with Enterprise XI 3.0, so you'd not find that an out-of-the-box option.
Another alternative to CachedRowSet is to define callback method in your JavaBeans class that Crystal will call when it's done with the data source.
This has been implemented in XI 3.0 (track ADAPT00877915) - excerpt from the track note:
<JavaBeans>
    <CacheRowSetSize>100</CacheRowSetSize>
     <JavaBeansClassPath>c:\javabeans\</JavaBeansClassPath>
     <CallBackFunction>CrystalReportsLogoff</CallBackFunction>
</JavaBeans>
      Customer can configuration the <CallBackFunction/> to let CR know
      which function should be invoked when loging off.
Advantage of CachedRowSet is that you can immediately close it after you've read all the data, disadvantage would be the default implementation stores all data in memory.
Advantage of the callback method is that it would use the JavaBean you've supplied (and not load all data immediately in memory), but callback won't be called immediately, but only after the report is done with.
Sincerely,
Ted Ueda

Multiple instances of the same entity bean?

I am designing a J2EE application that is made up of a number of separate components that each have a well-defined responsibility. Each component is made up of one or more J2EE components (web clients and EJBs). I want to design the application such that it is easy in the future to deploy each component (or a group of components) on different servers. In order to do this I need to make sure that the interfaces between each component are exposed as remote interfaces (but I will use local interfaces inside each component). However, there are a number of entity beans that need to be accessed by more than one component. I am wondering how best to expose these entity beans. I believe there are a number of options:
1. Expose remote interfaces on each of the shared entity beans. The disadvantage of this approach is that it is inefficient and that I will not be able to take advantage of container managed relationships. (I am intending to use container managed persistence.)
2. Create a facade object (stateful session bean) for each of the entity beans which exposes a remote interface and in turn accesses the shared entity beans locally. The disadvantage of this approach is that I have to create some extra EJBs and that I cannot directly make use of container managed relationships etc from the client component.
3. I don't know if this is an option but I am wondering whether I can deploy a copy of each shared entity bean with each application component. The advantage of this approach is that the component would access the entity locally and could make use of container managed relationships. However, I don't know what the issues are with having more than one instance (per primary-key) of an entity in the same application. I don't know whether this would cause errors of whether they would get out of sync (because different instances with the same primary key would be updated by different clients). Initially each component would be deployed in the same server but later they would be deployed in different servers. In both cases with this option each component (JAR) would have copies of the shared entity bean classes.
Any suggestions as to the best approach and whether the last option is feasible would be much appreciated.
Thanks.

I think 2 beats 1. The main reason being to minimise the number of network calls. You're basically asking, are fascades a good idea? and the answer is yes.
You can obviously do 3 in different app servers. However you'll need to configure your app servers so they can handle the fact that they're not the only ones updating the database. This is to handle concurrency as you mentioned. How you do this will depend on your app server and will affect performance, but shouldn't be a problem.
I think you should definately decide up front what's going in different app servers, I dunno if 3 would work in the same app server.
Why do you would want to use multiple app servers?
Why not have everything in the same app?
Is is just the 1 database?
You can use clustering for scalability.

Should we really go for bean data controls for a new project?

Hi,
I am still new data controls and trying to figure out the advantages of using bean data controls for our new project. Our UI is going to have customized UI components and our back end is going to be a tcp/ip server.
Is it a good idea to develop java beans and then create data controls to bind to UI layer? I think it makes sense to use data controls if we want to use existing java beans. Maybe we would be separating the model layer by using data controls, but only thing it would be doing for us would be the simple object calls to my java beans. Would it be better to use data controls or use I choose to make object calls?
Thanks,
Manoj

Hi,
the POJO data control will always give you a benefit and develope productivity, unless what you have to build fits on a single page - in which case you may not mind the burdon of manual UI component binding
Frank

Any difference in creating a web service from a java class or session bean?

Hi,
The JDeveloper tutorial at http://www.oracle.com/technology/obe/obe1013jdev/10131/devdepandmanagingws/devdepandmanagingws.htm demonstrates creating a web service from a plain java class. I'm wondering:
- Is it possible to create a web service from a stateless session bean instead of a java class? If so, what's the proper way to do this in JDeveloper? When I tried doing so in JDeveloper 10.1.3.0.4 (SU5) using the J2EE Web Service wizard, the wizard did not list the session bean in the Component To Publish dropdown (it does list any java classes available in the project). I can proceed by manually typing in the name of the session bean. After the wizard completes though, the @Stateless annotation that had been in my session bean class code is removed and replaced by a @WebService annotation. The end result is that it looks like it made no difference whether I had tried to create the web service from a session bean or plain java class as the annotations in the resulting web service code are the same (although if I had started from a session bean, the class for the web service still implements the Local/Remote EJB interface that the session bean originally implemented).
- Assuming it's possible to create a web service from a stateless session bean, is there any advantage/disadvantage creating a web service from a java class vs a stateless session bean? I'm creating the web service from scratch so I also need to either build the java class or stateless session bean the web service would be based on from scratch too.
Thanks for any ideas about this.

Hi,
EJB Session beans (EJB 3.0) are deployed as WebServices by annotating the class with @WebService and the methds with @WebMethod (both tags require you to add the JSR-181 library to your project (available in the JDeveloper list of libraries)). Unlike the J2E WebService, the EJB session bean service is turned into a WebService upon deployment. This means you obtain teh WSDL file after deployment
- Assuming it's possible to create a web service from a stateless session bean, is there any advantage/disadvantage creating a web service from a java class vs a stateless session bean?
The difference is that EJB Session bean based web services are integrated with the J2EE container, which means that they can leverage container services like transaction handling, data sources, security, JMS etc.
Frank

Bean or Container Managed Persistence

Hi,
I've been reading up on the Sun J2EE tutorial. One of the topics there is bean or container managed persistence. It states that container managed is easier for developers and allows for more portability. The class codes are much smaller compared to bean managed and developers need not worry about database queries.
Can anyone share their experiences on this? Any 'Real World' advantages and disadvantages? Is there a guideline I can follow when to use bean or container managed persistence?
Thanks,
-Ray

That seems like an obvious flaw. So why was it even considered in the
J2EE framework? I mean wouldn't the J2EE architects immediately realize
that? Just doesn't make sense to me why there's even a tutorial or books
for it. What does it suppose to solve then??I know what you mean... again, I think they thought it looked good on paper.
And it gets worse...
Before you use Entity Beans you must be absolutely sure that there will never be another app that accesses the underlying table that doesnt use the EntityBean to do it... For example a C++ App that accesses the tables directly... otherwise you have to set a flag in the App Server that states that basically every time a property on an EntityBean is read the Bean will have to RE-READ the beans state from the database!!
Some things look really good, from an OO perspective, but dont work really well in reality. Sure Entity Beans look really good in the example program in the tutorial, but what happens when you multiply the number of entity beans by 1000, 100,000, or more? Just think of the CPU, and Memory overhead for instantiating all those objects!
There are people out there who believe that using Stored Procedures is a no-no because in their minds it puts "Business Logic" on the database and not the App Server...To this I say... BUNK... Ive seen several instances where by simply moving a set of queries from the App Server to a stored procedure on the database, allowed for a 10-20 times performance gain because of the elimination of network IO. In one instance I saw a query go from 3 hours execution time on the App Server to under 10 minutes on the database... But stored procedures arent OO...
So IMHO before you use EntityBeans at all... be absolutely sure you understand all of the ins-and-outs of doing so.

EJB entity beans and BC4J

I have looked at BC4J and it looks good. Buy my question is that isn't this frame work in direct conflict with EJB entity beans. I know lot of stuff that is there in BC4J should have been in EJB enitiy beans, but as a developer why should I go with BC4J and not the standard EJB stuff considering the fact that BC4J is properietery to Oracle?Any thoughts?

Vimal,
Without going into exhaustive detail here, I would like to recommend that you take a look at the BC4J Technical White Paper available from the JDeveloper page on OTN (in the 3.0 Technical Information section):
http://technet.oracle.com/products/jdev/info/techwp20/wp.html
Amoung other things to note, BC4J is based on pure Java, and is what we consider a 'white box', meaning, you as a developer have complete control over what is going on. You can extend any of the code generated to customize it.
Primarily though, the major benefit of BC4J is that we have taken care of most of the complicated communication code for you. Communication between the client and the data server, transaction handling, row locking, etc are already written for you. You just use, extend, customize what we have provided.
In addition, BC4J allows you flexibility in your deployment environment decision. Regardless of where and how you deploy your BC4J Application Module, the client is unchanged.
Those are the key advantages. Again, for more details, I would take a look at the white paper to see if it more fully addresses your questions.

Container Managed Entity Beans and Client Identifier in Oracle

Is it possible to use Container Managed Entity Beans (EJB with CMP)
in a way that the Oracle database sessions still know the
individual Client Identifiers of the actual users
(not just the Identifier of the proxy user defined in the
Connection Pool)?
If Yes: How?
If No: The consequence would be that the
technologies EJB with CMP cannot be user together with
Oracle Virtual Private Databases (VPN) because VPN requires
some kind of Client Identifier.
I am grateful for any hint.
Regards,
Martin Siepmann
+49 (0)163 / 7765328

Not quite an auto-incrementing PK, but it is managed by the container. the following is from the turorial
Generating Primary Key Values
For some entity beans, the value of a primary key has a meaning for the business entity. For example, in an entity bean that represents a phone call to a support center, the primary key might include a time stamp that indicates when the call was received. But for other beans, the key's value is arbitrary--provided that it's unique. With container-managed persistence, these key values can be generated automatically by the EJB container. To take advantage of this feature, an entity bean must meet these requirements:
* In the deployment descriptor, the primary key class is defined as a java.lang.Object. The primary key field is not specified.
* In the home interface, the argument of the findByPrimaryKey method must be a java.lang.Object.
* In the entity bean class, the return type of the ejbCreate method must be a java.lang.Object.
In these entity beans, the primary key values are in an internal field that only the EJB container can access. You cannot associate the primary key with a persistent field or any other instance variable. However, you can fetch the bean's primary key by invoking the getPrimaryKey method, and you can locate the bean by invoking its findByPrimaryKey method.
Maybe that is good enough
christina

Handling Transaction in Stateful Session Bean

I wrote a public method like public void doTransaction()
it will call 2 private method, like: methodA and methodB
Both private methods have db accesss statement and will update the db. They got different db connection and will close the connection when method call finished.
How to include them to one transaction? I want to be able to rollback the job of the first method when I catch exception thrown by the second method.
I tried simply define transaction type of the public method to be Container and Required. But it doesn't work, the first method doesn't rollback. Of course I can let the 2 private methods share a same connection and commit after finishing calling them. But how if they are in different DB?

Ok... Here it goes...
You can do it in the following manner.
As you said you have got 2 private methods doing d/b updates and these are called from a public method.
Stateful session beans since associated with a client across methods, you can take advantage of it. Write your own user defined transaction.
Begin the transaction scope in your public before calling the 1st private method. Call the 2 methods in a try block. Once you are done with these methods, you can commit and end the transaction. If you get any exception, rollback the transaction in the catch block. Otherwise if u get any exception in the 2nd method, you can rollback the transaction there itself.
Stateful session beans lets u allow to spawn the bean managed transaction across methods. you can begin your transaction in one method and end it in a differnt method or you can end the transaction after calling the methods.
The problem you are dealing with can typically very well handled by writing bean managed transaction.
Hope this helps. If you need anymore clarity on my solution, please let me know.
-amit

Using custom classes that are not beans

Hi folks,
Is it possible to use java classes that are not beans. I mean, on a page, could you say Customer cust = new Customer("Jones", 25);
if you had a Customer class with a constructor that took a name and age (String and int).
If so, how do you go about this- do you need to import the class, or put it in a standard location? I'm using Tomcat, and would guess that this would go in WEB-INF/classes?
I hope it's not a stupid question, all the literature seems to be focused on JavaBeans
Any advice on this would be great!

Beans are used as putting Java code into a JSP is generally considered bad practice. The advantage of the bean pattern is that you use things like:
<jsp:setProperty name="laBean" property="someSetter" value="someValue" />so that you aren't embedding Java directly into the JSP. I'm not very religious about this particular topic personally and will throw a line or two in here and there.
Having said that though, you can easily use any Java class in a JSP. You'll have to import it first:
<%@ page import="java.util.*" %>And then you can easily use it like in a real Java program.

Bean advantage!

Similar Messages

Maybe you are looking for