Deliver superior customer experiences with an AI-driven platform for creating and deploying cognitive chatbots
Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
A complete cloud platform for an app or your entire digital business
Detect and predict anomalies by automating machine learning to achieve higher asset uptime and maximized yield
Automate decision processes with a no-code business rules engine
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Personalize and optimize the customer experience across digital touchpoints
Build, protect and deploy apps across any platform and mobile device
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
In this podcast Rob Steward explains the advantages of using wire protocol drivers. This podcast is runs for 2:56.
You may listen to the podcast here: http://blogs.datadirect.com/media/RobSteward_WireProtocolDatabaseDrivers.mp3
So when we talk specifically about wire protocol architecture drivers, this is something where really what you're talking about is a type 4 JDBC or a completely managed, 100% managed ADO.NET data provider, or in the case of ODBC, you have an ODBC driver which talks directly, opens up a TCP/IP socket or some network socket to the database and directly communicates using the network protocol and using the packets that the databases themselves understand. So that's kind of the difference between a wire protocol and a non-wire protocol, so you may have pretty much any type 4 JDBC driver is going to be talking a wire protocol to the database, because it has to stay within the DM and it can't call any native OS. A type 2 JDBC driver or a partially managed ADO.NET or what most people typically think of as ODBC, you've got that driver component on top of some other native component, and it's that native component that talks across the wire to the database, and the driver itself does not talk directly. So there's a lot of differences, a lot of different architectures out there with which to build the driver.
Now, of course, the obvious question is which one is best, and certainly, in my opinion, the best ones are the wire protocol drivers and the type 4 JDBC because in terms of performance, scalability, functionality, those are always going to be better in terms of performance and scalability in particular, and reliability, as well. When you get into pure Java solutions within the Java environment or 100% managed within .NET, theoretically you can't have things like buffer overruns or memory leaks, so reliability is increased with those type 4 wire protocol type solutions, as well. So -- and also in terms of performance and scalability, the fact that it is a wire protocol, let's say wire protocol ODBC, where that driver talks directly to the database and not through some intermediate component, it's going to perform better because it's designed to do exactly what your ODBC application needs. It doesn't have all this other stuff. It doesn't have double sets of buffering, one in that client layer, one in the driver layer, and the reliability, again, is going to be increased. So, you know, in my opinion certainly type 4 JDBC, 100% managed in the .NET world, and wire protocol ODBC are somewhat equivalent when you think about architecture, and those, to me, would always be the best performing and best scaling solutions.
View all posts from Rob Steward on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2018 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.