> I don't agree with you in this point... maybe switching is a
> good thing. This
> way you can make an application and sell it without worrying
> about things as
> load or scalability. These should be handled by the
> application server, so the
> company buying your software could choose from a variety of
> app servers based on
> their needs in number of users, load balancing, scalability,
> fault tolerance,
> availibility, etc.
These are the things I expect my application server to support. These are
all things I NEED my application server to support. (Because who wants to
write all that stuff?!)
Are you talking about potentially selling a product, to customers that
allows the customer to choose the application server that your EJB
application is deployed in? If this is the case, I may agree with you.
But, I have to question... Do you really want to give your customer the
flexibility of choosing the application server that your product should run
under? Is the ability to choose application servers going to dramatically
effect the cost of your product to attract different customers? Do you want
these low-cost customers? Are they informed enough to make the decision of
choosing an application server product? I don't see enough of a price
difference between the venders to use this as a business model. If I am
going to sell an application to a customer, I plan on entering a VAR
agreement with the application server company and selling the product as a
total solution. I make sure that aspects of the functionality, scalability
and other features are covered by the application server I choose.
If you are selling components and not entire applications, using EJB as a
model to model these components may be good.
Don't get me wrong. I reap the benefits of application servers every day at
work. But, I make informed decisions on which one I choose. I also choose
them on the basis that I don't intend on easily porting the code. So if I
need an application that requires all the wonderful things we just
mentioned... I will choose the right one. If my requirements change,
deployment budget etc... So does my application server decision.
Being able to port your code from a freeware implementation of an EJB server
to a 45K/cpu product and have no code changes is still a dream. I want to
be able to live this dream one day and fully support it. But, right now, I
have to hold my own because EJB isn't quite there yet.
> Ok, I'd like to join :o)
> I consider myself an object purist too, and I don't
> understand certain things...
> it seems there's a real push in industry towards object
> oriented programming,
> you know, Java is becoming or even has becomed a standard,
> UML is all around,
> CORBA and RMI are making sockets to be just an inner layer
> that a few people
> remember,... but it doesn't seem to be such a push in object
> persistance... what
> happened to ODMG, are they still working? what about EJB?
> doesn't seem a back
> step with all that RDBMS feeling? Is there any initiative to
> provide EJB CMP in
> OODBMS, or integrate these two worlds?
Like all design by comity ideas... they don't move fast enough. They were
unable to get things out fast enough, people were forced to choose other
products that were more "production ready" and OODBMS fell onto a back
burner in IT shops. As well some major members have pulled out of the ODMG
and with the recent loss of some OODBMS vendors. The future is not looking
good.
And when I read articles like the one that was just recently published in
the a popular Java magazine by a Java-RDBMS vendor about OODBMS... (It was
on the last page of the magazine.) I wonder why I didn't follow my fathers
footsteps in the construction industry... :) The article was so poorly
written, the facts so vague, I canceled my subscription.
You know what the sad thing is about the current state of OODBMSs. The
coolest applications out there are all using OODBMS. But, no one wants to
talk about it...
Sorry about my depressing comments here. I will write a cheery happy one
later... :D
Greg
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
