Composite Smart Clients
As my previous post mentioned, the Dell smart client was an implementation of the composite smart client pattern. A composite smart client allows the client solution to be composed of a number of discrete functional pieces (modules) that are integrated together within a host environment to form a fully coherent smart client solution. The composite pattern is a very important pattern and one that we have seen a lot in enterprise line-of-business smart client solutions – Dell, Thomson Financial, Commonwealth Bank of Australia, and call center applications built on the Microsoft Customer Care Framework to name but a few.
A smart client using this architecture generally involves a shell, which provides the overall user interface structure and access to a number of smart client services, and the modules which integrate with the user interface and communicate with the shell and with each other. This kind of plug-in architecture is not a new concept – remember ActiveX controls, application add-ins and MMC plug-ins? – but the key difference here is that the modules provide business logic and functionality at a higher level of abstraction, along with a more solution oriented integration model than simple UI controls or autonomous plug-ins that don’t interact with each other.
In addition to the overall UI structure, the shell provides key smart client capabilities, such as deployment, update, data caching, offline support, etc, that all smart client solutions need. This means that the modules can leverage these capabilities instead of having to implement them themselves. This allows a solution to be developed much more quickly because the smart client infrastructure is already in place – the modules can focus on the business logic and their piece of the overall solution rather than the plumbing required to provide the smart client capabilities that all smart client solutions need.
This approach also provides a number of advantages in terms of a separation of roles between the developer of the modules themselves and the solution designer/builder. The module developers are typically focused on the implementing the business logic required to provide specific business focused functionality (for example, providing access to the inventory, CRM, ERP, HR systems, etc). The solution designers are interested in being able to define a solution to a business problem at a higher and more broadly focused level of abstraction (for example providing a call center solution, a bank teller solution, or a document collaboration solution). Software Factories and Domain Specific Languages are a perfect fit here. A DSL can be defined that builds upon the basic conceptual framework provided by this architecture and adds design time and run time tool support.
By providing DSL driven development and management tools, a solution designer (or even an end user with little or no programming experience) can literally drag-and-drop their way to a solution. They define the solution by choosing a shell and a number of modules, and then set the solution configuration parameters – for example, the deployment and update policies, user authorization and role information, the workflow characteristics that control how the modules interact and communicate with each other, etc – and then automatically deploy the solution to the web server ready for the end user to access it. This approach gives a level of flexibility and agility that even allows ad-hoc solutions to be quickly defined and deployed. Pat Helland refers to these as low-road solutions – solutions that deliver value now by providing the majority of the required functionality quickly and efficiently – as opposed to high-road solutions that require much more analysis, design and development effort for little incremental benefit.
It turns out that this kind of architecture fits extremely well into a service oriented architecture. Very often, an organization will define their web service granularity based on business function which in turn is how the IT infrastructure itself is structured. This means that there will be a family of web services for the ERP system, the CRM system, the inventory systems, etc. This is a natural way for a service oriented architecture to be developed and to evolve. Solutions are then built on top of these services, or on composites of these services, leading to form so-called ‘composite solutions’. Each service typically needs a certain amount of know-how on the client side so that the service can be leveraged properly - for example, so that the client can gather the right security credentials, perform appropriate data caching, handle the semantics of dealing with the service in terms of tentative and cancelable operations, etc. Typically, the client-side piece of logic that handles these issues for a service is known as a service agent (Pat Helland used to call these ‘emissaries’).
There is a natural correspondence between the service agents and the modules that make up a composite smart client solution. This architecture allows the developers of the business capabilities, and the web services that expose them, to develop the user interface and client-side logic that can take maximum advantage of those services. Imagine, not only would you have a menu of business capabilities and web services to choose from, but a menu of client-side service agents that allow you to construct a composite client solution quickly and easily.
Since the modules that make up the client-side solution are loosely coupled (that is, there is no hard dependency between them since the shell provides a standard but simple mechanism for them to interact with each other), these modules can be independently updated and developed. We are effectively extending the benefits of loose coupling to the client. Of course, not all services will be integrated and coordinated on the client (for transactional, availability and reliability reasons) but many can be, and those that can’t can be implemented behind a façade service that uses a server-side orchestration engine such as BizTalk to coordinate these services on behalf of the client.
Not all smart client solutions are best served by this architecture of course. Solutions that require absolute control of their constituent components and their interaction with each other, or smart client solutions that are built on top of Microsoft Office using something like Information Bridge Framework, would be architected in a different way.
However, once an infrastructure is in place that allows a solution to be defined in terms of a number of discrete modules, allows policy and configuration information to be specified that binds them all together, and which automatically manages the deployment and update of the whole thing to the client, some pretty exciting scenarios are possible.
Modules are essentially made up from a number of file based artifacts – typically assemblies and executable code and resources, but they can also include documents, document templates, InfoPath forms, etc. In this way we can compose document or Office oriented solutions by managing the deployment of families of documents, templates, and forms to the client, along with the necessary client-side logic to integrate them with a service oriented environment.
For example, we could use the infrastructure to deliver and manage the deployment of VSTO enabled Office documents, InfoPath forms, Excel spreadsheets or even PowerPoint files that contains snapshots of corporate data. For the latter, we can pro-actively manage these documents and update the data or delete the documents as the data or logic they contain becomes too stale or out of date.
And here’s another powerful scenario – we can use this architecture to deliver and manage integrated Office solutions that provide a coordinated task-oriented user experience that integrates a number of Office applications. In that case, the ‘shell’ would be a system tray based application that provides coordination and smart client services to the Office applications. This is an important feature – the shell can provide data caching, offline and workflow support to the solution while it take full advantage of the power of the Office suite and the individual applications that it contains. This is exactly the architecture that GeneriCo is built on. That app uses the various applications to complete human resource type tasks which are launched from Outlook but involve InfoPath, Excel and Word, etc, all integrated in a task-oriented way.
So are composite smart clients the future of smart clients? I think they are a large part of it. We still have to think through how mobile smart clients can benefit fully from this approach – their requirements are slightly different but there are a lot of overlaps too. This architecture is so compelling that we are planning on producing a Patterns and Practices application block to support this architecture. The block will provide the client-side and server-side infrastructure to support this model. Watch this space for more news on this…
Comments
Anonymous
March 09, 2005
I saw a mention of Smart Client Composite Application Block in Tom Hollander's web log and this one also discusses the Composite pattern. Is the composite App Block available or if not any idea when?Anonymous
March 09, 2005
The Composite Smart Client Application Block is not yet available but will provide direct support for this mode. Watch this space - I'll post more information when the block becomes available.Anonymous
May 19, 2005
Further to my recent post on the composite smart client pattern, I am happy to announce that Microsoft...Anonymous
July 05, 2005
The Community Tech Preview (CTP) of the CompositeUI Application Block has shipped! Download it today...Anonymous
July 05, 2005
The Community Tech Preview (CTP) of the CompositeUI Application Block has shipped! Download it today...Anonymous
June 05, 2007
Well, it's been over a year since I last blogged about client application development on the .NET Framework.Anonymous
June 05, 2007
PingBack from http://msdnrss.thecoderblogs.com/2007/06/05/introducing-acropolis/