EJBs specifically. When I was at BEA, we were unable to find a single production installation of WebSphere using EJBs. They know that they don't work, and that's a big problem.
Since the question was specifically on EJB support, I can't believe that he could really want to go with WebSphere.
Hmmmm....interesting, except for one thing: nobody takes TPC-C numbers seriously anymore, because they don't matter.
One of the best things that the TPC has done is start on TPC-W, which more correctly simulates the workload that you're going to do in a web application infrastructure.
The TPC-C schema and data set are intended to simulate a bank network, and as such there are virtually no transactions which will cross some pre-defined Boundaries, which means that you can partition the data and applications very easily across a cluster. That is NOT true of web workloads.
Web Workloads tend to have a bunch of small transactions, which have some very big SELECTS as part of the transaction (such as integrating catalog data with personalization data). Those things can't very easily be partitioned across a cluster, so TPC-C numbers are irrelevant.
All TPC-C checks these days is how good your TPM (Transaction Processing Monitor) is optimized for TPC-C, that's it.
They're irrelevant, which is one reason why people like Amazon will never switch to SQLServer 2000.
I used to work for BEA in the EJB engineering group (I rewrote the CMP infrastructure for version 5.1, but left before the EJB2.0 work really began), and can probably shed some light on your potential infrastructure.
First, going with BEA is the right choice on the EJB front. I don't mean to be all conceited, but WebSphere really sucks. In competitive situations, we found that WebSphere couldn't point to a single marquee customer which was using their EJB technology in a production site. Their Servlets and JSPs were okay, and their JMS definitely was better than WebLogic's, but their EJB infrastructure was pretty much unusable. An ironic thing to note here is that one of the largest systems integrators working with WebLogic Server is IBM Services....they don't even pitch their own product for their own customers. That should be a sign of the relative strengths of WebSphere vs. WebLogic on this front.
BEA's technical support people are extremely overworked. It's just a fact of life there after the BEA acquisition of WebLogic that BEA hasn't spent that much on the technical support infrastructure. However, there are two mitigating factors there:
The actual engineers for the product lines read the WebLogic newsgroups, and regularly post messages. This is probably the best form of technical support you can get. (Take a look at them here )
WebLogic people have an enormous amount of experience cobbling together best-of-breed systems (i.e. DB from vendor A, App Server from WebLogic, OS from Vendor B), and it shows.
Specifically on your choice of Oracle for the database, I'd recommend that you think again. The Oracle model of concurrency control makes doing serializable transactions damn near impossible for real-world EJB-enabled applications, and you'll find Oracle rolling back your TX_SERIALIZABLE transactions all over the place. Either move to a different DBMS (DB/2 rocks, actually....), mark your transactions TX_READ_COMMITTED, or be prepared for constant rollbacks of far-along transactions at COMMIT time. Unfortunately, there isn't much of an option otherwise, because Oracle does crazy things internally to try to maximize concurrency at the expense of transactional semantics. Think carefully about this one!
In short, WebLogic rocks, DB/2 rocks, AIX rocks, and if you know how to work the system, WebLogic support is the best of the three.
I'm most interested in your need for a transactional DSS/OLAP solution. One of the whole points of the DataMart revolution is that transactions are meaningless in a read-only environment, and they just slow you down unnecessarily. Are you sure you need transactional DSS?
Is there a particular product you're used to working with which provides this bit of extra-functionality?
This would have to be VERY specific to the application in question, if they're doing trivial failover. Database connections of all kinds keep a WHOLE lot of state around. If you want transactional failover, you're going to be hard pressed to do it without a full-blown 2PC implementation.
Imagine the following scenario: You, client C, initiate a service/transaction with server A. Server A crashes. Your service/transaction fails over to server B. However, server B knows nothing about what's been going on in your stateful connection, and is thus unable to help you.
The only solution that you can have within a database for failover is in the case when you have a stateless connection, and/or full state replication across the cluster of server machines. However, this alone is going to almost certainly bog down any of your transactions to the point where you don't want to continue anymore!
A company which has done this extremely well is the old Tandem, with their NonStopOS and NonStopSQL. Their mastery of failover in transactions was superb, and quite a bit of wall street is still running their stuff, even though Compaq has been quite unable to successfully market their services now (NonStopNT.... that's a complete oxymoron!).
I suppose you COULD implement the type of service you're talking about with failover stateless connections, but if you're going to do that you're much better going with an app server in the middle, which handles failover of connections in an EJB type model, and use the features of the app server to handle this.
So to sum it all up: For simple services like RPC and HTTP and FTP and whatnot, which are stateless (or very nearly so) by their nature, simple failover is fine. For extremely stateful services (like a database system), you've got to use much more complicated measures.
Have you ever seen the Oracle Server source code? If not, I strongly urge you not to judge its quality.
It's one thing to say that a product runs well while being written in pure C code. It's entirely another to say that it's good source code, as a mixture of C++, ANSI C and K&R C.
As for the statement that corporate programmers always write good comments because they are paid to, I'm pretty sure that isn't a given. For example, a friend who worked at HP told me that his bonus at one time was based in no small part on non-comment-lines-of-code. This indicates to me that comments aren't important to them (and he was working on HP-UX).
But the thing about the examples that you've indicated, Linux and GCC, is that those were developed by open source developers in public: they weren't released at some mature point in their life. If you take something like the Mozilla source code, when it was released there were significant quality problems that had to be worked through before the project could go forward. That all hinders understanding and forward progress.
Besides, have you ever read something like Query Optimizer code? Take a look at the postgres code for this section. It's very dense code, very difficult to grok, and almost like black magic. That's the sort of code that database servers are riddled with, and if they're truly legacy sections, it could be very very difficult to understand them and move forward.
As I work for a software firm doing non-open-source work, I most certainly agree. I'm not going to slag on my own code, am I?:-)
But the point that I was trying to make, perhaps not as eloquently as I might have done, is that corporate code usually suffers from some very similar problems: it relies on idioms and dependencies which are not well defined and specified. This is largely as a result of it not having been open to peer review outside the company before. Thus the only people who submit comments are the same people who write it in the first place, and people who know all those underlying, understood dependencies.
Open-source code, when written from scratch, tends to have fewer of those dependencies and understood-but-not-specified details. When a large enough pool of people works on something, and different people all the time, you have to have these things spelled out or else it will be too difficult to maintain.
My concern is that Inprise will be dumping code on the world which hasn't been peer reviewed, hasn't been clarified, and hasn't been sufficiently documented. Not that it doesn't do its job well, but that it will be difficult for the open source community to add to.
K&R style means pre-ANSI standard C. There's the old-skool K&R book which defines the original C standard, and then the ANSI C book, also written by K&R I believe. You want to take a look at the cover and see if it says "ANSI" on it. If so, it's the current standard (with function prototypes and in-statement function parameter names), otherwise it's the original book. Still great reading, but not the current thing.
And you might want to pick up a C++ book as well. Knowing C++, I've found, actually helps you write better C code, as the idioms are better defined.
Nope, they left because Inprise showed no ability to push IB forward, and because they felt as though they were left in dead-end positions within the organization.
If your company said that they didn't care about your product anymore, you'd probably quit too.
I've been following the threads on the interbase mailings lists, and the thing that really struck me was the lack of true commitment to any tenets of Open Source development or products on the parts of the Inprise management.
They've stated that they didn't really set out to do this open source. They got forced into it by their own ineptitude.
Their own public statements are that the whole development management team for Interbase quit last month, that they no longer have the resources to support the product, that they don't feel that this is part of their core business, that they no longer have the technical knowledge of hte product to support it, and therefore they're going to release it Open Source.
So what the community gets is about 15 years of corporate (read: poor quality) code, with no commitment by Inprise to support it at all. And their statements indicate that they don't plan to, as they don't feel that it's part of their core business. Heck, the rumors that I've heard is that there are sections that nobody currently understands, and that are written in K&R style C. This doesn't bode well for the product.
I'm all in favor of open source applications, but considering that this seems like a desperation dump (and I wasn't planning on bringing up Mozilla, but.....), and that there seems to be no thought put into how they're going to actually manage it, I'd rather not have this multi-million line-of-code dump clouding the community's mind.
Actually, to the best of my knowledge, this is not their fault: really old patent law stipulates that in order to make patents understandable to laypeople, they must be phrased in a single sentence.
Remember that this is a case of a project which was already well underway, and had a lot of legacy source, and had gone down a lot of paths with a lot of dead ends in the source code. It's very difficult to take a half million lines of code and just send them out into the ether and expect anyone to be able to assimilate it, much less largely rework it, in any reasonable amount of time.
One of the reasons why it wouldn't compile, at least in part, is that if you look at the development environment for any major enterprise-level software project, it typically demands a very particular setup and environment to compile (i.e. you must be running the following apps with the following directory structure with teh following path and the following environmental variables just to get compilation, much less linking or debugging). Abstracting that away to a more general case of "I'm going to download the source and compile it because I'm bored" is a very very difficult proposition.
Most of the truly successful cases of open source projects have followed the "Release Early, Release Often" mantra. Perhaps if this is something that is that important to the community (which I think it is), it is worth starting from scratch. The problem is that starting truly from scratch would result in Mosaic, and it would take just as long to get something working. But in all likelihood the process and major contributors would be set by the time it got to have something useful in it, which would increase speed dramatically.
Kirk
San Francisco and Hunky Male Models...
on
LinuxExpo Report
·
· Score: 1
But then again the conference IS in North Carolina..... Maybe it's best to keep it hetero-male so that there isn't a rush "Jesse Helms vs. Linux" resolution in the Senate Foreign Relations Committee.
How's about this. When a conference come over here to Sodom By The Bay, then you'll do one with the hunky guy.
Gay geeks need soft-core ads too.......
Re:Read for the half I forgot to include :)
on
LinuxExpo Report
·
· Score: 1
Hey, glad to see what you meant by your post. I agree with you: conferences like this should be legitimized by the amount of money and support they give to the people who actually started the movement and still support it on a daily basis. There should be a "Shrine to Linux" booth or something.:-)
IBM DOES understand what's going on...
on
LinuxExpo Report
·
· Score: 3
Notice that IBM is offering support for Linux and Apache, that they're installing it at customer sites, supporting other players in the Linux space, etc. Their people tend to be very knowledgable, and when they don't know something, there is always somebody in their organization that does.
Yes, there are some firms that are just jumping on the Linux/OpenSource bandwagon. But to say that all firms that don't have an exclusively Linux focus are just paying Lip Service to the movement is a bit of an overgeneralization. They support the movement in many ways, including making it acceptable for a bigger corporation to play around with Linux. IBM or another large firm using or supporting Linux gives the movement credibility in the eyes of the people with the money. Who's to say whether those people will actually buy their solutions from IBM, or from Debian? Once the movement is legitimized, brand name lessens its grip on the thoughts of the people with the control to help world domination.
You can't expect a firm that takes in over $10bn a year in revenue to only sell Linux solutions, just as VA Research doesn't only sell Linux solutions (or at least they didn't....are they still offering Dual Boot systems?). Until World Domination (tm) is achieved, we need to make sure that the legitimization of the movement is one of the goals.
And even if it isn't, as Linux is supposed to be a happy little community that accepts all comers, why are you harping on the fact that some of those comers have a money-making agenda?
It sounds like your problems are more with those people setting up conferences and then charging exorbitant fees for them rather than with the big companies that are helping the movement along. I agree with you. But you probably wouldn't find much to do at a ZD conference anyway: it's by suits for suits. Head off to the Gathering or something if you want a more geek-friendly conference.
One of the problems with current open source projects is that many people are kinda "thrown in" to developing open source, when they find that their employer wants or is willing to allow them to develop for an open source project. It seems to be a side-effect of other projects, rather than the end goal. Admittedly, many great projects come out of this, but there's little room for people to approach your typical firm and say "I'd like to write device drivers for your object for Linux which you will release for free. How's that sound?"
In terms of allowing people who want to work on particular projects and get paid for it, a la DICE, this is a great connecting project. In terms of being different from other systems which have been established, well, it has Mr. O'Reilly. Love him or hate him (or even be neutral towards him), he has a great way of linking open source projects to the corporate and government concerns which have a the money and desire to pay for them.
This won't be for everyone, but for those of us who want to be able to work on particular open-source projects and still be able to pay the rent (we can't all win MacArthur Genius Grants, people), this could be a big boon. Remember, Mr. O'Reilly == Corporate Acceptance.
I've worked on a distributed database project based on Postgres (Mariposa at UC Berkeley) and the postgresql source code is in a bit of a, how shall we say this, bad state. I wouldn't trust my data with it unless I could afford to lose it.
And MySQL....sheesh....have you read the source code for it?
Slashdot Mirror
Yeah, I know about the party, but it was really the first calm, alone night Brian and I have had since The Great 5-Week Travels began.
Do you know how ridiculous it is that we're having this discussion on /.?
Kirk
Since the question was specifically on EJB support, I can't believe that he could really want to go with WebSphere.
One of the best things that the TPC has done is start on TPC-W, which more correctly simulates the workload that you're going to do in a web application infrastructure.
The TPC-C schema and data set are intended to simulate a bank network, and as such there are virtually no transactions which will cross some pre-defined Boundaries, which means that you can partition the data and applications very easily across a cluster. That is NOT true of web workloads.
Web Workloads tend to have a bunch of small transactions, which have some very big SELECTS as part of the transaction (such as integrating catalog data with personalization data). Those things can't very easily be partitioned across a cluster, so TPC-C numbers are irrelevant.
All TPC-C checks these days is how good your TPM (Transaction Processing Monitor) is optimized for TPC-C, that's it.
They're irrelevant, which is one reason why people like Amazon will never switch to SQLServer 2000.
First, going with BEA is the right choice on the EJB front. I don't mean to be all conceited, but WebSphere really sucks. In competitive situations, we found that WebSphere couldn't point to a single marquee customer which was using their EJB technology in a production site. Their Servlets and JSPs were okay, and their JMS definitely was better than WebLogic's, but their EJB infrastructure was pretty much unusable. An ironic thing to note here is that one of the largest systems integrators working with WebLogic Server is IBM Services....they don't even pitch their own product for their own customers. That should be a sign of the relative strengths of WebSphere vs. WebLogic on this front.
BEA's technical support people are extremely overworked. It's just a fact of life there after the BEA acquisition of WebLogic that BEA hasn't spent that much on the technical support infrastructure. However, there are two mitigating factors there:
Specifically on your choice of Oracle for the database, I'd recommend that you think again. The Oracle model of concurrency control makes doing serializable transactions damn near impossible for real-world EJB-enabled applications, and you'll find Oracle rolling back your TX_SERIALIZABLE transactions all over the place. Either move to a different DBMS (DB/2 rocks, actually....), mark your transactions TX_READ_COMMITTED, or be prepared for constant rollbacks of far-along transactions at COMMIT time. Unfortunately, there isn't much of an option otherwise, because Oracle does crazy things internally to try to maximize concurrency at the expense of transactional semantics. Think carefully about this one!
In short, WebLogic rocks, DB/2 rocks, AIX rocks, and if you know how to work the system, WebLogic support is the best of the three.
Kirk
Is there a particular product you're used to working with which provides this bit of extra-functionality?
BTW...sorry this isn't OSS related.
Imagine the following scenario: You, client C, initiate a service/transaction with server A. Server A crashes. Your service/transaction fails over to server B. However, server B knows nothing about what's been going on in your stateful connection, and is thus unable to help you.
The only solution that you can have within a database for failover is in the case when you have a stateless connection, and/or full state replication across the cluster of server machines. However, this alone is going to almost certainly bog down any of your transactions to the point where you don't want to continue anymore!
A company which has done this extremely well is the old Tandem, with their NonStopOS and NonStopSQL. Their mastery of failover in transactions was superb, and quite a bit of wall street is still running their stuff, even though Compaq has been quite unable to successfully market their services now (NonStopNT.... that's a complete oxymoron!).
I suppose you COULD implement the type of service you're talking about with failover stateless connections, but if you're going to do that you're much better going with an app server in the middle, which handles failover of connections in an EJB type model, and use the features of the app server to handle this.
So to sum it all up: For simple services like RPC and HTTP and FTP and whatnot, which are stateless (or very nearly so) by their nature, simple failover is fine. For extremely stateful services (like a database system), you've got to use much more complicated measures.
It's one thing to say that a product runs well while being written in pure C code. It's entirely another to say that it's good source code, as a mixture of C++, ANSI C and K&R C.
As for the statement that corporate programmers always write good comments because they are paid to, I'm pretty sure that isn't a given. For example, a friend who worked at HP told me that his bonus at one time was based in no small part on non-comment-lines-of-code. This indicates to me that comments aren't important to them (and he was working on HP-UX).
But the thing about the examples that you've indicated, Linux and GCC, is that those were developed by open source developers in public: they weren't released at some mature point in their life. If you take something like the Mozilla source code, when it was released there were significant quality problems that had to be worked through before the project could go forward. That all hinders understanding and forward progress.
Besides, have you ever read something like Query Optimizer code? Take a look at the postgres code for this section. It's very dense code, very difficult to grok, and almost like black magic. That's the sort of code that database servers are riddled with, and if they're truly legacy sections, it could be very very difficult to understand them and move forward.
Kirk
But the point that I was trying to make, perhaps not as eloquently as I might have done, is that corporate code usually suffers from some very similar problems: it relies on idioms and dependencies which are not well defined and specified. This is largely as a result of it not having been open to peer review outside the company before. Thus the only people who submit comments are the same people who write it in the first place, and people who know all those underlying, understood dependencies.
Open-source code, when written from scratch, tends to have fewer of those dependencies and understood-but-not-specified details. When a large enough pool of people works on something, and different people all the time, you have to have these things spelled out or else it will be too difficult to maintain.
My concern is that Inprise will be dumping code on the world which hasn't been peer reviewed, hasn't been clarified, and hasn't been sufficiently documented. Not that it doesn't do its job well, but that it will be difficult for the open source community to add to.
Kirk
And you might want to pick up a C++ book as well. Knowing C++, I've found, actually helps you write better C code, as the idioms are better defined.
Kirk
If your company said that they didn't care about your product anymore, you'd probably quit too.
Kirk
They've stated that they didn't really set out to do this open source. They got forced into it by their own ineptitude.
Their own public statements are that the whole development management team for Interbase quit last month, that they no longer have the resources to support the product, that they don't feel that this is part of their core business, that they no longer have the technical knowledge of hte product to support it, and therefore they're going to release it Open Source.
So what the community gets is about 15 years of corporate (read: poor quality) code, with no commitment by Inprise to support it at all. And their statements indicate that they don't plan to, as they don't feel that it's part of their core business. Heck, the rumors that I've heard is that there are sections that nobody currently understands, and that are written in K&R style C. This doesn't bode well for the product.
I'm all in favor of open source applications, but considering that this seems like a desperation dump (and I wasn't planning on bringing up Mozilla, but.....), and that there seems to be no thought put into how they're going to actually manage it, I'd rather not have this multi-million line-of-code dump clouding the community's mind.
Kirk
Of course, it has provided the opposite result.
But then again, IANAL.
One of the reasons why it wouldn't compile, at least in part, is that if you look at the development environment for any major enterprise-level software project, it typically demands a very particular setup and environment to compile (i.e. you must be running the following apps with the following directory structure with teh following path and the following environmental variables just to get compilation, much less linking or debugging). Abstracting that away to a more general case of "I'm going to download the source and compile it because I'm bored" is a very very difficult proposition.
Most of the truly successful cases of open source projects have followed the "Release Early, Release Often" mantra. Perhaps if this is something that is that important to the community (which I think it is), it is worth starting from scratch. The problem is that starting truly from scratch would result in Mosaic, and it would take just as long to get something working. But in all likelihood the process and major contributors would be set by the time it got to have something useful in it, which would increase speed dramatically.
Kirk
How's about this. When a conference come over here to Sodom By The Bay, then you'll do one with the hunky guy.
Gay geeks need soft-core ads too.......
Hey, glad to see what you meant by your post. I agree with you: conferences like this should be legitimized by the amount of money and support they give to the people who actually started the movement and still support it on a daily basis. There should be a "Shrine to Linux" booth or something. :-)
Yes, there are some firms that are just jumping on the Linux/OpenSource bandwagon. But to say that all firms that don't have an exclusively Linux focus are just paying Lip Service to the movement is a bit of an overgeneralization. They support the movement in many ways, including making it acceptable for a bigger corporation to play around with Linux. IBM or another large firm using or supporting Linux gives the movement credibility in the eyes of the people with the money. Who's to say whether those people will actually buy their solutions from IBM, or from Debian? Once the movement is legitimized, brand name lessens its grip on the thoughts of the people with the control to help world domination.
You can't expect a firm that takes in over $10bn a year in revenue to only sell Linux solutions, just as VA Research doesn't only sell Linux solutions (or at least they didn't....are they still offering Dual Boot systems?). Until World Domination (tm) is achieved, we need to make sure that the legitimization of the movement is one of the goals.
And even if it isn't, as Linux is supposed to be a happy little community that accepts all comers, why are you harping on the fact that some of those comers have a money-making agenda?
It sounds like your problems are more with those people setting up conferences and then charging exorbitant fees for them rather than with the big companies that are helping the movement along. I agree with you. But you probably wouldn't find much to do at a ZD conference anyway: it's by suits for suits. Head off to the Gathering or something if you want a more geek-friendly conference.
Kirk
In terms of allowing people who want to work on particular projects and get paid for it, a la DICE, this is a great connecting project. In terms of being different from other systems which have been established, well, it has Mr. O'Reilly. Love him or hate him (or even be neutral towards him), he has a great way of linking open source projects to the corporate and government concerns which have a the money and desire to pay for them.
This won't be for everyone, but for those of us who want to be able to work on particular open-source projects and still be able to pay the rent (we can't all win MacArthur Genius Grants, people), this could be a big boon. Remember, Mr. O'Reilly == Corporate Acceptance.
K
I've worked on a distributed database project based on Postgres (Mariposa at UC Berkeley) and the postgresql source code is in a bit of a, how shall we say this, bad state. I wouldn't trust my data with it unless I could afford to lose it.
And MySQL....sheesh....have you read the source code for it?