Webservices, Interfaces and Polymorphism in proxy classes.

Discussion in 'ASP .Net Web Services' started by JupiterMoonBeam, Oct 20, 2006.

  1. 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.
     
    JupiterMoonBeam, Oct 20, 2006
    #1
    1. Advertising

  2. JupiterMoonBeam

    David Jessee Guest

    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....




    "JupiterMoonBeam" wrote:

    > 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.
    >
    >
     
    David Jessee, Oct 20, 2006
    #2
    1. Advertising

  3. JupiterMoonBeam

    Daniel P. Guest

    I solved the type sharing between the web services tier and the client app by
    writing some code that takes the object and turns it into the target object.
    Basically you have two identical types and using reflaction you create the
    target type from the source type. I did not publish the code yet but I'm
    thinking to do it in the near future:

    http://danutp.blogspot.com/2006/06/web-services-sharing-data-between.html


    "David Jessee" wrote:

    > 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....
    >
    >
    >
    >
    > "JupiterMoonBeam" wrote:
    >
    > > 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.
    > >
    > >
     
    Daniel P., Oct 20, 2006
    #3
  4. 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?

    Daniel P. wrote:
    > I solved the type sharing between the web services tier and the client app by
    > writing some code that takes the object and turns it into the target object.
    > Basically you have two identical types and using reflaction you create the
    > target type from the source type. I did not publish the code yet but I'm
    > thinking to do it in the near future:
    >
    > http://danutp.blogspot.com/2006/06/web-services-sharing-data-between.html
    >
    >
    > "David Jessee" wrote:
    >
    > > 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....
    > >
    > >
    > >
    > >
    > > "JupiterMoonBeam" wrote:
    > >
    > > > 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.
    > > >
    > > >
     
    JupiterMoonBeam, Oct 30, 2006
    #4
  5. JupiterMoonBeam

    Guest

    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.

    JupiterMoonBeam wrote:
    > 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?
    >
    > Daniel P. wrote:
    > > I solved the type sharing between the web services tier and the client app by
    > > writing some code that takes the object and turns it into the target object.
    > > Basically you have two identical types and using reflaction you create the
    > > target type from the source type. I did not publish the code yet but I'm
    > > thinking to do it in the near future:
    > >
    > > http://danutp.blogspot.com/2006/06/web-services-sharing-data-between.html
    > >
    > >
    > > "David Jessee" wrote:
    > >
    > > > 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....
    > > >
    > > >
    > > >
    > > >
    > > > "JupiterMoonBeam" wrote:
    > > >
    > > > > 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.
    > > > >
    > > > >
     
    , Dec 7, 2006
    #5
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Krivenok Dmitry
    Replies:
    13
    Views:
    1,452
    Axter
    Jun 1, 2006
  2. Replies:
    3
    Views:
    355
  3. Manish

    IE proxy settings and webservices

    Manish, Oct 8, 2003, in forum: ASP .Net Web Services
    Replies:
    0
    Views:
    157
    Manish
    Oct 8, 2003
  4. Rob Thomson

    Interfaces and webservices

    Rob Thomson, Oct 28, 2003, in forum: ASP .Net Web Services
    Replies:
    0
    Views:
    104
    Rob Thomson
    Oct 28, 2003
  5. Steve
    Replies:
    1
    Views:
    258
Loading...

Share This Page