German Architects Forum 2004

German Architects Forum 2004
Smart Client German Architects Forum 2004 Martin Vollmer Architekturberater Developer Platform & Strategy Group Microsoft Deutschland GmbH

Agenda Geschichte der Clients Was ist ein Smart Client?
Office 2003 als Smart Client Deployment, Security, Versioning … Zukunft des Smart Client Zusammenfassung

Client Evolution Smart Clients Fähigkeiten Zeit Client-Server PC GUI
Web PC CUI Dumb Terminal

Thin Client Architektur
Web Server ‘Deployment’ Browser Page Data UI Logic UI Page Business Logic Thin Client Applications The Internet provides an alternative to the traditional rich client model that solves many of the problems associated with application deployment and maintenance. Thin client, browser-based applications are deployed and updated on a central Web server; therefore, they remove the need to explicitly deploy and manage any part of the application to the client computer. This model allows companies to very efficiently expose their applications to a large and diverse external audience. Because thin clients have proven to be effective at solving some of the deployment and manageability problems, they are now used to provide access to many line-of-business (LOB) applications to users within an organization, as well as access to externally facing applications to customers and partners. This is despite the fact that the needs and expectations of these two types of users are often radically different. Thin client applications have some disadvantages. The browser must have a network connection at all times. This means that mobile users have no access to applications if they are disconnected, so they must reenter data when they return to the office. Also, common application features such as drag-and-drop, undo-redo, and context-sensitive help may be unavailable, which can reduce the usability of the application. Because the vast majority of the application logic and state lives on the server, thin clients make frequent requests back to the server for data and processing. The browser must wait for a response before the user can continue to use the application; therefore, the application will typically be much less responsive than an equivalent rich client application. This problem is exacerbated in low bandwidth or high latency conditions, and the resulting performance problems can lead to a significant reduction in application usability and user efficiency. An LOB application that requires heavy data entry and/or frequent navigation across multiple windows can be particularly affected by this problem.

Rich Client Architektur
1 Client Datenbank Server Main Form Daten- zugriffs Schicht Und meist BL ADO, OLE DB, ODBC Rich Client Applications In the mid-1990s, the number of rich client applications developed for the Microsoft® Windows® operating system increased dramatically. These clients were designed to take advantage of the local hardware resources and the features of the client operating system platform. Despite the impressive functionality of many of these applications, they have limitations. Many of these applications are stand-alone and operate on the client computer, with little or no awareness of the environment in which they operate. This environment includes the other computers and any services on the network, as well as any other applications on the user's computer. Very often, integration between applications is limited to using the cut or copy and paste features provided by Windows to transfer small amounts of data between applications. There are technologies to help increase the connectivity of rich client applications. For example, two-tier applications allow multiple users to access common data residing on the network, and DCOM allows applications to become more distributed. (With DCOM, logic and state are no longer tied to the client computer, and instead are encapsulated within objects that are then distributed across multiple computers.) However, connected applications are considerably more complex to develop. As the size and complexity of these distributed applications grows, any tight coupling between client applications and the services they consume becomes increasingly difficult to maintain. While rich clients typically provide a high-quality, responsive user experience and have good developer and platform support, they are very difficult to deploy and maintain. As the complexity of the applications and the client platform increases, so do the difficulties associated with deploying the application to the client computer in a reliable and secure way. One application can easily break another application if an incompatible shared component or library is deployed, a phenomenon known as application fragility. New versions of the application are typically made available by redeploying the entire application, which can increase an application fragility problem.

Rich Client Architektur
2 Client Web Server Main Form Service Agent Web Service Proxy Web Service

Smart Client Architektur
Web Server Main Form Service Agent Web Service Proxy Web Service Smart Client Applications Smart client applications can be designed to combine the benefits of a rich client application with the deployment and manageability strengths of a thin client application, although the precise nature of the balance between the two approaches depends on the exact scenario. Smart client applications often have very diverse requirements, and so vary greatly in design and implementation. However, all smart clients share some or all of the following characteristics: Make use of local resources Make use of network resources Support occasionally connected users Provide intelligent installation and update Provide client device flexibility Many applications do not need all of these characteristics. As you design your smart clients, you will need to carefully consider your application scenario and decide which of these characteristics your smart client application requires. Incorporating all of these characteristics into your application will require very careful planning and design, and in many cases you will need significant implementation resources. Note The .NET Framework helps you to implement many of the characteristics of smart client applications. Self-describing and tightly bound assemblies, along with support for isolated and side-by-side installation of multiple versions of an application, help to reduce application deployment and fragility problems associated with rich clients. The .NET Framework base class library provides extensive support for interaction with Web services, and provides Windows Forms. By using the common language runtime (CLR), you can use any .NET-supported language to develop your smart clients. Using Local Resources A well-designed smart client application takes maximum advantage of the fact that code and data are deployed on the client and executed and accessed locally. It provides an application with a rich and responsive user interface and powerful client-side processing capabilities. For example, it might enable the user to perform complex data manipulation, visualization, searching, or sorting operations. Smart clients can take advantage of client-side hardware resources (such as telephones or barcode readers) and other software and applications. This makes them well suited to solve problems that a thin client application cannot solve well, such as point-of-sale applications. Smart clients can also take advantage of local software, such as Microsoft Office applications, or any installed LOB application on the client computer. Creating solutions that integrate with and coordinate multiple LOB applications allows your users to work more efficiently, make better decisions, and reduce data entry errors. Such solutions can also allow your application to be more tightly integrated with the user's working environment — for example by having a custom or familiar user interface — which can lead to decreased training costs. Other client applications can be integrated or coordinated by the smart client application to provide a coherent and efficient overall solution. These applications should also be aware of the context in which the applications are being used, and should adapt to that context to aid the user as much as possible; for example, by preemptively caching appropriate and useful data according to the pattern of usage or the role of the user. Maximizing the use of and integrating local resources into your smart client application enables your application to make better and more efficient use of the hardware that is already available to you. Very often, processing power, memory, and advanced graphical capabilities go unused. Using the resources on the client computer can also reduce server-side hardware requirements. Using Network Resources Smart clients can consume and use different services and data over the network. They are an effective way to retrieve data from many different sources and can be designed to analyze or aggregate the data, allowing the user to make more efficient and better informed decisions. For example, a smart client could use a mapping service to provide details on location and driving directions. Smart client applications should be as connected as possible and should make use of the resources and services that are available to them over the network. They should not be stand-alone applications and should always form part of a larger distributed solution. At a minimum, a smart client application should use centralized services that help maintain the application and provide deployment and update services. The connected nature of smart client applications allows them to provide valuable data aggregation, analysis, and transformation services. They can allow users to collaborate on tasks in real time or over a period of time. In many cases, a smart client application can provide portal-like capabilities to the user, allowing disparate data and services to be coordinated and integrated into an overall solution. For details about how to design your smart clients to make use of connected services, see Chapter 2: Handling Data Supporting Occasionally Connected Users Smart clients can be designed to provide functionality to users who are occasionally connected to the network, allowing the user to continue to work efficiently when explicitly offline, in low bandwidth or high latency network conditions, or when connectivity is intermittent. For mobile applications, smart clients can also optimize network bandwidth, for example by batching requests to the server to make better use of expensive connectivity. Even when the client is connected to the network most of the time, smart client applications can improve performance and usability by caching data and managing the connection in an intelligent way. In a low bandwidth or high latency environment, for example, a smart client application can manage the connection in such a way that the usability and responsiveness of the application is not impaired and the user can continue to work efficiently. Being able to work while disconnected or only occasionally connected increases user productivity and satisfaction. A smart client application should aim to provide as much functionality as possible when offline. For details about how to design your smart client applications to support occasionally connected users, see Chapter 4: Occasionally Connected Smart Clients Providing Intelligent Installation and Update Some of the biggest problems with traditional rich clients occur when the application is deployed or updated. Many rich client applications have a large number of complex installation requirements and may share code by registering components and/or by installing DLLs in a common location, leading to application fragility and update difficulties. Smart client applications can be designed to manage their deployment and update in a much more intelligent and flexible way than traditional rich client applications. They can avoid these common problems, which can help to reduce your application management costs. There are a number of different ways to deploy smart clients. These include simply copying files onto a local computer, downloading code automatically from a central server using no-touch deployment, or deploying Windows Installer packages using an enterprise push technology such as Microsoft Systems Management Server (SMS). The method you choose will depend on your specific situation. Smart client applications can update themselves automatically, either when they are run or in the background. This capability allows them to be updated on a role-by-role basis; updated in a staged manner, allowing applications to be rolled out to pilot groups or a limited set of users; or updated according to an established schedule. The .NET Framework allows you to strongly name your application components, which means that the application can specify and run with the exact versions of the components with which it was built and tested. The .NET Framework allows applications to be isolated from each other so that installing one application will not break another application, and multiple versions of the same application can be deployed side by side. These features greatly simplify application deployment and remove many of the application fragility problems that were associated with rich client applications. For more information about intelligent installation and updates, see Chapter 7: Deploying and Updating Smart Clients. Providing Client Device Flexibility Smart clients can also provide a flexible and customizable client environment, allowing the user to configure the application to support his or her preferred way of working. Smart client applications are not restricted to desktop or laptop computers. As connectivity and the power of small-scale devices increases, the need for useful client applications that provide access to essential data and services on multiple devices also increases. Together with the .NET Compact Framework, the .NET Framework provides a common platform on which smart client applications can be built. Smart clients can be designed to adapt to the host environment, providing appropriate functionality for the device on which they are running. For example, a smart client application designed to run on a Pocket PC should provide a user interface that is tuned to using a stylus on a small screen area. In many cases, you will need to design multiple versions of a smart client application, each targeting a specific device type to take full advantage of the particular features supported by the device. Because small-scale devices are typically limited in their ability to deliver a full range of smart client application features, they may provide mobile access to only a subset of the data and services that a fully featured smart client application provides, or they may be used to collect and aggregate data when the user is mobile. This data can then be analyzed or processed by a more fully featured smart client application or by a server-side application. An awareness of the capabilities and usage environment of the target device, whether it is a desktop, laptop, tablet, or mobile device, and the ability to tailor the application to provide the most appropriate functionality are essential features of many smart client applications. Note This guide does not cover architectural and design details specific to the development of smart client applications to be run on mobile devices, but many of the topics that are covered are equally relevant whether the application is run on a desktop computer or another device. Types of Smart Clients Smart clients vary greatly in design and implementation, both in application requirements and in the number of scenarios and environments in which they can be used. Smart clients therefore can take many different forms and styles. These forms can be divided into three broad categories according to the platform that the smart client application is targeting: Windows smart client applications Office smart client applications Mobile smart client applications It is common for a smart client application to target one or more of these platforms, depending on the role of the user and the functionality required. Such flexibility is one of the key strengths of smart client applications. The remainder of this guide concentrates on issues that are common to all three types of smart client applications, rather than providing a detailed explanation of issues that affect each individual category. However, it is useful to briefly examine each type in turn so that you can determine which style of application might be best for your situation.

Was ist ein Smart Client? Definition der Fähigkeiten
Nutzt lokale CPU Konsumiert WebServices Unterstützt online / offline Szenarien So what makes a client ‘smart’? When Microsoft refers to a smart client, we are speaking about software that: Click Takes advantage of the local processing power of the device it is running on, (Talk to possibilities of using Office as a smart client for analytical work) Takes advantage of today’s connected internet by consuming web services to provide richer functionality and up to date information for the user, Ideally supports both connected and disconnected states, enabling user productivity even when a connection is unavailable, (you may elaborate depending on customer about disconnected workforce, etc.) And, providing support for multiple types of devices and display factors from the same code base. (elaborate on customer scenarios here – talk about future .NET compact framework) All of these features of a smart client can be built using any technology you choose, But .NET makes it easy to create this type of software by providing a technology platform, Framework, and toolset that enables developers to quickly create the next generation of Software that will make your users more productive and increase enterprise agility. (elaborate on agility – reduced cost of implementation, better integration of existing Assets, increased revenue opportunities) Kann sich dem Gerät anpassen Intelligentes Deployment

Web Services & Offline/Online Unterstützung Anpassung an Geräte schwieriges Deployment “großer” Footprint DLL “Hölle” Netzwerk Abhängigkeit Poor User Experience Rich UI Schwierig zu entwickeln Große Reichweite Rich User Experience Entwickler- prduktivität einfaches Change Management Antwortzeiten einfaches Deployment

Microsoft Smart Client Plattformen
Windows Forms Office System 2003 Windows Mobile heutige Generation Version 1.1 XML Version 1.1 Nächste Generation Version 2.0 “Whidbey” Version 2.0

Smart Client Technologien
.NET Framework (Full & Compact) Deployment, App Isolation, CAS, Binding Windows Applikationen Windows Forms Office Smart Clients Office XML - InfoPath, WordML, ExcelML SmartTags & SmartDocuments Visual Studio Tools For Office - Word and Excel Information Bridge Framework - Meta-Data Driven Solutions Hybrid Embedded Browser, Browser Host

Windows Forms Office System 2003 Windows Mobile XML Version 1.1 Version 2.0 Radikal vereinfachte Anwendungsentwicklung ClickOnce deployment, update, rollback Optisch ansprechende Benutzeroberfläche Neue Daten Controls Office “Look and Feel” Entwicklerproduktivität Vereinfacht die Bearbeitung von Daten Weniger “lines of code” .NET Framework Verbreitung Installiert auf mehr als 120 Millionen PCs Vorinstalliert auf 60% aller neuen PCs und ansteigend Auf der SP2 CD enthalten Endverbraucher Bei 55% installiert bis zum Ende von ’04 Bei 75% installiert bis zum Ende von ‘05 Geschäftskunden Bei 50% installiert bis zum Ende von ’04 Bei 68% installiert bis zum Ende von ’05 Heutige Generation Version 1.1 Nächste Generation Version 2.0 “Whidbey”

Smart Client Architektur
User Interface Components User Process Components Service Interfaces Business Workflows Components Entities Data Access Logic Service Agents Data Source Service Security Operational Management Communication An examination of most business solutions based on a layered component model reveals several common component types. The slide shows these component types in one comprehensive illustration. Note The term component is used in the sense of a piece or part of the overall solution. This includes compiled software components, such as Microsoft .NET assemblies, and other software artifacts such as Web pages and Microsoft® BizTalk® Server Orchestration schedules. Although the list of component types shown is not exhaustive, it represents the common kinds of software components found in most distributed solutions. The component types identified in the sample scenario design are: User interface (UI) components. Most solutions need to provide a way for users to interact with the application. In the retail application example, a Web site lets customers view products and submit orders, and an application based on the Microsoft Windows® operating system lets sales representatives enter order data for customers who have telephoned the company. User interfaces are implemented using Windows Forms, Microsoft ASP.NET pages, controls, or any other technology you use to render and format data for users and to acquire and validate data coming in from them. User process components. In many cases, a user interaction with the system follows a predictable process. For example, in the retail application you could implement a procedure for viewing product data that has the user select a category from a list of available product categories and then select an individual product in the chosen category to view its details. Similarly, when the user makes a purchase, the interaction follows a predictable process of gathering data from the user, in which the user first supplies details of the products to be purchased, then provides payment details, and then enters delivery details. To help synchronize and orchestrate these user interactions, it can be useful to drive the process using separate user process components. This way the process flow and state management logic is not hard-coded in the user interface elements themselves, and the same basic user interaction "engine" can be reused by multiple user interfaces. Business workflows. After the required data is collected by a user process, the data can be used to perform a business process. For example, after the product, payment, and delivery details are submitted to the retail application, the process of taking payment and arranging delivery can begin. Many business processes involve multiple steps that must be performed in the correct order and orchestrated. For example, the retail system would need to calculate the total value of the order, validate the credit card details, process the credit card payment, and arrange delivery of the goods. This process could take an indeterminate amount of time to complete, so the required tasks and the data required to perform them would have to be managed. Business workflows define and coordinate long-running, multi-step business processes, and they can be implemented using business process management tools such as BizTalk Server Orchestration. Business components. Regardless of whether a business process consists of a single step or an orchestrated workflow, your application will probably require components that implement business rules and perform business tasks. For example, in the retail application, you would need to implement the functionality that calculates the total price of the goods ordered and adds the appropriate delivery charge. Business components implement the business logic of the application. Service agents. When a business component needs to use functionality provided in an external service, you may need to provide some code to manage the semantics of communicating with that particular service. For example, the business components of the retail application described earlier could use a service agent to manage communication with the credit card authorization service, and use a second service agent to handle conversations with the courier service. Service agents isolate the idiosyncrasies of calling diverse services from your application, and can provide additional services, such as basic mapping between the format of the data exposed by the service and the format your application requires. Service interfaces. To expose business logic as a service, you must create service interfaces that support the communication contracts (message-based communication, formats, protocols, security, exceptions, and so on) its different consumers require. For example, the credit card authorization service must expose a service interface that describes the functionality offered by the service and the required communication semantics for calling it. Service interfaces are sometimes referred to as business facades. Data access logic components. Most applications and services will need to access a data store at some point during a business process. For example, the retail application needs to retrieve product data from a database to display product details to the user, and it needs to insert order details into the database when a user places an order. It makes sense to abstract the logic necessary to access data in a separate layer of data access logic components. Doing so centralizes data access functionality and makes it easier to configure and maintain. Business entity components: Most applications require data to be passed between components. For example, in the retail application a list of products must be passed from the data access logic components to the user interface components so that the product list can be displayed to the users. The data is used to represent real-world business entities, such as products or orders. The business entities that are used internally in the application are usually data structures, such as DataSets, DataReaders, or Extensible Markup Language (XML) streams, but they can also be implemented using custom object-oriented classes that represent the real-world entities your application has to work with, such as a product or an order. Components for security, operational management, and communication: Your application will probably also use components to perform exception management, to authorize users to perform certain tasks, and to communicate with other services and applications.

Windows Forms Smart Client Design Guide und Building Blocks von PAG
Smart Client Architecture and Design Guide User Interface Process Application Block – V Data Access Application Block for .NET Smart Client Offline Application Block Updater Application Block for .NET Authorization and Profile Application Block Exception Management Application Block for .NET User Interface Process Application Block - Version 2.0 The User Interface Process Application Block provides a simple yet extensible framework for developing user interface processes. It is designed to abstract the control flow and state management out of the user interface layer into a user interface process layer. Data Access Application Block for .NET The Data Access Application Block is a .NET component that contains optimized data access code that will help you call stored procedures and issue SQL text commands against a SQL Server database. The documentation provides guidelines for implementing an ADO.NET-based data access layer in a multi-tiered .NET application. It focuses on a range of common data access tasks and scenarios and presents guidance to help you choose the most appropriate approaches and techniques. This guide encapsulates performance and resource management best practices and can easily be used as a building block in your own .NET application. If you use it, you will reduce the amount of custom code you need to create, test, and maintain. Smart Client Offline Application Block The Offline Application Block embodies the functionality that enables the smart client user to enjoy a seamless experience even when working offline. It demonstrates possible approaches for: Detecting the presence or absence of a network. Caching the required data so the application can function while offline. Synchronizing the client application state and /or data with the server when the application goes online again. Updater Application Block for .NET A .NET solution that provides a "pull model" solution to automatically download application updates from a central location, designed for organizations who want the rich functionality of Windows Forms applications with the centralized manageability of Web-based applications. By using the Updater Application Block to download application updates, you can overcome the security "sand box" limitations of downloading Windows Forms applications through a browser, while still maintaining control and security over the application update process. Authorization and Profile Application Block The Authorization and Profile Application Block provides an infrastructure for role-based authorization and access to profile information. The block enables you to: Authorize a user of an application or system. Use multiple authorization storage providers. Plug in business rules for action validation. Map multiple identities to a single user. Access profile information that can be stored in multiple profile stores. Exception Management Application Block for .NET Exception Management Application Block for .NET consists of an architecture guide and an application block. The documentation discusses design and implementation guidelines for exception management systems that use .NET technologies. It focuses on the process of handling exceptions within .NET applications in a highly maintainable and supportable manner. Exception Management Application Block for .NET provides a simple yet extensible framework for handling exceptions. With a single line of application code, you can easily log exception information to the Event Log or extend it by creating your own components that log exception details to other data sources or notify operators, without affecting your application code. Exception Management Application Block for .NET can easily be used as a building block in your own .NET application.

Windows Mobile Microsoft Smart Client Plattformen XML
Office System 2003 XML Version 1.1 Version 2.0 Windows Forms Heutige Generation Nächste “Whidbey” Windows Mobile Sofortiger Zugriff auf Daten überall und jederzeit Der Formfaktor und sofortige Bereitschaft nach dem Einschalten besser geeignet im Außendienst Zugriff auf existierende Web Services in SOAs Nutzt die vorhandenen Fähigkeiten und den vorhandenen Code auf Geräten mit .NET Compact Framework

Office System Microsoft Smart Client Plattformen Heutige Generation Nächste Windows Forms Version 1.1 Version 2.0 “Whidbey” Windows Mobile Office System 2003 XML Version 1.1 Version 2.0 Verbindet “Live Business Daten” mit Dokumenten - auch Offline Beschleunigt und verbessert das Treffen von Entscheidungen Verbessert Mitarbeiter Produktivität Reduziert Fehler verursacht durch Datenwiedereingabe und copy/paste Nutzt die existierende Erfahrung mit Office bei den Benutzern Erreichbarkeit von über 400 Millionen Office Benutzern Keine extra Trainings und Anschubzeit von neuen Anwendungen Reduziert hausgemachte Fehler in neuen Anwendungen Nutzt die reichhaltige und zuverlässige Office Funktionalität Hohe Entwicklerproduktivität = weniger Entwicklungszeit Verbesserte Wartbarkeit & Deployment Optimiert die Nutzung des PC & der zentralen Resourcen

Office als Smart Client Plattform
Klassiker „Visual Basic for Applications“ (VBA) Smart Documents Visual Studio Tools for Office (VSTO) Information Bridge Framework (IBF) Microsoft InfoPath 2003 Visual Studio Tools for Office 2005 (Beta) Smart Documents Architecture Smart documents allow developers to assign specified actions to XML elements within a previously existing or newly created document. The XML within the mapped document corresponds to an underlying XML schema. Once the document is prepared, developers can use the Smart Document API, available as part of the Office 2003 Solution Developers Kit, to assign the actions that will drive the solution. Developers have a lot of flexibility when working with smart documents. They can manipulate the document directly or interact with server-side processes, such as retrieving data or routing it elsewhere for use by a back-end system. Developers also have a lot of flexibility in how they want to develop: they can use Visual Basic 6.0, Visual Basic .NET, C#, or C++. Once a smart document DLL has been compiled, a developer must create a Manifest file that describes the location of the following items: • A DLL containing the automation code that drives the solution • An XML schema that corresponds to mapped elements within the document itself • The XML Manifest, which helps shield any complexity from information workers The Manifest acts as a central location that contains information about all the pieces of the smart document. Hence, installing a smart document solution to a document template is a simple matter of pointing the document to the Manifest file. Notice in figure 2 that the Solution URL is the path to the Manifest file, which provides the Solution Name, the path to the DLL, and so on. This smart document is now ready to use.

Visual Studio Tools für Office
Projekttyp Office in Visual Studio Programmiert in managed code Neue Debugging Möglichkeiten Sicheres Deployment Visual Studio Tools für Office

Deployment Hintergrund Historische Probleme
Drei Hauptprobleme bei Komponentensoftware Interoperabilität Zwischen Komponenten Über Prozessgrenzen Versionierung Sprachunabhängigkeit Komplizierte Installation Betrifft viele Bereiche des Systems Dateien werden an mehrere Stellen kopiert Einträge in der Registry Schwierig zu kopieren oder entfernen “DLL Hölle” Fehlende, eingebaute Sicherheit Until the advent of the .NET Framework, deployment was almost always an onerous process. Numerous difficulties stem from the four main problems of component software: interoperability—both among components and across disparate processes, versioning, and language independence. COM, DCOM, CORBA and other architectures have sought to address these problems but never managed to solve them. Traditional deployment also requires complicated installation and update procedures that seem to affect all parts the target machine. Files are installed to multiple locations and numerous registry entries are required. The nature of the relationship between a COM binary and its registry settings makes them very fragile, causing systems to break fairly easily. And once installed, software can be very difficult to move or uninstall. But the worst problem is when DLLs shared among applications are overwritten by a new installation, causing existing applications that use the overwritten version to break. This pernicious problem has given rise to the familiar term “DLL Hell”. Finally there is the problem of a lack of built-in security. Users are justifiably uneasy about installing new applications or updates because of the potential damage they could cause. All of this changes with the .NET Framework.

Deployment Hintergrund Willkommen beim .NET Framework
Assemblies DLL oder EXE mit: IL Code Typ Information Manifest mit “assembly metadata” Admin hat Kontrolle über Konfigurationsdateien Vorteile Keine Registry Einträge erforderlich “Private assemblies” “Public assemblies” bereitgestellt durch GAC Side-by-side Versionierung Code Access Security (CAS) .NET Assemblies are the answer to these historical problems. Assemblies are DLL or EXE files that contain a collection of types and resources which form a logical package of application functionality. They work similarly to traditional DLLs and executables except that they are self-describing. This means that, in addition to the Intermediate Language code containing the application logic, an assembly holds metadata in the form of type information (thus replacing the old type library files). It also contains other metadata, such as the assembly’s identity, version, strong name (if it has been signed), external dependencies, etc., all of which resides in what is called a “manifest”. Assemblies can also be controlled by three types of configuration files: an application config file, a Publisher policy file, and a machine config file (which has precedence over the other two). This permits you to change settings such as binding redirects and modes, assembly locations, etc. without having to recompile the application. All of this leads to numerous benefits, not the least of which is that you no longer have to rely on registry settings for an application to function properly. This makes deployment much easier.

Optionen beim Deployment
Klassisch über Windows Installer 2.0 XCopy Deployment No-Touch Deployment Unter Benutzung der Internet Explorers Eigenentwicklung mit Assembly.LoadFrom(url) .NET Application Updater Block Click-Once Deployment mit VS 2005 (Beta)

Application Updater Block
Downloader 1 Validator Deployment Server 2 Post-Proc Manifest Client App 4 Application Application Folder Config Assembly 3 Config App Assembly Config .NET Framework Assembly

No-Touch Deployment .NET Updater Application Block (UAB)
“Plug-and-play” Komponenten Eines von den Microsoft “Patterns and Practices” Oder man entwickelt seinen eigenen …: angepassten Controler speziellen Downloader massgeschneiderten Validator individuellen Post-processor Komplett dokumentiert und erweiterbar Taking it a step further, however, the UAB enables you to build custom controllers (which oversee the update process), custom downloaders (which copy the manifest and application files from a central server to a download folder), custom validators (which sign and verify manifest and updated files), and custom post-processors (which perform any post-installation configuration tasks such as writing registry entries). All of this is possible because the UAB is fully documented and extensible. You will find complete VB .NET and C# source code, QuickStart sample applications, and documentation in the MSDN Library.

Click-Once Deployment mit Visual Studio 2005
Deployment mit VS2005 Auto-Updating Applications Integration in Windows Sicheres Deployment Click-Once Deployment mit Visual Studio 2005

Platform Roadmap 3 Wellen welche nicht ganz in Longhorn kulminieren
Whidbey + Yukon Longhorn Heute Basic Web Services Advanced Web Services Indigo Kommunikation SQL Server 2000 SQL Server ‘Yukon’ WinFS Nach Longhorn  Daten Office 2003 WinForms Office 2003 WinForms Avalon Smart Client & Präsentation .NET Framework 1.1 .NET Framework 2.0 WinFx NGSCB… Grundlagen

Longhorn Architektur Später ...

Longhorn Architektur Presentation Data Communication
TM Presentation Data Communication Base Operating System Services

Ankündigung von WinFX™ Schnellere, einfachere Entwicklung
Basiert auf dem .NET Framework Gut strukturiertes “Programmier-Framework” für Windows Weiterhin Verpflichtung zur Abwärtskompatibilität

Windows Kommunikation
Erleichtert Service orientierte Entwicklung Advanced WebServices Sicher, zuverlässig, Transaktionen, asynchron Heterogene Interoperabilität leistungsfähige Messaging Infrastruktur Vereinfacht die Erstellung von Services Programmiermodell erweitert bestehende Möglichkeiten

Indigo und Vereinheitlichung
ASMX and WSE .NET Remoting Enterprise Services System.Messaging Simple Config Interoperable Service-Oriented Broad Vision Extensibility Object-Oriented Attributes Transactions Components Queuing Reliable Msg Durable Msg This slide shows what we've unified inside of Indigo. Today at Microsoft, in fact, a single team owns the current Web services stack, ASMX and WSE, .NET remoting, enterprise services, which is managed version of COM+ and system.messaging, which is the managed version of MSMQ. While all of these have their niche, they all pertain to the development of connected systems and, in an ideal world, would be represented within a unified development architecture. That’s what we’ve done with Indigo. We've created a single, unified product that supports all of those scenarios and all of the features of each of them and adds more onto them. So it adds, for example, interoperability to the kinds of things you can do with enterprise services. It adds the ability to support customer transports to the current Web services stack, and more. Indigo will supersede Microsoft’s existing connected systems technologies (think of it as a logical v2 to each of these technologies). Other technologies continue to co-exist and be supported via support policy So to summarize unification, migration and interop, Indigo is the way to build service-oriented applications on Windows in the Longhorn timeframe. With the logical v2 for our existing distributed systems technologies we've done a lot of work to make sure that you can incrementally use Indigo. Indigo can integrate with your existing applications that you've built on today's technology. You don't have to move whole hog. You can do what makes the most sense for your business. We're going to do a lot of work to make sure that it's easy to migrate from today's RPC technologies like enterprise services, .NET remoting to Indigo for those places where you choose to for business reasons move to take advantage of Indigo. And finally follow our prescriptive guidance if you're building service-oriented applications today. It's not only the best practices for using those technologies but it's also going to make migrating those apps that you want to much easier. Indigo

Vereinheitlichtes Präsentationsmodell für Windows Applikationen, Web Applikationen, Grafik, Media und Animationen Vektor orientiert Native Unterstützung für “advanced input” Unterstützung von deklarativer Programmierung

Deklarative Programmierung für Windows Code Named “XAML”
Dim b1 As New Button b1.Label = “OK” b1.background = New horizontalGradient(white,ltBlue) b1.width = New BoxUnit(1.0F,UnitTypes.Inch) Markup Sprache für Windows Aufbau von Applikationen in einfachen deklarativen Ausdrücken Leicht zu lernen, schreiben und lesen Code und Inhalt sind getrennt Vereinfachung der Zusammenarbeit von Designer und Entwickler Einfach von Werkzeugen zu konsumieren und zu generieren button b1 = new Button(); B1.Label = “OK” b1.background = new horizontalGradient(white,ltBlue); b1.width = new BoxUnit(1.0f,UnitTypes.Inch); <Button Width=“1in”> OK <Button.Background> HorizontalGradient White LtBlue </Button.Background> </Button> <Button Width="100px"> OK <Button.Background> LightBlue </Button.Background> </Button> Button b1 = new Button(); b1.Content = "OK"; b1.Background = new SolidColorBrush(Colors.LightBlue); b1.Width = new Length(100); Dim b1 As New Button b1.Content = "OK" b1.Background = New SolidColorBrush(Colors.LightBlue) b1.Width = New Length(100)

Zusammenfassung „Loslassen“ vom Thin-Client Paradigma
.NET macht es möglich … Office 2003 als Smart Client Framework .NET + Application Blocks = großartige Smart Client Entwicklungsplattform Noch besser in Visual Studio 2005 Planung für : Deployment, Security, Offline, Behandlung der Daten, Antwortzeiten “Responsiveness”

Smart Client Resources
Learn about the .NET Framework Windows Forms Sample code, forums, articles, etc. Check out the Windows Forms Quick Start in the SDK Office Newsgroups dotnet.framework.windowsforms office.developer.* MSDN Architecture Center

Patterns & Practices Resources
Smart Client Architecture Guide Application Blocks Offline Application Block Application Updater Block Caching Application Block

Office Developer Resources
Microsoft® Office 2003 Overview of Developer Technologies Brand New! Available for the first time here at MGB 50+ pages of fantastic Office development overview content Internal: Publicly available at: within a few months Contact: Joe Andreshak (jandre)

Visual Studio Tools for Office
Office Developer Center: Visual Studio Tools for the Microsoft Office System Training Understanding the Excel Object Model from a .NET Developer's Perspective Understanding the Word Object Model from a .NET Developer's Perspective Migrate Word VBA solutions to Visual Studio Tools for Office

Compact Framework & IBF Resources
Information Bridge Framework: Charles Maxson Articles on MSDN: Using Information Bridge Framework Solutions with the Office System Approaching Solutions with Information Bridge Framework Building User Interfaces with the Information Bridge Framework

German Architects Forum 2004

Ähnliche Präsentationen

Präsentation zum Thema: "German Architects Forum 2004"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

German Architects Forum 2004

Ähnliche Präsentationen

Präsentation zum Thema: "German Architects Forum 2004"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback