locked
setting up a service contract for java or .net clients RRS feed

  • Question

  •  

    In order to not break existing apps (not really 'break', but cause fewer changes), I would like to have a service return a .net dataset or datatable. I also want to create a  List of the custom objects for use in non -.net clients. I know, in one of the WCF books that I'm reading it says (paraphrase), 'if you are returning datasets, you should rethink your SOA strategy and use of services all together', but I think in the interest of adoption at this organization, it would be good to do just that.

     

    So, the question is, can I return .net specific types such as datasets / datatables in the service contract implementation and still have non -.net clients be able to call the service, just using the methods that don't return datasets? Or, should I create separate service contracts?

    Wednesday, October 3, 2007 6:58 PM

Answers

  • My 2 cents: this is a perfectly fine thing to do. You can make this separation even more explicit by exposing the dataset/datatable version over one of the Net*Bindings (Tcp, Msmq, etc. as appropriate). Expose a separate endpoint using DataContract/List.

     

    Please make sure to do at least this much: the DataContract/List version should consume your ADO.NET friendly version such that it ONLY does the transformation. Do this by having an internal class actually fetch the DataSet. Then, your dataset friendly endpoint has an implementation something like this:

     

    Code Block

    public DataSet MyDataGetter(params)

    {

    MyInternalObject obj = new MyInternalObject();

    obj.DoWorkWithParams(params);

    return obj.GetData();

    }

     

     

    Make this a one-liner if possible.

     

    then, your 'non .NET friendly version is this:

     

    Code Block

    public List<MyDataType> MyDataGetter(params)

    {

    MyInternalObject obj = new MyInternalObject();

    obj.DoWorkWithParams(params);

    DataSet ds = obj.GetData();

     

    // Code to convert ds-->List<MyDataType>

    return listOfMyDataType;

    }

     

     

    If I had to come along and maintain this code later, I'd rather see all the .NET specific stuff in one ServiceContract, all the 'interop' stuff in another ServiceContract, just so that my consumers would have a cleaner view of the world and would know which version to use and wouldn't have to focus on which Operations to use.

     

    Does this help?

     

     

    Wednesday, October 3, 2007 10:16 PM

All replies

  • My 2 cents: this is a perfectly fine thing to do. You can make this separation even more explicit by exposing the dataset/datatable version over one of the Net*Bindings (Tcp, Msmq, etc. as appropriate). Expose a separate endpoint using DataContract/List.

     

    Please make sure to do at least this much: the DataContract/List version should consume your ADO.NET friendly version such that it ONLY does the transformation. Do this by having an internal class actually fetch the DataSet. Then, your dataset friendly endpoint has an implementation something like this:

     

    Code Block

    public DataSet MyDataGetter(params)

    {

    MyInternalObject obj = new MyInternalObject();

    obj.DoWorkWithParams(params);

    return obj.GetData();

    }

     

     

    Make this a one-liner if possible.

     

    then, your 'non .NET friendly version is this:

     

    Code Block

    public List<MyDataType> MyDataGetter(params)

    {

    MyInternalObject obj = new MyInternalObject();

    obj.DoWorkWithParams(params);

    DataSet ds = obj.GetData();

     

    // Code to convert ds-->List<MyDataType>

    return listOfMyDataType;

    }

     

     

    If I had to come along and maintain this code later, I'd rather see all the .NET specific stuff in one ServiceContract, all the 'interop' stuff in another ServiceContract, just so that my consumers would have a cleaner view of the world and would know which version to use and wouldn't have to focus on which Operations to use.

     

    Does this help?

     

     

    Wednesday, October 3, 2007 10:16 PM
  • Thanks. Any specific naming conventions you would follow to name these service contracts? Suffixed with Interop or Net maybe?

     

    Thursday, October 4, 2007 6:02 PM
  • I'd think you'd want to go up a level, or just down. One partitioning that may make sense is something like:

     Interop: [YourCompany].Contracts.Interop

     Net:  Interop: [YourCompany].Contracts.Net

     

    It may even make sense for the interfaces to have the same name in these cases so that one can easily identify that there should be some sort of parity between the classes and namespaces.

     

    Thursday, October 4, 2007 10:36 PM