In article <[log in to unmask]>, Michael L Gueterman
<[log in to unmask]> writes
> (ODBC) is simply an application
>programming interface based on the ISO Call-Level Interface (CLI). I
>would venture to guess that there are still many more packages that
>interface with ODBC than with J2EE. As far as being inefficient, you
>need to place that in context. Is it what I would choose to transfer
>terabytes worth of information from one database to another? No,
>but I wouldn't choose a J2EE application either if given a choice :)
My understanding is that there are or have been a number of issues with
ODBC -
Limitations in multiple database environments.
Defines the client side of database connectivity but not the server
side.
ODBC middleware drivers typically rely on the underlying presence of a
vendor's proprietary driver.
Network administrators must install and configure an ODBC driver on
each client as well as on the server. Although there are exceptions to
this such as in Cold Fusion, I believe.
Both presentation and business logic occur on the client.
Client side is proprietary to Microsoft platforms.
Cannot be used for Applets in web browsers, although I concede that
webification doesn't have to rely on browser technology. There are other
ways.
Defines rudimentary or no transaction management services.
Doesn't scale well since each database access request spawns a separate
process.
The SQL code must be compliant with the ANSI standard which is an
important limitation to using ODBC since there are three levels of ANSI
compliance an ODBC driver can adhere to
CORE (ISO) - Level 1 (X/Open) - Level 2.
Not all ODBC drivers provided by Database suppliers are in full
compliance with the ANSI standards. For example, Core Level doesn't
support transaction services. Contrast this with the J2EE Connector
Architecture based Enterprise Resource Adapter which provides a
standardised interface (CCI) and is widely supported, particularly among
ERP vendors and major database suppliers.
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.
Contrary to common understanding, J2EE is actually a platform which
defines a range of simple platform-neutral standards that apply to all
aspects of designing and developing multi-tier server based
architectures where the business logic and potentially the client
presentation logic, as well as the data access logic, is managed.
The primary concern of J2EE is the platform specification.
It describes the runtime environment and infrastructure which includes
application components, containers, resource manager drivers, and
database and data resource access mechanisms. The elements of this
infrastructure communicate with a set of standard services that are also
specified - transaction management, security, resource pooling, etc.
There is no reliance on vendor specific implementations so it is
inherently "Back end agnostic" as well as "Front-end agnostic".
By following J2EE design principles, any part of an application can be
easily migrated to a different platform or to a different database;
multi-databases can be accessed concurrently.
So application development investment is effectively and efficiently
leveraged whether you continue to develop on the HP3000 or begin to
evolve part of your applications to different platforms. An important
aspect of J2EE, in addition to platform-neutrality, is that it is highly
scalable.
Since J2EE is designed as a Java platform, with inherent object-oriented
principles, then it would seem to be reasonable to employ the Java
language, which of course is itself inherently platform-neutral.
However, if you wish to use other non-object-orriented languages then
the J2EE infrastructure accommodates this by supporting RMI over CORBA's
communication protocols IIOP (I'nternet I'nter-O'RB P'rotocol)
And quality design environments like Visual Age for Java will
automatically generate the Stubs and Skeletons required.
But one would need to have very sound reasons for taking this route.
Actually this is an interesting, if complicated, approach since server-
based applications can use the RMI remote object to support RMI clients,
socket listeners for socket clients, and servlet architecture for http
clients in shared business logic classes.
One of the big, new J2EE uses is expected to be processing
so-called Web Services - SOAP, UDDI, WSDL which are XML based W3C
standards which provide platform neutral methods for businesses to
automate interaction with customers and suppliers on an E-commerce
basis. Rather like EDI but without the proprietary problems.
Such services involve clever software already available from a variety
of sources and involve public and private UDDI registries.
The .NET strategy from Microsoft is an attempt to catch up with this
platform-neutral technology, but as you may imagine, .NET includes MS
proprietary parts. I understand that Cold Fusion provides some support
for these services at release 5 but that the emphasis is directed
towards supporting .NET which includes the DISCO service (not yet
available I believe) which is similar to UDDI but MS proprietary.
The ANSI Open Commerce Services (OCS) for evolving HP3000 applications
(which were described in my original post) are designed around Java and
the J2EE standard because we believe that this platform offers the
widest scope for platform neutrality, availability of component software
from third parties, choice of J2EE application servers from major
corporation like IBM, BEA, Oracle, HP, and availability of
comprehensive development and test environments supporting the J2EE
platform. OCS typically supports socket clients, servlet architectures
and EJB's operating within any J2EE standard application server.
Java J2EE doesn't have to be a high cost solution either.
There is plenty of software available for a small charge or free to
download that allows pilot projects to be established.
Linux (free) or NT (licence required) boxes can be used for learning and
experimentation.
You'll need Apache and Tomcat free to download from jakarta.apache.org
A Java SDK. JDK 1.3 is now available to download from www.java.sun.com
If you want a good solid platform-neutral web browser that fully
supports HTML try Opera at www.opera.com It has some nice features
too.
For visual development environments there is a variety of free entry-
level downloads at ibm.com in the Websphere range and DB2 is also
available.
Also the basic ANSI Studio VDE, which provides a Java editor and
compiler will be available for free download for qualified recipients.
Contact Advanced Network Systems Inc.
For a J2EE web application server try Orion from www.orionserver.com
free to download for non-commercial use.
That's about all you need to get started.
Respectfully
Chris Thompson
> David's original statement is very valid and our company has done exactly
>that for several customers in the last few years. A web-based application
>(regardless of the middleware used) has large benefits to the customer
>when it comes to "server independence". If you write the application
>using products and procedures that are (to quote one of my customers)
>"Back end agnostic", then if the time comes where that back-end must
>be changed, the front-end remains pretty much untouched. Especially
>now that most e3000 users are going to be forced into some flavor of
>migration to another platform, this represents a way to continue your
>application development without sacrificing that effort when migration
>day arrives. If you choose to write that web-app in Java, then J2EE
>seems to be a promising way to go. If on the other hand you choose to
>use something other than JAVA, then you need to decide how you're going
>to interface with that back-end system and ODBC is one of a number of
>valid interfaces to choose from. I can understand your bias given your
>company, but J2EE is only one potentially viable solution.
>
>Respectfully,
>Michael L Gueterman
>SIG Web co-chair
>Easy Does It Technologies LLC
>http://www.editcorp.com
>voice: 888.858.EDIT or 573.368.5478
>fax: 573.368.5479
>--
>
>* To join/leave the list, search archives, change list settings, *
>* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
