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.
> Because many projects are not solvable by using EJBs. Certainly a large
> number are not. I would argue that the vast majority are not. And many
> of those that are specifically appropriate to the technology are not
> significantly (measurably) helped by it.
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. For example, in the case of EJBs they can be used to raise
the level of abstraction and free the developer from certain generic
programmatic (system level) issues such as remote connectivity, object
lifecycle management, persistence, transaction management and security.
If your application does not need to make use of these, then you would
not need to use EJBs. 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.
> 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.
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,.
> 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.
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?
-krish
===========================================================================
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".
