Please don't do Client/Server with Smart Client technology

I'm currently talking about Smart Clients around Norway and I've been focusing on the architectural aspects of Smart Client technology. Recently Clemens posted about much the same topic.

For a long time Service Oriented Architecture has been sold as the final silver bullet by vendors and evangelists, but now the hype seems to be dying. People are seeing it for what it really is, and Clemens rephrases SOA to SO/A to make the distinction. Services are really just another level of abstraction, and exactly the same issues applies for services as for components. You need to handle your dependencies, your versioning and your agility, but on a larger scale.

Related to Smart Clients I want to make developers aware about the dangers of recreating Client/Server applications with Smart Client technologies and WebServices.

Once again Microsoft is releasing a set of killer products for software development. Visual Studio 2005 and Visual Studio Tools for Office 2005 will undoubtedly make us more productive. At the same time new flashy features may blind us into rapidly creating yet another bunch of spagetti applications with poor cohesion and high coupling.

A Smart Client with loads of dependencies to services is no better than a legacy VB6 application. Because it's all about evolvability of systems. So what do we need to do?

Well, we need to start classifying services after their need for agility and we need to view humans as services in our system topology. When humans are service end-points they will most likely be at the top of the stack in need of agility, which implies that we need to build interfaces for humans that are highly evolvable.

How do you do that? High cohesion. Low Coupling. The oldest trick in the book. How do you achieve this? By creating asynchronous task-oriented applications to interface against humans.

What is an asynchronous task-oriented application? Well, often it will be a document or a form. In some cases it might be a specialized interface of some kind but this is where Smart Clients come in. Look at VSTO2005 for example. We can now create rich logic around Word and Excel documents. We can structure the documents based on XML Schema. This provides users with a document oriented task-solving model which by nature will imply very high cohesion.

To achieve low coupling we need to start implementing flexible process and workflow tools to handle the interaction between humans and services. Right now I regard K2.NET as the most attractive product in this space on the Microsoft platform. By allowing users to work with Smart Documents (documents based on XML Schema that include some logic to assist the user in performing a business task, which essentially is a message in a business process), and store them in for example Sharepoint Libraries, K2.NET can pick them up and progress a defined process. The user will not be involved until K2.NET asynchronously pings the user the next time (if any) the user needs to be involved.

This enables very low coupling between Smart Clients and the underlying business services. In larger scenarios K2.NET might handle the interaction with humans, and pass on messages to BizTalk orchestrated processes when needed.

With such a process layer we provide ourselves with quick, easy to develop, cheap applications towards the users triggered by a task in a workflow. This enables us to rapidly replace clients with new technology or remove them to automate the task without afflicting the entire application (which in this context is the clients, the processes and the services put together).

This all requires thinking about software development in a different way, but I believe it's the only way to actually gain value of our most recent abstraction evolution, namely SO/A. SO/A distincts itself from previous shifts in that it provides technology agnostic, standardized interfaces and that the abstraction level is now very close to business-level operations. Thinking asynch and task oriented is nothing new either. Go listen to Ron Jacobs PodCasts with Clemens and Arvindra and you'll pick up Clemens' analogy with the Barnes & Noble building in New York in the late 1930's. When we worked with paper, everyone had an inbox and an outbox on their desk. All paper in the inbox needed to be a (strongly-typed) form that this person knew how to handle. Not an approved form? Rejected. Otherwise the task related to the form would be performed by the person and after some time the processed form (message) would end up in the outbox. The mail-boy would then deliver the message to the next step in the process, in the way he was instructed by management, or by evaluating instructions on the form (message).

Please don't use Smart Client technology to create Client/Server applications. It's just wrong.

3 Comments

  • Very Interesting Article. I just have a question. I'm the company IT deparment is working to develop a SOA scenario for all corporate applications. We have to deal also with legacy systems like AS/400 and Informix, so we found out that the best approach for us is SOA, but what are the expectations of this Architecture?, is it loosing trust?. Is there any other new tendence?.I just think that smart clients are a good approach, but it doesn't mean that is feasible to use it in every scenario.



    Thanks for your Article.

  • I am not in any way discarding Service Orientation as the preferred approach to encapsulate business operations. What I'm saying is that we need to handle processes between services and humans more intelligently.



    Check out my post where I've included links to a couple of slides that illustrates my point in more detail.

  • I like this post. I just think that this wouldn't be the only mechanism I'd use to enable smart clients to interact with services. Direct (but typically still async) access is also applicable where it makes sense. Is this what you would call client/server?

Comments have been disabled for this content.