Hide web service details?
-
We're working on a project that goes against another application that exposes it's API via web services. Pretty cool, except for the complexity of actually getting anything done due to the interdependacy of the calls. So what we're doing is writing wrapper classes to abstract away the details to let people call a simple function that takes care of all the nitty gritty bits. Plus give us the future option of moving to another third party app by simply rewriting the wrappers. Now for the problem area... we want to hide the actual web service calls from the application programmers using our wrapper. Basically we want to try to prevent someone from going outside the sandbox and using the API directly, potentially causing problems with the app or future portability. With them referenced in the assembly, you can see them by default. I know it's probably basic, but haven't worked out how to make them private or internal. Someone got a pointer?
-
We're working on a project that goes against another application that exposes it's API via web services. Pretty cool, except for the complexity of actually getting anything done due to the interdependacy of the calls. So what we're doing is writing wrapper classes to abstract away the details to let people call a simple function that takes care of all the nitty gritty bits. Plus give us the future option of moving to another third party app by simply rewriting the wrappers. Now for the problem area... we want to hide the actual web service calls from the application programmers using our wrapper. Basically we want to try to prevent someone from going outside the sandbox and using the API directly, potentially causing problems with the app or future portability. With them referenced in the assembly, you can see them by default. I know it's probably basic, but haven't worked out how to make them private or internal. Someone got a pointer?
You can create this wrapper in an external project (into single DLL Assembly) to prevent programmers from seeing those. You can even obfuscate it to add more protection. But there is one thing I would suggest, is that are you sure the details (such as service address, WSDL, etc) won't change? If you're sure, then it's quite straight forward. But if you're not sure if the service address won't change, maybe you can "extract" the service address to be read from an external configuration. As for the WSDL uncertainty, I'm not quite sure about that, but maybe you can write your own WSDL&SOAP parser :) Hope it helps :) "If Mohammed won't go to the mountain, then the mountain must go to Mohammed" - Gil Grissom, CSI
-
You can create this wrapper in an external project (into single DLL Assembly) to prevent programmers from seeing those. You can even obfuscate it to add more protection. But there is one thing I would suggest, is that are you sure the details (such as service address, WSDL, etc) won't change? If you're sure, then it's quite straight forward. But if you're not sure if the service address won't change, maybe you can "extract" the service address to be read from an external configuration. As for the WSDL uncertainty, I'm not quite sure about that, but maybe you can write your own WSDL&SOAP parser :) Hope it helps :) "If Mohammed won't go to the mountain, then the mountain must go to Mohammed" - Gil Grissom, CSI
I'm afraid I don't follow. What we have currently is a single DLL wrapper project. That DLL has web references to the web services API of the other product. When a reference to the DLL is added to a client application, they not only see our wrapper functions, but also the raw service API as well. What we want to do is simply have them see our wrapper functions. The service address is driven by external configuration, but the autogenerated code from the WSDL generated by adding the web reference in our wrapper DLL is what we would ultimately like to hide.
-
I'm afraid I don't follow. What we have currently is a single DLL wrapper project. That DLL has web references to the web services API of the other product. When a reference to the DLL is added to a client application, they not only see our wrapper functions, but also the raw service API as well. What we want to do is simply have them see our wrapper functions. The service address is driven by external configuration, but the autogenerated code from the WSDL generated by adding the web reference in our wrapper DLL is what we would ultimately like to hide.
So you mean the automatically-generated code (by Visual Studio) is exposed automatically, and you want to hide this, and only expose facade class (that you made) to the client? In the DLL wrapper project, go to the Solution Explorer window, in the top click second icon from the left (It says "Shows All Files"). After that, you should be able to see in your Web References folder, you WS (which was one node only), now can be expanded. Try to expand it, and expand Reference.map, and you should file Reference.cs This cs file contains WS operation that we've been talking about. If you don't want to expose it, just change all class declaration here from
publicintointernal. Therefore, only class in this wrapper DLL (in the same assembly) can access this. "If Mohammed won't go to the mountain, then the mountain must go to Mohammed" - Gil Grissom, CSI -
So you mean the automatically-generated code (by Visual Studio) is exposed automatically, and you want to hide this, and only expose facade class (that you made) to the client? In the DLL wrapper project, go to the Solution Explorer window, in the top click second icon from the left (It says "Shows All Files"). After that, you should be able to see in your Web References folder, you WS (which was one node only), now can be expanded. Try to expand it, and expand Reference.map, and you should file Reference.cs This cs file contains WS operation that we've been talking about. If you don't want to expose it, just change all class declaration here from
publicintointernal. Therefore, only class in this wrapper DLL (in the same assembly) can access this. "If Mohammed won't go to the mountain, then the mountain must go to Mohammed" - Gil Grissom, CSI