|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 16
Messages: 16
Messages: 16
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
TSS Java Symposium 18 session reports & survey questions posted
TheServerSide's Java Symposium occured 2 weeks ago and we've posted an indepth conference coverage article including summaries of 18 technical sessions, from AJAX to EJB3 to project automation. We've also included the results of 23 audience survey questions, yielding surprising results such as 80% against backwards compatible EJB, 2.5% prefer Netbeans, and 40% say their in house QA team sucks.
Read: TheServerSide Java Symposium conference coverage
|
|
|
Message #162757
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EJB3 Backward compatility
Does backward compatibility matter to you with EJB3? Speak up!
Obviously backward compatibility is going to be important to some customers, and will be supported by the existing vendors. That's not the issue.
The question is whether someone should be allowed to create an EJB3-only certified container that does not have to support every single prior version of the specification.
And the community has overwhelmingly said yes.
|
|
|
Message #162758
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EJB3 Backward compatility
Does backward compatibility matter to you with EJB3? Speak up! Obviously backward compatibility is going to be important to some customers, and will be supported by the existing vendors. That's not the issue.The question is whether someone should be allowed to create an EJB3-only certified container that does not have to support every single prior version of the specification.And the community has overwhelmingly said yes.
And the Spec Committee has overwhelmingly said no.
|
|
|
Message #162760
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EJB3 Backward compatility
There isn't a law saying you can't make a EJB3 only container. Just don't expect to have it certified. If someone makes one that is better than others, it will succeed, regardless of the "Lords On High".
|
|
|
Message #162761
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EJB3 Backward compatility
Does backward compatibility matter to you with EJB3? Speak up! Obviously backward compatibility is going to be important to some customers, and will be supported by the existing vendors. That's not the issue.The question is whether someone should be allowed to create an EJB3-only certified container that does not have to support every single prior version of the specification.And the community has overwhelmingly said yes.
My feeling is that anything that brings more vendors to EJB3/J2EE5 will only make the specification stronger.
|
|
|
Message #162777
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EJB3 Backward compatility
And the Spec Committee has overwhelmingly said no.
The poll at TSS was actually the first time that a popular result showed so many people in favour of doing this. The Spec Committee has discussed this at length and has been polling people throughout the cycle. We would very much like to not require support for older versions since it would allow even more vendors to provide products, which is definitely a Good Thing for the spec.
If we came out and said this, though, there would be consequences:
- The migration story for existing applications would be worse, interop could be non-exsistent, and the new vendors would not even have a chance at any of the existing EJB users
- The spec would get cricized (as it already has by many) saying that it is taking a new road and has no right to leave existing customers with no support on an old and outdated spec
- The J2EE platform would be judged harshly as not being evolution-friendly and including forward development paths as part of the next gen specs
In some ways it is the rock-and-hard-place problem where the spec gets flak either for changing the model and not providing a migration path, or providing one and requiring new vendors to support previous technology.
Note that to most existing vendors it makes no difference to us whether the spec actually requires it or not. Oracle will certainly support it because we have lots of customers that use it and part of our planned stratgy is to offer them a smooth migration path. If it isn't in the spec then it is just value-add that we have to offer. The bigger issue, though, is whether this is a responsible thing to do.
In the end if enough of the community and the J2EE platform stewards think it is a good idea then it will happen. We need to think of the overall platform, though, not just a new app that does not want to catch glimpses of previous baggage under the tarps.
-Mike
|
|
|
Message #162790
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EJB3 Backward compatility
There isn't a law saying you can't make a EJB3 only container. Just don't expect to have it certified. If someone makes one that is better than others, it will succeed, regardless of the "Lords On High".
|
|
|
Message #162810
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The real issue
The problem is that I think people are forgetting how specifications work, and what the actual advantages of a specifications are over some random open source project.
A specification is a contract. For some customers, one of the biggest selling points of j2ee is that it's backed by specifications, specifications that on the whole, won't be pulled out from under them.
Should it be possible to have standalone implementations? Sure, it'd be good if they were clearly labelled so, and still had some kind of blessing from Sun. Perhaps they could be called JSR-220 compliant, instead of EJB3!
The problem with asking the tss crowd is that it's a vocal obnoxious majority where lone contractors run rampant. These guys love to have new toys for every gig, just to keep things interesting. These guys never have to maintain old applications, so quite rightfully, why on earth would backward compatibility matter to them, beyond it being a minor advantage in terms of marketing their chosen technologies?
I hope the EJB3 group is bright enough (well, they are actually, having met a bunch of them) to realise that the specification should not be born of mob rule. Keep comments from TSS type people in perspective!
Another factor that is often ignored is that for better or worse, there's an absolutely enormous market of ejb out there. What should these people do? I hardly think that 'screw em, they're too dumb anyway since they chose ejb' is quite the message that Sun would want to put out. TSS types might want to sneer and dismiss those people, but come on, even you guys are bright enough to know that *something* must be done with them.
EJB3 will attract a lot of new users, that's great and will really give the platform a boost and remove much of the stigma surrounding j2ee (since many other API's are becoming a lot more user-friendly, albeit without the spotlight and glamour of ejb). However, lets not forget that right now, the j2ee market is a huge behemoth where pretty much all the serious money is tied up. While you can earn the admiration and oohing and aahing from the other kids in the playground by denouncing these big guys, that sort of bravado won't do much to make sure that the food on the table is plenty and bountiful.
|
|
|
Message #162814
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EJB3 Backward compatility
To me I don't see why the don't expand the certification model and make everyone happy. From what I see most people want to have options here so why not have a EJB 3.0 only certification for containers that don't want to support the bagage of previous versions and an EJB 3.0 backward compatible certification for those that do.
I would be surprised that if in the long run Weblogic and JBoss do not end up with a configuration setting to turn off backwards compaitibilty for their EJB 3.0 container.
David
|
|
|
Message #162820
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The real issue
Oh come on Hani. This is disingenuous and intellectually bankrupt and you know it.
The problem is that I think people are forgetting how specifications work, and what the actual advantages of a specifications are over some random open source project.A specification is a contract.
Agreed, and J2EE 1.4 is ALREADY a specification and contract. What's wrong with WebLogic and OracleAS being J2EE 1.5 AND J2EE 1.4 certified?
For some customers, one of the biggest selling points of j2ee is that it's backed by specifications, specifications that on the whole, won't be pulled out from under them.
Did someone mention de-certifying the J2EE 1.4 specification? Are we talking about not allowing people to code to that spec and not allowing vendors to support it, even in new products?
Should it be possible to have standalone implementations? Sure, it'd be good if they were clearly labelled so, and still had some kind of blessing from Sun. Perhaps they could be called JSR-220 compliant, instead of EJB3!The problem with asking the tss crowd is that it's a vocal obnoxious majority where lone contractors run rampant. These guys love to have new toys for every gig, just to keep things interesting. These guys never have to maintain old applications, so quite rightfully, why on earth would backward compatibility matter to them, beyond it being a minor advantage in terms of marketing their chosen technologies?I hope the EJB3 group is bright enough (well, they are actually, having met a bunch of them) to realise that the specification should not be born of mob rule. Keep comments from TSS type people in perspective!Another factor that is often ignored is that for better or worse, there's an absolutely enormous market of ejb out there.
You're making my case here. There's a huge market. Do huge markets usually go ignored by vendors? If you know of any huge markets going ignored by vendors please drop me an email (offline, I don't need every independent contractor on here with nothing else to do to compete with me).
What should these people do? I hardly think that 'screw em, they're too dumb anyway since they chose ejb' is quite the message that Sun would want to put out. TSS types might want to sneer and dismiss those people, but come on, even you guys are bright enough to know that *something* must be done with them.
Are you really dependent on J2EE, or are you dependent on your vendor? You develop a product, so you may have gone through the pain of making sure it runs on more than one appserver (I've been through that pain), but people who are just writing applications for internal use are most likely NOT doing this, they're using the corporate standard app server vendor. Whether or not EJB 2.1 spec compliance is required by the EJB 3 spec, they'll really only care if it still works in the new version from their vendor, and their vendor will have a huge incentive to make sure it DOES work, or the customers will have to make a decision on porting to EJB3, where they may or may not choose the same vendor, or porting to a different EJB 2.1 implementation.
EJB3 will attract a lot of new users, that's great and will really give the platform a boost and remove much of the stigma surrounding j2ee (since many other API's are becoming a lot more user-friendly, albeit without the spotlight and glamour of ejb). However, lets not forget that right now, the j2ee market is a huge behemoth where pretty much all the serious money is tied up. While you can earn the admiration and oohing and aahing from the other kids in the playground by denouncing these big guys, that sort of bravado won't do much to make sure that the food on the table is plenty and bountiful.
That money will continue to flow. J2EE doesn't require COBOL runtime bindings either, and yet there manages to be a lot of COBOL code running out there...
|
|
|
Message #162832
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EJB3 Backward compatility
There isn't a law saying you can't make a EJB3 only container. Just don't expect to have it certified. If someone makes one that is better than others, it will succeed, regardless of the "Lords On High".
What is an "EJB3-only" container when backwards compatibility is a requirement of the EJB3 spec?
The value of a specification is in defining a common standard between implementations. If there is a clear subset of the new spec that is of value independent of the rest, why not define separate from the rest? Vendors could certify that they support the new EJB model defined by this lighter spec, and that would have a clear and verifiable meaning beyond the wink and handshake you would get if "EJB3-only" is not clearly defined. Call it "EJB3 light" if you like. Vendors can then declare which standards they support, and I can choose the product that meets my needs. If I need EJB2 and am willing to pay for it, I am sure some vendors will continue to support it. If I don't, why require the baggage?
Splitting EJB3 from its predecessors in no way requires that vendors drop support within their products. It simply lowers the barrier to entry in the EJB3 space and makes the very concept of EJB3-only containers that you mention a clearly definable and verifiable thing.
|
|
|
Message #162857
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The real issue
Oh come on Hani. This is disingenuous and intellectually bankrupt and you know it.
Oh come on, that'd be like me saying that you're only bitter about EJBs and J2EE because you get hired for that stuff (sure, you spend all your time migrating away from it, but it's the j2ee knowledge that gets you in).
|
|
|
Message #162984
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The real issue
I share Hani's viewpoint. For the large customers who really pay the bills and fund the continued development of the J2EE platform through their purchases of J2EE-compliant products, they make major long-term investments in whatever application platform they choose (we're talking about the level of J2EE vs. .NET for the customer's next 10 years). A major reason they went with J2EE in the first place was the "contract" that these specs make a serious commitment to backward compatibility -- that their investment in this platform will be protected over time by the specification itself, not the whims of a particular vendor.
On a previous thread someone implied I was taking this view because I happen to work for a large app server vendor (IBM). Yes, I happen to work for IBM but my views come more from the types of customers I typically work with (large), the amount of money they invest in their application platform (large) and the importance they place on the chosen platform's long-term stability and incremental upward compatibility (very large). They are making a long-term contract with the application platform they choose, not just with the vendor they choose. If all they cared about was the promises of the particular vendor, they could have gone with a single-vendor platform instead of choosing a standardized multi-vendor platform.
I understand the arguments of those who want a separate spec (still standardized and multi-vendor) that just covers the new EJB3 model without requiring support for 2.1 and prior models. However, when you go to sell that to a customer and try to convince them to invest in this new "platform", they will assuredly want to know how confident they can be that this new platform will support, for many years, the programming model you're asking them to commit to. Will this platform drop its support for the current model when the next new thing comes along, leaving them with effectively a single-vendor contract again? If there's no long-term commitment that the platform will support the current programming model even when new variants to the programming model come along, the attractiveness of this platform is really no greater than a single-vendor platform.
Randy Schnier
I work for IBM but opinions are my own, not necessarily IBM's.
|
|
|
Message #163297
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EJB3 Backward compatility
To me I don't see why the don't expand the certification model and make everyone happy. From what I see most people want to have options here so why not have a EJB 3.0 only certification for containers that don't want to support the bagage of previous versions and an EJB 3.0 backward compatible certification for those that do.I would be surprised that if in the long run Weblogic and JBoss do not end up with a configuration setting to turn off backwards compaitibilty for their EJB 3.0 container.David
+1
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
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)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
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)
|
|
