Discussions

News: IBM Announces Vela, their Next Generation Application Server

  1. IBM has announced the future of their WebSphere series. Code-named 'Vela' the new version will become the foundation across all IBM server applications. Many component services will then sit on top of this new foundation.

    This componentized approach sounds a little similar to some other application servers. JBoss has had services that sit on top of their JMX framework, as have others. Remember HP Bluestone and its core services framework?

    The new Apache Geronimo server is also going down this route. They are going to be implementing so many JSRs when you look at all of the stacks. It looks like services that implement these JSRs will be able to strap onto the lean, mean Geronimo core.

    Bob Sutor, director of WebSphere software, stated "Vela is what we consider to be the next generation of application servers and, in our particular case, it will serve as the universal foundation for the [IBM] software group's products. What [Vela] is providing on one hand is a foundation for the software group, but it is going to be part of the foundation for what we are doing with On Demand, grid, and autonomic computing as well. It will also fit in with service-oriented architectures and some things we will deliver there next year."

    So hear we learn that part of this componentization is to enable the new wave of on demand utility computing. It could open up a very different mode of purchasing enterprise software. Instead of choosing a version up front: "Standard", "Enterprise", "With JMS" we could move to a model where we purchase a core framework, and then pay as we add services to that core. That could be really interesting.

    IBM also think that the industry has finally worked out a way in which componentization can work. Some people thought that the advent of EJB, we would see a thriving component marketplace, where veritical enterprise components would spring up, and developers would be able to purchase a lot of functionality instead of invent it themselves. That never came to pass.

    IBM thinks that the time may have come.

    "A lot of the reason why componentization did not work was that the pieces were not loosely coupled enough. There were too many dependencies among the pieces, in terms of understanding how you talk to them as well as the way you connected them," Sutor said.

    Although IBM is embracing the buzzwords of Service Oriented Architecture, they don't seem to big on Enterprise Service Buses.

    When asked: How do EnterpriseService Buses (ESBs) factor into your thinking with SOAs and Web services?

    They replied: "I think the notion of ESBs has been inflated somewhat. For many people it was just a new acronym and so it became popular."

    Read IBM heads toward next generation of app servers

    Interview: IBM's Sutor on how SOAs fuel integration

    Is it really a brave new world? Is this really new, or has the wheel spun 360 degrees?

    Threaded Messages (20)

  2. Yes, finally, IBM admits failure in WebSphere. And now is trying to re-invent their application server again. I guess IBM is impressed with Microsoft's success with .NET born again strategy.

    You know, this has to really inspire the small software vendors, IBM's billions of dollars can't help them produce good software. You just can't buy a culture...
  3. Talk about flamebait. :)

    If WAS is a failure with a no1 position in the market can be discussed..
    But on a more philosophical note: why should someone elses failure inspire you? Seems pretty counter-intuitive, unless your name is Scott McNealy and you are conducting a personal crusade against Microsoft. ;)
  4. Yes, finally, IBM admits failure in WebSphere. And now is trying to re-invent their application server again. I guess IBM is impressed with Microsoft's success with .NET born again strategy.

    >
    > You know, this has to really inspire the small software vendors, IBM's billions of dollars can't help them produce good software. You just can't buy a culture...

    Pray Tell: How is .Net any different to old fashioned application servers, just because you have web services doesn't mean you don't have to fork out large ammounts of cash to support the entire framework.

    PS: judging by the number of fortune 500 companies who run WAS, companies where if you suggest Microsoft in the enterprise they start giggling hysterically. It really is difficult to see how you judge WAS to be a failure.
  5. Yes, finally, IBM admits failure in WebSphere. And now is trying to re-invent their application server again. I guess IBM is impressed with Microsoft's success with .NET born again strategy.


    The only admission of failure I see is the fact that more and more people and software vendors are quiently "de-enphasizing" EJBs and moving the limelight towards services... i.e. RPC with XML as transport plus a good deal of fluff!!!
  6. Yes, finally, IBM admits failure in WebSphere. And now is trying to re-invent their application server again. I guess IBM is impressed with Microsoft's success with .NET born again strategy.

    Most large companies do this all the time, and it is what keeps them relevant. Microsoft is perhaps the best example of a company successfully doing this. Success comes largely from failures. We rarely get anything right the first time (and often the second, third, ... times), but keeping your ear to the ground, learning from your missteps, and being persistent pays off in the end. Fast changing technology also forces companies to do this. Fail to keep up and you're toast (regardless of how big you are).

    The only admission of failure I see is the fact that more and more people and software vendors are quiently "de-enphasizing" EJBs and moving the limelight towards services... i.e. RPC with XML as transport plus a good deal of fluff!!!

    Every enterprise development effort I have been involved with uses EJB's. Entity beans were used extensively in the past, but that is rarely the case now. Session beans are almost always used and message-driven beans are also very useful. So when you say EJBs are being deemphasized, I think you need to calrify that statement. When it comes to dealing with heterogeneous, highly transactional, and/or distributed applications, EJBs have been a life saver so far!

    Regarding Web services, IMO they are only useful in certain situations so far(the most obvious is B2B communication). Any enterprise vendor or consumer that bets the farm on Web services will have some serious issues (and they already do with respect to their thinking). Use it where it makes sense and don't get caught up in all of the hype. Pretty simple really, but it is amazing how many people can't think for themselves and see the obvious. This isn't necessarily targeted at you Alessandro, but I thought it was worth mentioning...

    Regards,
    Bill Willis
    PatternsCentral
  7. Been there..[ Go to top ]

    Foundation for all enterprise services - sounds very similar to BEA's WebLogic Platform.

    In the latest 8.1 release, WebLogic Server is the foundation for all other services, like Integration, Work flow, Data transformation and aggregation, Portal design and run-time, Security, and custom app developement with Workshop.

    And to do that BEA didn't have to re-write their application server which has been gradually progressing from the original code-base for the last several releases.

    As before, IBM picks up someone-else's idea, makes a marketing spin, and promises a re-birth. To me it's clear to go with the proven products who really know what they do and focus on it.

    D.
  8. Been there..[ Go to top ]

    And to do that BEA didn't have to re-write their application server which has been gradually progressing from the original code-base for the last several releases.


    IBM isn't having to do a re-write either.

    Randy
  9. BEA needs a re-write of their TX core[ Go to top ]

    I've been using BEA in a transaction-intensive application (2PhC transactions) utilizing MQSeries and MDBs. We have found several bugs related to the transaction processing core of WLS.

    Some of these bugs are very serious causing loss of data. I would say that BEA have failed because they didn't re-enginer their transaction engine.

    Before WLS 8.1 BEA didn't even fully support other JMS poviders than their internal implemenentation. WLS 8.1 added the possibility to integrated MQSeries and other "foreign" JMS providers without the need for WLS-proprietary application coding. However, it is not possible to configure the size of connections pools when using foreign providers. WebSphere has a clean concept of using connectors all over the place.

    "Application logic" deployed in WLS 8.1 can not start a new JTA transaction after a transaction timeout. BEA engineers claims they would have to rewrite the tranasctional core in order to fix the problem, leaving one of the worlds largest medical companies with proprietary logic.

    There are many more exampels.

    If someone needs to re-enginner their product, it is BEA!

    /Johan
  10. BEA needs a re-write of their TX core[ Go to top ]

    Johan: Before WLS 8.1 BEA didn't even fully support other JMS poviders than their internal implemenentation. WLS 8.1 added the possibility to integrated MQSeries and other "foreign" JMS providers without the need for WLS-proprietary application coding.

    I don't know anything about the bugs that you mentioned (they sound serious), however, I do know that the main reason that BEA had a hard time supporting MQ Series was that IBM wasn't in a hurry to make MQ Series easy to support (specifically as a transactional resource.) BEA took a lead in driving the JMS extensions through the JCP that now allow them to support "foreign" JMS providers without "custom" coding solutions. They've been working on this particular challenge for at least 2 or 3 years now, and they were one of the first to provide decent support for MQ Series, so I don't think it's fair to beat them up on that account.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  11. This is not true, I had a customer on WLS 6.1 using MQSeries as the JMS provider. All you had to do was write a start up class that copied some JNDI tree with MQSeries JMS bindings into BEA's tree. The only thing that was not supported was MDB with XA (And at that time the MDB was based on a draft spec). You can have normal JMS calls with XA.
  12. BEA needs a re-write of their TX core[ Go to top ]

    Johan:
    Before WLS 8.1 BEA didn't even fully support other JMS poviders than their internal implemenentation.

    This is incorrect, we have supported foreign providers for MDB's since version 6.1, as the deployment descriptors attest.

    --
    Cedric
  13. I don’t see this as a failure of the IBM implementation of its J2EE app server at all. Instead this seems to be a realization and acknowledgement that the app server provides system services and components that can be bounded, packaged and reassembled for use in generalized servers, not just WebSphere. I’ll bet there are plans to provide these underpinnings to all WebSphere branded servers, including the servers within their DB2, Tivoli, Rat’l, and Lotus families. This looks to me to be a swag for server side programming that Eclipse brings to build-time tooling.
    The girth of IBM’s software footprint must be becoming expensive and cumbersome to manage. As a very Blue shop I am delighted by this because it may in fact drive faster development cycle times at a reduced cost. Also, I would anticipate the service levels to get even better because the common server componentry would go through more test teams prior to release.
    This is nothing more than IBM leveraging its assets.
    -McD
  14. Why was my post marked noisy? Can someone from the TheServerSide explain to me the definition of noisy?

    Surely, my post was critical of IBM's WebSphere, because I've had bad experience with WebSphere, (versions 3.5 and 4.0). Before I got involved with J2EE development I learned the specifications from SUN. Well, I had no problems aplying the J2EE specs with Borland Enterprise Server and Weblogic. But, with WebSphere, installation, configuration, deployment descriptors and EJB 2.0 specs were difficult to work with. I can't remember much about the specifics, also I don't think WebSphere was even EJB 2.0 compliant.

    Anyway, we all know software products have a life cycle. No software product is perfect, but at least "be good enough". So, the early on decision and effort to make Borland Enterprise Server and WebLogic products "good enough", allowed us developers to provide "perfect" solutions :)

    I don't think WebSphere's had a "good enough" product requirement. Perhaps, I'm the only person in the world with these WebSphere experiences, if so, and then my post was noisy...
  15. why a post is marked noisy[ Go to top ]

    Hi George -

    First of all, noone TheServerSide itself marked your post as noisy. Anyone is welcome to click "Mark as noisy" if they feel that the post is out of context. When enough of the community agree, a post is then marked noisy. In this case a group of TSS members thought your post was inflammatory and marked it as such.

    I just wanted to let you know that this is a self-policing system, and noone here marked your post.

    Cheers,

    Dion
  16. Enterprise Service Buses[ Go to top ]

    I think that most people who have worked with WebSphere understand the technical problems that still exist with the product. I was surprised to see their marketing talk about a "Next Generation" product, which in technical terms generally means "v1.0". I would have expected IBM to offer a message of continuity and stability, like they did with WAS 5.0, which was in many regards a rewrite from WAS 4.5.

    On the other hand, I completely agree with Sutor's comments on ESBs. ESB is a great marketing term, and Gartner has painted an ESB evolution from current EAI solutions by 2006. However, I don't see ESB as being anything more than a packaging story, and not a very appealing one at that. The core concept behind ESB is that I can do all my enterprise integration with Web Services, using an ESB for WS-based transport, security, choreography (BPM), etc.

    That's definitely not doable today, as the standards are way too immature. Even in the foreseeable future, it's not likely that I will base 100% of my component interactions on Web Services. The most obvious case being EJB to EJB calls. We just got developers to stop thinking that remote EJB calls were a necessity, and now the ESB model would have them marshalling XML over SOAP to make calls from one component to another.

    IMHO, ESB is generating more hype today than it will even generate substance. That's not to say that the ESB design is bad, but it will never be sufficient for any but the most basic needs, and I'm sure that any "ESB vendors" will continue to offer full EAI and/or platform products.
  17. Hopefully most people would view this as fairly evolutionary. The app server is becoming the foundation that many other products are based on (similar to an OS) and it is only natural to want to ship only the pieces of the foundation on your CD that are necessary for a particular product higher up in the software stack. And when you buy another product that also uses parts of the same foundation, the install of the second product just adds the pieces of the foundation that weren't already there from the first product install (rather than for example having two copies of the foundation on your system).

    Randy Schnier
    WebSphere EJB Container Architect
    I don't speak for IBM :)
  18. What happens when the component you install requires a DIFFERENT VERSION of the overlapping components that are already installed ?




    thanx
  19. What happens when the component you install requires a DIFFERENT VERSION of the overlapping components that are already installed ?


    This is a good question -- the overall aim is that it won't. But if for some (non-optimal) reason something further up in the stack did require a different version of a foundation component, at least it would be just the different version of *that component* installed alongside the existing version, as opposed to installing another copy of the entire foundation appserver codebase.

    Randy
  20. Improve the installation please![ Go to top ]

    I hope they spend at least a little of that money putting together a decent installation for linux.

    What a palava! Time for a bile....

    We have spent the last month - including getting IBM Professional Services in - just to get WAS 5.0.2 and also Websphere Portal 5 installed on Redhat AS 2.1 (or any other flavour of RH Linux for that matter).

    Why is it so hard??

    Lets look at Websphere Portal:
    How many downloads would you expect to have to do to install this bugger?
    1? 2? No. 4!

    The Websphere Passport Advantage site is a riot.
    Applying the filter: "Websphere Portal" and "English" gives me a page of some 70 downloads!

    Having 7 identically named downloads "Certain components for Websphere Portal" is also entertaining. In fact, each of them are platform specific patches for WAS 5.0.1 - as if that wasnt obvious from the name. Its obviously even more entertaining when you find that 2 of them are seemingly for linux.
    WHich one is the right one? If you were thinking that the description or readme files or anything would answer that question, you would be dissappointed.

    Then comes the installation.
    You MUST run the installation as root or it will fail - not documented anywhere.
    That may seem like common sense - but some people prefer to install it as the user it will run as (to save chmod'ing your installation afterwards)
    The script tries to up the open file limit - which you need to be root to do.

    Mid-way through the installation of the "Fixpacks", the JVM Core-dumps, leaving your appserver installation shagged. This is the JVM that comes with the downloads, by the way...
    You have to seperately download and install the latest IBM 1.3.1 JVM for it to work...

    Now, compared to WAS 4, this aint nothing! But all I ask of IBM is to please, please, spare a thought for the poor hapless users who have to fight with this kind of junk.

    Dont even get me started on MQSeries...!

    -Nick
  21. http://www.eecs.harvard.edu/~mdw/proj/seda/

    we need one of these for the j2ee stack, not just http processing

    apparently the hallmarks of nextgen servers are non-blocking I/O and throttled thread pools. I don't see anything to indicate the IBM move has anything to do with that.