I've been building ASP.net web applications using kbmMW as the backend server since mid-2004. All of the application servers have been Win32 based and of course the web frontend is dotnet based. During this time I've used various techniques for transferring data between the tiers.
These include
- ASP.net built using Delphi for DotNet connecting to kbmMW using the Delphi based kbmMW clients exchanging data as VCL streams of objects
- ASP.net built using Delphi for DotNet connecting to kbmMW using the Delphi based kbmMW client using kbmMemtable DotNetAdditions (alpha) so that kbmMWQueries can be bound to directly
- ASP.net built using VS2005 and DotNet 2 using kbmMWSpider extensions for DotNet
- Something else I have codenamed Agility
What I'd like to share with you is the third of these because we will be releasing it very shortly after kbmMW 2.70.
It is a reality today that there is no CodeGear offering for developing DotNet applications for anything above version 1.1 of the framework. However ASP.net 2 has some compelling features that we wish to tap into and certainly before the release of Highlander.
The clear choice then is VS2005 and C# as the programming language and then the kbmMWSpider client to connect to and interact with the application server. There is a problem with this approach though and that is the lack of kbmMemtable support running under dotnet 2. After some pondering the solution was kbmMWSpider extensions for dotnet.
This is in use at http://www.myc4d.com/, http://www.turbomiddleware.com/ and some other interesting projects including an existing customer for their new web work (they contracted us to bring this forward in the roadmap).
What is kbmMWSpider extensions for DotNet (yes we struggled with a name for this).
It is comprised of three things
-
an enhanced Spider C# client that supports connection pooling, request retries and failover
-
a complete VCL compatible streaming layer
-
two data formatters that accept kbmBinaryFormat (kbmMemtable in other words) and kbmMWFormat datastreams and decode these into System.Data.Datatable instances
In more detail
Enhanced Spider C# client that supports connection pooling, request retries and failover
An issue was dicovered when developing the portal. Should the application server connection be lost for some reason the dotnet socket layer still reports the socket as being connected. This sounds odd but in the world of sockets the only way generally to know if you're connection to the endpoint is valid is to attempt to send some data and see what happens. If the connected property of the socket returned true then in anycase this would only be accurate at the point of the call - the socket could still lose it's connection a microsecond later. In the Delphi client we have robust handling of request failures with logic to retry the request and then attempt to failover to other servers. The first incarnation of the Spider C# client didn't provide this logic so we have added it.
This issue was discovered because of another new feature added - connection pooling. We now provide managed and transparent connection pooling to boost responsiveness and performance in high request situations.
a complete VCL compatible streaming layer
Anyone that has used TWriter/TReader in the VCL will know the power it provides. It is also an integral part of the way kbmMW works. Without this the scope for bridging the Visual Studio and VCL worlds is limited.
Data formatters
This is where the VCL support was trying to take us to. Being able to make a request to a kbmMW application server, have it stream the results of a query into the resultstream and be able to decode and bind to this in the dotnet code.
Here is the real live deployed code for "mylicences.aspx" used in myC4D.com
Notice the line this.gridLicences.DataSource = dt line. This is native data binding to the result of the MyLicences call.
Now the MyLicenceses call
Here is a regular request to a kbmMW application server that saves it's query results onto the resultstream. In the ASP.net code we instantiate a C4D.kbmMW.Data.DataAdapter and get it to decode the contents using FillDatatable. From this point on we have our data in a dotnet friendly form that we can bind to and manipulate. It is efficient and complete.
I'm looking for more people to play with this before release so if you're interested let me know.
Richard