667514 members! Sign up to stay informed.

Sponsored Links


Resources

Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts

News News News Messages: 75 Messages: 75 Messages: 75 Printer friendly Printer friendly Printer friendly Post reply Post reply Post reply XML XML XML

The status of JBoss AS 5

Posted by: Rayme Jernigan on June 30, 2008 DIGG
So, was all of this just a fancy engineering exercise? No, not at all. This investment will have a drastic impact on the overall JBoss Enterprise Middleware offering, its longevity and its ability to adapt to market changes. If you take a 40,000 foot view of the AS market, you can essentially split it in three layers:

• The base runtime
• The core middleware services
• The programming model/API & language

More..

Threaded replies

·  The status of JBoss AS 5 by Rayme Jernigan on Mon Jun 30 12:11:32 EDT 2008
  ·  Rock solid by Kristof Jozsa on Tue Jul 01 18:37:27 EDT 2008
  ·  Suspicious of anything that takes three years to develop by Wille Faler on Wed Jul 02 04:45:10 EDT 2008
    ·  Re: Suspicious of anything that takes three years to develop by AD aa on Wed Jul 02 05:04:02 EDT 2008
      ·  Re: Suspicious of anything that takes three years to develop by Chief Thrall on Wed Jul 02 05:36:21 EDT 2008
        ·  Re: Suspicious of anything that takes three years to develop by Bela Ban on Wed Jul 02 08:09:49 EDT 2008
          ·  Re: Suspicious of anything that takes three years to develop by Chief Thrall on Wed Jul 02 08:18:18 EDT 2008
            ·  Re: Suspicious of anything that takes three years to develop by Bela Ban on Wed Jul 02 08:42:35 EDT 2008
              ·  Re: Suspicious of anything that takes three years to develop by Chief Thrall on Wed Jul 02 08:56:36 EDT 2008
                ·  Re: Suspicious of anything that takes three years to develop by Sacha Labourey on Thu Jul 03 07:01:22 EDT 2008
                  ·  Re: Suspicious of anything that takes three years to develop by Chief Thrall on Thu Jul 03 07:39:53 EDT 2008
                    ·  Re: Suspicious of anything that takes three years to develop by Bill Burke on Thu Jul 03 13:17:48 EDT 2008
                      ·  Re: Suspicious of anything that takes three years to develop by Cameron Purdy on Thu Jul 03 15:38:47 EDT 2008
                    ·  Re: Suspicious of anything that takes three years to develop by Sacha Labourey on Thu Jul 03 14:22:22 EDT 2008
                      ·  Re: Suspicious of anything that takes three years to develop by Bill Burke on Thu Jul 03 14:43:55 EDT 2008
                        ·  Re: Suspicious of anything that takes three years to develop by Chief Thrall on Thu Jul 03 17:16:50 EDT 2008
                          ·  Re: Suspicious of anything that takes three years to develop by Chief Thrall on Thu Jul 03 17:18:01 EDT 2008
                            ·  I doubt it.... by Noel O'Connor on Thu Jul 03 20:05:55 EDT 2008
                              ·  Re: I doubt it.... by Chief Thrall on Fri Jul 04 03:04:59 EDT 2008
                      ·  Re: Suspicious of anything that takes three years to develop by Chief Thrall on Thu Jul 03 17:11:58 EDT 2008
                  ·  Don't be so selfish by Pedro Andres Solorzano Parada on Tue Jul 22 20:31:41 EDT 2008
              ·  Re: Suspicious of anything that takes three years to develop by Cameron Purdy on Wed Jul 02 17:40:42 EDT 2008
              ·  Re: Suspicious of anything that takes three years to develop by George Daswani on Wed Jul 02 19:33:08 EDT 2008
            ·  Re: Suspicious of anything that takes three years to develop by Cameron Purdy on Wed Jul 02 17:58:30 EDT 2008
      ·  Re: Suspicious of anything that takes three years to develop by George Daswani on Wed Jul 02 19:18:55 EDT 2008
    ·  Re: Suspicious of anything that takes three years to develop by Sacha Labourey on Thu Jul 03 06:35:38 EDT 2008
      ·  profit by Chief Thrall on Thu Jul 03 07:00:00 EDT 2008
  ·  Re: JBoss 5 by douglas dooley on Wed Jul 02 07:40:05 EDT 2008
    ·  Re: JBoss 5 by Chief Thrall on Wed Jul 02 08:24:08 EDT 2008
      ·  Re: JBoss 5 by Rich Sharples on Wed Jul 02 08:40:47 EDT 2008
        ·  Re: JBoss 5 by Chief Thrall on Wed Jul 02 08:52:45 EDT 2008
    ·  Re: JBoss 5 by Rich Sharples on Wed Jul 02 08:26:09 EDT 2008
      ·  Re: fundamentally disagree by douglas dooley on Wed Jul 02 09:24:46 EDT 2008
        ·  Re: fundamentally disagree by Rich Sharples on Wed Jul 02 09:49:59 EDT 2008
        ·  Re: fundamentally disagree by James Watson on Wed Jul 02 11:09:34 EDT 2008
          ·  Re: misguided by douglas dooley on Wed Jul 02 15:58:25 EDT 2008
            ·  Re: misguided by James Watson on Wed Jul 02 16:23:37 EDT 2008
              ·  Re: JEE by douglas dooley on Wed Jul 02 22:37:26 EDT 2008
              ·  Re: misguided by Chief Thrall on Thu Jul 03 03:05:06 EDT 2008
                ·  Saying a standard is "less risk" doesn't make it so by Wille Faler on Thu Jul 03 05:30:26 EDT 2008
                  ·  Re: Saying a standard is "less risk" doesn't make it so by William Louth on Thu Jul 03 06:05:14 EDT 2008
                    ·  Re: Saying a standard is "less risk" doesn't make it so by Wille Faler on Thu Jul 03 07:09:05 EDT 2008
                      ·  Re: Saying a standard is "less risk" doesn't make it so by Andy Gibson on Thu Jul 03 14:02:43 EDT 2008
                        ·  Re: Saying a standard is "less risk" doesn't make it so by Wille Faler on Thu Jul 03 15:54:36 EDT 2008
                        ·  Re: Saying a standard is "less risk" doesn't make it so by Eelco Hillenius on Mon Jul 07 19:21:31 EDT 2008
                  ·  Re: Saying a standard is "less risk" doesn't make it so by Chief Thrall on Thu Jul 03 06:35:34 EDT 2008
                    ·  Re: Saying a standard is "less risk" doesn't make it so by Wille Faler on Thu Jul 03 07:15:08 EDT 2008
                      ·  Re: Saying a standard is "less risk" doesn't make it so by Chief Thrall on Thu Jul 03 07:28:08 EDT 2008
                        ·  Re: Saying a standard is "less risk" doesn't make it so by Wille Faler on Thu Jul 03 08:04:39 EDT 2008
                          ·  Re: Saying a standard is "less risk" doesn't make it so by Chief Thrall on Thu Jul 03 08:30:07 EDT 2008
                            ·  Re: Saying a standard is "less risk" doesn't make it so by Wille Faler on Thu Jul 03 08:48:06 EDT 2008
                            ·  Re: Saying a standard is "less risk" doesn't make it so by James Watson on Thu Jul 03 10:44:39 EDT 2008
                              ·  Re: Saying a standard is "less risk" doesn't make it so by Chief Thrall on Thu Jul 03 17:23:50 EDT 2008
                                ·  Re: Saying a standard is "less risk" doesn't make it so by James Watson on Thu Jul 03 22:36:48 EDT 2008
                                  ·  Re: Saying a standard is "less risk" doesn't make it so by Chief Thrall on Fri Jul 04 03:10:05 EDT 2008
                                    ·  Re: Saying a standard is "less risk" doesn't make it so by James Watson on Fri Jul 04 13:07:31 EDT 2008
                                      ·  Re: Saying a standard is "less risk" doesn't make it so by Chief Thrall on Fri Jul 04 17:17:17 EDT 2008
                                        ·  Re: Saying a standard is "less risk" doesn't make it so by James Watson on Fri Jul 04 20:57:31 EDT 2008
                                          ·  Re: Saying a standard is "less risk" doesn't make it so by Chief Thrall on Sat Jul 05 17:55:42 EDT 2008
                ·  Re: misguided by Eelco Hillenius on Mon Jul 07 19:13:56 EDT 2008
                  ·  Re: misguided by Chief Thrall on Tue Jul 08 03:17:55 EDT 2008
                    ·  Re: misguided by Chief Thrall on Tue Jul 08 03:20:44 EDT 2008
                      ·  Re: misguided by Eelco Hillenius on Tue Jul 08 12:47:39 EDT 2008
                        ·  Re: misguided by Chief Thrall on Wed Jul 09 05:52:26 EDT 2008
                          ·  Re: misguided by Chief Thrall on Wed Jul 09 05:55:39 EDT 2008
            ·  Re: misguided by Sacha Labourey on Thu Jul 03 07:13:13 EDT 2008
              ·  Re: nice work by douglas dooley on Fri Jul 04 00:04:42 EDT 2008
                ·  Re: nice work by James Watson on Fri Jul 04 21:45:01 EDT 2008
                  ·  Re: Frank and James by douglas dooley on Sun Jul 06 04:28:51 EDT 2008
    ·  Re: JBoss 5 by Sacha Labourey on Thu Jul 03 06:55:20 EDT 2008
  ·  Congratulations to JBoss. by Keith Weinberg on Wed Jul 02 08:48:48 EDT 2008
    ·  Re: Congratulations to JBoss. by Chief Thrall on Wed Jul 02 09:04:17 EDT 2008
  ·  Re: The status of JBoss AS 5 by Steve Lewis on Wed Jul 02 08:59:17 EDT 2008
  ·  CR to GA by bullz97 bullz97 on Wed Jul 02 22:47:38 EDT 2008
  ·  What's the major malfunction of Douglas Dooley? by Frank Bank on Fri Jul 04 04:54:54 EDT 2008
    ·  Re: What's the major malfunction of Douglas Dooley? by AD aa on Fri Jul 04 08:10:37 EDT 2008
  Message #260138 Post reply Post reply Post reply Go to top Go to top Go to top

Rock solid

Posted by: Kristof Jozsa on July 01, 2008 in response to Message #259887
"We have built rock solid, scalable and flexible middleware services"

hint: try to search the jboss issue tracker for 'deadlock' before posting such fancy news next time.

  Message #260147 Post reply Post reply Post reply Go to top Go to top Go to top

Suspicious of anything that takes three years to develop

Posted by: Wille Faler on July 02, 2008 in response to Message #259887
..maybe I'm wrong, but I'm just deeply suspicious of anything that takes three years to develop - that has a smell of multiple things going wrong somewhere along the way, or at least there being a very real risk that the world has gone by whatever was set out to be accomplished.

The latter might be very much the case, as I see application servers loosing in relevance every day, with people opting more for picking and choosing the components they wish.
But then again the more componentized JBoss AS can deal with this?
Could be a case of "JBoss AS is dead, long live JBoss AS"?

  Message #260148 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Suspicious of anything that takes three years to develop

Posted by: AD aa on July 02, 2008 in response to Message #260147
Agreed. I still wonder why did they take so long to deliver? Was it due to Redhat? We decided to switch to Glassfish from JBoss due to "lack of activity" on the JBoss side.
Now We are very happy with glassfish and JBoss AS5 or not, we see no reason to use JBoss in enterprise any longer and I am sure there are many other companies that have adopted or moved on from JBoss

  Message #260149 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Suspicious of anything that takes three years to develop

Posted by: Chief Thrall on July 02, 2008 in response to Message #260148
Last time I checked, Glassfish platform is much much better than JBoss in any aspect. If you don't believe me, try it out and you wont be disappointed if you are in a need to work with EJB.
To the best of my knowledge, only thing Glassfish is missing is product of similar quality as Tangosol Coherence (now re-branded to Oracle).

Too bad Sun's (open source) marketing department is failing at their job.

  Message #260153 Post reply Post reply Post reply Go to top Go to top Go to top

Re: JBoss 5

Posted by: douglas dooley on July 02, 2008 in response to Message #259887
Nice job, Sacha...

This is a welcome statement from an organization with a history of over-educating its audiences, and it was time for JBoss to make a statement to the Java community, thanks...

I may not have absorbed everything in the post, but i know i am going to have ongoing problems with this thesis, as stated in the blog entry:

"But what is interesting is that about 80% of those customers are not waiting for an EE5-certified application server, but want to leverage specific features of our AS 5.0 architecture (mostly our JBoss Microcontainer)."

While this may be true, that a sample of customers were taken and the consensus seems to be that they will not be migrating their apps to EJB 3, etc..., I find it to be a poor job of understanding JBoss' role and competitive advantage in the wider middleware space:

if JBoss 5 does not get customers to move to JEE 5, then it will be a Vista-like failure, where upgrades will be simply about extending e.o.l. support contract timeframes, and will not deliver the technical benefits of a revised specification, nor the new business opportunities for JBoss to go after....

in short, Sacha, watch your marketing of JBoss 5 as a fancy, techno, micro-container innovation, especially at the expense of application component development innovations, because there is this little company called SpringSource that is currently eating your lunch...

my suggestions is to get back on message with promoting JEE, and establishing JBoss 5 as the pre-eminent deployment platform for all things JEE on Linux, and start making a ton of money; nothing says market opportunity for Seam, like hundreds of new installations of JEE 5 shops that adhere to the full complement of the spec...

that is boring, and I understand Muzilla is on the 're-factoring' angle, so i am not going to scold, or question, i just think that there is real competition now, with Oracle, IBM, Glassfish, Spring, and .Net to compete with JBoss:

u guys need to execute like hell, and prove to everyone why u won the leadership position in the 1st place...

  Message #260155 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Suspicious of anything that takes three years to develop

Posted by: Bela Ban on July 02, 2008 in response to Message #260149
To the best of my knowledge, only thing Glassfish is missing is product of similar quality as Tangosol Coherence (now re-branded to Oracle).


Take a look at JBossCache (http://www.jboss.org/jbosscache), which is used as the underlying replicated cache (for example for HTTP session replication) in the JBoss appserver.

Bela

  Message #260156 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Suspicious of anything that takes three years to develop

Posted by: Chief Thrall on July 02, 2008 in response to Message #260155
Take a look at JBossCache (http://www.jboss.org/jbosscache), which is used as the underlying replicated cache (for example for HTTP session replication) in the JBoss appserver.

Bela


Thanks for the link. I am aware of JBossCache and JGroups offerings, however I doubt it can match Coherence in the quality.

While I do not have practical experience and/or scientific recommendations to back up my doubts, considering they were bought by Oracle, and instinct that companies specialized in one certain area always outperform corporations that offer everything at medium quality, I believe it stands correct: Coherence > any OS tool.

  Message #260157 Post reply Post reply Post reply Go to top Go to top Go to top

Re: JBoss 5

Posted by: Chief Thrall on July 02, 2008 in response to Message #260153
Nice job, Sacha...This is a welcome statement from an organization with a history of over-educating its audiences...


Good points. Seems they have forgotten about the bottom line here.

No concrete evidence has been shown that JBoss5 brings anything revolutionary to the table that will enable users to generate profit, hence seems JBoss5 development was nice way to lose time.

Is there anything in JBoss5 stack feature list that can not be done by some other OS tool, or combination of there of? Anything revolutionary, any killer app in middleware area?

If JBoss5 is not about EJB3, then I dont know what it is about.

  Message #260158 Post reply Post reply Post reply Go to top Go to top Go to top

Re: JBoss 5

Posted by: Rich Sharples on July 02, 2008 in response to Message #260153

While this may be true, that a sample of customers were taken and the consensus seems to be that they will not be migrating their apps to EJB 3, etc..., I find it to be a poor job of understanding JBoss' role and competitive advantage in the wider middleware space:


Doug, the point here is that many of the Java EE 5 features and APIs we're already included in AS 4.2 back in 2006 - so few customers have been demanding full EE 5 compliance from JBoss. EJB 3 isn't new to JBoss customers.

I'll restate it - Java EE 5 isn't the only release driver for AS 5.0 and JBoss has always been and always will be more than just a standard Java EE container. We're not betting our business on Java EE though we'll continue to support it as long as there is demand.

The world doesn't revolve around Application Servers (though they continue to be important).

And AS 5.0 isn't *just* a better App Server (though it may well be) - it's our investment in the future. A way for us (and others) to standardize on a very flexible enterprise Java run-time.

- Rich
Apprentice JBossian

  Message #260159 Post reply Post reply Post reply Go to top Go to top Go to top

Re: JBoss 5

Posted by: Rich Sharples on July 02, 2008 in response to Message #260157

If JBoss5 is not about EJB3, then I dont know what it is about.


It's *really* not about EJB3 - JBoss AS 4.2 was about EJB3 and that was released over a year ago.

What it is about is a well-designed, very flexible, modular enterprise Java run-time that has utility way beyond running EJBs. It's the same run-time we'll be able to use when the next server-side framework, programming model or paradigm comes along. We'll be able to adapt quickly and without disrupting the operational footprint of the run-time.

- Rich
Apprentice JBossian

  Message #260160 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Suspicious of anything that takes three years to develop

Posted by: Bela Ban on July 02, 2008 in response to Message #260156
Thanks for the link. I am aware of JBossCache and JGroups offerings, however I doubt it can match Coherence in the quality.


In what respect ?


Performance-wise, our benchmarks indicate JBossCache is about the same. If you benched the 2 products, and see us behind we'd be happy if you sent us your benchmark so we can run it ourselves.



Feature wise, they're ahead with data partitioning, but we're working on it (http://wiki.jboss.org/wiki/JBossCachePartitioning).




While I do not have practical experience and/or scientific recommendations to back up my doubts, considering they were bought by Oracle, and instinct that companies specialized in one certain area always outperform corporations that offer everything at medium quality, I believe it stands correct: Coherence > any OS tool.


Indeed, my team specializes in clustering: JGroups, JBossCache and PojoCache, as if they were standalone products. Thanks for the kudos :-)

Bela (happy JBoss employee)

  Message #260162 Post reply Post reply Post reply Go to top Go to top Go to top

Congratulations to JBoss.

Posted by: Keith Weinberg on July 02, 2008 in response to Message #259887
JBoss is a big deal for our industry and a big deal for free software. It is good to see that it is healthy, alive and kicking and still doing the most interesting stuff of any container. Congratulations!

As far as deployment goes (at least in the financial industry), Glassfish/Jonas and the other free containers are few and far between and JBoss has stayed strong and continues to grab marketshare away from Weblogic/Websphere.

As for EJB3/Spring. I couldn't stand EJB before 3 but EJB3 was a remarkable move forward. Personally, I'm a big Spring fan and use it every day (even with EJBs), but for apps that need the full services of a container (db access/modeling, hot-deploy, message-queing, transaction management, efficient RPC), "rolling my own" in Spring is really a much harder option (believe me I've tried) and there is something to be said for a pre-integrated enterprise stack that you don't have to write reams of XML to weave together from scratch.

So thanks, Redhat/Jboss for a major architecture refactoring, a brave push into component architecture for services and please keep the releases rolling.

  Message #260161 Post reply Post reply Post reply Go to top Go to top Go to top

Re: JBoss 5

Posted by: Chief Thrall on July 02, 2008 in response to Message #260159

If JBoss5 is not about EJB3, then I dont know what it is about.


It's *really* not about EJB3 - JBoss AS 4.2 was about EJB3 and that was released over a year ago.

What it is about is a well-designed, very flexible, modular enterprise Java run-time that has utility way beyond running EJBs. It's the same run-time we'll be able to use when the next server-side framework, programming model or paradigm comes along. We'll be able to adapt quickly and without disrupting the operational footprint of the run-time.

- Rich
Apprentice JBossian


If I got this right, JBoss5 will bring major advantage only in case new Big Paradigm shift and similar happens, and for good ol' Java EE its ok to stick with 4.2?

(I know 5 brings another improvements, but I am referring here only to major big advanateges that 5 could bring over 4.2)

  Message #260163 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Suspicious of anything that takes three years to develop

Posted by: Chief Thrall on July 02, 2008 in response to Message #260160
In what respect?


Like I said, I haven't done research in this area and my experience is limited to writing totem single ring membership protocol impl at spare time, however my 6th sense is telling me Coherence is better product overall (not cheaper).

  Message #260164 Post reply Post reply Post reply Go to top Go to top Go to top

Re: The status of JBoss AS 5

Posted by: Steve Lewis on July 02, 2008 in response to Message #259887
Congratulations to the JBoss team. We're on an older version of JBoss, but even when JBoss 3 came out it was obvious that there were going to be non-standard pieces of JBoss that existed primarily because certain customers requested certain features. I don't see what's so wrong with that.

More kudos will be expected when it's released.

  Message #260165 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Congratulations to JBoss.

Posted by: Chief Thrall on July 02, 2008 in response to Message #260162
...and still doing the most interesting stuff of any container


Are you sure? Mural MDM, Comet Ajax, native integration with second best IDE in the world (NetBeans) much?

Adding support for "JAR files with lifecycle", aka OSGi and similar is hardly innovation.

  Message #260166 Post reply Post reply Post reply Go to top Go to top Go to top

Re: fundamentally disagree

Posted by: douglas dooley on July 02, 2008 in response to Message #260158
Rich,

I am not sure if this has turned in to a pissing match for some reason other than i am publicly saying what many are feeling, but your response is patently false, with respect to JBoss AS 5:

it is about JEE, and the balance of the Internet does revolve around application servers, that are the run-time for everything from databases, to BPM, to ESBs, to Portals, i mean name one thing that does not touch app servers, and i'll show u an outdated and irrelevant mode of software development...

for the product management team to believe the hype around other modes of middleware is fine, but to come up with a statement like this:

"We're not betting our business on Java EE though we'll continue to support it as long as there is demand."

is just plain funny to me, i mean u of all people should be inculcating the JBoss org. with the mantra of stop splintering JEE, and deliver a world-class run-time for it, especially to make revenue on Linux deployments...

i mean what other ways do you guys expect to make money with JBoss other than on Enterprise Java?

  Message #260168 Post reply Post reply Post reply Go to top Go to top Go to top

Re: fundamentally disagree

Posted by: Rich Sharples on July 02, 2008 in response to Message #260166
Rich, with the mantra of stop splintering JEE, and deliver a world-class run-time for it, especially to make revenue on Linux deployments...

i mean what other ways do you guys expect to make money with JBoss other than on Enterprise Java?


Doug, nothing I have said should imply that JBoss is trying to splinter Java EE - we're not. JBoss has been a strong supporter, we employee lot's of bright people who work on various JSRs to make Java EE better. We support Seam - a framework that makes Java EE a better and more productive environment. The concepts in Hibernate made Java EE better. I'd say that JBoss has done a lot more than most vendors to make Java EE better.

But the fact remains, many of our customers do not want or need Java EE; they are mature and experienced enough to choose the technologies and frameworks that they want and they expect us to support them. And we will.

We support Java EE but it isn't our job to push it as the one and only technology for all use cases.


- Rich
Apprentice JBossian

  Message #260170 Post reply Post reply Post reply Go to top Go to top Go to top

Re: fundamentally disagree

Posted by: James Watson on July 02, 2008 in response to Message #260166
i mean name one thing that does not touch app servers, and i'll show u an outdated and irrelevant mode of software development...


I think a lot of people consider application servers to be an outdated approach to development. JEE is considered by many to be irrelevant.

  Message #260184 Post reply Post reply Post reply Go to top Go to top Go to top

Re: misguided

Posted by: douglas dooley on July 02, 2008 in response to Message #260170
Perhaps i am the biggest curmudgeon on TSS, but after re-reading Sasha's blog entry, i am feeling a little queasy on the direction of JBoss, and wonder whether there is actually customer support for the premise that different development models will actually make JBoss more business-scalable...

it is tempting to build a bigger business than the 1 that a company may b in, but i will submit that the temptation to be a run-time for everything including Spring, Grails, and potentially other development models, we have a product-line that is at least a year late to market...Cost-Benefit Analysis is tricky especially preceding a product release, but i am not so sure about this bet that JBoss has made on a new type of application server implementation, especially considering that it appears that SpringSource and Glassfish have already accomplished this modularity...

what is going to be the market adoption of something that is so classically in a follower position? that really is the question, and i just don't know what data and information went in to the decision to move beyond JEE, but I haven't seen anything convincing, other than purported job request figures from the Spring guys...

have enterprise customers moved away from Java: perhaps some, but to claim this is a trend that justifies what has happened with JBoss 5 seems a bit of a stretch; James Watson's statement of JEE being "irrelevant" is 100% propaganda, as is the premise that app servers don't have a future in generating the development model counter to .Net implementations...

basically, i am saying nothing new, but it just seems the more that people bet against JEE, or at least, predict its ultimate demise in reduced demand, that it is lacking in historical precedence or even based in reality...its one thing to have some fellow developers try out different development paradigms, it is quite another to get enterprise customers to standardize on something other than what is legacy...

i am so tired of the "JEE is dead" discussions, that i am completely baffled why JBoss seems to be hedging 4 it, perhaps u could argue that it is a risk-mitigator for the future, but right now, i just think it was misguided MRD and PRD analysis that called for an entirely new platform, that is not even close to done, with all the other moving pieces that need to be integrated...

my suggestion: get a Red Hat Enterprise Linux certified JBoss 5 out to market, and ditch Solaris, Hp-UX, AIX, and even NT, with a development supported product for XP; everything else is just too risky to pull off...

Rich, I hate to continue to be inflammatory, but i can c why they brought u in for Product management: JBoss is in some serious need of people to make decisions that are non-technical, and rely on business metrics; i hope u make the best of it...

  Message #260186 Post reply Post reply Post reply Go to top Go to top Go to top

Re: misguided

Posted by: James Watson on July 02, 2008 in response to Message #260184
James Watson's statement of JEE being "irrelevant" is 100% propaganda


I didn't actually write that, of course. But I will point out that you haven't actually made any coherent argument for JEE, you've just stated that anything else is outdated. Honestly, this seems pretty laughable to me and I find JEE so boring that I'll agree with you that talking any more about how it's dead isn't really a good use of time.

Hope you find your missing shift key and good luck.

  Message #260189 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Suspicious of anything that takes three years to develop

Posted by: Cameron Purdy on July 02, 2008 in response to Message #260160
Performance-wise, our benchmarks indicate JBossCache is about the same.


On anything less than 10G Ethernet, Coherence is wire-limited.

On 10G Ethernet (and Infiniband), Coherence is bus-limited, but can still sustain aggregate data throughput of over 10 gigabytes (bytes not bits) per second in a 16-node data grid on commodity x86 hardware.

For distributed caching use cases, most accesses should be local, and thus most products should benchmark similarly. For data grid use cases, Coherence has consistently won every benchmark that I've been aware of for the past several years. Nonetheless, our customers point out to me that the important thing is that the solution they pick has to highly available and must never lose data -- those are the "non-negotiable" items, and are much more important than performance ..

Peace,

Cameron Purdy
Oracle Coherence: Data Grid for Java, .NET and C++

  Message #260191 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Suspicious of anything that takes three years to develop

Posted by: Cameron Purdy on July 02, 2008 in response to Message #260156
I am aware of JBossCache and JGroups offerings, however I doubt it can match Coherence in the quality.


Coherence is rock solid. It has to be: It runs many of the largest exchanges, trading systems, travel systems, logistics systems, etc. around the world, 24x7x366 (it's a leap year .. ;-)

Peace,

Cameron Purdy
Oracle Coherence: Data Grid for Java, .NET and C++

  Message #260194 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Suspicious of anything that takes three years to develop

Posted by: George Daswani on July 02, 2008 in response to Message #260148
I did the same thing, JBOSS 5 beta's couldn't even deploy a properly packaged JEE5 ear. Moved to Glassfish and never looked back.

  Message #260195 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Suspicious of anything that takes three years to develop

Posted by: George Daswani on July 02, 2008 in response to Message #260160
Performance-wise, our benchmarks indicate JBossCache is about the same.


You are comparing apples (coherence) to well, something that's not even a fruit.

I've personally used Tangosol Coherence in a project before and it's simply not a "replicated" cache like JBOSS cache. It's a lot more than that, its flexibility is outstanding - just look at the number of combinations available to configure the right cache topology for the job.

In regards to benchmarks, you must strictly be talking about it from a replicated cache point of view (if one were to configure Coherence strictly as a replicated cache).

Compare it instead to Coherence configured as a near cache
(local cache for the front, and a partitioned back cache). Guaranteed it will be much faster for most use cases and will use up alot less memory on the cache servers.

  Message #260200 Post reply Post reply Post reply Go to top Go to top Go to top

Re: JEE

Posted by: douglas dooley on July 02, 2008 in response to Message #260186
This is fun, i actually got 1 past the JBoss contingent, even considering the inflammatory nature of my post that things are awry...i hate being such a punk, but i think that is a label that people most refer to when things go against conventional wisdom...

James, u r correct, u actually said some people rather than making it your own statement, so apologies for making it a quote, that was not legit...but it gives me reason to advocate to JBoss marketers and all potential nay-sayers of why JEE is alive, active, and relevant:

It is simple math - - .Net is predicated on volume, and other development models have come and gone based on the inability to reach critical mass; with a sizable head-start, Enterprise Java established itself as the singular platform 4 developers that needed to create web apps, and even without Netscape's ability to run the table, J2EE was without question the safe choice for Internet enterprise development and deployment...

a lot has come about in the 10 years since its cohesive introduction, but still the fact remains that TSS, the JCP, and the app server are the center of the universe for everything that is not Microsoft...Grails, Ruby, Spring, PHP, and the rest of the contenders are complimentary technologies but would never be considered a viable alternative to .Net; JEE is...

fashionable statements are exciting, because some common theories hold that innovation trumps all else, and Spring has demonstrated a business model that seriously contends with EJB for business logic on middleware, but there is no way JEE or the delivering mechanism of application servers is going anywhere...

the upgrade path as well as the migration path is 2 straight-forward, well-documented, and vital to the interests of the vendors that support it; evidence for this comes from Oracle in its embrace of WebLogic, in IBM's utilization of Geronimo, in Sun's re-commitment via Glassfish, in NetWeaver, and ultimately in the acquisition of JBoss...

what is not clear 2 me is that business people are running the show at JBoss, and even though it is a technical platform and there are literally dozens of moving pieces, some one over there needs to be taken to the Red Hat side of business and be indoctrinated with execution practices, and not make a shoot-the-moon strategy pre-eminent over delivery...

ultimately, whether anyone wants to admit yet or not, JBoss is not going to be scalable enough nor utilize efficiencies of scale to compete with anything other than Linux, and why would they? all deployments are going there anyway...just focus on business, get the darn product out, and quit trying to 're-factor' everything in the cloud...

it is really straight-forward, analysts will be calling for explanations in the next con call, and the answer will have to be a non-technical 1, is anyone willing to make the hard decision to do the right thing, and go all-Linux, all-the-time, we shall c, but i think it is only a matter of time...

  Message #260201 Post reply Post reply Post reply Go to top Go to top Go to top

CR to GA

Posted by: bullz97 bullz97 on July 02, 2008 in response to Message #259887
When is the GA? Hope it is not another few years.

  Message #260204 Post reply Post reply Post reply Go to top Go to top Go to top

Re: misguided

Posted by: Chief Thrall on July 03, 2008 in response to Message #260186
I find JEE so boring that I'll agree with you that talking any more about how it's dead isn't really a good use of time.


JEE could be boring, but who cares? Any serious business will always prefer standardized solution for mass scale development of business applications, irrelevant whether it is the best option or not. For specialized solutions (such as Coherence) it is not that important whether they have standard API.

Any serious manager will always go for standard solutions, such as JEE, simply because it is less risk.

  Message #260323 Post reply Post reply Post reply Go to top Go to top Go to top

Saying a standard is "less risk" doesn't make it so

Posted by: Wille Faler on July 03, 2008 in response to Message #260204
Any serious manager will always go for standard solutions, such as JEE, simply because it is less risk.


To play the devil's advocate for a second: WHY is it less risk?
4-6 years ago, everyone went crazy for EJB's because it was "a standard and less risk". Now most people who adopted them are in a right mess: can't upgrade their JVM's or app servers, too big a risk, can't improve or extend their codebase, too big a risk since EJB's are almost untestable.
On the other hand, anyone who went with writing things in mostly plain Java have been able to continue on their codebase and update JVM's & app servers to their hearts content.

Just stating something is "less risk" because it is a standard doesn't make it so. Sometimes you actually have to _think_ about what the actual, real risks are.

  Message #260324 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Saying a standard is "less risk" doesn't make it so

Posted by: William Louth on July 03, 2008 in response to Message #260323

Now most people who adopted them are in a right mess: can't upgrade their JVM's or app servers, too big a risk, can't improve or extend their codebase, too big a risk since EJB's are almost untestable.


I could say the same for all the in-house component/pojo libraries that turn into in-house component/pojo frameworks that eventually turn into in-house component/pojo platforms. It is not just the technology here but the planning, project, process and people as well.

In my CORBA days I always said that every custom built "light weight" remoting solution will eventually end up looking like CORBA they only difference is that one was designed with most of the features in mind whereas the other evolved as the (overlying simplified) problem domain was expanded because of harsh realities. The same can be said for much of the component/pojo middleware today. Which approach do you think is better?

One big problem with such debates on TSS is that the perspective is very narrow though understandable. It is always focused on the support offered during development and not on manageability of the runtime and the support for processes and teams.

You might also take into account the available skill pool.

William

  Message #260325 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Saying a standard is "less risk" doesn't make it so

Posted by: Chief Thrall on July 03, 2008 in response to Message #260323
Any serious manager will always go for standard solutions, such as JEE, simply because it is less risk.


To play the devil's advocate for a second: WHY is it less risk?
4-6 years ago, everyone went crazy for EJB's because it was "a standard and less risk". Now most people who adopted them are in a right mess: can't upgrade their JVM's or app servers, too big a risk, can't improve or extend their codebase, too big a risk since EJB's are almost untestable.
On the other hand, anyone who went with writing things in mostly plain Java have been able to continue on their codebase and update JVM's & app servers to their hearts content.

Just stating something is "less risk" because it is a standard doesn't make it so. Sometimes you actually have to _think_ about what the actual, real risks are.


It is less risk in the future, not less risk now. Lets say two years after mission critical business application was developed and deployed in production environment, software problems/bugs occur. Company has no in-house development, and has always outsourced/bought software development.

The original supplier does not longer exist (went out of business), so they have to buy contractors from some other company. If that business application was developed in some unknown technology stack, takes much more time to fix bugs because:
1) contractors have to learn technology
2) contractors have to learn business semantics of application.

In case it was developed in JEE, considering how big workforce market is, it would be easy and cheap to find workforce which would have to do only:
1) learning and fixing business semantics of application.

Since time is money, and application is mission critical, they are losing X$ per day. With JEE they save Y$.

  Message #260326 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Suspicious of anything that takes three years to develop

Posted by: Sacha Labourey on July 03, 2008 in response to Message #260147

...
The latter might be very much the case, as I see application servers loosing in relevance every day, with people opting more for picking and choosing the components they wish.
But then again the more componentized JBoss AS can deal with this?
Could be a case of "JBoss AS is dead, long live JBoss AS"?


I don't buy into the "AS are dead" simplification. As I explain in my blog, call them whatever you want (AS, component frameworks, whatever), at the end of the day, you will still rely on the same enterprise services. AFAICT, nothing that happened in the last 3 years says that applications shouldn't be secure anymore, or not use transactions anymore, or not be clustered. The core remains, the APIs come and go.

What people are asking for is more granularity in what they can do, they are not asking to get rid of any of the enterprise services. Now, call the resulting set of enterprise aspects the way you want, I personally don't shy away from using the name "application server". That's probably because we never saw JBoss AS as a fat monolithic AS in the first place :)


Sacha

CTO JBoss, a division of Red Hat

  Message #260327 Post reply Post reply Post reply Go to top Go to top Go to top

Re: JBoss 5

Posted by: Sacha Labourey on July 03, 2008 in response to Message #260153
Hello Douglas,

Nice to see how passionate you are about this :) Passion is good.

...I may not have absorbed everything in the post, but i know i am going to have ongoing problems with this thesis, as stated in the blog entry:

"But what is interesting is that about 80% of those customers are not waiting for an EE5-certified application server, but want to leverage specific features of our AS 5.0 architecture (mostly our JBoss Microcontainer)."

While this may be true, that a sample of customers were taken and the consensus seems to be that they will not be migrating their apps to EJB 3, etc..., I find it to be a poor job of understanding JBoss' role and competitive advantage in the wider middleware space:

if JBoss 5 does not get customers to move to JEE 5, then it will be a Vista-like failure, where upgrades will be simply about extending e.o.l. support contract timeframes, and will not deliver the technical benefits of a revised specification, nor the new business opportunities for JBoss to go after....


Douglas, I think you misunderstood what I wrote. I never said that EE5 or EJB3 weren't important. What I wrote is that JBoss 4.2.x *already* provides a BIG chunk of what is interesting in EE5. As part of JBoss AS 4.2.x, we ALREADY provide a complete EJB3 container, an EE5 WS stack, etc.

Consequently, customers that are eagerly waiting for our AS5 release, mostly do because:
- they want to leverage AS5.0 specific features (like our microcontainer - OEM/ISV)
- because their internal policies require that they use a EE5 *certified* AS (and 4.2.x is not EE5 certified)

As you probably remember, we have been big proponents of the EJB3 and JPA specs (we have provided the first implementation to market years ago) So we are certainly not shying away from EE5, we have spent a lot of time, energy and innovation into it.


in short, Sacha, watch your marketing of JBoss 5 as a fancy, techno, micro-container innovation, especially at the expense of application component development innovations, because there is this little company called SpringSource that is currently eating your lunch...


Again, read my blog: we are perfectly aware that many of our customers are using very different APIs to leverage our AS services. Most of them rely on EE, some of them on Spring, etc. And that's fine. I don't really mind which "wrapper API" they are using: we are here to support them in their preferred scenarios. What matters is how flexible our underlying foundation is so we are able support these multiple scenarios.

Having an API-agnostic core is key to longevity of your investment. This doesn't mean we don't care about these API/programming model, but they are really two different concerns.


my suggestions is to get back on message with promoting JEE, and establishing JBoss 5 as the pre-eminent deployment platform for all things JEE on Linux, and start making a ton of money; nothing says market opportunity for Seam, like hundreds of new installations of JEE 5 shops that adhere to the full complement of the spec...

that is boring, and I understand Muzilla is on the 're-factoring' angle, so i am not going to scold, or question, i just think that there is real competition now, with Oracle, IBM, Glassfish, Spring, and .Net to compete with JBoss:

u guys need to execute like hell, and prove to everyone why u won the leadership position in the 1st place...


(NOTE: we are a multi-OS solution, ew are not a Linux-only solution. We certify all of our platforms at least on Windows, Linux, Solaris, HP-UX, AIX. This doesn't mean we are not working on synergies with the RHEL team, au contraire, but our platforms are OS-agnostic)

As for the "boring" note, no need to sell me on this. Communities like TSS are not representative of the IT world out there. Posters are usually versed into new buzz, innovations and are very vocal. That's great, but it would be a mistake to think there is a one-to-one mapping between this community and the middleware market at large. Our job at JBoss is to make sure we provide what the largest number of "real life" users need out there *and* work on innovation for what's needed tomorrow (much like we did with EJB3 and JPA and what we do now with WebBeans). They are complementary tasks, they are not exclusive.

  Message #260328 Post reply Post reply Post reply Go to top Go to top Go to top

profit

Posted by: Chief Thrall on July 03, 2008 in response to Message #260326
Also, senior executives do not know and understand technology, nor they should. All they see are numbers: profit/growth, call it how you want.

Its your duty as techie to chose best option, not only for development phase, but also for the future, 5-10 years, depending how long project will live.

If two technologies are comparably equal, and neither one brings dramatic improvements in some areas where big revenue could be generated by simple fact of using one over the other, then standards will always be used, and standards will win.

That is why JEE is The Best at the moment. New technologies must make significant improvements in order to replace JEE.

  Message #260329 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Suspicious of anything that takes three years to develop

Posted by: Sacha Labourey on July 03, 2008 in response to Message #260163
In what respect?


Like I said, I haven't done research in this area and my experience is limited to writing totem single ring membership protocol impl at spare time, however my 6th sense is telling me Coherence is better product overall (not cheaper).


Thanks for sharing with us your 6th sense.

My 6th sense tells me many users won't know what to do with what your 6th sense tells you :)

  Message #260330 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Saying a standard is "less risk" doesn't make it so

Posted by: Wille Faler on July 03, 2008 in response to Message #260324
In my CORBA days I always said that every custom built "light weight" remoting solution will eventually end up looking like CORBA they only difference is that one was designed with most of the features in mind whereas the other evolved as the (overlying simplified) problem domain was expanded because of harsh realities. The same can be said for much of the component/pojo middleware today. Which approach do you think is better?


The problem at the heart of the issue is over-engineering: how many people that use ejb's actually _need_ the remoting capabilities? If not, do they actually need ejb's at all? The same goes for custom built "light weight" remoting solutions.

J2EE was originally applied with a crowbar into every crevace it could find.
If you are effectively shuffling data from a database to and from a web front end, why would you need anything more than a servlet container, a nice web framework, and an ORM framework?
By the same token, if you are dealing with a messaging system, why would you need anything but messaging middleware and possibly message driven beans?

See what I'm getting at?

  Message #260331 Post reply Post reply Post reply Go to top Go to top Go to top

Re: misguided

Posted by: Sacha Labourey on July 03, 2008 in response to Message #260184
Perhaps i am the biggest curmudgeon on TSS, but after re-reading Sasha's blog entry, i am feeling a little queasy on the direction of JBoss, and wonder whether there is actually customer support for the premise that different development models will actually make JBoss more business-scalable...

it is tempting to build a bigger business than the 1 that a company may b in, but i will submit that the temptation to be a run-time for everything including Spring, Grails, and potentially other development models, we have a product-line that is at least a year late to market...Cost-Benefit Analysis is tricky especially preceding a product release, but i am not so sure about this bet that JBoss has made on a new type of application server implementation, especially considering that it appears that SpringSource and Glassfish have already accomplished this modularity...


This is very wrong. The modularity required to face the challenges of the next 3-5 years is much higher than what you can find out there. Stating that things are fine because your AS relies on OSGi is as useful as stating that it is based on CORBA or CCM or JMX. Evolution's need have stronger requirements.

what is going to be the market adoption of something that is so classically in a follower position? that really is the question, and i just don't know what data and information went in to the decision to move beyond JEE, but I haven't seen anything convincing, other than purported job request figures from the Spring guys...


Agreed: EE is very strong, hence our TOTAL SUPPORT FOR IT (since AS 4.2.x btw). But why do you want JBoss to be mono-maniac when it comes to APIs and programming models? Those are like tastes and colors, you won't fit a one-size-fits-all solution, so let's bring flexibility!

As a EE user, what does it change for you? Just ignore the APIs you don't want to use :) It is about choice.




have enterprise customers moved away from Java: perhaps some, but to claim this is a trend that justifies what has happened with JBoss 5 seems a bit of a stretch; James Watson's statement of JEE being "irrelevant" is 100% propaganda, as is the premise that app servers don't have a future in generating the development model counter to .Net implementations...

basically, i am saying nothing new, but it just seems the more that people bet against JEE, or at least, predict its ultimate demise in reduced demand, that it is lacking in historical precedence or even based in reality...its one thing to have some fellow developers try out different development paradigms, it is quite another to get enterprise customers to standardize on something other than what is legacy...

i am so tired of the "JEE is dead" discussions, that i am completely baffled why JBoss seems to be hedging 4 it, perhaps u could argue that it is a risk-mitigator for the future, but right now, i just think it was misguided MRD and PRD analysis that called for an entirely new platform, that is not even close to done, with all the other moving pieces that need to be integrated...

my suggestion: get a Red Hat Enterprise Linux certified JBoss 5 out to market, and ditch Solaris, Hp-UX, AIX, and even NT, with a development supported product for XP; everything else is just too risky to pull off...

Rich, I hate to continue to be inflammatory, but i can c why they brought u in for Product management: JBoss is in some serious need of people to make decisions that are non-technical, and rely on business metrics; i hope u make the best of it...


No worries, we are doing more than fine. But we are certainly NOT going to ditch support for other OSes: we have a significant portion of our users going in production on Solaris, Windows, etc. and again, that is a matter of choice - we won't dictate that.

Cheers,


Sacha
CTO JBoss, a division of Red Hat

  Message #260332 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Saying a standard is "less risk" doesn't make it so

Posted by: Wille Faler on July 03, 2008 in response to Message #260325
It is less risk in the future, not less risk now. Lets say two years after mission critical business application was developed and deployed in production environment, software problems/bugs occur. Company has no in-house development, and has always outsourced/bought software development.


My point exactly is that it may _not_ be less risk in the future. How do you migrate an application based on EJB's from one app server coming to End of Life to a recent version in a risk free way? You don't.
How do you do it with something built in mostly plain java? You just drop it in.

The same thing goes for future development once the original people have buggered of: plain java is plain java, a skill easy to find. Finding someone who knows EJB 1.1 on Websphere 4 and all the ins and outs of deployment is harder, especially years on, not to mention someone actually willing to do the work.
Most people I know who would have that skillset don't particularly want to use it if they have a choice, leaving you with subpar developers to try to make sense of your old application.

Then try to find new developers/maintenance guys who have the courage to make changes if the testing cycle is change/build/deploy/test that takes 15 minutes.

  Message #260334 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Saying a standard is "less risk" doesn't make it so

Posted by: Chief Thrall on July 03, 2008 in response to Message #260332
Most people I know who would have that skillset don't particularly want to use it if they have a choice, leaving you with subpar developers to try to make sense of your old application.

Then try to find new developers/maintenance guys who have the courage to make changes if the testing cycle is change/build/deploy/test that takes 15 minutes.


Its not about migration but about size of workforce market, at least IMHO.

More people have know-how and offer services around standard APIs, tools.

Also you cant code everything in plain java, maybe can in small to mid size applications, but when there is lots of money at stake (any mission critical system), I can guarantee none project leader will allow usage of open source, a.k.a. you wont see usage of Bitronix, JOTM or any other open source transaction manager for big systems. That's why you buy EJB container: you buy contractual guarantees that mission critical aspect of your system (correct transaction management) is working correctly etc.

  Message #260335 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Suspicious of anything that takes three years to develop

Posted by: Chief Thrall on July 03, 2008 in response to Message #260329
Thanks for sharing with us your 6th sense.

My 6th sense tells me many users won't know what to do with what your 6th sense tells you :)


Well my 6th sense was largely based on the fact that 3rd largest software company in the world purchased Coherence, and that same company delivers best database in the world, so it is highly unlikely they would purchase something which is not among, if not, the best in the world. =)

  Message #260338 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Saying a standard is "less risk" doesn't make it so

Posted by: Wille Faler on July 03, 2008 in response to Message #260334
Its not about migration but about size of workforce market, at least IMHO.

More people have know-how and offer services around standard APIs, tools.

But that's exactly what I'm saying! I'm pretty sure there are more people around that now Java and the JDK API's, than people who for instance also know everything about EJB 1.1 on Websphere 4.
If people are more familiar with JEE API's than JDK API's, I'd be very wary of letting them come anywhere near my company.

Also you cant code everything in plain java, maybe can in small to mid size applications, but when there is lots of money at stake (any mission critical system), I can guarantee none project leader will allow usage of open source, a.k.a. you wont see usage of Bitronix, JOTM or any other open source transaction manager for big systems.

I don't think it really has to do with size of projects, it is about what technologies you need, and what they bring to the table to solve your task.


That's why you buy EJB container: you buy contractual guarantees that mission critical aspect of your system (correct transaction management) is working correctly etc.

I've seen lots of instances where people using EJB containers get it all wrong with transaction management for instance (explicit "beginTransaction", "commitTransaction" allover the place, swallowing Exceptions etc), and on the other hand instances with no EJB container where the transaction management has been flawless and completely transparent.

A container can only give you _contractual_ guarantees, not absolute guarantees. At the end of the day it comes down to quality of people and practices.
Believing a "standard" is automatically less risk and will automagically solve all challenges is just lazy thinking in my opinion.

  Message #260339 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Saying a standard is "less risk" doesn't make it so

Posted by: Chief Thrall on July 03, 2008 in response to Message #260338
A container can only give you _contractual_ guarantees, not absolute guarantees. At the end of the day it comes down to quality of people and practices.

Absolutely agree.

I'm pretty sure there are more people around that now Java and the JDK API's, than people who for instance also know everything about EJB 1.1 on Websphere 4.


I agree, but you cant do everything in Java SE, there are services in EE not present in SE, which you could emulate in SE but you would then reinventing the wheel in non-standard way, and with lower quality.

I've seen lots of instances where people using EJB containers get it all wrong with transaction management for instance (explicit "beginTransaction", "commitTransaction" allover the place, swallowing Exceptions etc), and on the other hand instances with no EJB container where the transaction management has been flawless and completely transparent.


Well I have seen pretty bad cases as well, however I still feel that given developers with same level of skill, usage of standard APIs will provide less risk in long term.

Believing a "standard" is automatically less risk and will automagically solve all challenges


Standard is less risk in high majority of cases, but it of course does not solve challenges: for that we need smart developers.

  Message #260340 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Saying a standard is "less risk" doesn't make it so

Posted by: Wille Faler on July 03, 2008 in response to Message #260339
A container can only give you _contractual_ guarantees, not absolute guarantees. At the end of the day it comes down to quality of people and practices.

Absolutely agree.

I'm pretty sure there are more people around that now Java and the JDK API's, than people who for instance also know everything about EJB 1.1 on Websphere 4.


I agree, but you cant do everything in Java SE, there are services in EE not present in SE, which you could emulate in SE but you would then reinventing the wheel in non-standard way, and with lower quality.

I've seen lots of instances where people using EJB containers get it all wrong with transaction management for instance (explicit "beginTransaction", "commitTransaction" allover the place, swallowing Exceptions etc), and on the other hand instances with no EJB container where the transaction management has been flawless and completely transparent.


Well I have seen pretty bad cases as well, however I still feel that given developers with same level of skill, usage of standard APIs will provide less risk in long term.

Believing a "standard" is automatically less risk and will automagically solve all challenges


Standard is less risk in high majority of cases, but it of course does not solve challenges: for that we need smart developers.


I think we are at an agreement. :)

  Message #260355 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Saying a standard is "less risk" doesn't make it so

Posted by: James Watson on July 03, 2008 in response to Message #260339
I'm pretty sure there are more people around that now Java and the JDK API's, than people who for instance also know everything about EJB 1.1 on Websphere 4.


I agree, but you cant do everything in Java SE, there are services in EE not present in SE, which you could emulate in SE but you would then reinventing the wheel in non-standard way, and with lower quality.


I'll jump back in here since I started this little sub-thread.

I agree that IT management tends to go for the standard because it is perceived to be less risky. In theory it should be but the experience of J2EE calls this into question. We have to support multiple app-server vendors because 3rd party products "only run on WebSphere" or "only run on WebLogic". If you don't get interchangeability, then there's no value being confined to the limits of a standard.

Actually, the Servlet spec from J2EE is a resounding success in my book and that's J2EE. It's just not what I think of when people talk about J2EE.

The other thing I'll say is that even though it seems that people would have to know JSE to know JEE, I interview a lot of people who are familiar with JEE and can't really answer any basic JSE questions. They seem perplexed that someone actually cares about the fundamentals. I agree with Willie that I don't want these people on my team.

Lastly, there are things that JEE offers that you shouldn't try to do yourself, assuming you actually need them. I have coworkers that insist that we need a full-blown app server when all they are acutally using is the servlet-container and a connection pool. To me that's just paying for something that's free and making life much more painful than it needs to be.

As far as standards go, I see a lot of potential in OSGi and I'm unconvinced that JEE has a value proposition that makes sense.

  Message #260362 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Suspicious of anything that takes three years to develop

Posted by: Bill Burke on July 03, 2008 in response to Message #260335
Thanks for sharing with us your 6th sense.

My 6th sense tells me many users won't know what to do with what your 6th sense tells you :)


Well my 6th sense was largely based on the fact that 3rd largest software company in the world purchased Coherence, and that same company delivers best database in the world, so it is highly unlikely they would purchase something which is not among, if not, the best in the world. =)


Hey, they (Oracle) tried to purchase us (JBoss) first, before InCoherence....So... <applause> Great theory, I agree with it wholeheartedly!!!

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

  Message #260366 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Saying a standard is "less risk" doesn't make it so

Posted by: Andy Gibson on July 03, 2008 in response to Message #260330

The problem at the heart of the issue is over-engineering: how many people that use ejb's actually _need_ the remoting capabilities? If not, do they actually need ejb's at all? The same goes for custom built "light weight" remoting solutions.

...

If you are effectively shuffling data from a database to and from a web front end, why would you need anything more than a servlet container, a nice web framework, and an ORM framework?
By the same token, if you are dealing with a messaging system, why would you need anything but messaging middleware and possibly message driven beans?


EJB != Remote Beans.

Why not just stick with the servlet spec and JDBC? Why bother with all that heavy weight ORM and web framework stuff? Why should I bog my app down with the Hibernate criteria api, or query by example when I just need to persist objects to and from the database?

How are you going to manage state? When your Ajax web framework keeps hammering the server with requests that you have to handle against your model, are you going to keep shuffling the data from the database to the view/business logic until it slows your app to a crawl? How are you going to handle optimistic locking when you keep on using the latest copy from the database? Are you going to throw it into the session? How are you going to handle replication? Dirty checking? Are you sure you pushed the object back into the session every time you modified it? What about opening the same page in two windows or tabs? Will it break because you name the session object the same thing in each page with one page overwriting the values of the other page?
Suddenly, just using a nice web framework and an ORM lib has you writing a bunch of additional code to handle all this.

Not every web application is just a hello world or a pet store with a session scoped user and shopping cart. I often wonder how people solve these problems in applications they build, but the more I see other people's code, the more I think they either a) Ignore it or b) just aren't aware of it because they certainly don't plan for it.

To address another point you made :


To play the devil's advocate for a second: WHY is it less risk?
4-6 years ago, everyone went crazy for EJB's because it was "a standard and less risk".Now most people who adopted them are in a right mess: can't upgrade their JVM's or app servers, too big a risk, can't improve or extend their codebase, too big a risk since EJB's are almost untestable.


That like saying years ago, people were using Microsoft DOS and now nobody uses it and they are stuck with all these unsupported DOS applications and data, so we should avoid all OS's from Microsoft which is fine because Mac OS X is way better than Dos. You can't compare what is available today with what is available now, especially when the technology of yesteryear was a building block to todays offerings. There is no Spring without EJB 2.1 frustrating the heck out of people.
If you are referring to homegrown POJO solutions, I would say that these probably have less functionality and are more complex to deal with until the developers are familiar with a custom framework.

If a 'public' framework like Spring, Wicket etc is less risk (and less complexity) than writing your own framework, it seems logical to follow the assumption that a 'standard' framework (which had obtained reasonable public acceptance) is even less risk.

  Message #260364 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Suspicious of anything that takes three years to develop

Posted by: Sacha Labourey on July 03, 2008 in response to Message #260335
Thanks for sharing with us your 6th sense.

My 6th sense tells me many users won't know what to do with what your 6th sense tells you :)


Well my 6th sense was largely based on the fact that 3rd largest software company in the world purchased Coherence, and that same company delivers best database in the world, so it is highly unlikely they would purchase something which is not among, if not, the best in the world. =)


I don't get your logic. Because you have the best DB, what does it mean? that you only do wise acquisitions? or that all of your products are great? But then, if all of your products are great, why do you need to do acquisitions in the first place? I don't follow.

  Message #260367 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Suspicious of anything that takes three years to develop

Posted by: Bill Burke on July 03, 2008 in response to Message #260364
Thanks for sharing with us your 6th sense.

My 6th sense tells me many users won't know what to do with what your 6th sense tells you :)


Well my 6th sense was largely based on the fact that 3rd largest software company in the world purchased Coherence, and that same company delivers best database in the world, so it is highly unlikely they would purchase something which is not among, if not, the best in the world. =)


I don't get your logic. Because you have the best DB, what does it mean? that you only do wise acquisitions? or that all of your products are great? But then, if all of your products are great, why do you need to do acquisitions in the first place? I don't follow.


No! NO!....Sacha...I like his logic, by his logic, we are the best app server in the world...

  Message #260369 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Suspicious of anything that takes three years to develop

Posted by: Cameron Purdy on July 03, 2008 in response to Message #260362
Hey, they (Oracle) tried to purchase us (JBoss) first, before InCoherence....


Poor Bill .. ;-)

Peace,

Cameron Purdy
Oracle Coherence: Data Grid for Java, .NET and C++

  Message #260370 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Saying a standard is "less risk" doesn't make it so

Posted by: Wille Faler on July 03, 2008 in response to Message #260366

EJB != Remote Beans.

..you are telling that to someone who has spent the bulk of his career working with messaging systems, so I've dealt with my fair share of MDB's, however, it does not take away the fact that a lot of cases of EJB use is supported on the strawman that maybe, just maybe someone somewhere will want to remotely access something over RMI (when in fact it will never happen).

As for your barrage of questions: you are just being ridiculous and completely missing the point.

People should use the technologies and frameworks that _make sense_ in their particular situation, but throwing in everything and the kitchen sink just because it is "a standard and less risk" is stupid.
And don't tell me it doesn't happen: I've seen it too many times when people just bulk up on everything, for no good reason (other than padding their CV's), and end up having 10 "standard" technologies and 5-6 layers when 2-3 technologies and 3 layers would have been enough.

KISS is a pretty good attitude and practice: use what you need, and no more.

  Message #260372 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Suspicious of anything that takes three years to develop

Posted by: Chief Thrall on July 03, 2008 in response to Message #260364


I don't get your logic. Because you have the best DB, what does it mean? that you only do wise acquisitions? or that all of your products are great? But then, if all of your products are great, why do you need to do acquisitions in the first place? I don't follow.


We all know Oracle has two strategies like any other big corporation: purchase and either embrace (Oracle doesnt have similar in house offerings or has but with lower quality, or simply purchased product has better brand) or kill (Oracle has better or similar quality offerings, just wants to get rid of competition).

If Oracle purchased MySql, they would have killed it, since we all know Oracle DB > Mysql.

They didn't had Coherence-like offerings in house, and they decided to strengthen their market position in middleware area by purchasing the best solution on the market.

That sounds like pretty solid plan to me, and considering Oracle has been on the market for over 30 years, it is very likely they have made very, if not the best move when purchasing Coherence.

There you go, you have just been enlightened...

  Message #260373 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Suspicious of anything that takes three years to develop

Posted by: Chief Thrall on July 03, 2008 in response to Message #260367
No! NO!....Sacha...I like his logic, by his logic, we are the best app server in the world...

Quite the opposite Bill. If JBoss was better than BEA in terms of cash flow and steady growth, Oracle would have purchased it over BEA.

Simply JBoss financial statements were in poor condition compared to BEA's.

And even if they have purchased BEA to kill it, it again shows they consider BEA much bigger threat on the market than JBoss.

Those are the facts.

  Message #260374 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Suspicious of anything that takes three years to develop

Posted by: Chief Thrall on July 03, 2008 in response to Message #260373
No! NO!....Sacha...I like his logic, by his logic, we are the best app server in the world...



Quite the opposite Bill. If JBoss was better than BEA in terms of cash flow and steady growth, Oracle would have purchased it over BEA.

Simply JBoss financial statements were in poor condition compared to BEA's.

And even if they have purchased BEA to kill it, it again shows they consider BEA much bigger threat on the market than JBoss.

Those are the facts.

Had to report, didnt use quote tags correctly.

  Message #260375 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Saying a standard is "less risk" doesn't make it so

Posted by: Chief Thrall on July 03, 2008 in response to Message #260355
I see a lot of potential in OSGi and I'm unconvinced that JEE has a value proposition that makes sense.

I'll try to quote one regular poster on TSS, who shall remain anonymous for the sake of simplicity

"OSGi is JAR file with lifecycle"

I agree with this strong but IMHO correct statement, OSGi is not some kind of revolutionary technology, and it seems it is more of IT buzz term, since in order for global IT companies to generate steady stream of income, we need from time to time to create buzz in the industry in order to sell easier to executives. Personally, OSGi belongs to same groups as SOA, Web2.0, Agile, REST etc.

People have been there and done that. Same old things in little different flavor.

Also, English aint my native so I couldnt figure out if you are saying that OSGi will replace EE? If not, please ignore this sentence.

The other thing I'll say is that even though it seems that people would have to know JSE to know JEE, I interview a lot of people who are familiar with JEE and can't really answer any basic JSE questions. They seem perplexed that someone actually cares about the fundamentals. I agree with Willie that I don't want these people on my team.


I agree with this but this is out of the scope, we are discussing why we need EJB/EE servers from business/tech perspective, not from HR/project leading view. Bad developers are bad in any platform/language etc.

I agree that IT management tends to go for the standard because it is perceived to be less risky. .... then there's no value being confined to the limits of a standard.


I dont think they only perceive, I think they know its less risky, and personally I would do the same. Imagine what would happen if we didn't have standards like JMS, JDBC and so on. With standards you go and see if vendor A is compliant, and if so, you read official spec, and you are 100% sure what the behavior of certain methods from standard API is. With standards we have globally agreed semantics of certain behaviors.

  Message #260398 Post reply Post reply Post reply Go to top Go to top Go to top

I doubt it....

Posted by: Noel O'Connor on July 03, 2008 in response to Message #260374
No! NO!....Sacha...I like his logic, by his logic, we are the best app server in the world...



Quite the opposite Bill. If JBoss was better than BEA in terms of cash flow and steady growth, Oracle would have purchased it over BEA.

Simply JBoss financial statements were in poor condition compared to BEA's.

And even if they have purchased BEA to kill it, it again shows they consider BEA much bigger threat on the market than JBoss.

Those are the facts.

Had to report, didnt use quote tags correctly.


Oracle bought BEA simply because they saw a lot of high value customers using BEA products. The problem now is that a lot of companies are moving to using a lot of open source in their projects hence the growth of spring etc,etc.
Oracle know that for the short term they have the previous BEA customers over a barrel hence the price hike.

People may bitch about how long it has taken JBoss 5 to come out and how that *now* [insert appsvr name here] is so much better but remember that these things a cyclic and soon enough others will be bitching about other app servers.

  Message #260407 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Saying a standard is "less risk" doesn't make it so

Posted by: James Watson on July 03, 2008 in response to Message #260375
I see a lot of potential in OSGi and I'm unconvinced that JEE has a value proposition that makes sense.

I'll try to quote one regular poster on TSS, who shall remain anonymous for the sake of simplicity

"OSGi is JAR file with lifecycle"

I agree with this strong but IMHO correct statement, OSGi is not some kind of revolutionary technology, and it seems it is more of IT buzz term, since in order for global IT companies to generate steady stream of income, we need from time to time to create buzz in the industry in order to sell easier to executives. Personally, OSGi belongs to same groups as SOA, Web2.0, Agile, REST etc.


OSGi is more than just a jar with a lifecycle. If that's what you really think it is, you should read up on it because you might be doing things in an outdated fashion without realizing it.


Also, English aint my native so I couldnt figure out if you are saying that OSGi will replace EE? If not, please ignore this sentence.


OSGi is one piece of the puzzle. It allows you to pull modular parts together. It means that you don't necessarily need a single vendor to deliver all the parts.

I think they know its less risky, and personally I would do the same. Imagine what would happen if we didn't have standards like JMS, JDBC and so on. With standards you go and see if vendor A is compliant, and if so, you read official spec, and you are 100% sure what the behavior of certain methods from standard API is. With standards we have globally agreed semantics of certain behaviors.


Standard can be very good. They can also be very bad. Just because something is a standard doesn't mean it's a good choice. J2EE has become a huge money sink for companies and most apps running on them are not portable without costly development efforts. Standards are like anything else. You must consider them based on their merits.

  Message #260457 Post reply Post reply Post reply Go to top Go to top Go to top

Re: nice work

Posted by: douglas dooley on July 04, 2008 in response to Message #260331
Sacha,

My congrats to you and to some extent, Rich, for coming on here and getting some much-needed information in to the public domain, i think it is a historical testament to JBoss' success that ur poeople have time and again, come on TSS to further the debate and make statements that give people more than just guess-work perspective...

I wrote a blog entry on my thoughts on the application server market that you can reference below, but here are a couple of points that i will make w/r/t the JBoss 5 impending release:

a. no one is buying 4.2x as JEE5

It may be that you guys have been in the expert groups, and have even been the shepherds of the process for bringing EJB back to life w/ v.3 and JPA, and I understand u have the latest JAX support in 4.2x, but as u kind of mentioned this does nothing for developers and truly only is relevant to die-hard JBoss customers to 'test' JEE 5 capabilities, albeit that is a large group, but Glassfish is now the go-to JEE 5 server, by any account...

b. OSGi and modularity

I honestly don't even understand this discussion, as I mentioned before referencing Muzilla's "re-factoring" discussions in the Register, so I can't comment on what it exactly mean to be "modular", but i don't think anyone can truly believe that u r more modular than Glassfish or Spring, that is simply a matter of semantics...

c. multi-OS strategy

What kind of business do you have on AIX and HP-UX, its got to be in the single digit millions with no real reason for that to go up, based on the growth projections of those OS's? I like the Linux only strategy because it declares u as the go-to implementation for all Red Hat customers, which is a magnitudes larger base than JBoss, and Solaris is kind of dying, anyway...besides, there is an opportunity cost component that i tried to address with the length of the JBoss 5 delay; also, there are so many things that could be done with ISVs if they just were able to certify on JBoss/Red Hat and not do every other platform:

imo, the major thing holding back the Red Hat Application Marketplace or whatever that OSS clearinghouse is called is JBoss, and not having something for the ISVs to mark to, and so it is actually hurting Red Hat to have a multi-OS JBoss strategy; that is a significant opportunity cost, in many respects...

d. JEE

we r just going to have 2 agree to disagree that there is a future for JBoss outside of JEE, i just dont see it, and considering the market opportunity, it kind of feeds the opportunity cost argument, that the more u guys 'diversify', the less ideas, implementations, and execution is given to the fight against Spring (to a small extent) and to .Net (to a much larger extent)...i know, i know, u guys love Spring, i just don't see it, until there is some common ground found with EJBs...

truly, all the best, i am apparently out of ideas, but i would encourage u guys to continue to populate this message board with information, i think we are all better-off the more that JBoss fights for its place in the marketplace, rather than assume it with a whiz-bang new release...

douglas dooley
douglasdooley.blogspot.com

  Message #260532 Post reply Post reply Post reply Go to top Go to top Go to top

Re: I doubt it....

Posted by: Chief Thrall on July 04, 2008 in response to Message #260398
Oracle bought BEA simply because they saw a lot of high value customers using BEA products.


Couldn't agree more on this one.

  Message #260539 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Saying a standard is "less risk" doesn't make it so

Posted by: Chief Thrall on July 04, 2008 in response to Message #260407
OSGi is more than just a jar with a lifecycle. If that's what you really think it is, you should read up on it because you might be doing things in an outdated fashion without realizing it.


I have read and used this stuff, so we shall see what OSGi will turn out to be.

OSGi is one piece of the puzzle. It allows you to pull modular parts together. It means that you don't necessarily need a single vendor to deliver all the parts.


You dont have to use one vendors stack in JEE as well. I just have counted jar files on classpath from my last project, and it includes ~80 jar files, excluding implementation of standard APIs provided by app server.

Standard can be very good. They can also be very bad. Just because something is a standard doesn't mean it's a good choice.


Well, we shall see about this part as well. If we keep an eye on new Spring's AppServer, we shall see how big players in industry will respond to offerings of non-standard platform, with no global consensus.

  Message #260563 Post reply Post reply Post reply Go to top Go to top Go to top

What's the major malfunction of Douglas Dooley?

Posted by: Frank Bank on July 04, 2008 in response to Message #259887
Either this guy should be hired by RedHat as a strategic technical blah, or should be fired by his current employer.

Seriously dude, what's your major malfunction?

  Message #260575 Post reply Post reply Post reply Go to top Go to top Go to top

Re: What's the major malfunction of Douglas Dooley?

Posted by: AD aa on July 04, 2008 in response to Message #260563
What exactly is wrong with his post? I did see some of yourother post and they are merely useless one-two liners wiht no real technical stuff in them. So what's YOUR major malfunction?

  Message #260580 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Saying a standard is "less risk" doesn't make it so

Posted by: James Watson on July 04, 2008 in response to Message #260539
Standard can be very good. They can also be very bad. Just because something is a standard doesn't mean it's a good choice.


Well, we shall see about this part as well. If we keep an eye on new Spring's AppServer, we shall see how big players in industry will respond to offerings of non-standard platform, with no global consensus.


First of all, where's the global consensus on JEE? J2EE was never derived from global consensus and that's where it went wrong. JEE is what it is now because tools that gained global consensus made it look ridiculous. OSGi, on the other hand is a standard built on consensus. It's not owned by a single company.

There's nothing that remains to be seen about that statement. There are many standards that adopters have regretted adopting. J2EE is a perfect example. All I have to do to make my case is show one bad standard. You would have to show that all standards are good. Anyone with a basic understanding of logic knows that. Either logic isn't your thing or you are purposely avoiding the real point that has been made. Either way, it's an annoying response.

Whether a non-standard implementation succeeds or not has nothing to with whether all standards are good.

  Message #260583 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Saying a standard is "less risk" doesn't make it so

Posted by: Chief Thrall on July 04, 2008 in response to Message #260580
J2EE was never derived from global consensus and that's where it went wrong.


Come on now, that statement is soooo wrong. Go take a look at list of vendors cooperating on EJB3, over 20 big corporations.
Probably every vendor supporting OSGi is also taking participation in some EE standard as well.

[osgi] It's not owned by a single company.

Being owned by single corporation is not automatically bad thing. Remember we are talking here about Sun, one of biggest open source contributors in the world, and they cant do as they are pleased since if there was no global consensus on EJB in early days, it probably wouldnt hit the mainstream.

All I have to do to make my case is show one bad standard. You would have to show that all standards are good.

Wrong again. One word: evolution of IT. If there were no EJB, there would be no Spring. OSGi aint no silver bullet, and in couple of years we will see new technology that will claim to be new OSGi, and circle of "innovation" will continue. No EE standard is bad, but there are some better alternatives for certain standards.


Either logic isn't your thing

Anyways, I aint gonna argue with you any more, believe what you want. I think you are pissed off at Sun/EE for some reason and hate anything related to EE and like everything that is alternative to EE.

Similar to RoR/Ruby/Scala guys. Go ahead do your thing, I'm kind of busy now, trying to make some cash and have fun at the same time on the most mature and stable platform in the world: Java EE.

  Message #260603 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Saying a standard is "less risk" doesn't make it so

Posted by: James Watson on July 04, 2008 in response to Message #260583
All I have to do to make my case is show one bad standard. You would have to show that all standards are good.

Wrong again. One word: evolution of IT. If there were no EJB, there would be no Spring.


You are repeatedly demonstrating an inability to follow a basic logical proposition.

I think you are pissed off at Sun/EE for some reason and hate anything related to EE and like everything that is alternative to EE.


Right. I couldn't actually mean what I said. If anyone disagrees with you it means they have an ulterior motive. That's a really mature way to think about the world.

I think you are long on rationalizing and short on critical thinking.

Similar to RoR/Ruby/Scala guys. Go ahead do your thing, I'm kind of busy now, trying to make some cash and have fun at the same time on the most mature and stable platform in the world: Java EE.


Oh really? I hate fun and money. That must be why I don't have much interest in JEE.

  Message #260610 Post reply Post reply Post reply Go to top Go to top Go to top

Re: nice work

Posted by: James Watson on July 04, 2008 in response to Message #260457
b. OSGi and modularity

I honestly don't even understand this discussion, as I mentioned before referencing Muzilla's "re-factoring" discussions in the Register, so I can't comment on what it exactly mean to be "modular", but i don't think anyone can truly believe that u r more modular than Glassfish or Spring, that is simply a matter of semantics...


Glassfish's modularity comes from OSGi. If you are talking about the Spring Application Platform, that too is built on OSGi.

  Message #261377 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Saying a standard is "less risk" doesn't make it so

Posted by: Chief Thrall on July 05, 2008 in response to Message #260603
If anyone disagrees with you it means they have an ulterior motive. That's a really mature way to think about the world.


Hahaha yeah, and if someone is disagreeing with you then "logic ain't his thing". You started first that kind of conversation buddy.

Glassfish's modularity comes from OSGi. If you are talking about the Spring Application Platform, that too is built on OSGi.

So what. There is nothing so revolutionary about OSGi you claim it to be. Morover, OSGi is sooo small part of overall IT and project management, yet you bully entire EE, though OSGi is alternative to maybe 0.005% of entire EE stack.

Your entire talk seems totally invalidated, go re-read your posts, you compare EE with OSGi and you say "I see a lot of potential in OSGi and I'm unconvinced that JEE has a value proposition that makes sense."

  Message #261435 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Frank and James

Posted by: douglas dooley on July 06, 2008 in response to Message #260610
Apologies, I have been sleeping for the past couple of days on this thread, and i didn't take the time to respond to the responses from u guys...

Frank,

I took the advice of the nice guy who defended me above, and looked at some of your older posts, where you claimed Java to b "legacy", to which i say: thank u, for making my main point in enterprise software - - that is, to be legacy is to b credible and reliable and legitimate, and therefore make that the best alternative in a sea of options...

Java as dying is your go-to argument, mine is Java is alive and very well, i think i am going to win this 1 every last time we discuss...

James,

I understand that modularity in this context often references an OSGi implementation, and i believe (though still not perfectly clear on it) that Muzilla was referring to modularity with his made-up concept of "re-factoring", and i know that Sacha's blog talks a bit about the JBoss 'modularity' campaign that may or may not be the same as Muzilla's re-factoring, but i am still unclear what the hell that means...

I am just a low-key observer, but i got to expect that after 10 years following Enterprise Java, if i don't have any idea what Muzilla is talking about, and if modularity seems to be a nice thing to have, but not a differentiator, that those Red Hat customers in Nebraska and around the world that the JBoss team should be focusing on won't have any idea either...

myopia is an interesting and useful word when appropriately utilized, and i throw it around from time-time to be inflammatory (like when MuleSource claims to b 'standard' without JBI), so i'll apologize a bit for thinking out loud here, but it seems that you guys have been somewhat myopic on this thread with the 'Java means nothing' argument,

all i can say is:

keep trying, its fun beating up on u...

  Message #262049 Post reply Post reply Post reply Go to top Go to top Go to top

Re: misguided

Posted by: Eelco Hillenius on July 07, 2008 in response to Message #260204
Any serious manager will always go for standard solutions, such as JEE, simply because it is less risk.


And the smart ones make up their own mind and pick the best match for their projects.

Also, many impressive tech companies (Google, Amazon) built their own software infrastructure, or at least important parts of it.

  Message #262050 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Saying a standard is "less risk" doesn't make it so

Posted by: Eelco Hillenius on July 07, 2008 in response to Message #260366
If you are referring to homegrown POJO solutions, I would say that these probably have less functionality and are more complex to deal with until the developers are familiar with a custom framework.

If a 'public' framework like Spring, Wicket etc is less risk (and less complexity) than writing your own framework, it seems logical to follow the assumption that a 'standard' framework (which had obtained reasonable public acceptance) is even less risk.


It depends on what you consider to be a standard framework I guess. I'm (happily) surprised you mention Wicket, because a common argument people have against Wicket is that it isn't a standard framework (these people pick JSF instead).

Personally I believe that people always win over frameworks. Frameworks, standard or not, can help you save a lot of work and reduce complexity etc, but they can also get in the way. But good people can do anything, even with mediocre tools/ frameworks.

  Message #262063 Post reply Post reply Post reply Go to top Go to top Go to top

Re: misguided

Posted by: Chief Thrall on July 08, 2008 in response to Message #262049
Also, many impressive tech companies (Google, Amazon) built their own software infrastructure, or at least important parts of it.


The talk is about companies whose primary interest is not in IT, a.k.a. companies which use software to support daily operations. They will always prefer to buy than to develop in house because its cheaper and less risky.

  Message #262064 Post reply Post reply Post reply Go to top Go to top Go to top

Re: misguided

Posted by: Chief Thrall on July 08, 2008 in response to Message #262063
Also, many impressive tech companies (Google, Amazon) built their own software infrastructure, or at least important parts of it.


The talk is about companies whose primary interest is not in IT, a.k.a. companies which use software to support daily operations. They will always prefer to buy than to develop in house because its cheaper and less risky.


Also, I agree partially. If the difference between quality of non-standard and standard product is huge (in favor of non-standard solution, with potential to gain competitive advantage at some level), yes they will chose non-standard.

If there is no difference, or difference is minor in favor of non-standard solution, they will go for standard solution, though it is more expensive.

  Message #262240 Post reply Post reply Post reply Go to top Go to top Go to top

Re: misguided

Posted by: Eelco Hillenius on July 08, 2008 in response to Message #262064
If there is no difference, or difference is minor in favor of non-standard solution, they will go for standard solution, though it is more expensive.


That sounds sane, but is it actually true? Can you point to research that supports your opinion?

I would hope that many decision makers look at a broad spectrum of pros and cons, including whether their project team will be happy to use a certain technology, whether that tech supports the way they want to work (e.g. do they put the emphasis on test first programming, or do they want to build quick prototypes using visual interfaces), etc. There can be advantages to using a 'standard' - though you'll have to make those advantages explicit for your situation -, but I don't think that should ever be the sole deciding factor like you sketch it to be.

  Message #262455 Post reply Post reply Post reply Go to top Go to top Go to top

Re: misguided

Posted by: Chief Thrall on July 09, 2008 in response to Message #262240
That sounds sane, but is it actually true? Can you point to research that supports your opinion?


Nope, no research, my opinion is based on various business management sources such as books, blogs, and on my work experience, such as one for 70k employees company, one of the largest in its industry (non-IT sector).

but I don't think that should ever be the sole deciding factor like you sketch it to be

I agree, standard should not be sole reason, however given factors from my previous post seems IMHO standards will always win.

Simply compare these two numbers:

1) Potential profit to be gained by using non standard solution (for example will give huge boost to daily operations...)

2) Potential loss (risk) by using non standard solution (core developers leave in middle of development so new hires must be found with limited market workforce pool, post development maintenance and critical bug fixes, if application is mission critical what will happen if original supplier of non-standard solution is out of business in 5 years, who will bug-fix if it is written in unknown technology X, and even if there are suppliers for that technology, it will cost more than EJB workforce body leasing, since high demand and low supply increases prices)



If 2 is bigger than 1, standard wins.

  Message #262456 Post reply Post reply Post reply Go to top Go to top Go to top

Re: misguided

Posted by: Chief Thrall on July 09, 2008 in response to Message #262455
That sounds sane, but is it actually true? Can you point to research that supports your opinion?


Nope, no research, my opinion is based on various business management sources such as books, blogs, and on my work experience, such as one for 70k employees company, one of the largest in its industry (non-IT sector).

but I don't think that should ever be the sole deciding factor like you sketch it to be

I agree, standard should not be sole reason, however given factors from my previous post seems IMHO standards will always win.

Simply compare these two numbers:

1) Potential profit to be gained by using non standard solution (for example will give huge boost to daily operations...)

2) Potential loss (risk) by using non standard solution (core developers leave in middle of development so new hires must be found with limited market workforce pool, post development maintenance and critical bug fixes, if application is mission critical what will happen if original supplier of non-standard solution is out of business in 5 years, who will bug-fix if it is written in unknown technology X, and even if there are suppliers for that technology, it will cost more than EJB workforce body leasing, since high demand and low supply increases prices)



If 2 is bigger than 1, standard wins.


Its all about numbers and risk in business.

  Message #263974 Post reply Post reply Post reply Go to top Go to top Go to top

Don't be so selfish

Posted by: Pedro Andres Solorzano Parada on July 22, 2008 in response to Message #260329
Thanks for sharing with us your 6th sense.

My 6th sense tells me many users won't know what to do with what your 6th sense tells you :)


Communities like TSS are not representative of the IT world out there. Posters are usually versed into new buzz, innovations and are very vocal. That's great, but it would be a mistake to think there is a one-to-one mapping between this community and the middleware market at large


You cannot be so selfish. People from "Communities like TSS" usually recommends technology to decision makers (if they are not decision makers), so it is not too bright from you to ignore them. Meanwhile they will continue to deploy on Glassfish as a real enterprise quality open source JEE5 AS.

Oh, I forgot that JEE is not your business anymore,

It is not *really* about EJB3


Well, you seem to forget the origin of the JBoss name (EJBOSS rings any bells to you?). But, yes, that was Marc Fleury's crazy ideas... Flury is gone, lets do business with whats left, two years later. Well, maybe JBoss AS 5 is the best platform if you want to deploy anything different to EJB3 and JEE5. Until I need something like that I will continue using JEE as the best EE platform in the world, and of course over JEE commited Application Servers, like Glassfish.

New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com

Dependency Injection in Java EE 6 - Part 1

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: It's Not just for Web services

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)

Programming is Also Teaching Your Team

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)

Can Java EE Deliver The Asynchronous Web?

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)

JSF Flex

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)

The Rules of SOA - A Road to a Successful SOA Implementation

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 Talks About Terracotta 3.1

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)

Enterprise Application Integration, and Spring

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)

Google Web Toolkit: An Introduction

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)

Just Enough Early Architecture to Guide Development

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)

Productive Programmer: On the Lam from the Furniture Police

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)

Auto-Scaling Your Existing Web Application

Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers. (May 21, Tech Talk)

Automating Hibernate Mapping and Queries For Java Web Development

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)

Auto-Scaling Your Existing Web Application

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)

Free Book PDF Download: Mastering EJB Third Edition

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)

Application Server Matrix

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)
News | Blogs | Discussions | Tech talks | Patterns | Reviews | White Papers | Downloads | Articles | Media kit | About
Java Solutions
All Content Copyright ©2007 TheServerSide Privacy Policy
Site Map