locked
Problem with Webservice & Typed Dataset(xsd)

    Question

  • I have a Webservice webmethod which takes a typed dataset as a parameter. And i have all my webservices defined under one project and classes which calls these webservice are placed in other projects of the same solution.

    But one problem i have been seeing was whenever i update the Webservice reference, the reference file instead of refering to the already existing Entity(.xsd) passed to it, it creates one in the the reference file of the webservice project and then it throws an error saying failed to convert the actual entity to the entity it created in the reference.

    The way i was handling this problem so far was , when ever i update the webreference i was commenting out the entity it creates in the referece.cs and create a reference to my actual entity which works fine. But the problem is whenver somebody updates the web reference same problem arises and they may not know that they have to comment out the entity in the reference.cs to get it working.


    Its really frustrating to tackle this. Another work around i found for this is to change the Webmethod signature to accept a normal dataset , but still pass a typed dataset, once its in the webmethod i am doing a dataset merge to my actual entity and proceeding with my actual entity from there. This one works fine even if someone updates the reference in future.

    But my question is why cannot i pass a typed dataset to the webservice without these problems. Why is this not strait forward? did any one run into same issue before? (I am using VS2005)



    Tuesday, May 19, 2009 3:09 PM

Answers

  • Remember again that web services are meant to be cross-platform. This means (roughly) that any true statement about web services should also be true when the service is .NET and the client is Java.

    But consider the statement "the service requires a parameter of type System.String, so the client sends it a parameter of type System.String". This statement is true for .NET but not for Java. In fact, a Java client will send a Java string. How could this possibly ever work?

    It works because the Java client sends a Java string, which the Java infrastructure converts into XML. The service receives XML, and parses out a System.String. It then passes that System.String instance as a parameter.

    Now, do the same exercise with your typed dataset. Obviously, a Java client will not be able to have the exact same typed dataset as a .NET service.

    In fact, the issue is more general. Clients are not meant to have access to server code, period.

    [Lecture will continue after I get some sleep]

    John Saunders
    Use File->New Project to create Web Service Projects
    Use WCF for All New Web Service Development, instead of old ASMX or obsolete WSE
    • Marked as answer by edhickey Tuesday, June 02, 2009 8:24 PM
    Friday, May 29, 2009 3:27 AM
    Moderator

All replies

  • Please see Basics: How Web Services Work and maybe How to Consume a Web Service to understand why the type on the server is not meant to be the same as the type on the client.

    Also, I assume you're aware that passing types specific to .NET limits you to .NET clients, but I'm adding this for others who may read this.

    John Saunders
    Use File->New Project to create Web Service Projects
    Use WCF for All New Web Service Development, instead of old ASMX or obsolete WSE
    • Marked as answer by edhickey Tuesday, May 26, 2009 6:51 PM
    • Unmarked as answer by WorkaholicDude Tuesday, May 26, 2009 7:10 PM
    Tuesday, May 19, 2009 4:02 PM
    Moderator
  • Hey John,

    Do you mean to say that Webmethod signature should never match with the call?

    Say there is a webmethod with just one parameter string. I think i was always able to call that webservice by passing a string paramter. It was same for all other types. Only problem i had so far is with the TypedDataset. (For which i had to change the Webmethod signature to accept a normal dataset instead of typed dataset and then do the conversion there in the Webmethod to convert to the relevant typed dataset).

    Eg

    [

    WebMethod]
    public string Task(DataSet ds)
    {
    //need to convert the dataset to the entity
    TaskEntity te = new TaskEntity();
    te.Merge(ds);
    }


    //Client Call
    TaskEntity te = new TaskEntity();
    //populate te
    Webservice ms = new Webservice();
    ms.Task(te);
    Tuesday, May 26, 2009 7:18 PM
  • Remember again that web services are meant to be cross-platform. This means (roughly) that any true statement about web services should also be true when the service is .NET and the client is Java.

    But consider the statement "the service requires a parameter of type System.String, so the client sends it a parameter of type System.String". This statement is true for .NET but not for Java. In fact, a Java client will send a Java string. How could this possibly ever work?

    It works because the Java client sends a Java string, which the Java infrastructure converts into XML. The service receives XML, and parses out a System.String. It then passes that System.String instance as a parameter.

    Now, do the same exercise with your typed dataset. Obviously, a Java client will not be able to have the exact same typed dataset as a .NET service.

    In fact, the issue is more general. Clients are not meant to have access to server code, period.

    [Lecture will continue after I get some sleep]

    John Saunders
    Use File->New Project to create Web Service Projects
    Use WCF for All New Web Service Development, instead of old ASMX or obsolete WSE
    • Marked as answer by edhickey Tuesday, June 02, 2009 8:24 PM
    Friday, May 29, 2009 3:27 AM
    Moderator