ITGumbo: spicing IT up

Hello you Service oriented designers,

Today I would like to discuss a very basic issues that could sound trivial.

When we decide to expose something as a service, what exactly do we expose?

Normally, you have some application or engine that has the functionality you want to expose.

For example, you want to expose the ability to create a Sales order over the web. So, design a message for the service.

Now is the time to think, do you expose the Sales order as it appears in the server or maybe in the UI?

Usually these alternatives are far from each other.

• The server side Sales order has a normalized data structure including the separation of Product and Customer to different objects.

• The UI Sales order is aimed for the user comfort and not keeping any strict data design rules.

Sometimes it seems that requirements are clear because they came directly from the service consumer. This is very tempting but you have to think about reusability of the service. What another consumer would need a similar service but with slightly different Response?

So, back again, what will you expose?

I would like to suggest the following approach:

1. Think as a UI designer. The UI designer thinks about the end users and the way they would work with the  system. You are the "UI" designer for your fellow developers that will consume the service.

   • Think about usability How easy it would be to understand what the service is actually doing.

   • Are the data types you use in the Request and Response clear? Use known terms, not internal terms.

   • Do you provide enough content in the Response?

2. Think about the use case you are solving. There are different ways to expose a service for "Create Sales order"

   • For B2B, you will probably add more information to the data type such as Product name and description.

   • For A2A, you could assume some common master data repository, so the Product could be represented only by its key.

3. Try to guess the future requirement from that service. Making the service more genric will increase its reusability and reduce any future changes.

4.  And finally, review your service with colleagues that are not developers, preferably, product managers. They will be able to rate the usability from the business point of view.

In my next post, I will talk more about the implementation regarding service exposure.

Best wishes,

Noam