Krishnan Subramanian wrote:
>
> Joe,
>
> > You were making two technical points about your product. The first that
> > was that your product would solve a number of general purpose problems
> > ("complexity", "Longevity", etc.)
>
> No product can claim to solve those metrics for you! It takes time,
> discipline and effort to create a good design & implementation. In
> no way did I mean to claim Borland's product would solve those for
> you.
>
I agree. But that is not what your post suggested. The following is
from your previous post. It directly suggests that the use of JDBC does
not have those qualities while the use of EJBs and EJB containers do.
It is very explicit about it.
------------------------------------------------------------------------
> Performance is not the only yardstick by which enterprise applications
> are measured. Often just as important, or more important, are metrics
> such as:
>
> - Complexity: how hard is the system to build?
> - Modularity: how much of the system can be reused in future projects?
> - Extensibility: how easy is it to enhance the system?
> - Longevity: what is the usable lifetime of the system?
>
> ...
>
> A good example of the tradeoff between raw performance and a well-designed
> application is the use of Container Managed Persistence Entity Beans for
> accessing the database, verses using direct JDBC. Although admittedly it
> is possible to write a JDBC program that accesses the database directly,
> and for this application to be faster than a well-designed CMP Entity
> Bean based application, we have probably traded off modularity and
> extensibility for performance.
------------------------------------------------------
>
> J2EE systems and [specifically EJBs] are useful in solving certain
> problems by helping the developer focus primarily on application
> domain functionality. They are by no means the answer to the world's
> problems. ...If you did, you would find that they'd be getting
> in your way. Such usage would typically lead to a complex, badly
> implemented J2EE application.
Again I agree. I was trying to point out that I am questioning how many
projects really benifit from using EJBs. It is my supposition (my
opinion) that a non-trivial number of projects are using EJBs simply
because of hype and not because of any real need.
>
> > I believe I cited indirectly references in several different journals
> > where none of those matter in the vast majority of software development
> > because those although the terms are taken seriously the practice is
> > not.
>
> I think you'd agree that any application or program does not automatically
> benefit from "OO goodies" just by virtue of it having being written in
> an OO language (say C++/Java). Which does not mean that OO concepts
> are a failure (far from it!). J2EE aims to raise the bar so that a
> developer can focus on the business problem at hand; rather than having
> to worry about middleware APIs, work programmatically with transaction
> management, persistence, security at different tiers etc (a systems
> programmer in other words),. Also if you control system level aspects in
> your code, you are coupling that with the code implementing business
> logic. Therefore, systems level parameters become harder to maintain and
> modify. J2EE can help with these issues and the fact is - they are often
> not used as the component-based middleware platforms they are.
Again I would agree with that or at least not disagree with that.
But Object Oriented Databases (OODB) made the same claim. And history
has proven that either they did not provide what they claimed or that
they "raised the bar" so high that they became incomprehensible for
common usage.
>
> I've worked on a number of J2EE projects - both in Borland (~15 months
> now - with our customers) and prior to joining Borland. In some of
> these projects, EJBs were not really necessary or being used inappropriately
> (bad design & implementation). You could see the book "J2EE in practice"
> which has a number of case studies including one with Borland's AppServer.
> (used by AT&T - see Sun's JavaSoft site for an online version of this)
> Or even the book "Application Servers for e-Business" which has a case
> study of a project I worked on. These also enumerate some of the decisions
> taken - J2EE or not to J2EE; EJB or not to EJB, etc,.
>
And? I don't believe I ever said that EJBs were absolutely worthless.
I am questioning the the perception in the market of the role that the
might play is far broader than the role that they should (or will)
play. I doubt that EJBs will go away. But OODBs haven't gone away
either.
> > It took C++ 10 years or more to really own the market. It only took
> > java about 4-5 years to reach wide spread appeal (although based on
> > Software Development Nov 2002 there are more C++ developers.) I would
> > expect that a new methodology now would take less than 10 years to
> > overwhelm the market. And j2ee has been been out for at least 3 years
> > now.
>
> Granted J2EE has been there for sometime now. But given the complexity,
> range and depth of issues that J2EE has had to deal with; it has taken some
> time for the technology (and products that support it) to mature and gain
> acceptance. Furthermore, many (non-trivial) J2EE projects that started
> sometime ago are going into production only recently.
Yes. And it is that complexity that is very likely to lead to
diminished market share.
CORBA has a fine history, strong current standards and an ongoing
standards process, and is very suitable for certain applications. It is
also rather complex. Not only to understand initially but to maintain
correctly. And last year the companies that are looking to CORBA to
provide solutions declined significantly. CORBA was also significantly
hyped some years ago.
That doesn't mean that there is anything wrong with CORBA. But it
simply isn't suitable for many applications that the initial hype seemed
to suggest.
>
> Perhaps, J2EE has such a steep(?) learning & productivity curve, potentially
> increased complexity and a higher level of abstraction than what developers
> are used to - that we do not really identify anymore with the technology
> platform or the business benefits it brings?
>
It could have such a steep curve that developers simply are not willing
to put up with it.
As I pointed out in another post that although I do not agree with the
"not invented here" philosophy it does have the very strong point that
when I am done coding it I do understand it. I have no choice. It
might be slower, it might be more complex, but I do understand it.
I certainly suspect that there are projects under way and in production
where the developers do not understand why they did it in a particular
way using EJBs.
And if they leave that project and go to another and use the same
practices on the next project, not because it is the best choice, but
because it worked the first time, would you consider that a good thing?
===========================================================================
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".
