Welcome to weblogs.com.pk Sign in | Join | Help

Enterprise Applications and InterOp

I posted few days back about converting .NET Dataset into ADODB Recordset.

Here is the deployment diagram of the scenario we were dealing with.

The sensitive application web service’ certain methods return dataset, this is done for the reason that in single trip, more data is retrieved and cached on the client applications thus saving expensive web services call.

We believe that there should not be redundant implementations, for two reasons, better maintenance and your single implementation get matured. We earlier had two modes to access sensitive application, the good old DCOM based, and the more recent implementation which is web services based. Now we want to stop using DCOM based connectivity for the above said reason.

Our client applications are written in variety of platform (due to number of reasons, the prime most is, we love trying new and different things each time <smile/>)

For PHP and (Classic) ASP based client application, we need front-end components that are COM aware (as these both platforms inter-op very beautifully with COM)

The famous data access methodology in COM world is ADO, which has one famous object, Recordset.

We don’t want that we re-write the ASP/PHP application code, for this reason, we ultimately have to expose and receive the data in ADODB Recordset format.

Khurram Hanif gave couple of URLs, and I also did some browsing to find what people have done, and all has suggested using either typed dataset so that data is returned in form of array of objects, or using raw XML to transform the data. No doubt both approaches are great, but handling these two requires significant investment to develop the client component.

We adopted the simple one; we have developed the proxies for the web services in .NET and wherever dataset is used, we transformed the data into XML using XSL, saving that data in the file and returning the path of that file to VB COMponents, which open recordset from that file and return them to PHP/ASP client applications.

  • Saving content to file in .NET and then opening it from VB COMponents, saved dependency in ADODB interop assembly.
  • The only bottlenecks we feel are that data is saved to file, which is not a big deal, we had to do it, for the caching anyways, and overhead of COM Callable Wrappers, which is not very observant at this moment, as we have gained overall a good boost due to caching I have talked about.

I will post about, why we separated the sensitive application, why we used VB, how we implemented caching and may be how we displayed the data in PHP/ASP application coming all the way from sensitive application passing through all these different layers <smile/>

Published Thursday, August 18, 2005 6:34 PM by khurram
Filed under:


No Comments

New Comments to this post are disabled