Webservices, Interfaces and Polymorphism in proxy classes.

J

JupiterMoonBeam

Hello,

I wonder if anyone can help.

As a rule I have a design policy of programming to interfaces
especially with 'data' classes. I like a client to be responsible for
implementing its own version of classes it sends to a service rather
than the service dictating what the class should be. This provides
immense flexibility and is a good practice. For example in a web
application if I need to submit a login I have a service with the
method:

public bool Logon(ILogonCredentials);

And then on the web page I can do:
public class MyPage: ILogonCredentials
{
public string ILogonCredentials.UserName
{
get { return UserNameTextBox.Text; }
}

public string ILogonCredentials.Password
{
get { return PasswordTextBox.Text; }
}

public void LogonOnClick(...)
{
LogonService.Logon(this);
}
}

There are also other reasons for doing this as I can implement
different class logic in web apps over desktop apps etc.

The problem I am having is trying to establish how to do this with web
services. I understand that the web service itself MUST implement a
real class to desirialize the request to but when I add a web reference
in VisualStudio 2005 I want to be given interfaces for the objects that
are serialized/deserialized between the service and client (though not
for the service itself) so I can be free to use the benefits of
polymorphism and have multiple implementations of the interfaces
through my clients.

I know it's completely technically possible to do as I have do it
easily by editing the auto generated code but this is a BAD thing (as
VS will just nuke it at will) and I don't want to be having to manually
write my proxy's with all the events and yuk yuk yuk.

Any help would be GREATLY appreciated: I wan't to use some OOP
techniques in a OOP language and I know it must be possible I just need
the secret key.

Many thanks in advance.
 
D

David Jessee

I've run into this myself. And yes...I've jumped through hoops to get it to
work.

With web services, the only interface you REALLY have is the WSDL contract
from the client to the server. In reality the server could be in Java, or
some other language so, by the nature of how web services work, you really
shouldn't be using a .NET interface to enforce the design pattern because you
don't know what the server technology is. This is why, when you set the
reference in Studio, it creates the client class as well as all types that
need to be used. If you're trying to use the same library on the client and
server (e.g. a customer object returned from a web method) you end up with 2
customer types....the type you defined and the type that was generated when
the reference was set via the wsdl tool.

But, I'm with you, I want an interface, mostly because if I'm programming
against interfaces, I can enforce the contract at the code level and also
create proxy server classes for testing purposes.

So, what's the solution??

There isn't really a good one. In most of these cases, I ended up using
Remoting instead and then creating web services that are used by client that
I do not have control over. Web services don't really have that much to do
with OOP, so if you try to take a strict OOP approach, you're going to get a
couple bumps in the road.

The only solution I've been able to come up with is:
1) execute the wsdl.exe tool manually, supplying parameters that tell the
runtime which .NET types map to the different SOAP types. This allows you to
use the same library on the client and the server.
2) Create a Wrapper Class that implements the appropriate interface. The
wrapper class would simply delegate the calls to the generated client class
generated by the WSDL tool. This way, your code sees the wrapper, which
defines Interface X

Hairy, I know....
 
J

JupiterMoonBeam

Damn, how irritating.

David: I completely agree that WS are not strictly OOP but the code on
the client is. All the proxy class is as far as .NET is concerned is a
serializable class (default constructor, public getters and setters)
nothing else. Based on that I can see no reason why it shouldn't be
possible to tell .NET to generate interfaces.

The wierd thing is that you can get wsdl.exe to generate interfaces for
the main proxy class which represents the web service body (method
calls etc.) but not the classes passed in parameters, which, quite
frankly is a bit crazy because:
1 wsdl.exe does a faily good job at handling all the wiring and
ugliness of implementing the code (events etc.) to call a WS
2. its really the 'business objects' that are more likely to change
implementation based on the client.

Also, I should clarify that I am only concerned with the client - I
only want the client to implement the parameter objects as interfaces.
As already stated, in a web service as a best practice these should
only truly be data objects with values only which in .NET means a
serializable class therefore I cannot understand why it is not possible
to use an interface on the client?

The most irritating thing is if MS really have such an issue with
interfaces why couldn't they have made the properties virtual so I
could at lease override their behaviour?

Daniel: Wrappers, I know I've thought that too but the issue there is
I have to create a new object for every request. This is on a web app
with potentially a few hundred simultaneous users and a lot of requests
to the WS - the GC is gonna have a field day!

As a last requests does anyone know of any modified/similar tool to
WSDL.EXE I could use to generate the code with interfaces or David how
do I get WSDL just to share my types from an existing assembly?
 
M

meghal247

Have you tried using SVCUtil? That one generates interfaces. I have not
read all the posts in this thread in detail, so my apologies if my
reply is off.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,537
Members
45,021
Latest member
AkilahJaim

Latest Threads

Top