|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 46
Messages: 46
Messages: 46
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Does EJB 3.0 really make application development easy?
Raghu Kodali has written a blog entry called Does EJB 3.0 really make application development easy? detailing his migration of one of the J2EE 1.4 tutorials from EJB 2.1 to EJB 3.0 to see if the claims about EJB 3.0 regarding simplicity and code size were true.EJB 3.0 definitely simplifies the development of entity and session beans. Ease of use comes from the simplified model, and leveraging well known artifacts like POJOs and interfaces. The new EntityManager API is a big plus; I was able to make the changes to the business methods quite easily and did not require the need of reading the specification... All the features that make the application development easier will also provide returns in application maintenance cycle. All in all, I will recommend that developers take a fresh and unbiased look at the EJB 3.0 specification, by checking out the features and giving the publicly available EJB 3.0 containers a spin. Publicly available EJB3 containers are available from two places as of this writing:
|
|
|
Message #164591
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Blog: Does EJB 3.0 really make application development easy?
There real name of EJB's should be ETB's (Enterprise Transaction Beans). That's what the spec is about.
In my field experience, there are limits too how much you can (and should) simplify transactional business methods.
|
|
|
Message #164597
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Another EJB 3.0 test container
Caucho (with whom I am not affiliated) have a container that has as least some support for EJB 3.0, I'm not sure how comprehensive it is. They also have some built in support for IoC. http://www.caucho.com
|
|
|
Message #164598
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Another EJB 3.0 test container
I tried to find a link to it on caucho.com, but was unsuccessful: do you have a direct URL?
|
|
|
Message #164610
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
good article
I saw this blog last week and was hoping it would make it to TSS. Great article Raghu.
|
|
|
Message #164612
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
further simplifying using the EJB 3 model
We've announced this before on TSS, but I wanted to shamelessly plug some of JBoss's EJB 3 features while we're on the topic of EJB3. We liked the new EJB 3 development model and thought new features for the Session/MDB side got neglected. So here's some JBoss EJB3 extensions:
I'm hoping that other vendors will pick these extensions up as well and that we can agree on some de facto standard and get an iteration of them in EJB 3.1.
Bill
|
|
|
Message #164623
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
further simplifying using the EJB 3 model
I would like to have methods with transaction lifecycle greater than call/method lifecycle.
In other words, a new thread is kept running with handle to the same transaction as the one started by the called method, while the method returns a value.
Could't we have a EJBContext.createThread(Runnable) in which the container associates the thread to the transaction?
|
|
|
Message #164629
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
further simplifying using the EJB 3 model
I would like to have methods with transaction lifecycle greater than call/method lifecycle. In other words, a new thread is kept running with handle to the same transaction as the one started by the called method, while the method returns a value.Could't we have a EJBContext.createThread(Runnable) in which the container associates the thread to the transaction?
Our asynch EJBs do propagate TX and Security, but I see what you mean. You want even finer grain thread control...
|
|
|
Message #164631
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
further simplifying using the EJB 3 model
I would like to have methods with transaction lifecycle greater than call/method lifecycle. In other words, a new thread is kept running with handle to the same transaction as the one started by the called method, while the method returns a value.Could't we have a EJBContext.createThread(Runnable) in which the container associates the thread to the transaction? Our asynch EJBs do propagate TX and Security, but I see what you mean. You want even finer grain thread control...
It works using Stateful Session Beans (EJB 2.1 Spec, p. 365):
A stateful session bean instance may, but is not required to, commit a started transaction before a business method returns. If a transaction has not been completed by the end of a businessmethod, the container retains the association between the transaction and the instance across multiple client calls until the instance eventually completes the transaction.
|
|
|
Message #164634
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
further simplifying using the EJB 3 model
I would like to have methods with transaction lifecycle greater than call/method lifecycle. In other words, a new thread is kept running with handle to the same transaction as the one started by the called method, while the method returns a value.Could't we have a EJBContext.createThread(Runnable) in which the container associates the thread to the transaction? Our asynch EJBs do propagate TX and Security, but I see what you mean. You want even finer grain thread control...
It works using Stateful Session Beans (EJB 2.1 Spec, p. 365):A stateful session bean instance may, but is not required to, commit a started transaction before a business method returns. If a transaction has not been completed by the end of a businessmethod, the container retains the association between the transaction and the instance across multiple client calls until the instance eventually completes the transaction.
I'm not sure this would actually work...Although the SFSB does retain this information, there is no standard way to propagate TX/Security to another thread (except maybe JCA WorkManager??? Never used it). So what I'm saying is that you couldn't spawn threads to call this SFSB. The EJB Container may/may not throw an exception when you tried this.
Bill
|
|
|
Message #164636
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
further simplifying using the EJB 3 model
I would like to have methods with transaction lifecycle greater than call/method lifecycle. In other words, a new thread is kept running with handle to the same transaction as the one started by the called method, while the method returns a value.Could't we have a EJBContext.createThread(Runnable) in which the container associates the thread to the transaction? Our asynch EJBs do propagate TX and Security, but I see what you mean. You want even finer grain thread control...
It works using Stateful Session Beans (EJB 2.1 Spec, p. 365):A stateful session bean instance may, but is not required to, commit a started transaction before a business method returns. If a transaction has not been completed by the end of a businessmethod, the container retains the association between the transaction and the instance across multiple client calls until the instance eventually completes the transaction.
I'm not talking about tx propagation between calls, but between threads, which I think it's a major EJB limitation.
let's say
1. methodCall on thread 1
2. txmgr.begin
3. actual method call
3.1. get adapter A
3.2. enlist adapter A in tx 1
3.3. new thread 2
3.4 runnable->run get adapter B
3.5 enlist adapter B in tx 1
...
...
method return
thread 1 dies
...
...
thread 2 before dying.
tx 1 commit
thread 2 dies
|
|
|
Message #164651
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
whats a pojo
Plain old java object. A term coined by Martin Fowler to denote a standalone java class that can be executed in any environment. That is, it doesn't need any framework nor application container.
|
|
|
Message #164653
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
further simplifying using the EJB 3 model
You get that with the JSR 236/237. These will give fine grained threading. I'd question the value of the JBoss async calls given that work is coming. The same thing can be done with slightly more code using these JSRs.
Billy
|
|
|
Message #164655
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
further simplifying using the EJB 3 model
We have a lot of resistance to moving a transaction from one thread to another. The async beans code in WebSphere 6.0 does the following:
* JNDI and component meta data
The new thread can use the same JNDI stuff as the component that created it
* Security
Any credential on the old thread is propogated
* Transaction
It has no impact on the existing tr if any on the original thread. The new thread has a local transaction by default and the developer may start a global transaction if it chooses
* i18n
Copied over
* Profiles (WAS feature)
Copied over.
Basically the Runnable runs with an exact copy of the thread context of the creator with the exception of the transaction. WebSphere allows this to be tuned so that only a subset is copied (performance reasons).
|
|
|
Message #164658
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
further simplifying using the EJB 3 model
You get that with the JSR 236/237. These will give fine grained threading. I'd question the value of the JBoss async calls given that work is coming. The same thing can be done with slightly more code using these JSRs.Billy
Well, that's the whole point...Less coding, simpler development. I don't think 236 nor 237 come close to addressing simplicity. I don't know how many times I've gone to a site that was using MDBs just for asynchronicity. Talk about using a sledgehammer...
Bill
|
|
|
Message #164669
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
further simplifying using the EJB 3 model
Talk about using a sledgehammer...
Unfortunately, QoS-by-contract and simplicity are often conceptually at odds. I have seen MDBs being used for async as well, but it's not that much of a sledgehammer, and it's getting simpler.
No offense, but you (Bill) and Billy are talking about two fundamentally different approaches to systems. I've seen them both, and I can tell you which one is being used to run the major financial exchanges.
Peace,
Cameron Purdy
Tangosol, Inc.
Coherence: Cluster your POJOs!
|
|
|
Message #164670
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
further simplifying using the EJB 3 model
We've announced this before on TSS, but I wanted to shamelessly plug some of JBoss's EJB 3 features while we're on the topic of EJB3.
Bill, it's shameless how you hi-jacked this thread from being a good documented example of using the Oracle EJB 3.0 Preview to easily and successfully migrate an app! :-)
<<blockquote>I'm hoping that other vendors will pick these extensions up as well and that we can agree on some de facto standard and get an iteration of them in EJB 3.1>
So many things to consider, so little time...
I am not yet convinced that these things will make the spec better or simpler, but will gladly reserve judgment until later on to see if people actually try out these types of proprietary features.
-Mike
|
|
|
Message #164676
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
further simplifying using the EJB 3 model
We've announced this before on TSS, but I wanted to shamelessly plug some of JBoss's EJB 3 features while we're on the topic of EJB3. Bill, it's shameless how you hi-jacked this thread from being a good documented example of using the Oracle EJB 3.0 Preview to easily and successfully migrate an app!
If I didn't, you'd have like zero comments on this thread...It is hard to argue against a well written blog/article such as Raghu's. So good, I've referenced it from our WIKI.
|
|
|
Message #164689
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
further simplifying using the EJB 3 model
Unfortunately, QoS-by-contract and simplicity are often conceptually at odds.
I don't think so at all. For example in a servlet's descriptor I could switch amongst security constraints (none, integrity, confidentiality) without recompiling. Asynchronicity seems just another delivery parameter, likely easily annotated.
|
|
|
Message #164696
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
further simplifying using the EJB 3 model
I don't mind simpler programming model so long as when I need to kick down, I can. Thats what 236/237 addresses and whats sorely lacking in the spec today. It's too dumbed down and I talk with lots of customers dropping J2EE for J2SE plus some framework not because it's easier but because it's just not possible with J2EE stack. A lot of the changes I've been making in WebSphere are in reaction to this. Async beans gives J2EE application a fully supported threading model. This is being standardized in 236/237 and the WebSphere Partition Facility (WPF) offers hot singleton support for customers that needs asymmetric clusters. The combination of both these features makes WebSphere useful for the highend customer because basically they can do what they need using this 'toolkit', J2EE + Async + WPF.
I think Cameron may be talking to the same customer set. The async API you've proposed could be built very simply as a sample using proxies on top of 236/237, I don't see a whole lot of value making it part of the standard given this.
I prefer this approach. Make the underly primitive APIs available to customers. Make a simple wrapper on top for common use cases but don't hide the primitives because some customer don't like the simple wrapper.
Billy
|
|
|
Message #164707
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
further simplifying using the EJB 3 model
I don't know how many times I've gone to a site that was using MDBs just for asynchronicity. Talk about using a sledgehammer...Bill
I use MDBs not only for asynchronicity, but also for load balancing a system via multiple MDBs with different message selectors.
Using JMX hooks, I can throttle the number of MDBs instances per message selector allowing me to dynamically control the resource load of various "levels" or "weights" of async processes in the container. The JMS queue functions as a persistent threading/process buffer. All of this done with very little infrastructure coding at all.
The one thing I wish were easier to do with MDBs is to be able to either dynamically create new MDBs on the fly or at a minimum to be able to easily change pooled MDB message selectors at run-time.
I am all for making MDBs more lightweight, but don't gut all the functionality they currently have in 2.1 because that sledgehammer is a mighty fine sledgehammer for some of us.
|
|
|
Message #164738
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
further simplifying using the EJB 3 model
I don't mind simpler programming models so long as when I need to kick down, I can (...) I prefer this approach. Make the underlying primitive APIs available to customers. Make a simple wrapper on top for common use cases but don't hide the primitives because some customer don't like the simple wrapper.Billy
I support this view. As I see it, J2EE is about specifications for low-level system services, which is arguably where standardization is most important.
Such low-level APIs are usually not about convenience or simplicity, but rather about allowing to work at a very basic level, not imposing any restrictions in usage style. Consider JDBC or JavaMail as examples: those APIs are powerful (allowing to control each and every detail), but they are arguably not convenient.
This tradeoff is fine, IMO: As long as the low-level APIs are standardized, higher-level conveniences can be built on top of it. This is where application frameworks like Spring and data access libraries like iBATIS SQL Maps come in. The same applies to the Servlet/Portlet APIs and web MVC frameworks that build on them.
Essentially, all of J2EE follows that low-level system service approach - except for EJB, which enters the application domain and provides a specific application component model. The latter is fine for system entry points (such as servlets and remote services), IMO, but less important for local components within an application.
There will always be a demand for different application-level programming models (both in the UI tier and in the middle tier), because of user requirements differing so widely. The beauty of J2EE is that it allows for a rich ecosystem here, all building on the same standardized low-level system services (Servlet API, JTA, JNDI, etc).
Juergen
|
|
|
Message #164757
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Dynamic MDBs
You can do the equivalent of dynamic MDBs in WebSphere 6.0 with very little code. You can also deliver the messages using a custom threading scheme if transactions aren't important (delivering market data feeds etc). We've used this to dynamically subscribe to market data feeds when a particular cluster members needs them. We used a couple of threads to pull a dynamic set of topic subscriptions into WebSphere and then used a sequenced thread pool to deliver those messages to the POJOs interested in the messages. The sequencer delivers the message using a threading model that ensures for a given topic messages are delivered serially whilst messages from different topics are processed in parallel.
When combined with WebSphere Partitioning Facility (WPF, a feature of WebSphere XD) then this becomes a great way for building electronic trading systems or applications with dynamic messaging requirements.
Billy
|
|
|
Message #164773
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
further simplifying using the EJB 3 model
So when can we expect to see IBM release a WebSphere "EJB3" Tech Preview ? (especially given your blatant marketing of WebSphere 6 and all its so-called advanced features).
|
|
|
Message #164784
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
So, nobody says "EJB 3.0 sucks"
When i saw this thread, i firstly thought that people would say lots of negative opinions. I'm just a j2ee newbie and worked only on a hibernate based project. I really want to know if EJB has a future?
|
|
|
Message #164786
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
So, nobody says "EJB 3.0 sucks"
When i saw this thread, i firstly thought that people would say lots of negative opinions. I'm just a j2ee newbie and worked only on a hibernate based project. I really want to know if EJB has a future?
Get with the times, dude. The "EJB sucks" thing was so 2 years ago...
|
|
|
Message #164797
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
So, nobody says "EJB 3.0 sucks"
Get with the times, dude. The "EJB sucks" thing was so 2 years ago...
Well, in the meantime, even Linda - the EJB spec lead - herself essentially says that EJB 2.1 sucks (in her public presentations). Of course, EJB 2.1 is still the official production version of EJB out there, and will continue to play that role for at least a further year.
After all, certified EJB3 containers are still a while away... a lot of early PR doesn't change that fact. Previews are nice, but noone is gonna get certified before the official release of the J2EE 1.5 umbrella spec - which won't happen before early/mid 2006.
So arguably, EJB in its current production incarnation still sucks, and will continue to do so for a while :-)
That said, Oracle's EJB3 preview and the associated documentation look decent. Congratulations, good job there!
There are huge gaps in the API, though, in particular regarding exception handling: There doesn't seem to be any consistent exception strategy in the persistence part, for example. Well, not really a surprise; after all, the spec is still unfinished...
Juergen
|
|
|
Message #164845
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
So, nobody says "EJB 3.0 sucks"
When i saw this thread, i firstly thought that people would say lots of negative opinions. I'm just a j2ee newbie and worked only on a hibernate based project. I really want to know if EJB has a future? Get with the times, dude. The "EJB sucks" thing was so 2 years ago...
You forgot the end "...and can I sell you a container?"
|
|
|
Message #164861
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
further simplifying using the EJB 3 model
It is blatant and yes, I am shameless :) But after Bill plugged the other stuff, I couldn't resist.
But, I do think our stuff is really cool plus I have quite a bit of sweat in it so what can I say.
I can't comment on when we'll have EJB 3.0 in preview or otherwise as it's not announced publicly yet.
Billy
|
|
|
Message #164907
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
So, nobody says "EJB 3.0 sucks"
When i saw this thread, i firstly thought that people would say lots of negative opinions. I'm just a j2ee newbie and worked only on a hibernate based project. I really want to know if EJB has a future? Get with the times, dude. The "EJB sucks" thing was so 2 years ago...
You forgot the end "...and can I sell you a container?"
Who cares whether EJB3 sucks or not? The vendors will have a hard time selling it, won't they?
|
|
|
Message #164917
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
So, nobody says "EJB 3.0 sucks"
After all, certified EJB3 containers are still a while away... a lot of early PR doesn't change that fact. Previews are nice, but noone is gonna get certified before the official release of the J2EE 1.5 umbrella spec - which won't happen before early/mid 2006.
So arguably, EJB in its current production incarnation still sucks, and will continue to do so for a while :-)
OK, so let me get this reasoning straight:
Because an EJB3 implementation cannot be *certified* until mid 2006, it will be impossible to use it in production mid until 2006. This is the case even though there are alpha releases out *now*, and mature releases will certainly be available coincident with the approval of JSR-220 (which has to happen well before the new J2EE rev).
OK, got it.
And as a corollary to that, since Sping/Hibernate can never, ever be certified as compliant with any standard anywhere, nobody anywhere can never ever use Spring/Hibernate in production.
Something wrong there, but I can't quite put my finger on it...
There are huge gaps in the API, though, in particular regarding exception handling: There doesn't seem to be any consistent exception strategy in the persistence part, for example. Well, not really a surprise; after all, the spec is still unfinished...
Very nicely spotted, Juergen. Correct, the spec is not finished. That's why its called "Early Draft Release 2". Ooops, I feel like I'm stating the bleeding obvious....
Cheers mate
|
|
|
Message #164936
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
So, nobody says "EJB 3.0 sucks"
And as a corollary to that, since Sping/Hibernate can never, ever be certified as compliant with any standard anywhere, nobody anywhere can never ever use Spring/Hibernate in production. Spring and Hibernate are mature products with large user bases. Unlike an immature spec, they won't change in a way that breaks user code. With a spec that is evolving, it is likely that application code developed against each snapshot will be broken. It's hard for vendors to protect against that.
If standardization was the be all and end all, people would be using entity beans rather than Hibernate, TopLink, Kodo and others. But they chose to deliver applications that worked and took a reasonable time to deliver...
|
|
|
Message #164967
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
So, nobody says "EJB 3.0 sucks"
Spring and Hibernate are mature products with large user bases
Since EJB 3.0 implementations can be very simple wrappers around mature ORM products like Hibernate/TopLink/Kodo, and mature EJB 2.1 containers, all with even larger user bases, this is spurious.
Unlike an immature spec, they won't change in a way that breaks user code.
Hmmmm .... one month ago, Hibernate changed in a way that broke user code.
Can I take this as the Spring team committing to never make any changes that break user code in any future revision of Spring?
Wow. That's a big call.
If standardization was the be all and end all, people would be using entity beans rather than Hibernate, TopLink, Kodo and others.
Strawman. Nobody here every claimed that standardisation is the be-all/and-all. But, when a technology is sufficiently understood, it makes sense to standardize.
The question really is: what should people starting new projects now, that they expect to go into production in 12 - 18 months time use? Is it safe to adopt EJB3 for *development* now? Maybe, maybe not, depends upon who you are, how risk-averse you are. But there is certainly no doubt that (for non-toy projects) if you are starting a project in three months from now, then by the time you go into production, there will be mature implementations.
|
|
|
Message #164971
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
So, nobody says "EJB 3.0 sucks"
Gavin,
This is not about certification per se, it's about production-readiness of the overall J2EE environment. J2EE servers like WebLogic and WebSphere usually don't declare a version production-ready until it's fully certified for a specific J2EE umbrella spec. You can't simply plug EJB3 into an existing J2EE 1.3 or 1.4 environment there.
The main difference between a library like Hibernate or Spring and an EJB container is that the former drops nicely into existing J2EE environments, interacting with the established server infrastructure, while the latter does not: to properly run a full EJB3 container in a J2EE environment, you need to upgrade your J2EE *server*.
Many people happily drop new Hibernate or Spring versions into applications running in their *existing* J2EE environment. But hardly anyone upgrades the entire J2EE server in an instant; that approvement process can take ages. An in particular, noone will upgrade their entire production J2EE server to a pre-release version.
So how can someone properly adopt EJB 3.0 on, for example, WebLogic or WebSphere before production J2EE 1.5 versions of those servers are out? At best, someone could choose to use standalone "javax.persistence" on such an existing server, but that's hardly full EJB 3.0. Direct Hibernate or TopLink usage might be a better choice in such scenarios.
I am aware that the JBoss EJB3 preview is implemented as add-on to JBoss4. However, I doubt that this strategy can last beyond the previews, in particular due to the conflict between the EJB3 jar and the old EJB2 jar. In the current previews, there is just an excerpt of EJB3 in the jar, but what to do with the final, full EJB3 implementation, which is bound to have overlap with the old EJB2 API classes?
Juergen
|
|
|
Message #164972
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
So, nobody says "EJB 3.0 sucks"
Hmmmm .... one month ago, Hibernate changed in a way that broke user code. True. No doubt you had valid reasons for making that choice. But the migration exercise wasn't too hard, as the same mappings should work and the API is quite similar (if a superset). If your user community had objected violently you no doubt wouldn't have made the same degree of changes, so it's not like there was no accountability there. Furthermore, as with any technology meant to act on POJOs, users with well-designed Hibernate applications should find that most of their domain model should require no change. The POJO point is crucial here.
Can I take this as the Spring team committing to never make any changes that break user code in any future revision of Spring? Well our record on backward compatibility so far has been excellent. Compared for example with EJB 1.0 - 1.1 - 2.x - 3.0. I'm happy to make a commitment to continue that excellent record. It's not so difficult with a well-designed framework using Dependency Injection and AOP.
Realistically you can never get 100%. E.g. if you upgrade most app servers to a major or even a point release--even on the same specification version--typically any really complex application will break. But will usually be easy enough to fix. But we are confident that we can continue to be damn close to 100%.
Anyway, the extreme twist on this came from you, not me. My point was that we know that the evolution of the EJB3 spec towards the final product is likely to break code written against it now; it's unlikely that the same is true of code written against Spring now, because lots of applications have been written against it, many corner cases identified and addressed etc.
I'm not quite sure what we're arguing about at this point: as you rightly say, it's a decision for companies to make whether or not they're comfortable developing against a non-final spec, not for us to make for them.
Rgds
Rod
|
|
|
Message #164989
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
further simplifying using the EJB 3 model
It is blatant and yes, I am shameless :) But after Bill plugged the other stuff, I couldn't resist.But, I do think our stuff is really cool plus I have quite a bit of sweat in it so what can I say.I can't comment on when we'll have EJB 3.0 in preview or otherwise as it's not announced publicly yet.Billy
Actually we (Oracle)will support EJB 3.0 features in production release of Oracle Application Server 10g 10.1.3 (planned to shipped this summer)as fully supported feature so customers do not have wait another one year and get a jumpstart in building EJB 3.0 applications.
Debu Panda
Oracle
http://radio.weblogs.com/0135826/
|
|
|
Message #165003
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
So, nobody says "EJB 3.0 sucks"
Gavin,This is not about certification per se, it's about production-readiness of the overall J2EE environment. J2EE servers like WebLogic and WebSphere usually don't declare a version production-ready until it's fully certified for a specific J2EE umbrella spec. You can't simply plug EJB3 into an existing J2EE 1.3 or 1.4 environment there.
This is *NOT* completely true as I remember BEA always included early implementation of J2EE features in the past.
The document proves that WLS 6.0 included features of EJB 2.x before it was finalized.
http://e-docs.bea.com/wls/docs60/ejb/EJB_whatsnew.html
The Enterprise JavaBeans 2.0 implementation in WebLogic Server Version 6.0 will be fully supported and can be used in production. However, be advised that the Sun Microsystems EJB 2.0 specification is not yet finalized, and the WebLogic Server implementation of the EJB 2.0 architecture is based on the most current public draft of this specification.
regards
Debu
|
|
|
Message #165008
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
So, nobody says "EJB 3.0 sucks"
The document proves that WLS 6.0 included features of EJB 2.x before it was finalized. I remember very well. I actually tried to use that new CMP implementation at the time. Not a happy experience, as it was quite immature, unlike WLS as a whole, which we were otherwise happy with in. I also remember the radical changes in the EJB 2.0 spec at a late stage in the review process.
|
|
|
Message #165017
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
So, nobody says "EJB 3.0 sucks"
Rod,
We will make sure that you will have not have the similar experience with Oracle's EJB3 implementation when we go to production (:-
Our EJB3 Persistence layer is built on the top of Oracle TopLink and hence inherits all it's robustness
-Debu Panda
Principal Product Manager, EJB Container
Oracle Application Server development team
|
|
|
Message #165036
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
slow progress on jsr 237 ?
Too bad that the Work Manager JSR doesn't seem to make any progress. It's not even in the proposed list of JSRs to be considered for J2EE 5.0! Do you know any details considering bea is in the expert group?
Simon
|
|
|
Message #165037
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
slow progress on jsr 237 ?
The JSR is moving along. In the meanwhile, both WebLogic and WebSphere implemented a subset of the Async beans APIs that are portable across both products. Some enterprising soul could implement this on JBoss/Geronimo pretty easily also. I've also written a layer to make the async beans APIs look like Doug Leas concurrentj with little effort. Problem is just the process of getting the code to the public.
I also work for IBM BTW, your note makes me think I work for BEA.
|
|
|
Message #165068
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
So, nobody says "EJB 3.0 sucks"
hardly anyone upgrades the entire J2EE server in an instant; that approvement process can take ages. An in particular, noone will upgrade their entire production J2EE server to a pre-release version.
And even when the server version is a 6.0 production one, and you have the approval, sometimes trying to follow the upgrade path so carefully documented by the app server provider in order to move your cluster to a new version is an incredibly painful process, that literally takes weeks because of having to wait the usual "talk with 1st level support - wait until they understand they don't know a damn about how to solve your problem - wait until they admit they have never tried something like that - talk with the second level support - send them your whole app server config - wait for them to reply (from the other part of the globe, different timezones, etc.) - retry and move on - restart from 1st level support with the new problem...
|
|
|
Message #165073
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
So, nobody says "EJB 3.0 sucks"
Our EJB3 Persistence layer is built on the top of Oracle TopLink and hence inherits all it's robustness.
This is certainly true and an indicator that Oracle's EJB3 persistence *backend* will be robust. It doesn't say anything about EJB3 API stability before the final spec gets released, though.
Early EJB adopters might have burned their fingers back in the EJB 2.0 pre-final days, when the last-minute introduction of local interfaces radically changed EJB 2.0's overall approach from the ground up...
Juergen
|
|
|
Message #165132
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
slow progress on jsr 237 ?
I see, WebSphere and not WebLogic. Anyway, looking forward to the relese of this JSR; definitely a huge need.
Simon
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
