Discussions

News: IBM Claims WebSphere 5 Extends Beyond J2EE

  1. IBM Claims WebSphere 5 Extends Beyond J2EE (22 messages)

    Danny Sabbah, vice president of IBM’s application and integration middleware division, discusses WebSphere 5, and the direction it has taken. He talks about how support for the latest version of the J2EE spec doesn't mean everything, and how WebSphere 5 goes above and beyond.

    Danny champions the new support for WSIF (Web Services Invocation Framework), WSFL (Web Services Flow Language) and Axis (SOAP).

    Some interesting quotes:

    "a simplistic implementation of J2EE 1.3 standards would not give you an understanding of how to deploy it in scalable clusters. You can do a simplistic implementation of J2EE 1.3, which we proved very early on, but our customers were asking for features around self-configuring, self-healing, self-optimization, real integrated security and failover, in combination with configuration and scalability. That takes some time [to build]."

    "you have to go beyond J2EE, period. You need Web services, XML and security-based standards, which are evolving independently of J2EE. What you will see with [WebSphere] 5.0 is a full-blown implementation of the Web services standards, as they currently exist today"

    "the realistic pace of adoption and deployment of those [Web services] standards is a heck of a lot slower than what vendors are talking about, to the point where a large majority of our customers are asking us to slow down because they can’t consume [the new standards]"

    Here is the full story

    Threaded Messages (22)

  2. Why does IBM keep referring to their hacked version of Axis as Axis 3.0 when the main Axis development branch is at 1.1 beta?

    Are we supposed to assume that their version is 3 times as good?
  3. <Corby Page >
    Why does IBM keep referring to their hacked version of Axis as Axis 3.0 when the main Axis development branch is at 1.1 beta?
    </Corby Page >

    at first I was surprised to, my guess is that it is all marketing. MS created a bad precedent that software is now good before version 3. Axis is follow-up on Apache SOAP project and SAOP is at version 2 so they probably started counting from 3. The same question is for jdk that is currently at 1.4 but somehow is referred to as java 2.
  4. You asked:

    "Why does IBM keep referring to their hacked version of Axis as Axis 3.0 when the main Axis development branch is at 1.1 beta?"

    From Apache FAQ:

    "What is Axis? What is its relationship to Apache SOAP?
      Axis is essentially Apache SOAP 3.0. It is a from-
      scratch rewrite, designed around a streaming model
      (using SAX internally rather than DOM). The
      intention is to create a more modular, more flexible,
      and higher-performing SOAP implementation (relative
      to Apache SOAP 2.0)."

    Also, I wouldn't go so far to say that IBM's version of Axis is "hacked," seeing as about 1/3 of the active committers are IBM employees. This is on top of the fact that Apache SOAP started life as an AlphaWorks project soap4j.
  5. The J2ee spec can make the users' applications run any kind of J2ee application server. The concept drives away the old technologies and the companies based on them , and makes a few new comers keep a big share of the market.
    Now they want to beyond the J2ee, why ? they provide the private features, and want to keep the users
  6. roughly 95% of the Code you usually find in a quite ordinary j2ee-system is portable between app-servers: Let's get back 3 or 4 years into a pre-j2ee-era and imagine someone would have told you that. These are amazing figures. The differences between bea, ibm and even jboss have become marginal - at least from a software-engineering point of view: The j2ee-community has agreed on a standard approach to architecting Enterprise-Applications - if you move into a new Project, regardless on which app-server it runs, the basic Architecture of the Application is more or less the same, you always find Variants of the same Patterns. This is truly amazing and a real difference between a pre-j2ee Age, when we spent considerable time into acrchitecting our own frameworks for distribution, security, transaction, persistence etc.- and when you came into a running project you not only had to adopt the business-domain , but also to often queer architectural-approaches. And apart from the marketing-guys, that have to make up points to differentiate their servers, noone out there really cares on which server the stuff runs, as long as it runs j2ee.

    Pleas, guys, if you rumble about where we are, please do not forget where we come from.
  7. <quote> ... if you move into a new Project, regardless on which app-server it runs, the basic Architecture of the Application is more or less the same, you always find Variants of the same Patterns. </quote>

    True. That's one reason why I hate it when companies look for people with e.g. "experience in IBM WebSphere and WSAD", obviously still convinced that somebody who knows WebLogic could not make a switch to WebSphere or vice versa.
  8. obviously still convinced that somebody who knows

    > WebLogic could not make a switch to WebSphere or vice
    > versa.

    Of course they know that you can make a switch to a new application server, they just dont want to pay for the time it takes you to make that switch.
  9. <quote>Of course they know that you can make a switch to a new application server, they just dont want to pay for the time it takes you to make that switch. </quote>

    Might be, but they'd rather take a bad developer with experience in the particular products they use instead of a better one - simply because they can't imagine that things might have changed since the days of proprietary-only software ...

    Time to stop whining. It's just that I get so annoyed when I see people state "experience with JBuilder" a must in their requirements ;-)
  10. If websphere was clone of JBOSS would you buy it. What a company looks at is the "total cost of ownership". It does not matter if they spend the money on software or on payroll. As long as the J2EE vendor provides everything that J2EE provides I think the value added features are a good thing.
  11. The Beginning of the End?[ Go to top ]

    Now many vendors; Weblogic, IBM, JBOSS, are talking about extending beyond J2EE cause, "...J2EE can't do everything you need and it's too cumbersome..."

    I know J2EE was always supposed to support the idea of vendor value add through improved implementation of J2EE specs, but the tone of some of the discussions coming out of these vendors sounds more like J2EE isn't there and we're going to extend or eclipse it (in a non-portable way for sure).

    What would happen if J2EE as we know it died? What if the vendors started doing their own thing with J2EE on the side?

    Look at where JBOSS seems to be going: A more generalized framework of services and AOP where specific services (not just the ones envisioned in EJB or J2EE) can be lashed together and completely customized to the performance and feature needs of a particular app.

    The market for 3rd party EJB components never materialized... Could there be a 3rd party market for JMX Mbeans to plug into a Java "kernel" instead? Buy security from one vendor, transactions from another and apply them to your business logic classes via AOP?

    What would be the need for J2EE in this type of environment?

    Just some thoughts...

    Cheerio,
    Chris
  12. The Beginning of the End?[ Go to top ]

    Specification are the kind of stuff we call as one size fits all. We no there is no such thing as one size fits all. Making money by writing specs doesn't sound like a good business plan to me.
    I cannot understand the logic behind the specs. How come one person or a group person can envision set of all problems and come up with a solution? It just doesn't sound logical to me.

    The value of spec a spec is visible in a job requirement advt, where the employer only wants candidates with experience in certain app servers. Then what value is it for me learning only a spec?
    And if I am going to specialize in a certain app server to get a job, then why spec?

    Spec is justified where it is really need like specfying the size of bricks, nuts, bolts and power outlets.
    Software is so malleable and IMHO we need spec mainly for interfacing with external systems.

    May be we should quit writing specs and solve real world problems instead and then come with as many patterns as you can which will enable others to reuse your knowledge.
  13. The Beginning of the End?[ Go to top ]

    What good are specs that are always changing anyway?
    EJB, Servlet, JSP, etc. specs seem to be changing on a regular basis.

    Maybe one day they'll mature and not change so much but right now the specs are in constatn motion.
  14. The Beginning of the End?[ Go to top ]

    Sartoris: "What good are specs that are always changing anyway? EJB, Servlet, JSP, etc. specs seem to be changing on a regular basis."

    True enough. However, we've worked with customers upgrading their applications from very old to very new app server editions, and there is rarely many (if any) code changes that they have to make.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  15. The Beginning of the End?[ Go to top ]

    Let me share my 2 cents with you guys regarding specs and standards. It's nothing but a vary planned effort from big companies like IBM, MS etc to keep people away from their own creativity, so they can preempt any small vendors way ahead of time. What are specs and standards any way, things that already have been created and developed in their labs, and then we all have to follow it. And since we are always way behind them (naturally), we can never beat them or compete them. See the new waves of standard and how all-big companies are participating in it. They always have resources and now a platform in form of standard to force people what they think is right.

    Don't get me wrong, standards are good, without them we cannot live, but there is a line that we should never cross.

    Like some one of you said

    <quote>
    How come one person or a group person can envision set of all problems and come up with a solution? It just doesn't sound logical to me.
    </quote>

    It only sounds logical to people who would like to eliminate all the competitions.
  16. The Beginning of the End?[ Go to top ]

    <Rashid>
    Let me share my 2 cents with you guys regarding specs and standards. It's nothing but a vary planned effort from big companies like IBM, MS etc to keep people away from their own creativity, so they can preempt any small vendors way ahead of time.
    </Rashid>

    Right on. That's almost conventional wisdom in the software business now. However, app server vendors like IBM and BEA just keep on piling ever more complexity on top of their bread and butter solution which fires back when rejected by end users and ISVs. JBoss takes a more compelling approach which is done in the J2EE spirit of extension. They allow ISVs to select best-of-breed facilities and deliver a custom built container to serve specific application needs. JBoss is not compelled like the commercial app server vendors to cause end users to choke on layered complexity and they recognize the value of innovation by smaller vendors.

    A good example is an orchestration container that extends J2EE to support business flows using Web services.

    Cheers.

    Jill.
  17. The Beginning of the End?[ Go to top ]

    Let me share my 2 cents with you guys regarding specs and

    > standards. It's nothing but a vary planned effort from
    > big companies like IBM, MS etc to keep people away from
    > their own creativity, so they can preempt any small
    > vendors way ahead of time.

    Not true, open specifications unifies the market and turns software into what it should be, a commodity. Specifications and standardisation benefits the most efficient implementer, be it a large or a small vendor. Without the J2EE specs, small initiatives such as JBoss would never had a chance...
  18. The Beginning of the End?[ Go to top ]

    Not true, open specifications unifies the market and turns >software into what it should be, a commodity

    Then why do the big brother app server vendor has armies of consultants lined up behind when they make a deal?
    If you pay their consultant to make their commodity work then why pay for the commodity?
    After all, it's not a commodity.
  19. The Beginning of the End?[ Go to top ]

    <Rajnikant Sivalingam>
    >Not true, open specifications unifies the market and turns >software into what it should be, a commodity
    Then why do the big brother app server vendor has armies of consultants lined up behind when they make a deal?
    If you pay their consultant to make their commodity work then why pay for the commodity?
    After all, it's not a commodity.
    </Rajnikant Sivalingam>

    Consultants are often needed to take care of things that are not in the spec. Things like configuration management, clustering, performance, failure scenarios, etc. Also for features the development team needs that are provided by the vendor but not in the current spec.

    For example, in theory you should be able to move from OpenJMS to IBM MQ for your JMS provider by just changing your JNDI lookups and dropping the right jar in the right spot. In practice, you may need help configuring MQ (a non-trivial task), configuration parameters may need to be tweaked to hit the performance levels you need, etc.

    Consultants can go a long way towards solving these types of issues rapidly. But you certainly don't need an "army", and you only need them if you have short time-to-market pressure or the new environment is really, really new to you. Sometimes it also makes sense if you're a big institution that's pushing the server to its limits.

    Despite all of this, though, 90%-95% (and often more) of the underlying developer code won't need to change. Tweaks may be needed to work around a bug in the new product, or to improve performance, or what have you. But the bulk of the code will run as-is.

    For many projects, it really, really doesn't matter what app server you're using. It often comes down to how much the developers like it (e.g. how easy it is for Joe Developer to deploy apps, restart, etc). Where the big guns like IBM make their money is with big enterprises where that 5%-10% is a huge difference. Where the enterprise needs 200 transactions/second across all components, has stringent failover/clustering requirements, etc. Having an IBM consultant (or BEA, or Sun, or whoever) who is truly an expert in their company's product can shave weeks or months off of getting your app bullet proof.

    But for the bulk of J2EE apps, that 5%-10% differentiation makes no discernible difference. And it's up to you (or whoever's in charge) to make intelligent choices. If you don't have crazy transaction rates or clustering needs or bizarre linkups to legacy stuff, use JBoss or something similar and avoid the hassle of big corporations. But if you need that stuff, it's really nice to be able to lay the burden on a big fat company and their hordes. Maybe JBoss could do it, maybe not. But if I go BEA/IBM, I can negotiate a contract and put their ass on the line if need be. If I go JBoss, things are dicier if it doesn't scale up to my needs. Of course contracts sometimes are a bitter consolation if the big corp fails, but it gives the managers the warm fuzzies if nothing else.

        -Mike
  20. The Beginning of the End?[ Go to top ]

    And that's my point - software is not commodity you need really good craftmanship to make things work.

    Specs are only good if they are themselves good. You can write a half-assed spec and expect it do its job.
    Spec are needed where it makes sense and where they can be justified without limiting the choices.

    I have to convince management really hard if I don't want to use EJB or some aspects of spec. Corporate management were made to believe J2EE solves everything and it is a panacea.

    I am not saying consultants are bad.

    They were just made to look bad by some unscrupulous companies claiming to solve all the problems but all they really to do really is make quick and easy money.
  21. The Beginning of the End?[ Go to top ]

    The vendor is already free to go beyond the J2EE as long as it supports the specification. No one is preventing this right now.

    Why IBM's rants and the inclusion of vendor specific features indicate some sort of end to J2EE?

    Use the vendor specific stuff if you want, no one is preventing you from doing so. The nice thing is, is that if something needs to be vendor neutral it can be.
  22. The Beginning of the End?[ Go to top ]

    Not really !

    As long as all these vendors continue to provide a water-tight implementation of latest J2EE specifications , I see nothing wrong with them differentiating their products by way of additional bells and whistles.
  23. WSIF (Web Services Invocation Framework), WSFL (Web Services Flow Language) and Axis (SOAP).

    --> Whoa.. that means WebSphere is soon going down the tubes. We did a POC with WSIF and their Broker implementation. Man that sucked so bad we trashed the POC and didn't move any further. We also did performance evaluation with their JCA implementation which annoyingly uses WSIF and fuc*s the whole thing up. The performance was horroble here too, we are now waiting for a newer version of WebSphere where they promised WSIF would be improved. Be wary people, sales people do their jobs exceedingly well and thats what makes them dangerous. IBM makes good money by sending dumb consultants to client locations where the client teaches these folks about their own products. It has happened and I have seen it. At the end of the day, you do debugging for free when you buy any IBM software for the J2EE platform less than 2 years post release.