ITGumbo: spicing IT up

Hello to you, the service developer!

So, after the lengthy discussion about the need for multiple technologies, is there a good reason for it?

Beside the simple fact that this enables you to handle the same business content with multiple technologies I could see 2 more benefits:

1. When the business logic application is a legacy system, it could be not service friendly.
   You could still manage the business content of the service in the same development tool of the legacy application and let modern tools with interoperability to the legacy application to handle the service ennoblement.

2. Normally, business logic is more sustainable than technology. I think you would agree that the Purchase order content that you know, haven't changed much during all your career. Technologies do change. We are not yet finished implementing with SOAP and suddenly there comes JSON.
   If you decouple service technology from business content, you will have less work when service technology will change.

Just for nostalgia and also to prove a point, I got this Purchase order from 1937. Anyone can now compare it the Purchase order they know.

http://legacy.library.ucsf.edu/action/document/page?tid=fbn31a00

I got it from:http://legacy.library.ucsf.edu/ . This is a good site if you are interested in business archeology.

Have a good week and service well.

Yours truly,

Noam

Hello to all service enablers,

I would like to elaborate the discussion about service enabling.

It is tempting and also less work expose the service in a specific technology e.g. HTTP/SOAP.

As seen in my another post:

This should work.

The question now is: Is this satisfactory? Do you really can plan of having only a single technology?

The answer as you could expected, is NO.

In real life we are working in more than one service consumption technology. Just take the good old Purchase order. We want to query it with HTTP/SOAP for our Portal, we want to download it to a file, we want send it by mail and this just contemporary technologies that we are working with now.

The sad truth is that we accumulate legacy technologies over time and we cannot dispose them. For example: EDI, SQL views, FTP.
Should I mention more?

So, the conclusion is: for the same business content we need more than one exposure technology. That brings me to the following:

The layer of Service logic is focused only on producing and processing the service business content, the message.

The Service technology layer knows how to handle data object that could be processed by the Service logic layer.

• In case of inbound calls, the Service technology layer will handle the call and create the data object and pass it to an object in Service logic layer to process it.

• In case of outbound calls, an object in the Service logic layer will prepare the data object and will pass it to Service technology object that will handle the sending.

Have a good week and service well.

Yours truly,

Noam

Hello to all service enablers,

In the last post I discussed the service content and logic. I will return to that in future posts in greater details.

Now it is time to get more practical. Let’s have one roundtrip of development around the service block.

I will try to explain my view on the best practice of service enablement architecture.

I already discussed the difference between the application's Business logic and the Service logic. This logic separation already suggests the architecture but there is also a twist in the plot.

It should be clear by now that the Service logic is coded based on the Business logic without changing it. This would mean a layer on top of the Business logic.

First, you need to identify your Business logic layer. Naturally you would look on your application and say: there it is!

Let’s make life easy and assume that the Business logic you need resides in that single application. If there are more applications involved, you are in the cloudy zone of words like mash-ups and composites.

Back to that single application, how do you connect to the Business logic?

A bit of pessimism: it may be, that the Business logic layer is not so clear. This is typical in legacy systems and other systems that are simply not designed for API. I am sorry that I cannot give any solution here. Every case is different and every solution is innovative by itself.

The only idea I can contribute is the following diagram:

If you are lucky, you are on the tip of the arrow. If not, look for the less friendly Classes, function or database tables.

And now, to the architecture. To complete the task of service enablement.

Please note the important details:

1. The Business objects in the Business logic layer may not really exist. If you want to be ready for the future, it would be a nice idea to wrap your Assets of Business logic as objects.

2. The Service providers layer is a separate component for coding and deployment. In case of a legacy system with older technology, consider to code the Service layer in a modern technology that can interoperate with the older technology.
   Trying to use older technology for SOAP services could be frustrating but challenging.

In my next post I will show the twist in the plot that I mentioned.

Wish you all a great job and interesting projects.

Noam

Powered by Qumana

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

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