There is no single right answer to this question. In fact, for any given service interface you can probably find five designers with five different opinions on the "right" way to define the interface. Here are a couple of the rules I apply to the problem. First I want a single "service" to be meaningful in my world view. That is, if I think of my world as made up of customers and orders, I?d like to have services that correspond to customers and orders. I don?t think of it as a customer lookup service and a customer update service. Sometimes you can get yourself in trouble with this model when you are building from the bottom up. For instance, you design an address service, a salary service and job description service. Now you discover what you really want is an employee service. In some sense your world view has changed and your interface must adapt to that change. You have to "combine" these smaller services into a larger one that both makes logical sense and can be more efficient (because I can make one request rather than requesting each of the components individually). I usually try to minimize performance considerations in these interface definitions. For example, I need to route various customer requests to different servers because I have a heavy load. Rather than having several functional interfaces that can be partitioned I think it is better to leave the customer interface alone and use your underlying Web services infrastructure to figure out where each request should go. This will insulate the changes required to improve performance from the logical interfaces used by your Web services-based applications.
Dig Deeper on Topics Archive
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.