Skip to content

DBAzine.com

Sections
Personal tools
You are here: Home » SQL Server » SQL Server Articles Archive » Creating and Deploying a Smart Client with Plug-Ins - Part 1
Seeking new owner for this high-traffic DBAzine.com site.
Tap into the potential of this DBA community to expand your business! Interested? Contact us today.
Who Are You?
I am a:
Mainframe True Believer
Distributed Fast-tracker

[ Results | Polls ]
Votes : 3554
 

Creating and Deploying a Smart Client with Plug-Ins - Part 1

by Eric Charran

Part 1  |  Part 2

Introduction

Smart Clients exist as a type of application that combines the richness and full-featured functionality of a thick client application with the benefits and ease of management of a thin client application. Microsoft’s .NET framework provides the ability to craft applications as Windows forms projects and ensure that they enjoy the benefits of traditional Internet applications. In the past, much application development migrated from older Visual Basic 6.0 thick clients to Internet applications. Their ubiquitous access, ease of management and deployment without a significant client footprint provided a significant lure for quick and easy application development to disperse client bases and geographies.

What businesses gave up are the benefits of a rich user experience. While the Internet provided much of the logistical benefit, businesses realized that the trade-off was a less functional and feature-rich interface. The majority of application processing occurred on the server so local processing and client resources could not be counted on. Thus application architects had to be wary of how much processing application activities required and had to design around these constraints.

Smart Clients provide a desirable cross-section of these two diametrically opposed types of applications. Because Smart Clients natively support no-touch deployment, the benefits of the logistical ubiquity of the Internet application are maintained. Additionally, these applications can supply a responsive, rich and sophisticated interface and utilize the resources of the client to work in a connected or disconnected fashion.

Because of these benefits introduced by Smart Client technology in .NET, developers can now create Windows forms with next generation languages (i.e., C# and VB.NET). These languages allow the application to benefit CLR features such as native connection pooling, inheritance and code access security.

One of the many advantages of this concentration of technology is to write applications that are anti-monolithic. In other words, with these technologies it is easier than ever to produce an application that is framework-based rather than functionality focused or specific. One excellent example of this concept is the notion of an application that supports functional plug-ins.

The value proposition that this approach brings to a business is that a common interface can host multiple, specific implementations of application logic. So, instead of writing separate management interfaces, executables and deployment projects for multiple applications, developers can now write for a specified framework and leverage base capabilities of an application platform that will host their plug-in. Deployment, security, database connectivity and other capabilities are all handled and marshaled by the base application frame. Developers can now omit those elements from their applications and write code directly to perform business functions, with the knowledge that their assembly will fit into the base application frame.

The Plug-in Application Concept

The concept of the plug-in application is based in the school of thought for application development that tries to leverage code into a framework that can service business needs rather than several silo applications. The idea is that an application can host multiple child applications where each serves a specific set of functionality while leveraging common code constructs.

The plug-in application framework has two logical components. The application frame contains the code to provide a cross-section or base set of functionality that is fundamental to the application framework. In other words, the application frame will serve as the construct to host more specific applications.

The plug-in exists as a more specific piece of application code that is geared toward solving or meeting specific business needs. The plug-in contains logic that allows for the conduct of business transactions, while leveraging the basis of the framework (in this case the application frame) in which it’s hosted. The following sections describe the concept behind these two components of the application framework.

The following diagram is a representation of the plug-in application’s entire architecture:

Figure 1.1: Plug-in application architecture.

The Application Frame

The application frame exists as a base Windows form that can be run by clients from the URL. Its rudimentary function is to provide a framework that will host plug-in applications. The application frame supplies some generic functionality common to all plug-in applications. In the scenario discussed below, the architecture will allow the application frame to supply some security and menu choices based on the logged-in user. It will also provide the ability for the user to choose to perform administrative tasks on a specified SQL Server using plug-in components.

The frame will also choose to run dependent plug-in applications from the URL. In essence, the application frame takes the form of an MDI application where it becomes the MDI parent and the plug-ins are MDI children. Based on selections made in the application frame by the user, the application frame will consult a Web service to determine from where to fetch the plug-in assembly. It will then load the plug-in assembly within its MDI child space.

The Web Service

The authentication Web service is a .NET Web service that provides user authentication, menu and assembly information to the application frame. The authentication Web service supports requests from clients by providing them with group information from either the Active Directory or its own database-driven account and group store. In either case, the Web service returns a dataset that comprises the Active Directory or security database information.

The application frame obtains user information based on the credentials of the logged-on user. The application frame, as part of the received dataset retrieves menu and plug-in information associated with the user’s credentials. The application frame launches the plug-in using the assembly information associated with the menu choices rendered in the interface.

The Plug-in

As mentioned above, the plug-in is a separate assembly that will inherit from a base class. This base class allows the plug-in assembly to obtain objects, properties and methods that the application frame expects. This also ensures that the assembly will run inside of the application frame parent. Developers should have the ability to choose whether or not to make the plug-in operable in a standalone format and be integrated with the application frame environment itself.

Other than some small changes the plug-in can be written exactly like a separate Windows application. The benefit here is that it is based within a framework that provides horizontally common capabilities that can be leveraged by the plug-in itself.

The Deployment

The fourth application component to the plug-in application solution is a Web project that distributes the application frame and its plug-ins from a virtual directory within IIS to the client upon request. This Web project exists as an ASP.NET project which contains separate directories for the console’s executable and dependent files and a batch file that will adjust the user’s .NET code access security level to trust all code running from the specified URL of the deployment Website.

Users, instead of looking to their machines to run the application, can launch the executable directly from a desktop shortcut that points to the executable via a URL. This arrangement permits application developers to update the code at any time and immediately have the users run the updated version (both the application frame and the plug-ins) the next time the application is launched.

Next Steps

In the next segment of this three part series on developing a plug-in application framework, the details and techniques surrounding implementation of this solution will be covered. Concepts that will be discussed include the actual design of the application frame component of the application and the associated designs of the plug-ins themselves.

These specification guidelines will assist developers in customizing the application plug-in framework to their specific enterprise’s needs. The architectural strategy for deployment and implementation of the solution, as well as security implications will be discussed in future articles.

--

Eric Charran is currently working as a Technical Architect and Web Developer, in Horsham, PA. Eric holds Microsoft Certifications in SQL Server and has significant experience in planning, designing, and modeling n-tier applications using SQL Server 2000, as well as architecting and implementing .NET framework based applications, solutions and Web services. Eric’s other professional skills encompass Database Administration, Data Warehousing and Application Architecture, Modeling and Design, as well as Data Warehouse Transformation and Population using DTS. Eric is also skilled in developing and implementing ASP.NET and Windows forms applications, using technologies such as COM+, the .NET framework, VB.NET and other .NET languages.


Contributors : Eric Charran
Last modified 2006-01-06 02:11 PM
Transaction Management
Reduce downtime and increase repeat sales by improving end-user experience.
Free White Paper
Database Recovery
Feeling the increased demands on data protection and storage requirements?
Download Free Report!
 
 

Powered by Plone