Smart clients and services

As people are absorbing the guidance around autonomous services, specifically the asynchronous communication aspects, questions about interactions with client software come up. I've been getting a lot of these questions recently. Before I dive in to the nitty gritty of smart client SOA development, I wanted to lay some foundations first.

If we accept the view that services are coarse-grained, business focused units, and that a service may be made up of numerous executables, windows and web services, and run on multiple computers, data centers, and sites - is there any reason that a service should not present an interface to a person?

Let's put down the baggage of Client-Server that we've been carrying around so long.

Maintenance "screens" belong to the service, as do all the requisite maintenance activities. It doesn't matter if they're part of a smart client, or just a web page, it is simply a part of the autonomy principle.

If these UI programs are part of the service, there would be no requirement for them to communicate using the same paradigm as external services, would there? Synchronous communication is perfectly acceptable within a service.

Let's now consider what functionality is left in the "smart client" once we've re-packaged, and re-distributed its functionality among the services that it communicates with. We'll find one of two cases:

1. Nothing's left. The smart client was all about maintenance stuff for various services. Done! Isn't that great.

2. Some business functionality is left. That's probably a good candidate for another service, don't you think? And once again we'd find the client "collapse" into the service.

3. I know I said 2, but there is another one that isn't very common or well known. I'll delve into more detail next time, but consider the case where the user/smart-client combo is a service in and of itself.

Until next time.

Posted by Udi Dahan at 04:44 PM  Permalink