Sunday, March 26, 2006

cost benefit analysis of the Composite UI application Block

Composite UI application block provides common infrastructure components and a programming model for smart client applications that are composed out of views and business logic that might come from different teams or need to evolve independently. It has been architected considering many a convergence of many patterns observed in large successful customer applications and where the platform and tools are going in the future in this space.
The benefits of using Composite UI application block can be immense, especially considering the infrastructure of it.
It contains:
• WorkItems: a programming abstraction to simplify encapsulating use cases into 'contexts' that have shared state and orchestrating logic and nested recursively
• Plug-in infrastructure: providers for enumerating available modules and loading them into the environment, and orchestration of the application bootstrap
• Shared shell abstractions: a set of interfaces that allow logic to 'share a shell' and to facilitate separation of concerns between UI-intensive shell development and business logic development
o Workspaces - a set of interfaces that specify how to show controls in an a given area or style - such as portal, tabbed, MDI windows, etc
o UI Extension sites - named 'slots' in a shell where controls are to be added such as menus or status bar panes
o Commands - a common way of hooking up multiple UI events to a specific callback inside the application
• Composition infrastructure that helps objects find each other and communicate - such as the ability to share state, auto-wire-up of pub-sub of events
• A service locator/lifetime container/dependency injection++ foundation
o Built on ObjectBuilder - which allows extending the architecture specifying what it means to 'contextualize' an object.
• A reflective architecture that can be explored to see the current state of the application, and a visualization architecture that allows architects and troubleshooters have views that exploit this reflective nature and can show you the internals of the application structure and how it's running while it's live

Moreover the application block is designed to support the development of smart client line-of-business applications such as the ones found in the following scenarios:
• Online transaction processing (OLTP) front-ends, in areas such as stock distribution centres or data entry applications
• Rich client portals to back-end services, such as portals to government services or bank teller applications

• UI intensive information-worker standalone applications, such as those used by call centre staff, IT support desks, or stock traders


The good thing is that all these benefits from the Composite UI application block can be had for free of cost as this is a freely available tool on the Microsoft patterns and practices website. Support is available in terms of forums and user groups who actively contribute and thus highlighting the advantages of using this block as well as troubleshooting guidelines.

Saturday, March 25, 2006

Deployment Procedure

Introduction
This document describes the deployment procedures for the Project i am currently working on.


Creating a Deployment Project Plan comprises of:
• Creating a project plan outline.
• Deciding the appropriate timeline for the deployment.
• Planning the deployment, as defined in the general MOF guidelines.
• Determining resources.
• Gathering information about the current environment.
• Determining technical considerations and dependencies.

All the above mentioned factors have been considered and reviewed before considering deployment on the development and test servers.


There are currently 2 alternatives to deploy components:

a) Copy the components to the broker sever proxies bin directory (or root) the components will be loaded and registered with the available brokers using the standard Fusion (CLR Loader) policy. This means that the components will be locked for the duration the process is running
b) Copy the components to the path configured as the “Business Component Path” components loaded from this location are shadow copied so they can be replaced, additional the broker server proxy watches for changes to these files and reloads when a new version of the component is deployed to this location.

[NOTE: Do not use option (b) at the current time as there issues which we are currently resolving with this mechanism]



Deployment Process

The deployment process is from the development machines to the test servers is carried out in three steps as mentioned below.
4.1 Deploying the build on local machine and verifying the work

A local instance of Service broker has been installed with the help of Framework team on every development PC.
The main steps involved in deploying the build on the local development Pc are:
• Configuring the ‘Mondial.Common.BrokerServiceHost.exe.config’ file for Service broker, Service Gateway and Data Access Service access.
• Configuring the client Config file for accessing the Service Broker on the appropriate server using the appropriate transport protocol.
• Deploying the relevant BPC’s and all other dependent DLL’s.
• Restarting the Windows Service:
Service Broker (Broker) and
Service Broker (Server) for new server registration files.

Note: If we need to re-deploy the BPCs then, you should stop the services and then copy the BPCs and then re-start the services.

Deploying the build on development server and verifying the work

After successful deployment of work on development machine, the solution is deployed on the development server. All the steps mentioned above for local machine deployment have to be followed in addition to the setting up of the environment for prime entity access.


MQ services have to be setup on the development server. A queue manager has to be created. The current queue manager on development server is: PHX.PHXSG.UAT.QM02
Additionally the local reply queue and clustered request queue has to be configured.



Deploying the Service Broker on test server

Deployment of Service Broker on Test Server is carried out by the Framework team. Only the Broker host is supported on test serer and there are different test servers, different components respectively

Deploying the build on test server and verifying the work

After successful deployment of work on development server, the solution is deployed on the test server. All the steps mentioned above for local machine deployment have to be followed in addition to the setting up of the environment for prime entity access.
For each deployment a MSI (UI installer with Build number) will be handed to test for installation of the client user interface. Test team will use different database for testing.
The MSI contains:

• All application files, in compressed mode.
• All options available through the installation process, when using either a graphical user interface or automatic unattended mode.
• Location of application files.
• User environment settings, such as Start-menu entries and desktop shortcuts and icons.
• Uninstall information.
• Registration requirements, if necessary.
• Other configuration settings required to successfully install and register the application.

Deployment is considered successful only if the client application works as desired on the test servers.