Which Web Client Framework? BC4J-JSP, UIX-JSP, UIX-XML, etc

Question

Trying to determine which, if any of the JDeveloper frameworks, to use for do web browser (HTML) clients.
What are the pros/cons of BC4J-JSP, UIX-JSP, UIX-XML, etc?
What are some common things you might rule out using one or more of the frameworks?
I plan to be using BC4J, updating, inserting data (currently MS-SQL) and the apps will run on WebLogic 7 or Caucho Resin (webapps no EJB) in a cluster. I would like to be as RAD as possible and still be able to do what I need to do. One main concern is being able to add custom HTML/JavaScript for things like client side validation. I didn't see a way to do this when doing BC4J-JSP. Is that right?
If I define any validation in the BC4J, will UIX utilized any of this to define a JavaScript validator or must it be redudantly defined?
One other concern is what the framework requires in terms of architecture, like do I have to have sticky sessions in my web cluster or can it work fine stateless or stateful?
For UIX-XML, how is this architected for performance? Specifically, is the XML effectively compiled and converted into something more efficient and performant or does it do XML parsing all the time? Is there any significant performance differences between the frameworks?
Is there any significant difference in dealing with security? Anything in the framework to make it easier to handle certain users being able to see/edit different set of data?
I have things like some groups can edit only certain entities (product info but not pricing), others only certain types of products (possibly subclass entities) and others situations where what fields than can edit varies. Obviously I can handle this programmatically, but I was wondering what the frameworks had to offer, especially in terms of having different views of the same data.
Steve

Answer 1

...I am little confused then about how BC4J works and what is meant by "session" here.
When you talk about appmodules in the plural, does this mean that there are potentially multiple instances of the same data on a single server or there is a common datastore with pending data and client specific stuff varying?
The common datastore is the database. Each client (momentarily, during the span of their request) uses an instance of an application module from the pool. The pool can grow and shrink with load on your system and all of the various tuning parameters. Our doc on the AM Pool covers all the parameter settings and their users.
What kind of "session" is this?
It is an abstract notion of a session for a user. The implementation used for Web clients uses the HTTP Session Key as the session key. However, we have other session implementations (and you can provide your own to do custom stuff for more sophisticated needs). We don't store anything else in the HTTP Session to the best of my knowledge. This way in a cluster, the web container doesn't have to waste time propagating all of your serialized HTTP Session state among cluster members. This session key also include an id for the application module and together those provide the key to store your pending state in the database for the "Stateful == Managed State" feature.
I assume that if I have a cluster which doesn't use session-to-same-server-affinity but uses JDBC for http-session persistance or distributed in-memory http-sessions then I cannot use stateful BC4J even though I can use http-sessions.
You can use BC4J in this way because the browser will send a cookie that contains the key to your database-stored pending state. In this way, we work great in a server farm for failover and/or scalability reasons.
Even if I use stateless BC4J, are there issues with round-robin'ng all requests to different servers in a cluster?
As I said, both our Stateless and Stateful features are designed to be used in Server farms, no problem.
BTW I wouldn't necessarily say you picked the wrongs terms for the modes, but I know what you mean. There's problems with these terms. I am trying to explain to my mgrs/engineers that there is some state in stateless transactions - that simply making everything "stateless" doesn't mean don't lose anything in a disastrous failure. I am arguing to get support for sessions in our cluster, that the performance gain and simplified development is worth it as long as you put intelligent limits on what you store in the session. Right now, they are insisting on randomly sending requests into two entirely different data centers, with two different clusters.
Amen. I have seen too many developers make the mistake of trying to be totally stateless, only to completely complicate their development environment with having to peristent partially-completed transaction data to the database. I've seen this done with sets of "Shadow" tables (yuck!) or using hand-written techniques similar to what BC4J provides a robust implementation of in the box.
We've tuned our "Stateless With Affinity for Server Farms" model over several releases of carefully studying the performance of the Web apps built by our internal Oracle Applications teams using BC4J (over 20 of them now, and growing!) so compared with a hand-written strategy for your web-tier state management, using BC4J's implementation will be much more productive for you.
We're tuning and tweaking and enhancing it even more for the 9.0.3 release as new needs are highlighted with continued use by our customers (both Oracle internal and external).