Although Sun remains the dominant platform for BEA deployment, HP is up 31 percent. Approximately 60 percent of BEA deployments on HP hardware were on the HP-UX operating system, with Linux and Windows accounting for 30 and 10 percent, respectively. Sun and BEA used to be very close, until Sun started to really push Sun ONE. It seems that HP is taking on that role.
"The Gartner analyst believes that the HP-BEA relationship could become even closer, spurred on by competitive pressures from IBM Corp. and Sun. "There is a distinct possibility that in the next two years HP will be acquiring BEA," he said. "I do not believe that the new HP -- with Compaq (Computer Corp.) -- is satisfied with not being in the platform competition. All of their competitors are in it," he said. "So they're going to want to be in it again."
Read: BEA says deployments on HP up 31 percent
How would you feel if HP bought BEA?
If HP were to aqquire BEA, it would be a pretty natural move, considering HP:s quite visionary past in moving into new markets (we might forget that from time to time, but they have been around for a while, and successfully so).
But I dont think HP will make a move until they have a very clear strategy on how to differentiate themselves from the pack, HP:s legacy and culture wont let them be just a "me too" company, so if and when they do move for BEA, they will move into the market to kill (successfully or not, who knows?).
It was a pretty natural move. I think HP is glad that it did not make the move. Many things are happening now: Sun's Orion is priced so low, it will hurt BEA's revenue; Open source JONAS will be certified soon, it is free and will come with RedHat Linux. Apatche's J2EE server is coming....
HP bought BlueStone and dumped it. It will not buy another one.
HP bought BlueStone and dumped it. It will not buy another one.
They bought it and dumped it because they didn't believe they could grow it into a market leadership position - which is/was probably true. Part of Fiorina's core strategy: only focus on what they excel in. Buying market leading BEA may be a very interesting strategy for them - but they probably should have done it a year ago when BEAS was at an alltime low ...
platform independence? Think again...
I would hate to see BEA getting bought off by HP.
HP is a hardware company BEA is a software company, the 2 dont mix well.
I would rather want BEA to expand in the software market than getting acquired.
I am over sure BEA can compete with Open source app server market.
I agree. In fact, I think ORACLE is a natural choice to acquire BEA.
Over time, I start to understand why the companies I've worked for all choose WebSphere. No one can acquire IBM, right? I am glad to see WebSphere 5 with WSAD 5.1 finally reaches a production quality.
"I think ORACLE is a natural choice to acquire BEA."
This will set back J2EE into the dark ages; the Weblogic application server will decay into typical Oracle renderings. People would then have to start using WebSphere, and then these people would give up on J2EE forever.
However, the Borland Enterprise Server could replace Weblogic as the technical choice for the "real" J2EE users.
I think HP is the only choice to acquire BEA; this will best serve everybody.
Oracle is a database company, which has no business doing anything else. Perhaps, we need something like the federal antitrust law; we can call it the anticrap law. Every time Oracle tries something, we can slap a billion dollar anticrap claim...
I use WebLogic server from the beginning of year 2000, Jan and implemented BEA WebLogic server solution to more than 12 clients in North America.The beauty of BEA products is that they don't tie up with particular OS/Hardware.
All my 12 customers are having the same opinion.Because big companies often change their OS/Hardware and they expect portability and platform independence.At present, BEA WebLogic is the right fit for all OS/Hardware.
If HP buys BEA, they will customize it for their platform and they push their OS into market.It is not healthy to diversified BEA customers.
Better, I recommend my customers to go with IBM shop if it happens.
I think HP and BEA will continue to get closer and closer, but I personally don't see HP buying BEA. I've been speculating about the HP <-> BEA buyout/merger for a while and I used to think it would happen. But if you look at HP today, they are trying to be an open-we'll-do-what-you-want type of company with a close alliance to Microsoft for the Windows market. They are adopting Linux and aggressively marketing that instead of HP-UX. I think they've figured out something Sun hasn't figured out -- Hardware and services is their bread-n-butter and they don't need to waste time on software and operating systems wars. Support all of them and make your money on the hardware.
I was at BEA eWorld earlier this year and Carly Fiorina was one of the keynote speaker at the event. She didn't want her picture taken at the BEA podium and so a special announcement was made before she took the stage about no pictures. Kinda humorous :)
Personally, I wish HP would buy BEA giving BEA the edge (cash) it needs to compete with IBM on the marketing side. BEA has IBM beat on the product side, but IBM has the cash to drown BEA with those entertaining IGS commercials.
Vinny hit the nail on the head. HP and BEA will move closer but HP is very unlikely to try to acquire BEA. How do I know this? Simple.
When the dot.bomb implosion started and the B2B I helped build laid me off along with most of the field sales force, I went to work for Bluestone Software just weeks before the HP acquisition closed. I was part of HP Middleware Division for as long as the ride lasted. Trust me; it was a mercy killing.
As painful as the consequences were for me personally - and believe me, they were painful - HP made the right decision to pull the plug on HPMD. Now, they totally screwed the pooch every which way possible from the very beginning of HPMD, but they made the right decision in the end. HP is horrifically bad as a software vendor (with the possible exception of OpenView) and they know it. And Vinny is right about their strategy of straddling the J2EE/.Net fence.
That's my $.02
Don's easily one of the brightest minds in software today, especially in terms of being able to grasp a paradigm in its totality and being able to explain it. You kind of have to be able to learn his means of communicating - his books can be hard to parse through - but once you have, it's usually a treasure of insights.
In this article, he's pushing the same line that the "component software" guys like Brad Cox have been pushing for over a decade. Right there he's giving away his hand: SOA is not anything revolutionary, it's merely the same old component based development on top of a new technology kernel (SOAP, HTTP, XML).
His view of OO is also somewhat unique because of years of arguments about whether COM is "truly" OO. For years people said it wasn't because it didn't have inheritance. Now with all of the AOP and modern design techniques, most realize that polymorphism was the "real deal" and inheritance wasn't as big a deal. It's funny how things work out. I get the impression that Don is pointing to a version of OO that already is culturally extinct.
Don does get a little bit ahead of himself sometimes with how excited he gets about XML. It's important to understand the perspective he's coming from when you read stuff like this, as he's been saying this kind of thing for over 2 years now (anybody remember the last eWeek quip suggesting that we have to move away from HTTP?) Don's a provocateur, he does this stuff to shake people out of their stasis. That doesn't mean he's always correct.
For example, at a tutorial at OOPSLA 2001, he mentioned that "objects were great back in the 1980's" and proceeded to suggest that all distributed processing could be done by XSLT transformations or some sort of XML Post-Validation Schema Infoset compliant language. A lot of people are opposed to this idea (just read the XML-DEV and SOAP mailinglists out there), but he was suggesting it was fait accompli. Microsoft's rumoured X# will probably be an attempt at this kind of paradigm. It will be interesting to see what they come out with, I think the idea has merit, but I'm skeptical.
Another suggestion he made was that there are effectively two distributed systems stacks in use today: the network component network stack (COM, CORBA, EJB) and the web server stack (HTTP, XML, SOAP). He went on to suggest that if all of the world's EJB systems died, it would only cause a few guys "a weekend worth of work" to fix it, because 99% of EJB projects never make it to production anyway. The web, on the other hand, could not go down.
Now, I get the point here: the web is much bigger than EJB ever could be. But I know for a fact that if EJB all of a sudden "died" everywhere, then almost half (or more!) of the world's equitiy, fixed income, and derivatives trading systems would cease to function, and it would be months to swap architectures.
He really seems to believe that it won't be a tremendous paradigm shift for developers to move away from the "network component" model of old to the "network service" of new.
Well, he's right, and he's wrong. XML Web Services and SOA probably will make traditional component-based development irrelevant, if there really were any life left in them. EJB, CORBA, and COM are really no longer relevant - they're way too complicated at the "core kernel" level (which is DCE RPC/CDR and CORBA/IIOP), and don't add much value above what you will be able to do with the WS-* and W3C specifications. But it will take a long time to migrate people off of it, and for products to mature into these new specifications. And, the specifications don't add a tremendous amount of novelty over component based approaches. They change the core kernel, but the higher-level features are very similar.
So, will SOA defeat OO? I think not. It's a red-herring. OO is a "programming in the small" construct that has over 30 years of history behind it. SOA is a "programming in the large" construct that replaces prior constructs such as "distributed objects" and "component-oriented architectures" that took their cues from OO programming. And SOA has to be programming in the large because of the fundamental problems inherent in distributed computing: partial failure, latency, non-uniform memory access, and concurrency. These are "big" issues, not something one deals with at the "micro" level. SOA at the "micro" level is nothing more than traditional modular library development.
He seems to be suggesting that most programmers will be programming at the "SOA wiring" level and that the real problem is that too many people are building "software ICs". This is wrong-headed. The problem is twofold: reuse is hard, and distributed computing is hard. There are a lot more problems in that space that still haven't satisfactorily been resolved. I still think it's much cheaper to build software that relies on people to build these OO "software ICs" than it does to put together a distributed system out of reusable services.
The underlying protocols don't change that reality, it's that we haven't developed enough education in the software development community at large to all become distributed systems programmers. I see way too many systems that are "distributed by skill set", one component in CORBA, one in EJB, one in .NET, all talking to each other through MOM or CORBA or XML, but with no performance or scalability. That's the world we're entering with this relentless hype about web services: an SOA version of the "world wide wait".
Finally, Don goes on to say: "all this stuff shifts the focus from types and abstractions to contracts and schemas". This is a meaningless statement.
Let's do a Merriam Webster look up, shall we?
Type: qualities common to a number of individuals that distinguish them as an identifiable class
Abstraction: expressing a quality apart from an object
Schema: a mental codification of experience that includes a particular organized way of perceiving cognitively and responding to a complex situation or set of stimuli
Contract: a binding agreement between two or more persons or parties
Type = Schema = Abstraction. They're the same thing. And we all know that contracts exist in OO and design-by-contract was popularized by Bertrand Meyer.
So. SOA is good, but it takes a lot of ideas from component based software, which in turn took a lot of ideas from OO. I think it's a red herring to say it's going to defeat "OO" in the same way that AOP is going to defeat OO, or components were going to. We're just evolving the way we do things. We're paying an homage to the past, in my opinion. The only thing that will "defeat" OO would be a paradigm we haven't seen yet (like what OO was in the early 1990's.)