Hi all,
i know this question has been asked 100 times but we have specials needs.
Using Websphere or Weblogic, we want to create WebServices that "query" approximatively 100 tables.
The goal is to read the objects, no update or creation needed, external batchs, executed many times a day, have in charge to do this work (pb for caching??).
The critical need is the availability, the WebServices will be used by 10 to 15 apps (maybe more) so we need short time response and availability.
Should we use:
1- a full ejb solutions?
2- POJO mapped with hibernate running on WebSphere or WebLogic

How can the second solution take advantage of WebSphere or WebLogic advanced features ?
Is there limitations about caching (don't forget the batchs) and pooling ?

Thanks in advance,
Anthony

How ejb solutions will solve your pb in a better way ?

that is the question i'm asking ;), i'm using hibernate since more than one year, but never have worked with ejb, so i'm asking experts which solution is the best...

You do not need EJB for this use case. I think it better to do without hibernate too, try some simple jdbc framework with agressive cache and without object model betweent DB and Service.

I think it could be usefull for us to use a "reusable" domain model and make object-oriented queries.
We could reuse it (both model domain and queries) on other J2EE apps (not the WebServices), and for this it's easier to go with hibernate isn't it?

We were thinking about the limitations on the domain model design if we choose EJB, the second point is the performance....

As I understand you can implement trivial code generotor for this kind of webservices:

input is some descriptor:

<Method id="methodName(int,String)" return="int">

SELECT count(*) FROM my TABLE WHERE id=$1 and name =$2

</Method>

Output is webservise code or pluggable web method handler without java code generation.

in fact the WebServicesMethod are returning data formatted in XML.
Two ways to do this:

1- JDBC, + webservices "transforms" resultset in XML (that is how it works)
2- Webservices connected to app server and ask Object graph, here we can think about using the real domain model since the XML are the real business representation of the data. I mean, we can have a getArticles() method inside Articles we'll found suplier....
We have in charge to design the best domain model.

With the second way, the advantage is that future apps will be able to use the same domain model + mapping files + some business method.

I found this is very bad way in practice to complicate design for future apps ( You do not know the future ). It has meaning if you reuse model in the same system and at the current time. I found the good way for future is just to have normalized DB without workarounds. I think object model for 100 tables is a compilated thing for data retrieving service and just for transformation data to text .
But it is more philosofy than enginiering :) and if you realy need object model then use hibernate not EJB, hibernate supports more advanced mapping and queries than EJB and I think it is more easy to tune it for performance.

Thank you for your interesting experience and point of view, and excuse me for my english, i know it's not always easy to understand what i mean ;/


In fact, this DB is stable and is a part of our "business" skeleton (commercials apps), i think we will surely reuse it.

But i'll transfer the topic to my team, it will surely help us to take a good decision.

What baliukas said make sense.
But in the EJB vs Hibernate I don't think you'll find critical perf differences between (at not in defavor of Hibernate :) )
- good EJB in cluster impelmentation
- Hibernate + TreeCache or any distributed cache.

thanks again but we have to deal with "external" apps (AS400 for example) and batchs that can update the db so it will be hard to manage a cache

Well, there is even less difference between Hibernate and entity beans in the case of non-exclusive database access. Hibernate should kick the EJB container's ass by giving much more flexible association fetching, query pagination, etc.

Its true that there is some difference between HB and EJB in the case of exclusive access (where you can do caching), since Hibernate never locks in the middle tier and /always/ uses instance-per-transaction. But we think this makes us /more/ scalable, not less.

It must be good to cache generated XML and it must be trivial to manage this kind of cache. Store version number in DB sequence and in memory,
1. incement sequence after batch.
2. query sequence value before to return content form cache, return cached content if version numbers are the same and clear cache if version was changed.
You can optimize version query with some rule dependant on time too.

Baliukas, Gavin, thank you