Conversive Services Part 2

In my last post I talked about the concept of dynamic services holding a conversation to achieve a goal rather than just the usual request and response service calls that many of us are familiar with.

Why bother to hold a conversation between services?

Well, when two people meet for the first time it is good to get to know one another. What interests both parties have in common or an exchange of ideas and opinions. In system terms it is good to get to know the service consumer so that you understand them better and can put their requests into context.

In the previous post I discussed the example of a currency service not being able to convert two currencies. In this example the service can identify the context, monetry conversion for going on holiday, and make a decision on how to handle the request. If the request, as in this case, is obviously for tourism, then the service may behave in one of several ways.

1. It may decide that it should not process obvious tourism related requests (based on context) and redirect the consumer elsewhere.
2. It may gracefully redirect the consumer to an affiliate service that can process the request once it discovers that it cannot convert the currencies.
3. It may log the context, the type of exception and then reply gracefully that it does not understand the consumers request.

This requires two things.

1. Intelligent services that can be configured to understand not only the request but the context of that request so that it can decide if it is the best agent to carry out the task.
2. Intelligent consumers that can communicate with and manage connections with intelligent services.

The next part of this blog will cover how services and consumers can find one another.

Stay tuned.

Conversive Services

Recently there has been some dicussion about the merits of SOA as an approach for building a new lagacy of systems (and I do mean legacy unfortunately).

Am I a big fan of SOA as it stands at present? Not really, but this does not mean that it cannot be a great asset in the future. The basic set of principles seem reasonably sound, but I do not yet believe that there is a level of maturity in either the current technology or in the understanding of those who preach it.

Why am I not convinced?

For me, the whole concept of a service is that it should be kept loose. By binding a service to a contract, we can choose the service that we want to use, if and only if, it supports a predetermined contract. This sounds rather tight to me. Okay, so I have choice over which service I use that supports a given interface, but if it later changes its contract then I am in deep trouble!

Now lets try to think differently. Imagine I want to convert Dollars to Euros.

1. I search for services that convert currencies.
2. I pass the values that I expect to be converted to a selected service.
3. I receive back an exchange rate.

Simple.

Now lets view this task as a conversation.

1. (Me) Do you convert currencies?
2. (Service) Yes I do. Why do you need the conversion?
3. (Me) I am going on my holidays.
4. (Service) What curencies would you like to convert?
5. (Me) Dollars to Euros.
6. (Service) How many Dollars need converting?
7. (Me) 200 Dollars.
8. (Service) 200 Dollars is worth 100 Euros.
9. (Me) Thank you.

Ah, what is going on? How have we managed to make such a long winded process out of what should be a very simple procedure? Well what happens if the service I am talking to can convert currencies, but not the ones that I want it to convert? The contract would be sound but I would still generate an exception in real terms. Conversive services aim to address this and many other issues associated with the contract based approach to services.

Over the next few posts I will explain why I think that this level of communication between services is necessary and hopefully get some bench time to code some examples.