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 *