locked
Service Contract Design RRS feed

  • Question

  •  

    What are peoples thoughts on the following designs for a service contract?

     

    1) Should the interface always use the action request / response approach wrapping request and return data in another type?

     

    Code Snippet

    public interface ISomeService

    {

       SomeActionResponse SomeAction(SomeActionRequest someActionRequest);

       AnotherActionResponse AnotherAction();

       void DoSomething(DoSomethingRequest doSomethingRequest);

    }

     

     

    2) Or is OK to have a mixed approach?

     

    Code Snippet

    public interface ISomeSevice

    {

    SomeActionResponse SomeAction(SomeActionRequest someActionRequest);

    AnotherActionResponse AnotherAction();

    Person[] GetAllEmployees();

    }

     

     

    Sometimes it seems unnecessary to wrap requests and response in another type.  But should I really adopt a consistent approach across the service?

     

    Any thoughts...?

    Thursday, August 16, 2007 4:59 PM

Answers

  • Many will argue different viewpoints on whether its right now wrong but I think a good portion of this type of application end up with a CRUD style service layer design. Mostly because its the most simple to begin with. Most of the tools generate things for it and people moving from other architectures into SOA still tend to use what they know and what they are comfortable with.

     

    Usually CRUD style APIs on services are somewhat unusable by other applications within an enterprise and security becomes a huge factor as you've just exposed all of data to an externally accessible API.

     

    If you go this route, watch for chattiness. You don't want 40 calls that could be handled in a single call. Crossing any type of explicit boundary is very expensive. You also don't want to hold on to the data so long that you make one call with 30 MB of data Smile So, try to manage your cache on the smart client side as much as possible - make service calls only when you need them and have a look at WCF/WSE security.

     

    And yse, I have seen a mix of both which usually revolved around how the call would be used in the context of the entire applications operation. Generally I tend to favor the Message/Response style for business process oriented APIs. The tough part is trying to fit application specific calls within a message request/response scenario. A lot of the times it can't be done. Now, if you were to design your service truly as a stand alone service then base your application off of what the service could provide - things would be different. Is your service the application you're building or is the service just another layer in a N-Tier design?  That drives the design quite a bit. See what i mean?

    Friday, August 17, 2007 12:43 PM

All replies

  • If I understand you correctly, you are asking about whether or not you should return a generic datatype (e.g. dataset) vs a specific datatype (e.g. object collection).

    From personal experience, Object collections are better and specific responses usially make it easier to work from the client.

    Generic responses on the other hand are goo if your frontend will access your service throught a gateway that will expose only a generic interface.

     

    I hope this was helpful, if not please clarify more.

     

    Thursday, August 16, 2007 5:57 PM
  • Hi,

     

    Not exactly.  In examples I've seen people often wrap service methods with a message type for the request and response.

     

    For Example: http://www.thinktecture.com/resourcearchive/tools-and-software/wscf/wscf-walkthrough

     

    In the above example you have messages such as GetRestaurantsResponse.  This contains a RestaurantInfoCollection type.  Rather than just returning the type RestaurantInfoCollection.

     

    Does this make sense?

    Thursday, August 16, 2007 6:38 PM
  • I think there are several topics/arguments here.

     

    One is a messaging style interface versus a more RPC style interface.

    GetAllRestaurants() , UpdateRestaurant(), GetRestaurantParkingLot() type APIs tend to be chatty and are something you'd see in a 3 tier architecture without services as you transfer data from a data tier up to a business logic layer. These designs usually pass data using business entities representing the data.

     

    Messaging and Response objects deal with the same data you'd find in a entity but in a different way - you design how you want things returned and how you expect things in your method call. You don't really pass around business entities but messages which contain specific data. These designs are more specific and tend to be more business process oriented instead of data oriented.

     

    Inside of a response message you could also represent your data with data transport objects to abstract your actual operation business entities. Changes to contracts wouldn't really effect the entitites and changes to entities may/may not have as much of an impact on your data contracts (DTOs). It just gives you a little bit of more loosely coupled design.

     

    I guess the main question back to you is, what is it that you are trying to achieve? Are you trying to expose data via services? Are you trying to kick off different business processes and have responses that let you know the process succeeded, started,etc.?

     

     

    Friday, August 17, 2007 4:19 AM
  • Hi,

     

    I'm just trying to expose data via services really.  These services will support a smart client application written using the Smart Client Software Factory.

    Friday, August 17, 2007 5:59 AM
  • Many will argue different viewpoints on whether its right now wrong but I think a good portion of this type of application end up with a CRUD style service layer design. Mostly because its the most simple to begin with. Most of the tools generate things for it and people moving from other architectures into SOA still tend to use what they know and what they are comfortable with.

     

    Usually CRUD style APIs on services are somewhat unusable by other applications within an enterprise and security becomes a huge factor as you've just exposed all of data to an externally accessible API.

     

    If you go this route, watch for chattiness. You don't want 40 calls that could be handled in a single call. Crossing any type of explicit boundary is very expensive. You also don't want to hold on to the data so long that you make one call with 30 MB of data Smile So, try to manage your cache on the smart client side as much as possible - make service calls only when you need them and have a look at WCF/WSE security.

     

    And yse, I have seen a mix of both which usually revolved around how the call would be used in the context of the entire applications operation. Generally I tend to favor the Message/Response style for business process oriented APIs. The tough part is trying to fit application specific calls within a message request/response scenario. A lot of the times it can't be done. Now, if you were to design your service truly as a stand alone service then base your application off of what the service could provide - things would be different. Is your service the application you're building or is the service just another layer in a N-Tier design?  That drives the design quite a bit. See what i mean?

    Friday, August 17, 2007 12:43 PM