1. Trang chủ
  2. » Công Nghệ Thông Tin

Microsoft SQL Server 2005 Developer’s Guide- P28 pdf

10 304 0

Đang tải... (xem toàn văn)

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 10
Dung lượng 458,26 KB

Nội dung

Chapter 7: Developing with XML 249 also supported. The PORTS keyword specifies the TCP/IP port that will be used. Supported vales are CLEAR (default 80) or SSL (default port 443). CLEAR is used to respond to HTTP requests, while SSL requires HTTPS. Finally, the SITE keyword specifies the name of the host SQL Server system. The FOR SOAP clause describes the Web service. The WEBMETHOD keyword specifies the name of the Web method that will be executed by the Web service. The name keyword is used to link the Web method to the stored procedure on the SQL Server system. In this example when the Web Service GetManagers method is executed, it will in turn call the uspGetEmployeeManagers stored procedure in the AdventureWorks database. The FORMAT key indicates the type of results that will be returned by the Web service. Support values are ALL RESULTS and ROWSETS_ ONLY. If you want the client system to be able to consume the results of the Web service as a dataset, then you must specify the value of ROWSETS_ONLY. While this example uses a single Web method, you can specify multiple Web methods per endpoint. The WSDL keyword indicates whether the endpoint supports WSDL. The value of DEFAULT means that WSDL is supported. NONE indicated WSDL is not supported. Alternatively, you can provide a stored procedure name to implement a custom WSDL. The SCHEMA keyword specifies whether an inline XSD schema will be returned for the Web method. Supported values are NOE and SCHEMA. The DATABASE keyword specifies the name of the default database. The NAMESPACE keyword is used to supply a namespace for the endpoint. Once the HTTP endpoint is created, it can be accessed via a SOAP request issued by an application. You can list the SOAP endpoints that have been created by displaying the contents of the sys.soap_endpoints system view. select * from sys.soap_endpoints You can use the ALTER ENDPOINT and DROP ENDPOINT DDL statements to manage SQL Server’s HTTP endpoints. The new HTTP endpoints are also able to provide data stream encryption using SSL. Using SOAP Endpoints If the SOAP endpoint is created using the STATE value of STARTED, it can be accessed immediately after the command completes. However, before users can connect to the endpoint, they must be granted connect rights to that endpoint. The basic syntax for the CONNECT ON ENDPOINT statement follows: { GRANT | DENY | REVOKE } CONNECT ON ENDPOINT:: <EndPointName> TO <login> 250 Microsoft SQL Server 2005 Developer’s Guide The GRANT, DENY, and REVOKE permissions all work exactly like the standard SQL Server object security. GRANT allows access, DENY prohibits access, and REVOKE undoes the current permissions. The EndPointName identifies the endpoint, and the login identifies the database login. For instance, the following command illustrate how you might use the GRANT CONNECT permission to enable the Sales group to connect to the MyAdWWebService: GRANT CONNECT ON ENDPOINT:: MyAdWWebService to HR Querying the Web Service Using WSDL WSDL (Web Services Description Language) is used to create XML documents that describe a Web service. Such a document specifies the location of the service and the operations (or methods) the service exposes. WSDL provides the information necessary for a client to interact with a Web service. Tools such as Visual Studio .NET and JBuilder use the WSDL to generate proxy code that client applications can use to communicate with a Web service. If the endpoint has WSDL enabled, that endpoint will produce WSDL when it receives a request for it. For example, the following listing shows how to request the WSDL for our sample SOAP endpoint. http://sql2005-2/AdwWS?wsdl NOTE You will need to replace the value of sql2005-2 with either the name of your server or the value of localhost if you are running the browser on the same system as your SQL Server 2005 instance. In this example the value of sql2005-2 is the name of the SQL Server system where the Web service is located. The value of /AdWWS refers to the path or virtual directory for the Web service. This corresponds to the value used in the CREATE ENDPOINT statement’s PATH keyword. You can see an example of the WSDL displayed in the browser in Figure 7-2. Calling the Web Service After the SOAP endpoint has been created and the users have been granted connect access to the endpoint, you call the Web service from your client applications. The following section illustrates how to build a VB.NET application that calls the Web service. You can see the sample application in Figure 7-3. Chapter 7: Developing with XML 251 Figure 7-2 Displaying the Web service’s WSDL Figure 7-3 The Web service client application 252 Microsoft SQL Server 2005 Developer’s Guide To use the sample application to call the Web service and display the result in the grid, the user enters an employee ID number in the text box and then clicks the Call GetManager button to execute the Web service and display the result set in the grid. To create this project, you open Visual Studio 2005 and select a new Visual Basic Windows Forms project. Open the designer and drag a Button control, a TextBox control, and a DataGridView control to the design surface. After arranging the interface elements, you need to add a reference to the Web service by selecting the Project | Add Web Reference option, which will display a dialog like the one shown in Figure 7-4. In the URL prompt enter the same URL that you would use to display the Web services WSDL. Then click Go. If Visual Studio finds the Web service, it will be listed on the screen as you see in Figure 7-4. You can optionally rename the reference using the Web Reference Name text box. You add the Web reference to your project by clicking Add Reference. After adding a reference to the Web service, you can create the code to execute the Web service. You can see the code that calls the GetManagers Web method and displays the results in the following listing: Figure 7-4 Adding a Web reference Chapter 7: Developing with XML 253 Imports.System.Data Private Sub Button1_Click(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles Button1.Click ' Create a new instance of the web service Dim MyAdWService As AdWWS.MyAdWWebService = New _ AdWWS.MyAdWWebService() ' Authenticate to use the service MyAdWService.Credentials = _ System.Net.CredentialCache.DefaultCredentials ' The web service results converted to a DataSet Dim ds As System.Data.DataSet = DirectCast _ _(MyAdWService.GetManagers(TextBox1.Text), DataSet) ' Display the Results DataGridView1.DataSource = ds.Tables(0) End Sub To create a bit more readable code, I first renamed the Web reference from sql2005-2 to AdWWS by right-clicking the reference in the Solution Explorer window and then typing in the new name. After the Web reference was renamed, the code that you see near the top of this listing creates a new instance of the Web service, named MyAdWService. Then the Credentials property of that object is assigned the value of System.Net. CredentialCache.DefaultCredentials, which causes the client program to pass the user’s Windows credentials to the Web service for authentication. Next, a DataSet named ds is created to contain the results passed back from the Web service. The ds DataSet is then assigned the results of the GetManagers call. The call to GetManagers passes in the value that the user enters into a text box. After the DataSet is populated with the results from the Web service call, it is bound to a DataGridView object and the results are displayed to the end user. Summary The new XML data type adds a whole new level of relational database-XML integration capabilities to SQL Server 2005. In this chapter you saw how to declare and use both typed and untyped XML data values as well as how to use the FOR XML statement, how to bulk load XML data, and how to create HTTP and SOAP endpoints for XML Web Services. This page intentionally left blank 255 CHAPTER 8 Developing Database Applications with ADO IN THIS CHAPTER An Overview of OLE DB OLE DB Architecture Overview ADO (ActiveX Data Objects) OLE DB and ADO Files ADO Architecture Adding the ADO Reference to Visual Basic Using ADO Objects with Visual Basic Advanced Database Functions Using ADO Copyright © 2006 by The McGraw-Hill Companies. Click here for terms of use. 256 Microsoft SQL Server 2005 Developer’s Guide I n this chapter, you will see how to develop SQL Server database applications using Visual Basic and ActiveX Data Objects (ADO). In the first part of this chapter, you get a brief overview of OLE DB, with a look at the OLE DB architecture, as well as the basic relationship of OLE DB and ADO. The second part of this chapter illustrates the basic ADO database programming techniques used to build SQL Server database applications. Microsoft created OLE DB as the successor to ODBC. ODBC was primarily designed to handle relational data, and the ODBC API is based upon SQL. While it works well for relational database access, it was never intended to work with other, nonrelational data sources. Like ODBC, OLE DB provides access to relational data, but OLE DB extends the functionality provided by ODBC. OLE DB has been designed as a standard interface for all types of data. In addition to relational database access, OLE DB provides access to a wide variety of data sources, including tabular data such as Excel spreadsheets, ISAM files such as dBase, e-mail, Active Directory, and even IBM DB2 data. Using OLE DB, you can access many different and diverse data sources using a single interface. An Overview of OLE DB As its name implies, OLE DB is built on an OLE foundation. Unlike ODBC, which provides a DLL call-level interface, ADO provides a COM interface for OLE DB that allows it to be called from other OLE-compliant applications. OLE DB has been created with the understanding that business data is maintained in a variety of diverse data sources. OLE DB provides a similar interface to all sorts of data. OLE DB can be used to access any data that can be represented in a basic row and column format. OLE DB Architecture Overview Applications that use OLE DB are typically classified as either OLE DB providers or OLE DB consumers. Figure 8-1 illustrates the relationship between OLE DB providers and OLE DB consumers. As you can see, OLE DB consumers are nothing more than applications that are written to use the OLE DB interface. In contrast, OLE DB providers are responsible for accessing data sources and supplying data to OLE DB consumers via the OLE DB interface. More specifically, there are actually two types of OLE DB providers: data providers and service providers. Data providers simply expose the data from a data source, while service providers both transport and process data. Service providers Chapter 8: Developing Database Applications with ADO 257 typically provide more advanced functions that extend the basic data access found in OLE DB data providers. Microsoft Query is an example of an OLE DB service provider, while the Microsoft OLE DB Provider for SQL Server is an example of a data provider. As you would expect from its ODBC roots, OLE DB provides different levels of functionality based on the capabilities of the different OLE DB providers. While all OLE DB drivers support a common interface, each individual driver is able to extend the basic level of OLE DB functionality. The following OLE providers are shipped with SQL Server 2005: ᭤ Microsoft SQL Native Client OLE DB Provider ᭤ Microsoft OLE DB Provider for ODBC ᭤ Microsoft OLE DB Provider for Jet ᭤ Microsoft OLE DB Provider for DTS Packages ᭤ Microsoft OLE DB Provider for Oracle Very similar to ODBC, each different OLE DB source uses its own OLE DB provider. Figure 8-2 illustrates how different OLE DB providers are required to access multiple data sources. In this figure, you can see a high-level overview of how a Visual Basic application might use OLE DB to access several heterogeneous data sources. With the exception of ODBC databases, each different data source is accessed using a different OLE DB provider. For example, SQL Server databases are accessed using SQLOLEDB, Microsoft’s SQL Server’s OLE DB provider. Data contained in Microsoft Excel or Exchange is accessed using their respective OLE DB providers. ODBC is an exception to this one OLE DB provider-per-data-source rule. To provide maximum Applications (OLE DB Consumer) OLE DB Interface OLE DB Provider Data Sources Figure 8-1 OLE DB consumers and providers 258 Microsoft SQL Server 2005 Developer’s Guide compatibility with existing ODBC data sources, Microsoft developed MSDASQL, the OLE DB provider for ODBC. Unlike most OLE DB providers, which provide direct database access, the MSDASQL OLE DB provider for ODBC accesses data using existing ODBC drivers. The MSDASQL OLE DB provider for ODBC maps OLE DB calls into their equivalent ODBC calls. Each OLE DB provider delivers data access and reflects its capabilities through its exposed COM interfaces. However, the OLE DB COM interface is a low-level interface that requires support for pointers, data structures, and direct memory allocation. As a result, the direct use of OLE DB providers is unsuitable for development environments that don’t support low-level functions like pointers, such as Visual Basic, VBA, VBScript, Java, JScript, JavaScript, and several others. This is where ADO fits in: ADO allows OLE DB providers to be accessed by interactive and scripting languages that need data access but don’t support low-level memory access and manipulation. ADO (ActiveX Data Objects) ADO is essentially an OLE DB consumer that provides application-level access to OLE DB data sources. ADO is an OLE automation server that most OLE-compliant development and scripting environments can access. Both OLE DB and ADO are VB Application ADO OLE DB for ODBC (MSDASQL) ODBC Driver OLE DB for SQL Server (SQLOLEDB) OLE DB Provider OLE DB Provider OLE DB Provider Excel Exchange Other Data Sources ODBC Data Source SQL Server Other Figure 8-2 OLE DB overview . with SQL Server 2005: ᭤ Microsoft SQL Native Client OLE DB Provider ᭤ Microsoft OLE DB Provider for ODBC ᭤ Microsoft OLE DB Provider for Jet ᭤ Microsoft OLE DB Provider for DTS Packages ᭤ Microsoft. are running the browser on the same system as your SQL Server 2005 instance. In this example the value of sql2 005-2 is the name of the SQL Server system where the Web service is located. The. McGraw-Hill Companies. Click here for terms of use. 256 Microsoft SQL Server 2005 Developer’s Guide I n this chapter, you will see how to develop SQL Server database applications using Visual Basic

Ngày đăng: 05/07/2014, 05:20

TỪ KHÓA LIÊN QUAN