Create and deliver personalized experiences across digital properties at scale
Build engaging websites with intuitive web content management
Leverage a complete UI toolbox for web, mobile and desktop development
Build, protect and deploy apps across any platform and mobile device
Build mobile apps for iOS, Android and Windows Phone
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Automate UI, load and performance testing for web, desktop and mobile
Host, deploy and scale Node.js, Java and .NET Core apps on premise or in the cloud
Optimize data integration with high-performance connectivity
Automate decision processes with a no-code business rules engine
Transform your businesses in order to survive in a completely digitized and connected world driven by software innovation.
Globally scale websites with innovative content management and infrastructure approaches
Content-focused web and mobile solution for empowering marketers
Faster, tailored mobile experiences for any device and data source
UX and app modernization to powerfully navigate today's digital landscape
Fuel agility with ever-ready applications, built 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 © 2016, 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 or appropriate markings.