Project This document describes the objectives for the second phse of the Smrt Client k the RI2 phse
Работа добавлена на сайт samzan.net:
Поможем написать учебную работу
Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
от 25%
Подписываем
договор
RI2 Phase of the SC BAT Project
This document describes the objectives for the second phase of the Smart Client, aka the RI2 phase. The first, the RI1 phase of the project demonstrated the basic use of the CAB and the Enterprise Library blocks, and illustrated the following Smart Client capabilities:
- Modularity
- The application has one module loaded based on configuration
- The application provides shared services as well as services provided by the module
- Application component communicate via events
- User eXperience
- Shell provides two workspaces used by the model
- View navigation
- Customization of the shell form and use of application commands
- Status bar describing the state of service connectivity
- Communication of the progress of user operations (downloading files).
- Deployment and updates
- ClickOnce deployment
- User notifications about new versions
- Web service communication
- Abstraction of the service into the service agent
- Asynchronous service invocation with timeout
- Download/upload of multiple files over HTTP channel
- Resuming download/upload after server communication has been interrupted and then reestablished
- Local storage
- The application stores business entities (appraisal data) and files (attachments) in the local file system
- Security
- The application uses Windows authentication to identify user
- Manageability
- The application uses the Enterprise Library Exception Handling Application Block to process exceptions
- The application uses Enterprise Library Logging Application Block to keep an audit log of the interactions with the server.
- CAB configuration
Those features are the basic features any Smart Client will have, but do not demonstrate the strengths of the CAB-based, composable architecture and WinForms-based client that can effectively use the local computer resources.
Customer Requirements
What we hear from our larger and more sophisticated customers is consistently the same story. They want:
- To separate the development of a standardized shell of their client from the development of pluggable application modules that can be hosted in that shell
- Make the development of the modules simple and predictable by providing a module development environment (a SC Module Software Factory)
- Make client highly configurable and adaptable
- Make it possible to add and remove modules
- Make it possible to change the look and feel of the client without redeploying the shell
- Allow for integration of legacy client components into modules
- Allow multiple users with different roles to log-on and log-out to/from the client, and make it possible to change client’s capabilities depending on the user role
- Load modules on demand
- Allow the user only to use the modules that s/he is entitled to
- Simplify, for the user, communication with multiple services that use different authentication and authorization schemas and subsequently require different log-on steps and credentials
- Simplify client deployment and in particular the deployment of new modules and module versions
- Understand how the client can operate, possibly with limited capabilities, when it has not connectivity to some services
The scenario below created by Eugenio illustrates those requirements.
GlobalBank branch automation systems have evolved during the years to provide different business capabilities to the branch employee. In the past, each GB business unit provided an end-to-end solution (meaning client, middleware and backend) to its users on different technologies and platforms. In the beginning, these were just a few applications meaning that the branch user would just use a 2 or 3 solutions to achieve its tasks. Often, these systems were just basic entry points to core capabilities like account management (savings, checking, loans).
Changing business drivers led to a proliferation of systems that provided broad access to multiple functions that expanded well beyond those initial core capabilities. Today, a branch officer performs much more complicated and sophisticated actions as GB offerings evolved together with its customers. Many of these systems were created with lack of architecture guidance from the core IT teams, some of these are packages, others are custom built, departmental solutions lacking the minimal technical features to be efficiently managed, operated and maintained.
In practice this means that the Branch Officer spends a significant amount of time switching between applications that have no knowledge of each other, re-enters the same data multiple times with a severe impact on data quality and his overall productivity is greatly affected because some of the most common tasks are not efficiently automated and integrated. Besides, each application today uses its own UI metaphors and look & feel and this has an impact on branch employees training. Finally, GB IT is reluctant to deploy new solutions using the same approach, because troubleshooting, maintenance and operations costs increase exponentially with each new application installed on a branch desktop; which impacts the agility GB considers appropriate to respond efficiently to business and market demands.
To address these issues, the most experienced team in the GB IT will be tasked with the mission of creating a framework for developing, deploying and operating Smart Client branch solutions in the most efficient way; enabling a vastly improved end user experience, whilst giving each business unit dev team the independence of building solutions on their own schedule without compromising the quality of the end-application and promoting good design practices. This framework is known as the “GlobalBank Integrated Desktop”.
Objectives of the Phase
In this phase we should to separate and address the concerns of the shell developers and the module developers.
A partial list of the shell developer questions includes:
- What is the recommended structure of the “foundational” modules that provide shared services?
- How to control module loading sequence?
- How to control what modules are loaded depending on user role?
- How to recognize that new module versions are available?
- How to load modules on demand?
- What services should be provided in the shell and what services should be provided in foundational modules?
- How to recognize user roles and “disable” or “enable” client capabilities depending on the role?
- What “hosting” services should be provided to the application modules so they can
- “Register” themselves with the shell
- Recognize the shared services
- Recognize what other modules are in the shell
- Communicate with other modules
- Analyze the shared application state (also referred to as the client context)
- Identify the workspace allocated to the module
- Identify and modify the extensibility sites
- How to implement flexible client layout and look and feel that can be modified without impacting the shell and the modules?
- How do I store and recover client state?
- How do I secure application data?
- How to make the host resilient to stupid or malicious modules, like for example blacklist such modules and prevent them from loading again?
- What is the skeleton of the managed-code application module?
- What interfaces should an application module implement and what is the required module initialization (registration) sequence and rules?
- What parts of application module development can be automated?
- What is the wrapper-module for web client applications and how does it supports two-way communication of between the web pages the client component?
- How to manage multiple user credentials (when communicating with different services)?
- How to support collaboration between different views in different modules so that they can refer to the same data?
Many of the module developer concerns and the flipsides of the concerns of the shell developer. For example
- How do I initialize the module in the shell host?
- How do I discover what workspace I should be working in?
- How do I discover what service and other modules are already in the shell?
- How to I communicate what I am doing to the other modules?
- How do I find out what other modules are doing?
- etc.
However in general the emphasis of the phase should be on creating a Module Software Factory (a Module SDK) for developing modules hosted in our shell architecture. That means that we should approximate the scenario described by Eugenio as best as we can.
- Have a separate shell solution
- Crate different starting points (solution templates) for different module developments
- Managed code module
- Unmanaged code module
- Web module
- Reference the shell dll from the modules solutions (not include the shell code in the template)
- Allow the module developer to select the foundational modules they need to develop their module
- Write how-tos that describe writing modules for that specific shell architecture
- Automate the common tasks of writing such modules