Suggestions on OLE DB architecture [modified]
-
Hi all, I'm embarking on a fairly complex project (I know. Please don't say simply "Google for it". I already did). What I want is to implement an OLE DB layer between a physical DB (connection via standard OLE DB interface) and a client application. The aim is to implement row level security and additional functions (such as logging) in the OLE DB layer. So the architecture should be like this (top-down):
Client Application <- Ole DB consumer application (MFC, .NET, Excel...) ----------------------- OLE DB Provider <- On the client. Dumb connection to my service via the Network layer ----------------------- Network layer <- I really don't know how to pass through this ----------------------- OLE DB Consumer/Provider service <- This should be on a network server. Here I'm implementing row level security. This service acts as an OLE DB consumer for the DB and exposes data to the client. ----------------------- Physical DB <- Any OLE DB-compliant database (mainly SQL Server or Oracle) -----------------------My question is: what is the best way to implement the Network layer? I found an OLE DB Remoting Provider by Microsoft, but seems outdated and not supported ATM. If using this, I should implement OLE DB Provider interfaces into the Service on the server. Any suggestions? (Cross-posted in the C++/MFC Forum. Don't know which forum is best suited)modified on Wednesday, February 4, 2009 12:33 PM
-
Hi all, I'm embarking on a fairly complex project (I know. Please don't say simply "Google for it". I already did). What I want is to implement an OLE DB layer between a physical DB (connection via standard OLE DB interface) and a client application. The aim is to implement row level security and additional functions (such as logging) in the OLE DB layer. So the architecture should be like this (top-down):
Client Application <- Ole DB consumer application (MFC, .NET, Excel...) ----------------------- OLE DB Provider <- On the client. Dumb connection to my service via the Network layer ----------------------- Network layer <- I really don't know how to pass through this ----------------------- OLE DB Consumer/Provider service <- This should be on a network server. Here I'm implementing row level security. This service acts as an OLE DB consumer for the DB and exposes data to the client. ----------------------- Physical DB <- Any OLE DB-compliant database (mainly SQL Server or Oracle) -----------------------My question is: what is the best way to implement the Network layer? I found an OLE DB Remoting Provider by Microsoft, but seems outdated and not supported ATM. If using this, I should implement OLE DB Provider interfaces into the Service on the server. Any suggestions? (Cross-posted in the C++/MFC Forum. Don't know which forum is best suited)modified on Wednesday, February 4, 2009 12:33 PM
Hi, Here's an idea: Asynchronous WinHTTP[^],...but, it's probably NOT what you're looking for. I think you'll see what I'm getting at, it's difficult for anyone to guess at the implementation specifics of your project. You should provide us with a little more information. Versions of the server operating system, COM?, DCOM?, NET?, level of security,...stuff like that. It's a typical type of component development,...I would begin by reviewing the various security implementations that already exist for your preferred mode of transport, and go from there. Maybe, something like this: DCOM Technical Overview[^], would be a good place to start. Or, maybe, you could peruse. Codeproject Database Articles[^]. Codeproject has an amazing amount of information available, you have to scan it, though.
-
Hi, Here's an idea: Asynchronous WinHTTP[^],...but, it's probably NOT what you're looking for. I think you'll see what I'm getting at, it's difficult for anyone to guess at the implementation specifics of your project. You should provide us with a little more information. Versions of the server operating system, COM?, DCOM?, NET?, level of security,...stuff like that. It's a typical type of component development,...I would begin by reviewing the various security implementations that already exist for your preferred mode of transport, and go from there. Maybe, something like this: DCOM Technical Overview[^], would be a good place to start. Or, maybe, you could peruse. Codeproject Database Articles[^]. Codeproject has an amazing amount of information available, you have to scan it, though.
Thank you much for your suggestions! I was not much specific about implementation detail just because they are quite fuzzy, ATM. I'm sketching the system architecture designing boxes to be filled with selected components. So the question is "what is the best technology for implementing this component"? I can't start working if I don't have a picture of the desired result. I.E. For the data provider on the client side, for maximum compatibility, the choice is still VC++, COM and OLE DB (either with ATL or not). This manages the communication with the client-side only, so I needed some hint on what's the best technology (for scalability, flexibility, ease of use, performance, ...) to implement the network communication layer. DCOM, for instance, is harder to implement and does not get easily through firewalls (for what I read, I didn't use it really). I read about .NET remoting: it's easy to use and performs quite good, but it's managed and seems difficult to integrate with native OLE DB code. Asynchronous WinHTTP seems really promising: thanks for pointing that out! If you have any other suggestion, it's really appreciated.
-
Thank you much for your suggestions! I was not much specific about implementation detail just because they are quite fuzzy, ATM. I'm sketching the system architecture designing boxes to be filled with selected components. So the question is "what is the best technology for implementing this component"? I can't start working if I don't have a picture of the desired result. I.E. For the data provider on the client side, for maximum compatibility, the choice is still VC++, COM and OLE DB (either with ATL or not). This manages the communication with the client-side only, so I needed some hint on what's the best technology (for scalability, flexibility, ease of use, performance, ...) to implement the network communication layer. DCOM, for instance, is harder to implement and does not get easily through firewalls (for what I read, I didn't use it really). I read about .NET remoting: it's easy to use and performs quite good, but it's managed and seems difficult to integrate with native OLE DB code. Asynchronous WinHTTP seems really promising: thanks for pointing that out! If you have any other suggestion, it's really appreciated.
I had to read up on OLE DB, as I'm unfamilar with its object hierarchy. And, I really don't know what to suggest, except that you do some serious research on the underlying RPC transport that COM uses when accessing remote objects, for instance: (The RPC Model Overview, MSDN[^]). This occurs in a largely transparent way (from a programmer's point of view). So, you don't really create a network layer, specifically. Typically, with standard marshaling, MIDL is used to generate COM interface definitions for your DB provider and comsumer components, and the Proxy/Stub architecture that COM relies on for instantiating remote objects. The security model is implemented at the network machine level boundary (think, AccessCheck) through authentication and Operating System mechanisms of access control which can be configured either programatically or administratively. If you can get a copy of Don Box's 'Essential COM' or, 'Inside COM+ Base Services', by Guy Eddon, I would suggest that you familarize your self with the security aspects of COM. There are a number of technical articles at MSDN, for instance: COM, Component Object Technologies, MSDN[^], and, COM Security in Practice, MSDN[^], or, DCOM Architecture, MSDN[^]. The .NET Framework is largely designed to make internet access easy, but, this depends largely on which version of the runtime you use. Interop between COM and the .NET Framework is also a possibility, but, many programmers initially find this approach cumbersome and error prone. Also, the NET redistributables and whatever dependent libraries are necessary, must be installed on both server and client. I think your answer, is to do more research,...but, start with COM, since the OLE DB component is COM (this will initially simplify alot of development).