Casting a WebService instance to a custom interface
-
Heres an interesing (I hope) question The short version of the question: Is it possible to cast an instance of a WebService reference to an custom interface (the webservice contains the methods as defined in the interface) The long version: I have an application framework that consists of the following key components: (A) Client API (B) Server WebService (C) Server Remoting Listener / Application In runtime, the Client API pushes requests onto the Server WebService, which inturn pushes them onto the Server Remoting Listener / Application. So as an example the Client API exposes a
DoSomethingmethod which calls theDoSomethingweb service method, which calls theDoSomethingServer Remoting Listener / Application method, the return value of which is returned back up the tree. In order to maintain a degree of control (and for remoting) all of these components use a common interface, i.e.public interface IFrameworkMethods
{
int DoSomething();
}The reason for all these degrees of seperation is that typically all three components are on different devices to split the load across the enterprise. For reasons of policy connectivity from client to server farm must be across HTTP however within the farm I can use remoting. All decisions that cannot be changed. Now heres the question: Under some configurations the Client API and Server Remoting Listener / Application are on the same device. As such it seems sensible to not take the performance hit of performing a HTTP post to localhost, and to push the requests directly onto the local listener. In the first run of the code, I simply did something like this:
public int DoSomething()
{
int resultCode = 0;if (directRemotingAvailable)
{
//create necessary remoting objects
resultCode = remotingObject.DoSomething();
}
else
{
//create necessary web service access objects
resultCode = webServiceObject.DoSomething();
}return resultCode;
}This obviously works, but this API exposes alot of methods so it is alot of if/else and bloat. Which got me thinking, I am using the interface for remoting, so why not use the interface defintion for the webservice as well. So my Client API method now looks something like this:
public int DoSomething()
{
IFrameworkMethods obj = GetInterface();
int resultCode = obj.DoSomething();
}private IFrameworkMethods GetInterface()
{
IFrameworkMethods obj = n -
Heres an interesing (I hope) question The short version of the question: Is it possible to cast an instance of a WebService reference to an custom interface (the webservice contains the methods as defined in the interface) The long version: I have an application framework that consists of the following key components: (A) Client API (B) Server WebService (C) Server Remoting Listener / Application In runtime, the Client API pushes requests onto the Server WebService, which inturn pushes them onto the Server Remoting Listener / Application. So as an example the Client API exposes a
DoSomethingmethod which calls theDoSomethingweb service method, which calls theDoSomethingServer Remoting Listener / Application method, the return value of which is returned back up the tree. In order to maintain a degree of control (and for remoting) all of these components use a common interface, i.e.public interface IFrameworkMethods
{
int DoSomething();
}The reason for all these degrees of seperation is that typically all three components are on different devices to split the load across the enterprise. For reasons of policy connectivity from client to server farm must be across HTTP however within the farm I can use remoting. All decisions that cannot be changed. Now heres the question: Under some configurations the Client API and Server Remoting Listener / Application are on the same device. As such it seems sensible to not take the performance hit of performing a HTTP post to localhost, and to push the requests directly onto the local listener. In the first run of the code, I simply did something like this:
public int DoSomething()
{
int resultCode = 0;if (directRemotingAvailable)
{
//create necessary remoting objects
resultCode = remotingObject.DoSomething();
}
else
{
//create necessary web service access objects
resultCode = webServiceObject.DoSomething();
}return resultCode;
}This obviously works, but this API exposes alot of methods so it is alot of if/else and bloat. Which got me thinking, I am using the interface for remoting, so why not use the interface defintion for the webservice as well. So my Client API method now looks something like this:
public int DoSomething()
{
IFrameworkMethods obj = GetInterface();
int resultCode = obj.DoSomething();
}private IFrameworkMethods GetInterface()
{
IFrameworkMethods obj = nMrEyes wrote:
Is it possible to cast an instance of a WebService reference to an custom interface (the webservice contains the methods as defined in the interface)
What methods it exposes has nothing to do with what "type" it is. You can only cast an object to a type that it is or implements in the case of interfaces, period. I strongly urge you to study software development material until you gain a more comprehensive understanding of fundamental concepts like this one before you develop production software.
-
MrEyes wrote:
Is it possible to cast an instance of a WebService reference to an custom interface (the webservice contains the methods as defined in the interface)
What methods it exposes has nothing to do with what "type" it is. You can only cast an object to a type that it is or implements in the case of interfaces, period. I strongly urge you to study software development material until you gain a more comprehensive understanding of fundamental concepts like this one before you develop production software.
led mike wrote:
I strongly urge you to study software development material until you gain a more comprehensive understanding of fundamental concepts like this one before you develop production software.
Great piece of advice, however serves absolutely no purpose beyond hobbiests, classrooms and virgin standalone projects. When working in the real world of a preexisting production application framework that is currently deployed to around a 15 thousand servers, over a 200 thousand clients and has prooved to be extremely reliable and profitable, I find that rewriting and redeploying is, shall we say, a tad stupid. There are many ways to meet a development challenge, unforutunalty many professional developers loose sight of the fact that they exist to serve end users not their own foibles and technical curiosity. As long as the result meets requirements and specifications and is supportable, usable, maintainable and scalable; I absolutley don't care if its architecture doesnt meet the current flavour of the day. Bottom line, rant over, I have found a solution, it works. Of to read some books, maybe, hmmm, The very Hungry Caterpillar :| P.S. For anybody who is interested the solution is to create a wrapper around the webservice object that also uses the interface. When the WS interface is needed the main worker class creates/reuses an instance of the WS wrapper/proxy that can now be cast to the interface type and called using the same code that calls the remoting interface. Logic must exist within the wrapper/proxy to set initial params (i.e. url, timeout etc)
-
led mike wrote:
I strongly urge you to study software development material until you gain a more comprehensive understanding of fundamental concepts like this one before you develop production software.
Great piece of advice, however serves absolutely no purpose beyond hobbiests, classrooms and virgin standalone projects. When working in the real world of a preexisting production application framework that is currently deployed to around a 15 thousand servers, over a 200 thousand clients and has prooved to be extremely reliable and profitable, I find that rewriting and redeploying is, shall we say, a tad stupid. There are many ways to meet a development challenge, unforutunalty many professional developers loose sight of the fact that they exist to serve end users not their own foibles and technical curiosity. As long as the result meets requirements and specifications and is supportable, usable, maintainable and scalable; I absolutley don't care if its architecture doesnt meet the current flavour of the day. Bottom line, rant over, I have found a solution, it works. Of to read some books, maybe, hmmm, The very Hungry Caterpillar :| P.S. For anybody who is interested the solution is to create a wrapper around the webservice object that also uses the interface. When the WS interface is needed the main worker class creates/reuses an instance of the WS wrapper/proxy that can now be cast to the interface type and called using the same code that calls the remoting interface. Logic must exist within the wrapper/proxy to set initial params (i.e. url, timeout etc)
MrEyes wrote:
P.S. For anybody who is interested the solution is
So the solution wasn't casting the WebService object to the interface because of what I stated, right?
MrEyes wrote:
Bottom line, rant over
MrEyes wrote:
I absolutley don't care if its architecture doesnt meet the current flavour of the day.
What did my post have to do with architecture?