Adam,

I think we need to reflect on the original context of this thread which
was
<snip>
David Darnell recommended ODBC as a framework for migration ... for a
small shop on a tight budget.
</snip>

To which my response was essentially promoting the platform-neutral
Connector Architecture technology for Enterprise Resource Adapters as an
integration technology to leverage investment -

<snip>
IMO a better way is to employ the new platform-neutral J2EE standard
Connector Architecture compliant Enterprise Resource Adapter technology.
ERA's run in Application Servers (like Weblogic, ANSI Web, Websphere,
and maybe Bluestone). The interface to ERA's is provide by the Common
Client Interface (CCI), an easy to implement platform-neutral set of
Java classes. Because this approach completely devolves the data access
from the application (presentation and business logic), moving to a
different data source becomes a simple matter of changing the resource
adapter.
</snip>

Since the Connector Architecture is part of the J2EE standard, the
thrust of the response also promoted J2EE as an architecture and
development infrastructure for enterprise scalable platform-neutral
migration, which I felt would be of interest and importance to many
HP3000 users. I also mentioned several tools and application servers
that support it, notably from IBM who are arguably the leader in
implementing J2EE.

However, I should also have mentioned that this is a technology that
also supports both ODBC and JDBC standards, but is not constrained to
use either, which makes it attractive for integrating or evolving EIS
and ERP systems to platform-neutrality.

It was not my intention to make comparisons between ODBC and JDBC which
incidentally is virtually the same technology. And for small shops and
low scalability, ODBC is still a good choice if platform-neutrality is
not an issue. ODBC has certainly helped us in the past.

However, your partner, Michael Gueterman asked that I place ODBC's
inefficiencies in context -
<SNIP>
 'O'pen 'D'ata'B'ase 'C'onnectivity (ODBC) is simply an application
programming interface based on the ISO Call-Level Interface (CLI).
.........  As far as being inefficient, you need to place that in
ccontext.
</snip>

So in a subsequent post I elaborated on what is commonly believed by
many to be ODBC difficulties. But at the same time attempted to steer
the discussion back to its original purpose - migration strategies.

Michael subsequently responded to those issues with an excellent and
informative post.

However, since you asked for ODBC/JDBC comparisons then I believe the
following to be the case.
Both are based on X/Open SQL CLI
Both provide an interface to RDB's
There is a close mapping between both architectures because they are
based on the same standards.
JDBC is considered by many to be a lot easier to use than ODBC
They both share conceptual components -
Driver Manager, Driver, Connection, SQL Statement, Metadata, ResultsSet.
JDBC was built on ODBC but in addition provides all of the benefits of a
pure Java API , portability being the key issue.
JDBC provides a loose coupling which allows easy replacement of the data
store - dependent upon the type of JDBC driver and any vendor-specific
proprietary extensions.

Finally there is another method of connecting to data sources - the high
performance socket listener - which is considerably faster than either
ODBC or JDBC. If properly implemented, Java-based socket listener
designs can be run as either client/server or in n-tier applications.
The ADBC software is an example.

Oh, by the way, I note that release 5 of Cold Fusion (CF) supports
Server Side Java (requires JDK 1.2 from SUN) and provides support for
Java Objects, EJB's, Servlets, and proprietary CFX tags via the cfx.jar
file. Apparently these features were added to improve CF's capabilities.
And both ODBC and JDBC are supported as they are in most other J2EE
application servers.
When you get too comfortable using the mallet, chisel, hammer, and
nails, you often fail to appreciate the efficacy of the multi-jointer
and compressed-air nailer.

I appreciate your $0,02 worth. All contributions gratefully received :-)

Regards

Chris Thompson

In article <[log in to unmask]>, Adam Dorritie
<[log in to unmask]> writes
>Chris,
>
>Michael's suggestion isn't that J2EE isn't as good as you say, it's just
>that ODBC isn't as bad.  You're taking apples and comparing them to a
>company which produces orange-flavored liqueur.  If you want to make a valid
>comparison in which, I am sure, Java will make a strong showing (if not
>shine), then try comparing the ODBC apple to its Java counterpart-- JDBC.
>ODBC is simply a standard (and yes, it is a standard) implementation of the
>X/Open and ISO CLI (Call-Level Interface) intended for _accessing
>databases_-- not providing an application framework, a development
>methodology, or "the standard for developing multitier enterprise
>applications" (java.sun.com) as is J2EE.  If you want to compare apples to
>apples, in an effort to let folks know why you think they should buy your
>product, then feel free to call out any of the application server
>environments available today (including Cold Fusion) which support ODBC and
>tell them why yours is better-- I'm sure you'll be right.
>
>Oh, by the way, we use ODBC because it's convenient and works well in the
>situations we've had to apply it to.  If the situation called for it, we'd
>use JDBC or even develop under a J2EE-compliant application server to meet
>the needs of our customers.  The key to having a useful box of tools is
>knowing the value and use of each one.  When you get too enamored of a
>particular tool, you find yourself doing things like using your favorite
>pile driver to pound a nail into place.
>
>Just my $.02.
>
>Regards,
>
>Adam Dorritie
>
>Chris Thompson orates:
>
>> My understanding is that there are or have been a number of issues with
>> ODBC -
>>
>
><snip>
>  A number of reasons why ODBC sucks-- some likely valid, some invalid.
></snip>
>
>
>> ODBC, unlike J2EE, provides simply a client/server mechanism for
>> connecting to data sources using SQL. So although it separates data
>> access from business and presentation logic it provides little else.
>> The programmer still has to design and maintain a whole range of
>> services that J2EE provides by default. With J2EE you just consume the
>> services which means lower time to market and lower development and
>> support costs.
>
><snip>
>  Several paragraphs extolling the virtues of J2EE
></snip>
>

---------------------------
The Internet Agency, UK
http://www.the-internet-agency.com
European Distributors for Advanced Networks Systems Inc.
Distributors of CCS TRAX and CCS C-iX 'C' compiler for MPE
Voice:  +44 7836 364575
Fax:    +44 1202 418209
Email   [log in to unmask]


Advanced Network Systems Inc. ANSI
http://www.advnetsys.com
Voice:  +1 908-638-3330
Fax:    +1 908-638-3331
Email   [log in to unmask]

-----------------------------------------

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *