July 11, 2008 7:54 AM
The logic behind the service
Hello to the service creators,
I would like to follow-up my previous post and elaborate on the service design and implementation.
Let's take the "Create Sales order" service. After the decision about what data would be used in the service message, there is the time to find how to process it.
When you create a simple Sales order you have the header with dates, addresses, totals and customer data. On the order lines you would have the products, prices and quantity.
Let's focus on the header. How would the customer be represented in the message?
Basically, there are 2 alternatives:
- With the required customer data such as Name, address, phone etc. This is comprehensive approach but costly.
- With a customer key. This is good only if you have created the Customer first and also shared the data with the service consumer.
Actually in a generic design, both alternatives should be used.
So what next? Now it is the time to design the service provider.
First you need to allocate the underlying business objects. That could vary from database tables and up to a set of classes that manage the business object.
In our example it would be at least: Sales order, Customer and Product.
Why don't we just expose each business object and let the consumer decide what to do?
The answer is simple, there is some logic that we know about in the underlying business objects. This logic originate from the associations between those and required validation and other functionality. For example, we do not want to confuse our service consumer with questions like: Is the order total comply to the Customers profile? We normally do not want to expose the fact that we have a Customer profile.
We want to keep the control of that logic and make the consumer work easier.
So, I would like to suggest the term: Service logic. This is the logic that is specific for the service functionality while based on the underlying business logic.
In my previous post I mentioned the resembles to UI design. So, if there is UI logic, there should be Service logic.
In my next post I will elaborate on the technical implementation that is derived from this.
I have a small request, I would like to discuss these ideas. If you feel that this is new, old, trivial, fantastic or any other opinion, I would like to read it in the comment.
Thanks for your interest,
Noam


