We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Open for Business

Noam Tamarkin

The logic behind the service

user-pic
Vote 0 Votes

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:

  1. With the required customer data such as Name, address, phone etc. This is comprehensive approach but costly.
  2. 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

Leave a comment

In this blog, Noam Tamarkin provides ideas for improving and better integrating your applications.

Noam Tamarkin

Senior software architect and CTO. Experience in solution design and implementation. Holds the ability to understand complex business processes and translate them to technology. Expert in Enterprise applications, integration, SOA, SaaS. Experienced in project management, technical infrastructure, procurement and manufacturing.

Subscribe

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT