| Summary This article introduces Visual Studio .NET Enterprise Templates and their advantages. In this article, you will learn about Enterprise Architecture Planning and how Enterprise Templates are a solid, cohesive part of an Enterprise Architecture Plan. You will learn about Distributed Application Architecture as it relates to Enterprise Architecture and Templates. You will also be introduced to Enterprise Template Architecture, Template Policy Files, the Template Definition Language (TDL), Template Building Blocks, and Dynamic Enterprise Template Help. The .NET Architect Enterprise Template Series will help you build the following projects: - Enterprise Template Editor Add-In
- Enterprise Template Editor Web Service
- Enterprise Template Editor Windows Service
- Enterprise Template Editor Web Control
- Enterprise Template Editor Windows Control
- Enterprise Template Editor Framework
Requirements- Visual Studio.NET Enterprise Developer, or Enterprise Architect Edition
- VB.NET or C#.NET Programming Knowledge
Contents Section 1: Introduction
Section 2: Enterprise Architecture Overview
Section 3: Distributed Application Architecture
Section 4: Enterprise Template Advantages
Section 5: Enterprise Template Architecture
Section 6: Enterprise Template Policy Files
Section 7: Enterprise Template Definition Language (TDL)
Section 8: Enterprise Template Building Blocks
Section 9: Enterprise Template Dynamic Help
Summary
About The Author Section 1: Introduction The .NET Enterprise Template Series covers the fundamental concepts of Enterprise Architecture, Distributed Application Architecture, and Enterprise Template design, development, and deployment. A thorough examination of these disciplines is too expansive to be adequately covered in a single article; however, you will, at a minimum, examine the major conceptual foundations of each discipline. A brief introduction to Enterprise Architecture and Distributed Application Architecture will aid your understanding of the role of Enterprise Templates in a large, distributed organization. To create Enterprise Templates, you must have either Visual Studio .NET Enterprise Developer or Visual Studio .NET Enterprise Architect installed on your computer. The .NET Architect Series is a collection of articles which demystifies the role of the Enterprise Architect. Enterprise Templates are one tool Enterprise Architects employ to ensure adherence to corporate standards, policies, and procedures. This series covers the architecture, planning and implementation of Visual Studio .NET Enterprise Templates, culminating in the creation of an Enterprise Template Editor, implemented using a variety of Visual Studio .NET project types. The .NET Architect Enterprise Template Series comprises the following articles: - Article 1: Enterprise Template Overview
- Article 2: Enterprise Template Policy Files
- Article 3: Enterprise Template TDL Language
- Article 4: Enterprise Template Dynamic Help
- Article 5: Enterprise Template Exercise
- Article 6: Enterprise Template Editor Add-In
- Article 7: Enterprise Template Editor Web Service
- Article 8: Enterprise Template Editor Windows Service
- Article 9: Enterprise Template Editor Web Control
- Article 10: Enterprise Template Editor Windows Control
- Article 11: Enterprise Template Editor Framework
- Article 12: Enterprise Template Developer Notes
Section 2: Enterprise Architecture Overview Enterprise Templates do not exist in a stateless technological vacuum; they exist to compliment other Enterprise Architectures and Technologies. Enterprise Templates are part of a solid, cohesive Enterprise Architecture Plan in your organization. The discipline of Enterprise Architecture is an expansive one; therefore, you will only be introduced to the major conceptual and logical thought processes that contribute to effectively structuring your own Enterprise Architecture Plan. The Enterprise Architecture discipline involves performing an objective evaluation of your organizational structure and how it functions. The evaluation spans the planning, organizational, systems, data, and technological divisions within your organization. The output of Enterprise Architecture activities is a detailed document describing the operation of your organization. The Enterprise Architecture Document is a useful guide to remaining adaptive and responsive to rapid changes in business and technology - including changes in standard policies, procedures and best practices. There are four models and four perspectives that collectively form an Enterprise Architecture Document. The four models are the objectives and goals model, the processes and organization model, the systems and data model, and the technology model. The four perspectives are the business perspective, the application perspective, the information perspective, and the technology perspective. The correlation between the models and perspectives is as follows: The Model | The Perspective | The Objective and Goals Model | The Business Perspective | The Processes and Organization Model | The Application Perspective | The Systems and Data Model | The Information Perspective | The Technology Model | The Technology Perspective |
( figure 1.0 ) We will discuss each perspective in turn, beginning with the Business Perspective. As you move further toward defining the Technology Perspective, a more detailed picture of your organization appears. The Business Perspective is the foundation of all Enterprise Architecture activities. It describes how your enterprise is structured, both internally and externally; it describes the business strategies and decisions that keep your organization focused on growth, profit and goals; it flushes out the internal organization structure of management and the interlocking relationships between business units; and it exposes the overall objectives and goals of your enterprise. At a minimum, the Business Perspective should enumerate your organization's values, goals, vision, and mission. The Business Perspective may also contain your organizational structure, management philosophy, marketing goals, and your business plan. The Application Perspective involves understanding the core, mission-critical applications that are currently in production or planning to be deployed in the future. It describes how your organization automates business processes, both internally and externally; it describes the interactions and dependencies among processes, systems, and components; and it provides a mechanism for developing new applications and extending existing applications. If the applications identified in the Application Perspective do not significantly contribute to meeting, or exceeding, stated organizational business objectives, the validity of the application should be questioned. The Information Perspective reveals the critical information necessary to effectively operate your organization. The primary focus of the Information Perspective is data. It delineates the data models of your enterprise; it defines the procedures, processes, and policies that govern your data management activities; it provides you with a greater understanding of your data recovery, backup, and usage patterns; and it provides greater understanding of the relationships and interdependencies among the data documents within your organization. The Information Perspective is about capturing, defining, and understanding data as it relates to organizational business processes, workflows, and data repositories. The Technology Perspective enumerates the state of your organization's hardware and software infrastructure. It identifies desktop and server hardware; it identifies the operating systems and network infrastructure; it identifies any network components such as printers, modems, and faxes; and it provides a common set of standards and best practices for supporting the business mission of your organization. The Technology Perspective may also include an inventory of internal and external vendors, an evaluation of current technology staffing preparedness, and the Information Technology Expenditures Budget. An effective Enterprise Architecture Plan involves the four major perspectives: The Business Perspective, the Application Perspective, the Information Perspective, and the Technology Perspective. The true benefits of performing Enterprise Architecture activities lie in gaining a greater understanding of what your organization does, how it functions, and how well you are positioned to leverage and exploit your strategic, business position in the marketplace. The key to effectively interpreting the Enterprise Architecture Document lies in understanding the relationships, interactions, and dependencies among the various Enterprise Architecture Perspectives. By objectively examining your organization, you will notice opportunities for improving your processes, policies, and productivity. Enterprise Templates should be included as part of your organization's complete, cohesive Enterprise Architecture Plan because they can leverage your current standards, best practices, and policies. We will see why Enterprise Templates are considered indispensable by some organizations as we progress through this article series. So far, you learned that Enterprise Architecture is a series of activities designed to help you better understand and manage your organization. The output of the Enterprise Architecture process is the Enterprise Architecture Document, which summarizes your discoveries. You learned that Enterprise templates are indispensable for many organizations and when implemented, reduce the cost of creating, planning and deploying software systems. Before Enterprise Templates are investigated further, you must learn how Distributed Application Architecture relates to Enterprise Template planning and implementation. Section 3: Distributed Application Architecture Distributed Applications are often large, complex systems with multi-tiered architectures, comprising thousands of globally deployed components. When we talk about large, complex systems, we mean software systems containing thousands of individual components as part of the problem domain solution. When we talk about a software system having many tiers, we mean the problem domain - or the software system being considered - can be conceptually, logically, and physically separated into layers. These layers implement and expose functionality that accomplishes various tasks for the application correlating with the conceptual purpose of the tier. When we talk about an application being globally deployed, we mean the software system is comprised of components deployed on many platforms, using many technologies, and installed on devices worldwide - whether the devices are virtual machines, servers, hand-held computers or other personal communication devices. These devices are then connected to a communication channel, such as a wireless network or the Internet, enabling the sharing of data and resources. When Enterprise Templates are used to develop distributed applications, they utilize Microsoft's Distributed Application Architecture Mode l recommended. There are seven layers to a Distributed Application Architecture: the Business Services Layer, the Business Facade Layer, the Business Rules Layer, the Data Access Layer, the System Frameworks Layer, the Web Services Layer, and the Web User Interface and Windows User Interface Layers. The Business Services Layers is a conceptual container for two other layers, the Business Facade Layer and the Business Rules Layer. The Business Facade Layer organizes the application business objects around the use cases developed during the analysis and design phase of the Software Design Life Cycle (SDLC). This layer maps possible execution paths to underlying business object functionality. The Business Facade Layer generally acts as a buffer between the User Interface Layer and the Business Rules Layer. The Business Facade Layer abstracts the caller from the intricate details of the called business objects. When business objects are modified, the Business Facade Layer needs only minimal changes. The Business Rules Layer contains the physical business objects and their implementations. It might also call database stored procedures or external routines via calls to the Data Layer. The data returned from executing an object in the Business Rules Layer is returned to the Business Facade Layer. The Data Layer manipulates data in databases, files, or other data repositories; it may also call external services such as Web Services to perform tasks. The data retrieved from calling into the Data Layer is returned to the Business Rules Layer where the Business Rules Layer performs data validation checks, range checks, and other checks, before returning the data to the Business Facade Layer. The Data Layer should strictly function as a data pump - providing data to requests for data and nothing else. The System Frameworks Layer can be called from any layer in the Distributed Application Architecture. Source code in the Frameworks Layer is logically organized into namespaces; each one containing a logical grouping of source code for solving a specific task, or groups of tasks. The System Frameworks Layer should contain common, reusable functionality, organized into conceptual hierarchies by namespaces. The User Interface Layer typically comprises a series of Windows Forms, Web Forms, a combination of both, or no interface at all - depending upon the type of application under development. User interfaces typically present, capture, and validate data. They also process error messages and provide both contextual and online help for the application user. The User Interface Layer is also called the Presentation Layer. In summary, Distributed Applications are often large, complex systems with multi-tiered architectures, comprising thousands of globally deployed components. Applications that implement their functionality in logically separate layers are classified as Distributed Applications, or multi-tier applications. Distributed Applications can be built using the following layers: the Business Services Layer, the Data Layer, the System Frameworks Layer, and the User Interface Layer. Distributed Applications provide the foundational reference for the Enterprise Template implementation in Visual Studio .NET. They are also among the most complex applications constructed within Visual Studio .NET. To make creating Distributed Applications productive, effective and intuitive, Microsoft introduced the Enterprise Template. Section 4: Enterprise Template Advantages The Enterprise Template is an intuitive, productive, and cost-effective mechanism for rapidly developing Distributed Applications using Visual Studio .NET. The advantages of using Enterprise Templates include: - Rapidly defining the initial structure of distributed applications
- Providing architectural best practices and suggestions
- Providing technological best practices and suggestions
- Minimizing collections of white papers, standards, and policies documents
- Reducing developer mistakes implementing best practices and standards
An Enterprise Template divides an application into the layers mentioned above - the Business Services Layer, the Data Layer, the Framework Services Layer, and the User Interface Layer. Projects are added to each layer, providing the application's services, components, and internal and external interfaces. Once an Enterprise Template has been created, the developer has a majority of the common, routine coding tasks already coded; the initial application structure is defined as well. In future articles, we will learn how Visual Studio .NET makes it easy, intuitive, and enjoyable to create your own customized Enterprise Templates. Section 5: Enterprise Template Architecture An Enterprise Template contains three main items: a prototype, a policy file, and custom help topics. It may contain two types of projects: Enterprise Template projects and Language Projects. Enterprise Template Projects have the ".etp" extension, while Language Projects have the extension of the language itself. For example, a C# Language Project would have the extension of ".csproj". 
( figure 2.0 )
Prototypes are pre-built language projects that encapsulate some specific functionality. Common types of prototypes include Login Screens, Splash Screens, Windows Forms, Web Forms, Class Libraries, Windows Control Libraries, Web Control Libraries, Windows Services and Web Services. Prototypes are implemented using any language that supports the specifications of the Microsoft .NET Common Language Runtime (CLR). Policy files allow you to restrict and filter which items are used to build your application. Policy files are authored using a special XML Grammar called the Template Definition Language (TDL). The elements in figure 4.0 are combined to create Enterprise templates. Figure 3.0 lists the node hierarchy of the "DAP.tdl" file for an Enterprise Template policy file. In addition to defining which projects and items are allowable for the current project, a Policy File also configures the Visual Studio .NET IDE elements such as menus and toolboxes. By associating custom help topics with your Enterprise Template, you enable others to more easily understand its structure and usage. The basic rule to follow when deciding to include dynamic help for your templates is this: if you can provide help, do it. If you were trying to determine the capabilities of an enterprise template authored by someone else, what would you need to completely understand the internal working of the template? Section 6: Enterprise Template Policy Files This is the schema representing the node hierarchy in an Enterprise Template Policy File. The node names are taken from the XML Grammar Elements listed in figure 4.0. Enterprise Template Policy Files have a file extension of ".tdl". The ".tdl" Policy File is designed, customized, associated with an Enterprise Template Project file (".etp" file), then deployed for use. When users create a project based upon an Enterprise Template, its associated policy file is consulted, parsed, and loaded into memory; the individual projects are loaded into a Visual Studio .NET Solution, and the customizable items of the Visual Studio .NET IDE are modified according to the policy file configuration settings. DAP.tdl Policy File 1 : TDL
2 : DEFAULTSETTINGS
3 : DEFAULTACTION
4 : ORDER
5 : POLICYMODE
6 : CONSTRAINTS
7 : PROPERTYCONSTRAINTS
8 : MENUCONSTRAINTS
9 : TOOLBOXCONSTRAINTS
10: ELEMENTS
11: ELEMENT
12: ID
13: CONTEXT
14: CTXTKEYWORD
15: CTXTATTRIBUTE
16: NAME
17: VALUE
18: IDENTIFIERS
19: IDENTIFIER
20: TYPE
21: IDENTIFIERDATA
22: NAME
23: VALUE
24: FEATURELINKS
25: MENULINKS
26: MENULINK
27: TOOLBOXLINKS
28: TOOLBOXLINK
29: PROTOTYPES
30: PROTOTYPE
31: CONSTRAINTS
32: PROPERTYCONSTRAINTS
33: PROPERTYCONSTRAINT
34: NAME
35: READONLY
36: DEFAULT
37: MINVALUE
38: MAXVALUE
39: MENUCONSTRAINTS
40: MENUCONSTRAINT
41: ID
42: ENABLED
43: TOOLBOXCONSTRAINTS
44: TOOLBOXCONSTRAINT
45: ID
46: ENABLED
47: ELEMENTSET
48: DEFAULTACTION
49: ORDER
50: INCLUDE
51: EXCLUDE
52: CONSTRAINTS
53: PROPERTYCONSTRAINTS
54: MENUCONSTRAINTS
55: TOOLBOXCONSTRAINTS
56: MEMBERCONSTRAINTS
57: MEMBERCONSTRAINT
58: ID
59: PROPERTYCONSTRAINTS
60: MENUCONSTRAINTS
61: TOOLBOXCONSTRAINTS
62: CATEGORIES
63: CATEGORY
64: ID
65: CATEGORYMEMBER
66: FEATURES
67: MENUS
68: MENU
69: ID
70: CMDID
71: GUID
72: TOOLBOXITEMS
73: TOOLBOXITEM
74: ID
75: DESCRIPTOR |
( figure 3.0 ) Section 7: Enterprise Template Definition Language (TDL) An Enterprise Template is built using an XML grammar that specifies the projects, items, and constraints that comprise the template definition. The grammar elements in this table comprise the Template Definition Language (TDL) and represent the available grammar elements for constructing Enterprise Templates. You will learn more about the Enterprise Template Definition Language (TDL) in article 3 titled, "Enterprise Template TDL Language." Template Definition Language (TDL)
Grammar Elements | | | | | | ●CATEGORIES | ●CATEGORY | ●CATEGORYMEMBER | ●CMDID | ●CONSTRAINTS | ●CONTEXT | ●CTXTATTRIBUTE | ●CTXTKEYWORD | ●DEFAULT | ●DEFAULTACTION | ●DEFAULTSETTINGS | ●DESCRIPTOR | ●ELEMENT | ●ELEMENTS | ●ELEMENTSET | ●ENABLED | ●EXCLUDE | ●FEATURELINKS | ●FEATURES | ●GUID | ●ID | ●IDENTIFIER | ●IDENTIFIERDATA | ●IDENTIFIERS | ●INCLUDE | ●MAXVALUE | ●MEMBERCONSTRAINT | ●MEMBERCONSTRAINTS | ●MENULINK | ●MENULINKS | ●MENUS | ●MINVALUE | ●NAME | ●ORDER | ●POLICYMODE | ●PROPERTYCONSTRAINT | ●PROPERTYCONSTRAINTS | ●PROTOTYPE | ●PROTOTYPES | ●READONLY | ●TDL | ●TOOLBOXCONSTRAINT | ●TOOLBOXCONSTRAINTS | ●TOOLBOXITEM | ●TOOLBOXITEMS | ●TOOLBOXLINK | ●TOOLBOXLINKS | ●TYPE | ●VALUE | | | | | | |
( figure 4.0 ) Section 8: Enterprise Template Building Blocks Enterprise Template Building Blocks are Visual Studio .NET projects written in any language supported by the .NET Framework and the CLR. Policy files are associated with each project. There are two types of policy files: the "Vside.dtl" and "DAP.tdl" file. The Vside.tdl file configures the IDE Environment. The DAP.tdl file provides common, shared functionality to distributed application project types. You should copy and then customize the DAP.tdl file to fit your specific distributed application's needs. Suppose you defined your Enterprise Template using the following structure: 
( figure 5.0 )
Figure 5.0 contains a nested hierarchy of embedded Enterprise Template projects; each template contains C# Language projects; each Enterprise Template is associated with policy files. In Figure 5.0 , the parent Enterprise Template "MyTemplate" contains three other child templates: "BackendProjects", "UIProjects", and "UtilityProjects." Each of these templates aligns to its associated policy files. Remember, the two policy files are the DAP.tdl policy file and the Vside.tdl policy file. The "BackendProjects" Template contains a single Web Service named "Service1.asmx". If more Web Services need to be added to this template, they will be added under the "BackendProjects" template. When a user opens our Enterprise Template for the first time, all the projects listed under the "BackendProjects" template will be automatically included in the new application. The "UIProjects" Template contains a single C# Windows Forms Application named "WinApp". Notice that you can add your Splash Screen, Login Screen, Help Screen, and other screens, to the "WinApp" project of the "UIProjects" template. When a user opens your Enterprise Template for the first time, all projects listed under the "BackendProjects" Template, as well as those listed in the "UIProjects" Template, will be automiatically included in the new application. The "UtilityProjects" Template contains a single C# Class Library called "UtilityLibrary", which contains a single class named "Class1." If more classes need to be added to this class library, they become associated to the "UtilityProjects" Template, and are inserted into the "UtilityLibrary" class library project. When a user opens our Enterprise Template named "MyTemplate", all projects contained within the "BackendProjects", "UIProjects', and "UtilityProjects" Templates will be included in the new application. Section 9: Enterprise Template Dynamic Help In Visual Studio .NET, the Dynamic Help Window functions as a context-sensitive, inline version of the standard help files. To receive dynamic help, the dynamic help window must be visible; it must be the active window; and you must select the item for which you want to receive help. The guidance you receive from the help topic should better explain something or provide some useful information. Enterprise Templates should provide dynamic help, which makes the template more intuitive and easy to use. Displaying Dynamic Help for your Enterprise Template involves creating your help topics, creating your custom context files, and inserting a <CONTEXT> node into the policy file associated with your template. Dynamic Help Topics can be associated with individual template elements. When a user selects an Enterprise Template element, a help topic automatically displays in the Dynamic Help window. To automatically associate and load a dynamic help topic, Visual Studio .NET consults a file named "context.xml". This file cross-references the dynamic help window topics, the policy file associated with your Enterprise Template, and the help topic to display to your template consumer. You must create your own XML file based upon the "context.xml" file to display your own custom help topics in the Dynamic Help window. The "context.xml" file is located in the following directory: C:\Program Files\Microsoft Visual Studio .NET\Common\IDE\HTMLXMLLinks\1033. Adding help files to your Enterprise Templates make your templates easier to use when questions arise. Summary The .NET Architect Enterprise Template Series comprises the following articles: - Article 1: Enterprise Template Overview
- Article 2: Enterprise Template Policy Files
- Article 3: Enterprise Template TDL Language
- Article 4: Enterprise Template Dynamic Help
- Article 5: Enterprise Template Exercise
- Article 6: Enterprise Template Editor Add-In
- Article 7: Enterprise Template Editor Web Service
- Article 8: Enterprise Template Editor Windows Service
- Article 9: Enterprise Template Editor Web Control
- Article 10: Enterprise Template Editor Windows Control
- Article 11: Enterprise Template Editor Framework
- Article 12: Enterprise Template Developer Notes
This article introduced you to Visual Studio .NET Enterprise Templates and their advantages. You learned about Enterprise Architecture Planning and how Enterprise Templates are a solid, cohesive part of an Enterprise Architecture Plan. You learned about Distributed Application Architecture as it relates to Enterprise Architecture and Templates. You were introduced to Enterprise Template Architecture, Template Policy Files, the Template Definition Language (TDL), Template Building Blocks, and Dynamic Enterprise Template Help. You learned that Enterprise Templates do not exist in a stateless technological vacuum; they exist to compliment other Enterprise Architectures and Technologies. The Enterprise Architecture discipline involves performing an objective evaluation of your organizational structure and how it functions. The evaluation spans the planning, organizational, systems, data, and technological divisions within your organization. The output of the Enterprise Architecture Process is the Enterprise Architecture Document. There are four perspectives to Enterprise Architecture: the Business Perspective, the Application Perspective, the Information Perspective and the Technology Perspective. You learned that Distributed Applications are often large, complex systems with multi-tiered architectures, comprising thousands of globally deployed components. Distributed Applications can be built using the following layers: the Business Services Layer, the Data Layer, the System Frameworks Layer, and the User Interface Layer. Distributed Applications provide the foundational reference for the Enterprise Template implementation in Visual Studio .NET. The are many advantages of using Enterprise Templates including: - Rapidly defining the initial structure of distributed applications
- Providing architectural best practices and suggestions
- Providing technological best practices and suggestions
- Minimizing collections of white papers, standards, and policies documents
- Reducing developer mistakes implementing best practices and standards
An Enterprise Template contains three main items: a prototype, a policy file, and custom help topics. It may contain two types of projects: Enterprise Template projects and Language Projects. Enterprise Template Projects have the ".etp" extension, while Language Projects have the extension of the language itself. Policy files allow you to restrict and filter which items are used to build your application and are authored using a special XML Grammar called the Template Definition Language (TDL). An Enterprise Template is built using an XML Grammar that specifies the projects, items and constraints that comprise the template definition. This grammar is called the Template Definition Language (TDL) and represents the available grammar elements for constructing Enterprise Templates. Enterprise Template Building Blocks are Visual Studio .NET projects written in any language supported by the .NET Framework and the CLR. Policy files are associated with each project. There are two types of policy files: the "Vside.dtl" and "DAP.tdl" file. The Vside.tdl file configures the IDE Environment. The DAP.tdl file provides common, shared functionality to distributed application project types. You should copy and then customize the DAP.tdl file to fit your specific distributed application's needs. In Visual Studio .NET, the Dynamic Help Window functions as a context-sensitive, inline version of the standard help files. To receive dynamic help, the dynamic help window must be visible, it must be the active window, and you must select the item for which you want to receive help. Displaying Dynamic Help for your Enterprise Template involves creating your help topics, creating your custom context files, and inserting a <CONTEXT> node into the policy file associated with your template. About The Author Brian has worked in the Information Technology profession since 1995. He currently lives in Denver, Colorado with his wife and family. He enjoys road trips, hiking, fishing, and spending time in the mountains of Colorado. Brian worked for Microsoft as an ASP.NET Support Engineer during the worldwide launch of Visual Studio .NET. While at Microsoft, Brian developed an interest in researching .NET language development, .NET Windows Services, and IDE programmer productivity add-ins. He is writing textbooks for teaching C# and VB.NET to aspiring developers. If you interested in his book, please contact him at: VBAnswerGuy@adelphia.net.
|
