Sign in or 
Location: ADF Methodology - Work in Progress
Discussion: Why not EJBs?
Category:
Discussion Forum /
General Discussion
Share this
Showing 7 posts
|
pa_ko |
Why not EJBs?
Jul 12 2008, 3:48 AM EDT
I notice that ADF methodology doesn't consider EJBs as "standard" development step? While BCs, which are definitely non-standard (proprietary) technology, are considered "standard"? This is wrong. I can understand Oracle's sentimental reasons for keeping BCs a live, but the EJBs are standard and the future belongs to them (the EJB 3.1, JPA 2.0 coming this year).
3
out of
4 found this valuable.
Do you?
Keyword tags:
adf
jdeveloper
|
|
Avrom |
1. RE: Why not EJBs?
Jul 13 2008, 10:57 PM EDT
It's not really a matter of what's "standard"; in fact, the acceptability of proprietary frameworks is one of the questions considered in the first section of the page. If the answer is no, then ADF BC is not an ideal choice for your project...but I'm not quite sure ADF Faces RC is, either--those components are, as of now at least, proprietary as well (they're built on top of Trinidad, but they aren't currently part of Trinidad).On the other hand, ADF BC does have a *lot* of functionality built in that EJBs don't--take a look at the entire *huge* declarative validation framework in 11g, for example. I'm also not sure the *Oracle* future belongs to EJBs, considering that the entire OA framework is built on top of ADF BC. It's also not like Oracle is just "keeping them alive" with the bare minimum of bugfixes; 11g is a very serious revision to BCs, the first in a while. 1 out of 1 found this valuable. Do you? |
|
pa_ko |
2. RE: Why not EJBs?
Jul 14 2008, 2:33 PM EDT
Well, if you look in to JDeveloper 11g evolution, form Tp1 to Tp4, you will notice:1. In TP1-TP2, EJBs were technology choice in Fusion Application stack. 2. In TP1-TP2, EJBs support was much improved (data controls, bindings, wizards...) compared to 10g. For me it was clearly visible that Oracle is investing in EJBs as well as into EclipseLink. 3. After TP3, BCs are again put in the middle again (Fusion dev stack now again is ADF RC + BCs). EJBs support was staled – no new wizards, empty placeholders in wizards for EJBs etc. Coinciding with Oracles numerous acquisitions (BEA WebLogic), latency in Fusion AS 11g production (migration of old PL/SQL code to true ADF RC multitier Web UI), I beleive they decided to drop EJBs as platform for porting 11g (as it is much easier with BCs when you have a lot of legacy PL/SQL code and SPs). While EJB 3.1 and JPA 2.0 is much advanced and Java-friendly that BCs, they decided to postpone support for EJBs in R1 (both Fusion 11g AS and JDev 11g) as they don't need them right now and they will be ready when new standards are in place (they will got some breathing space with just porting UI to ADF RC while middle-tier is good enough even on BCs). Regarding declarative validation, please note that JPA 2.0 will support Bean Validation annotations (JSR-303). So, BCs declarative validation is nothing special and is much simplified compared to JSR-303. So, if we neglect Oracles emotive relation to BCs as well as pragmatic reasons (hurry to deliver new, fancy, Rich UI to their apps), the future of EJBs is much brighter than BCs. You can promote ADF Methodology with BCs is focus, but you will make a bad influence on many developers which will go that way and learn (in year or two) that there is something much better out there (named EJBs, in core of JEE 6 coming next year). 1 out of 1 found this valuable. Do you? |
|
Avrom |
3. RE: Why not EJBs?
Jul 14 2008, 4:27 PM EDT
I dunno. JSR-303 is a huge step forward, certainly, but how much work it will require individual developers to do depends a fair bit on what "built-in" validators are included (the spec draft doesn't say). Implementing, say, the equivalent of a UniqueKeyValidator or ExpressionValidator strikes me as not exactly trivial, for example. I'd also like to see a way you could specify something like business logic groups in a declarative fashion (as opposed to having to do something like introduce polymorphism in your EJB entity beans for a single table, and having to program a new subclass, with different validators, every time a new discriminator comes up).Please note that, if you want to implement your own validators in ADF BC, you can do that (that's not even new to 11g--you've been able to do that since the old JBO days, IIRC), which I think gives you pretty much all the flexibility you see in JSR-303. Or do you mean something else by "much simplified"? And that's just validation. It's ignoring issues like managed state or JDBC tuning. Neither is exactly out-of-the-box with EJB. Obviously, in the general J2EE community, the future of EJBs is much brighter than that of ADF BC. *Any* official Java standard has a brighter future than *any* company's proprietary technology in the general J2EE community. But even ignoring Oracle's "emotive relationship" to ADF BC, I'm unconvinced that EJB is a superior technology (from a functionality, rather than an openness, perspective) to ADF BC. And if you factor in the increased productivity for people with a PL/SQL or Forms background, I'm unconvinced that it's even nearly as good for those individuals. (I might feel differently about this whole question if this session were aimed primarily at developers with a J2EE-centirc background, as opposed to an Oracle-centric background. But it isn't.) 1 out of 1 found this valuable. Do you? |
|
pa_ko |
4. RE: Why not EJBs?
Jul 20 2008, 9:03 AM EDT
While we can go in details comparing JSR-303 and ADF BCs validation, I think it is pointless at this occasion. While BCs have strengths, there are also weaknesses. And vice-versa for JSR-303. So, the total productivity impact cannot be weighted by case-by-case comparison of "features" but by "at large" effect of one technology or the other in real-world projects. And this will also depend on type of project: large/small, complex/simple, development methodology, programmers habits etc. The point here is that your title "ADF Methodology" is misleading. It should be "ADF Methodology for BCs" or even more honestly "ADF Methodology for Oracle-centric developers (with strong Forms background)". 1 out of 1 found this valuable. Do you? |
|
Avrom |
5. RE: Why not EJBs?
Aug 5 2008, 2:41 PM EDT
In fairness, I'm inclined to agree with this, more or less. We are, now, including a section where we briefly discuss various ADFBC alternatives, but we probably need to clearly call out that this is specifically focused on "ADF end-to-end"--ADF BC + ADF databindings + ADF task flow + ADF faces.1 out of 1 found this valuable. Do you? |
chriscmuir |
6. RE: Why not EJBs?
Aug 5 2008, 6:59 PM EDT
Pa_ko, actually, it's nothing sinister against EJBs, it's just a matter of scope. In starting up this collaborative process I knew that we'd have all sorts of people interested in all sorts of things, mainly because JDeveloper supports so many technologies. While this is great from the tools and developers point of view, it's not great from the collaborative point of view, as I wanted people to focus their efforts. As such I limited the *initial* discussions to ADF BC + ADF Faces RC (a big enough undertaking regardless you'll agree).I'm sorry we haven't picked your exact interests to start with, but as the saying goes, you can only satisfy 80% of the people 20% of the time. Thus I encourage you to start considering your own interests and form your own sub-group among the existing collaborators. In time if the overall ADF methodology moves on, it will hopefully consider EJBs too, + the array of other technologies. By the way, you're being somewhat flippant about "Oracle's sentimental reasons for keeping BCs a live". That's just your subjective opinion. Oracle has announced several times now that ADF BC is core to Fusion Apps and ADF BC has been around far longer than EJB3.0+, that shows resiliance in my books. In dismissing ADF BC as you've done here, you've actually done what we've done to your preferred EJBs, and you can see my response in turn. CM. 4 out of 4 found this valuable. Do you? |
