ITGumbo: spicing IT up

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