Re: The demise of the Oracle professional?

In article <ae590c$429gr$1_at_ID-87429.news.dfncis.de>, you said (and I quote):
> > > Because J2EE can be deployed everywhere where you need
> > > scalability.
> > What the heck has that got to do with horizontal market technology?
> Keyword: "everywhere".

Nope. That's portability. And scalability, as you point out. That has nothing to do with horizontal market sectors.

>
> As I said, J2EE can be applied wherever there is a need for
> scalability.

Sure. So can more CPU grunt. Exactly what is it in J2EE that makes it a preferred solution for multi-tier? What is the difference in scalability between running a custom app with app server(s) and a J2EE framework?

> However:
> - Java is here since 1995.
> - J2EE is here since 1998.
>
> That's too long for a "fad."

I don't have a problem with Java itself. It's a language. As for J2EE, it might have been ANNOUNCED in 98. However IIRC, Websphere's release (4) to fully support it dates from where? Oh yes, end of 2001. And Weblogic's full support for J2EE dates from when? Oh yes, mid 2001. Same for O9iAS.

That is still very much in "fad" territory. At least in my book. There IS a difference between announcements and reality, no matter what Sun says.

>
> ATMs, anyone?

With J2EE? yeah, sure. Majority of the darn things are still running OS2...

> Thousands of terminals within a bank?

Yeah, so? Wanna bet there is a 3270 mainframe terminal emulator in EVERY SINGLE ONE of those terminals at the bank?

>
> HTML code is just a smallish part (HTML representation) of a smallish
> part (JSP, servlets) of J2EE.
>
> Are you confusing J2EE with servlet containers?

No I'm not. Just answer the question please: how the heck do I produce general purpose reports from a J2EE architecture?

>
> J2EE is all about databases and server components, NOT about
> documents.

J2EE is about NOTHING. It makes vague statements about databases, which change depending on who you're talking to. And it makes a lot of wild claims about servers. Mostly irrelevant anyway because other technologies have been addressing (and solving) the same problems for many years. Once again: let's not confuse client/server with J2EE.

As for an architecture that purports to address the entire ENTERPRISE area (hence the name Enterprise Edition, no?), it's a very poor showing when it doesn't even remotely cater for two of the most fundamental demands of enterprise data processing: reporting and batch processing.

>
> Just send in a message-driven bean at 01:00.

And?

You have never designed or had to run a batch system, have you?

>
> Automatically. Everything is there for you, app server
> gives you many nice capabilities "for free", and that's
> the beauty of J2EE.

That just reminded me of the claim from one of our J2EE "experts" that he could apply app server cache to an entity EJB and therefore make it run faster.

Brilliant technological breakthrough, never found anywhere else for the last 25 years!...

When questioned about exactly how that would work when the table(s) accessed by the EJB needed to be accessed in other modes by other concurrent applications, some possibly even not written in Java, things went surprisingly "clunk"...

You see, the niceties of the app server containers are not necessarily exactly new. Databases have been using optimised caches for decades. They are a much more efficient solution in that aspect than any container will ever be. EJB c ontainers are fine if you have non-shared flat files as your data store. Otherwise, they are simply redundant and inneficient for ANY kind of serious processing.

As for the "free" bit, nothing could be more wrong. There is no such thing as a free lunch in IT. There is a very heavy price to pay for the container functionality inbuilt into J2EE app servers. Most are simply optimised for "shopping cart" functionality (OLTP) and little else. And most make assumptions about data processing that are at the very least redundant.

There is no provision whatsoever for EJB sharing between applications other than through RMI or Corba, two notably inneficient and hard to use technologies.

That is the whole crux of J2EE: it's a complex and redundant solution desperately looking for a problem that doesn't exist. And providing no new solutions to age old problems.

>
> Life got easier for people using systems. Life got
> more complicated for people developing systems. On that
> "complexity gradient" we are making good money.

And that's what it's all about, no? Making $$$$. Anything else is secondary.

Like for example, the most basic tennet of marketing: the creation of long term demand for a product. Key word: long. Means: a LOT more than 2 years.

-- 
Cheers
Nuno Souto
nsouto_at_optushome.com.au.nospam