Oracle Launches Middleware Architecture Series

Discussions

News: Oracle Launches Middleware Architecture Series

  1. Oracle Launches Middleware Architecture Series (8 messages)

    The Oracle Technology Network is hosting a 10 week series of Oracle expert presentations, similar to TSS' Hard Core Tech Talks. Each presentation includes a video and a whitepaper. Last week Oracle posted a talk on architecting Web Services, this week they are featuring a "Performance guidelines for architecting J2EE applications" talk with Steve Harris, Director of their Java Platform Server Technlogies group.

    Future seminars are said to focus on topics such as clustering, security, firewalls, transactions and high availability.

    Check out the Middleware Architecture Series.

    Threaded Messages (8)

  2. Anyone else read this stuff?[ Go to top ]

    I just read the "white paper" with the title "Oracle9i Application Server Performance guidelines for architecting J2EE application". I guess the fact that the title is grammatically incorrect should have signalled something to me.

    According to Oracle, good J2EE architecture involves the developer "... paying close attention to good Java programming practices that affect performance, they need to understand the way their application behaves under load, and they need to take advantage of unique features of their application server." Gee, that's really groundbreaking stuff. So, basically, the guidance for good performance is to pay attention to performance?! I guess that's hard to argue...

    I get the feeling that someone at Oracle said, "Quick! We need to publish some more whitepapers! Give me something by noon."

    There's five minutes of my life I'll never get back.
  3. Anyone else read this stuff?[ Go to top ]

    I just scrolled through the "white paper" and decided it's not worth reading it.
  4. Anyone else read this stuff?[ Go to top ]

    Funny, there is a small Architect Poll about "What's your preferred Java Application Server?" on the right side.

    Guess who's the winner till now ?

    Laurent
  5. Anyone else read this stuff?[ Go to top ]

    <snip>
    I get the feeling that someone at Oracle said, "Quick! We need to publish some more whitepapers! Give me something by noon."
    </snip>

    you really mean to say you didnt know that that is very close to how these things most often come about?
  6. Anyone else read this stuff?[ Go to top ]

    I can still *act* surprised, can't I? :)

    Big vendors in the Java world are becoming a pet peeve of mine recently. We have all this talk of the complexity of J2EE and the corresponding steep learning curve. Then we read (or know first hand) that 80% of projects use about 20% of the features of J2EE. Now go work with products/tools of "Big Vendor A" and/or "Big Vendor B" (pick one). It takes forever to figure out how to wade through the 80% I don't care about to get to the 20% I do care about, tripping over land-mines the entire way.

    This leaves be to believe that either A) "Big Vendor" couldn't *architect* their way to their a$$es with both hands, or B) they do it deliberately in hopes of generating more consulting revenue ("Oh, well, our consultants can sure help you figure that out" translates to "our consultants have the secret decoder ring"). So that means my options are to believe that either "Big Vendor" is stupid or corrupt. In either case, it probably isn't a trait that I want to find in someone I'm going to trust my business to.

    Personaly, I believe you can teach CODING EJBs to a monkey and J2EE architecture to anyone with some common sense that will listen. C'mon, it ain't rocket science. Learning how to use the tools shouldn't be nearly as hard as it is, and I think it is the tools/implementations that are "complex" and "hard to learn", not J2EE.

    Let me give you guys a bit of advice, and I'm sure a lot of you already know this. If you ever write J2EE code that says "import com.bigvendor.*", you really need to look for an alternative before committing to that decision. It loosely translates to "import com.bigvendor.lock.in.to.our.product.forever.and.dont.even.think.this.will.port.or.even.be.supported.by.us.in.the.next.rev.java"

    What does this have to do with this Oracle stuff? I don't know, but reading "white papers" like that only add fuel to the fire.

    I've obviously tried real hard not to bash any *particular* vendor, but I'm sure many of you can guess what product I've been working with lately....or I'm scared to think that maybe you all have different products in mind.

    Oh, and while I'm expressing my opinions so openly, let give one more piece of professional advice (again, many of you already know this): Market share of a product does not have a darn thing to do with product quality and you DON'T always get what you pay for (OK, that was two opinions).

    Sorry....too much coffee today.....
  7. Anyone else read this stuff?[ Go to top ]

    I think this comment is worth. I have been working a major vendor's employee and in last one year I am out of their Professional services. Instead of addressing major features of J2EE some time vendors want to teach how to use their tools so that you can write a J2EE application to run hardware. Six months ago I challenged one major vendor&#8217;s portal service and addressed a number of bad ways they are looking into J2EE framework and delivering a portal frame work on J2EE technologies. I concluded that discussion by telling one sentence, wait I am heading to another client who recently moved from Microsoft to J2EE framework and they are going to build their first portal on the above vendor&#8217;s portal frame work. I have been working in that framework since it&#8217;s first version, still they are into its way, no change in terms of flexibility, portability etc. By just writing EJBs and TAGLIB and XML files some people believe that they are the best J2EE solution providers and on their dot com age market value they still believe and keep their egoism. We are in the final stage of our production delivery and once we are done with that I will come back to the same web site www.theserverside.com to point out what are the nonsense technology they are selling in j2EE label. Wait and see !!! This time I have full list of technical data a group of senior developers faced during a six month of application development in a major vendor&#8217;s portal framework. Dude current financial market is too late for major vendors to get out their dot com age high market value theory and think about their fundamental problems

  8. Anyone else read this stuff?[ Go to top ]

    It ["import com.bigvendor.*"] loosely translates to "import com.bigvendor.lock.in.to.our.product.forever.and.dont.even.think.this.will.port.or.even.be.supported.by.us.in.the.next.rev.java"

    Maybe this is why some vendors want to get into the development tools market.. so they can try and hide this hint about the consequences of your actions from you :-)
  9. I agree with Chris !![ Go to top ]

    I think your comments are valuable and not just too much coffee.

    "Personaly, I believe you can teach CODING EJBs to a monkey and J2EE architecture to anyone with some common sense that will listen. C'mon, it ain't rocket science. Learning how to use the tools shouldn't be nearly as hard as it is, and I think it is the tools/implementations that are "complex" and "hard to learn", not J2EE. "

    I think this is absolutely correct based on my own experience. I might as well come out with it up front and admit that I am, in fact, a monkey ... J2EE has been my ticket out of the cage, man. I'll never eat a banana again in my life ! I had to teach myself EJB coding though. I couldn't do it with the tools from IBM (VAJ and later WSAD) or figure out the random errors produced by BEA's 'deploytool' and I had to resort to coding sevlets/JSP/EJBs and writing deployment descriptors by hand. Then it was easy ! Since I understood what was really happening it has become very difficult to convince me that I need a complex GUI to make text entries in an XML 'deployment descriptor' text file ... or to JAR Java code and copy it to the right place. And when I do it it always works, which is unlike my experience with ANY VENDOR'S 'TOOLS'.

    I truly think that a good Ant build template library is more useful than all the vendor development tools put together.

    Nothing I have seen in J2EE 'architecture' differs significantly from the n-tier models we used 15 years ago. Not that it would have to, of course, but vendors and consultants (like myself) talk about 'J2EE architecture' like only the apostles can do it and only God will really understand it ... total nonsense, if we are talking about application architecture. (If we are talking about real architecture that would be true of course, but I have never met a real architect and I am not sure such beings exist.)

    It seems to me that there is no question that you are right and that the only unusually complex thing about J2EE is the poor toolsets - obstaclesets ? - that developers are sold.

    How can we end this situation ? It is bad for all of us ... hmmmm ... I wonder. You know what, there may be a business opportunity here for someone ... selling configurable Ant build scripts for J2EE build and deploy !!

    Is this stupid ? Or will it demystify us all right out of our jobs ? Wait, maybe that's not an 'or' question ...