Your Development Environment: The Big Picture


Before going into the specific hardware and software requirements for SQL-NS, it's important to understand the high-level picture of the development environment you'll need to set up. This section describes the environment in general terms, and the following sections provide detailed instructions on how to set it up.

Terminology Clarification

The term "SQL Server" has several meanings, depending on the context in which it is used. When used as a noun by itself, such as "connect to your SQL Server," it generally refers to an instance of the relational database server. This is also sometimes referred to as the "database engine." When used as a qualifier to another noun, such as "consult the SQL Server documentation," it usually refers to the SQL Server 2005 product as a whole. Throughout this chapter and the remainder of this book, I have tried to use these forms consistently.


Computers

First, you'll need a computer on which to do your development. You'll install the SQL-NS tools and execution engine on this computer. You'll use the SQL-NS tools to write, compile, and debug your applications and you'll invoke the SQL-NS execution engine to run them.

You'll also need a SQL Server 2005 database server. When you build your applications, SQL-NS creates or modifies databases on this SQL Server, and when your applications run, they manipulate the data in these databases.

The simplest and most convenient arrangement is to have the SQL Server run on your development computer. Throughout the remainder of this book, I'll refer to this configuration as the local SQL Server configuration. If you are able to set up your system this way, I highly recommend doing so. (Remember that the recommendations in this chapter are for development only; in deployment, it may be best to run your SQL Server on a different computer than the SQL-NS engine.)

If the constraints in your environment prevent you from installing a local SQL Server on your development computer, don't be concerned; SQL-NS fully supports development against a SQL Server that runs on a remote computer. This chapter includes instructions on how to set up your environment to support this. I'll refer to this as the remote SQL Server configuration.

In the following sections (and in the rest of this book), I'll refer to the computer on which you do your development as your development machine. I'll refer to the computer running the SQL Server database engine as your SQL Server computer, or just your SQL Server. If you're using the local SQL Server configuration, the development machine and the SQL Server will be the same physical computer.

Tools for the Development Process

The development process of a SQL-NS application is similar to that of any other application: You write code, compile that code, and then test and debug it. The following sections describe the tools you'll need to perform these steps in the development process.

SQL Server 2005 Management Studio

SQL Server 2005 Management Studio is the new, standard tool for managing SQL Server 2005 databases. It's a part of the client tools suite that ships with SQL Server 2005. In addition to supporting the usual database management operations, Management Studio also provides powerful T-SQL and XML editors, as well as other tools used in database application development. If you're familiar with the SQL Server 2000 client tools, think of Management Studio as a combination of Query Analyzer and Enterprise Manager, integrated with some features of the Visual Studio .NET development environment.

Building a SQL-NS application mainly involves writing XML documents that declare the application's data types, logic, and configuration, processing those XML documents with the SQL-NS compiler, and testing the application using T-SQL scripts. Management Studio is an ideal tool for doing all these tasks. The XML editor built in to Management Studio provides syntax highlighting, syntax checking, XSD validation, and IntelliSense statement completion, all of which make the task of defining SQL-NS applications easier. The T-SQL editor is just as powerful and useful when testing SQL-NS applications. In addition, all the SQL-NS compilation and management tools are available directly in the Management Studio user interface.

In all the examples in this book, Management Studio will be the primary development environment for building SQL-NS applications. Chapter 3, "The Simplest Notification Application: Stock Quotes," introduces the first sample SQL-NS application and uses Management Studio to examine its XML definition. Chapter 4, "Working with SQL-NS Instances," explains the SQL-NS tools built in to Management Studio in detail.

Visual Studio .NET 2005

Visual Studio .NET 2005 is Microsoft's premier development environment for building applications based on the .NET Framework 2.0. Some aspects of building a SQL-NS application involve writing procedural code, and Visual Studio .NET 2005 is well suited to these tasks.

For example, if you're building a user interface for subscription management or a custom plug-in component to extend the SQL-NS framework, you'll probably be writing managed code (in C#, VB .NET, or any of the other .NET languages). Chapters 7 through 10 cover these aspects of SQL-NS application development and explain the use of Visual Studio .NET 2005.

Although Visual Studio .NET 2005 certainly makes managed code development easier, it is not strictly required to build a SQL-NS application. You can also build all the managed code components using just the .NET Framework 2.0 SDK (available as a free download from Microsoft's MSDN website, http://msdn.microsoft.com). However, all the managed code examples in this book assume you are using Visual Studio .NET 2005.

Caution

Because all components of a SQL-NS 2005 application must be based on version 2.0 of the .NET Framework, you cannot use earlier versions of Visual Studio .NET for SQL-NS 2005 development. Visual Studio .NET 2005 is the first version to support the .NET Framework 2.0. Visual Studio .NET 2003, for example, supports only the .NET Framework 1.1.


Command-Line Tools

The SQL-NS compiler and all the other SQL-NS tools are available in command-line versions, in addition to the graphical versions built in to SQL Server 2005 Management Studio. The command-line versions are useful for automating SQL-NS management tasks through scripts. In my experience, most SQL-NS users find the command-line tools most convenient to use after they have learned the basics of SQL-NS, but the graphical versions are more user friendly the first time around.

In Chapter 3's walk-through of the first SQL-NS application in this book, the instructions refer to the graphical tools only. In Chapter 4, I explain both sets of tools in detail. In subsequent chapters, instructions reference the command-line tools only, but you should have enough information to perform the same steps using the graphical tools if you prefer.

Accounts and Security

It used to be commonplace, not so long ago, to run everything as Administrator and turn off all security features. Things were easy to configure and deploy, and you would never see those annoying Permission Denied error messages.

But hackers and virus builders exploited these careless practices. Nowadays, you have to be more careful. In every topic covered in this book, we're going to pay attention to security and configure everything we build as securely as possible. This is going to mean a few extra steps to get things running and will require some thinking about user accounts and their permissions up front. But as you will see, maintaining a focus on security is not difficult and gives you tremendous peace of mind.

SQL-NS is designed to enable notification applications to run securely. Although SQL-NS development and administration tasks require Administrator permissions, the SQL-NS runtime execution components are designed to run in much lower-privileged security contexts.

When thinking about security for SQL-NS applications, the first account to consider is the one you use to log in to your development machine to build your applications. This account requires administrative privileges on the development machine because it'll be installing Windows Services and creating Registry keys, among other operations.

The account will also need system administrator permissions on the target SQL Server because some of the operations you do during SQL-NS application development install and manipulate tables in system databases. The section "SQL Server Authentication Modes" (p. 25) describes the various ways you can connect to your SQL Server; the particular mode you choose affects the way you configure your SQL Server permissions. Specific instructions for setting up SQL Server permissions are provided in the section "Setting Up SQL Permissions and Accounts" (p. 32).

The other account to consider is that under which the SQL-NS engine runs. The engine is usually run as a Windows Service, which you configure to run under a particular account. It's recommended that this account not have Administrator privileges. That way, in the unlikely event that the service should become compromised by a hacker or a virus, any code injected into the service process will not be capable of doing much harm. The account under which the engine runs needs only a few specific permissions on the SQL Server to run your applications. You'll grant the service account basic login access to the SQL Server as you work through the instructions in this chapter; you'll grant the other permissions it requires when you create each application. (The required permissions are explained in Chapter 4.)

Note

Chapter 17, "Hosting the SQL-NS Execution Engine," describes how you can host the SQL-NS engine in any application process. When hosted this way, the SQL-NS engine will assume the credentials of the hosting process. The account under which that process runs will need to be granted the same permissions normally granted to the Windows Service account.


SQL Server Authentication Modes

SQL Server offers two authentication modes by which a user can log in to the database server: Windows Authentication and SQL Server Authentication. With Windows Authentication, Windows credentials are used to authenticate the user and log in to the database server. With SQL Server Authentication, at the time of the connection the user supplies a SQL Server username and password, which are used to authenticate the user and log in. The SQL Server username and password used in SQL Server Authentication may be different from the Windows username and password of the user making the connection.

Windows Authentication is recommended because it's the more secure of the two methods and is easier to configure, but both methods are supported. As described in the previous section, both the account under which you do development and the account under which the SQL-NS engine runs need to connect and log in to the SQL Server. You can use either Windows Authentication or SQL Server Authentication for these connections.

Your choice of authentication mode affects how the SQL-NS command-line tools and the SQL-NS engine are configured. The "Environment Variables" section (p. 36) describes the settings that control the authentication mode used by the application examples in this book. Chapter 4 describes other configuration steps required for each of the modes.




Microsoft SQL Server 2005 Notification Services
Microsoft SQL Server 2005 Notification Services
ISBN: 0672327791
EAN: 2147483647
Year: 2006
Pages: 166
Authors: Shyam Pather

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net