JBossDeveloper

Pretty clearly,
DONT DO THIS!!
you are propagating a jdbc dependent data type (rowset) past the data access layer (entity beans/persistence manager).

If you think rowsets are the ideal container for your data, don't use j2ee, in fact you'll probably be much happier using Delphi, where the equivalent construct (ClientDataSet) is much more powerful than rowsets/resultsets.

If you want to use j2ee:

--inside the vm, use collections of entity beans, accessed from session beans.

--outside the vm, use collections of data objects that specifically contain your data, enforcing type safety.

if you think writing all those data objects is too much work, use xdoclet to do it for you.

Thanks for your answer !
We have two kinds of customer.One of them will use browser to visit business function and another will use a windows GUI client application to do more complicated things.
Now we are planning to use EJB to implement the business logic.For the first kind of customer it will be ok to use the following pattern:
browser ---> Jsp/Servlet -> JavaBean ---> EJB --->RDBMS
And for the second kind of customer we want to use delphi to develop the GUI however the Collection cannot work well with delphi's VCL controls,such as TDBGrid,TDBEdit,etc..So we do need the the finder methods to return other type other than Collection.
Up to now we are studying the com-bridge which will be used to call EJB.And we will use XML(ClientDataSet format) to packgae data.
I have developed multi-tier windows application using delphi for a long time.So it is inevitable for me to misunderstand j2ee because there is no entity bean concept in M$ MTS/COM+.I really hope you can correct me .

Best Regards!

There will always be a tendency for people to gravitate towards what is easy for the moment. EJBs are not convenient to learn, and neither are collections.

If you take the time to learn them though, they become easy. Virtually everything you took the time to work through should be easy for you today.

The question is, when is it worth our effort. I learned an important lesson with the success of SQL and database servers which encourages me not only to take the time to become proficient with EJBs, but yes, Container Managed Persistence (CMP) as well.

The fundamental concept is to let the server do the work, freeing development productivity to focus on business logic. Granted, EJBs and CMP are not quite there, yet; but they, like SQL in its early days, are clearly designed with this direction in mind. This is the fundamental benefit of EJBs over every other technique mentioned on this thread.

If you don't feel that EBJs and CMP are idealistically mature and flexible today, then consider using entity beans based on the principle direction, rather than their complete present capacity. This is what I have done, and have been very happy with both the results, and the position my application is in to exploit future improvements in these technologies.

One side note about stored procedures, which I heard mentioned here... they are inherently vendor dependent. You cannot port Oracle PL/SQL to SQL Server without significant modifications. In order to support more than one database, you create dual+ maintenance by having to duplicate the stored procedures in each vendor's proprietary language.

Perhaps you are convinced you are only developing for one database vendor. What about reusable components you create? What about a RAD framework that sprouts from your work? What about scalability and growth? Do you want to lock yourself into a single database vendor, or create an unnecessary cost for the option of supporting new database vendors down the road?

EJBs help not only to give us the benefits of delegating work to the servers, but they can also open the door to creating unprecedented vendor independence with large long-term payoff. Of course, JDO in general does this. Yet, I am addressing those that consider stored procedures a desirable alternative to EJBs and JavaBeans.

Some of the issues mentioned here are what we have struggled with during the early phases of our development with EJB's. Since we started with the EJB 1.1 spec we had to design without the utility of local interfaces and it was a good experience as it gave us opportunity to really learn HOW to use entitys.

here is my 'rule of thumb' on entitys. use an EJB to represent a row of data or a business object that spans multiple tables. the entity is used for all read/update/and create functions.

Use a session facade for bulk finders, queries that require JOINS or which are going to be purely read operations. Although local intefaces should allow you to put bulk finders in the entity, we have experienced performance degradation when you are loading 300 entitys each containing large amounts of text data. Also, its easier to implement search methods that 'iterate' (e.g. first 10 records, then next 10) in a session bean, then it is to implement the same in a finder method.

IMHO, the ejb spec needs most work on the finder method area. Thats the biggest bottleneck.

Also, the valueObject pattern is very useful for reducing the network traffic. We use VO wrappers to transfer bulk finder results. XML comes in handy here. When the client needs to get one entire object, it then calls the entity directly.

Any comments?

YSK

>>Use a session facade for bulk finders, queries that require JOINS or which are going to be purely read operations.

it is ok for read operations.However if the client modifies the ValueObjects then how do the session bean receives bulk of the changed VOs ?
It seems there is no standard way for bulk write operations :(


Best Regards!

In our project, I have noticed two interesting trends.

First - we had to justify, in excruciating detail why we might want to use Entity Beans. Quite simply, Entity Beans have a really bad press now due to too much bleeding-edge adoption in EJB 1.1. Version 2.0 of the spec strikes me as the first really useful version. Which means being able to write on your system "Entity-bean-free" is politically expedient - using entities is politically risky.

Second - we would not really consider Entity Beans without using XDoclet to force a common 'style' or 'template' on our entity beans (pattern is an overloaded word here). We are connecting to a legacy database, so BMP is the only option, for reasons beyond our control. XDoclet and the 'DAO' or 'valueHolder' pattern ensures our beans stay maintainable even if they're written by different developers with different levels of EJB experience. So in this sense I guess we're an example of some of the trends set out.

You has to write custom finder method in jaws.xml by specifying the where condition.

your finder mehtod is.

java.util.Collection findByEmpname(String empname) throws ...

yur collection having the set of remote interfaces and each remote interface represents one row of DB table.

your jaws.xml should include,




java:/DefaultDS
<type-mapping>mySQL</type-mapping>

<default-entity>
<create-table>true</create-table>
<tuned-updates>false</tuned-updates>
<read-only>false</read-only>
<time-out>300</time-out>
<select-for-update>tue</select-for-update>
<remove-table>false</remove-table>
true
</default-entity>

<enterprise-beans>


<ejb-name>EmployeeBean</ejb-name>
<table-name>Employee</table-name>
<remove-table>false</remove-table>


findByEmpname
instr(empname,{0}) > 0
empname
<read-ahead>true</read-ahead>




</enterprise-beans>





Enjoy,
Jini

On my current project I edged into the use of EB with all the best of intentions. What I hadn't appreciated was that an EJB EB caches the data, and will monitor any changes *it* thinks has been done to the underlying DB. Hence, when somebody came along and *insisted* that they would modify the DB outside the EJB framework (pox on them and their families for 3 generations :-), I had to withdraw my EBs and go back to session beans. Perhaps there was a way out of this, but time didn't allow.

The point is, that unless you can turn off the caching of EBs, EJB may sit badly alongside other applications - and this often happens.

Ian Hunter