Build Data-Driven Web Services with Updated XML Support for SQL Server 2000

Download the code for this article: SQLXML3.exe (239KB)
SUMMARY XML is becoming the ubiquitous data format on the Web, and XML support in SQL Server is evolving to meet the additional demand. Using XML, SOAP, HTTP, and SQL Server, you can now build powerful Web Services easily. To show just how simple it is with SQLXML 3.0, this article walks the reader through the process step by step, from setting up a virtual directory enabling data access via HTTP to executing queries and building Web Services. Finally, the author illustrates the creation of two Web Services clients梠ne with C# that works with the Microsoft .NET Framework and one with the SOAP Toolkit 2.0 for anyone still using earlier development tools.
It's hard to believe that XML support in SQL Server?2000 has been around for over two years. In the software world, that's a lifetime. SQL Server 2000 was the first version to provide native support, and this was limited to the more basic XML feature set (template queries, mapping schemas, and OPENXML). Using simple HTTP queries you could retrieve formatted relational data in XML format. With a little help and some Extensible Stylesheet Language (XSL) magic, you could spit out the data in a formatted, HTML-friendly manner. Later, with the introduction of features like updategrams, you could easily submit an XML-based SQL template to insert or update rows of information in SQL Server with little effort.
Initially, I thought that some would consider XML support a frivolous addition to an already powerful product. If a developer wasn't displaying SQL data in a Web page or feeding a system that only speaks XML, were these features all that useful?
Previously, the only viable approach for accessing data, for the middle-tier anyway, was through a traditional data access layer built with ODBC, OLE DB, or ADO. Now with SQLXML 3.0, SQL Server 2000, SOAP, BizTalk? and the .NET Framework, XML is no longer a frivolous addition梚t's the data language of choice.

Using SQLXML 3.0 for Data Access
SQLXML 3.0 is the third iteration of XML support for SQL Server. The biggest difference between the old way of representing data and the way it's represented with XML is how the rowset is created, where it is created (server-side or client-side), and how it is formatted (raw, nested, element-based, or attribute-based). For more on raw and explicit formats, refer to the information listed in the article summary.
For those of you already working with some of the .NET server products such as BizTalk, managed classes, and the like, you already know how important it is to use XML as your data format. If using XML for data access is new to you, this may take some getting used to. If you choose to use XML as your data format, you must take into account the subtle differences between relational and hierarchical representation and how you can exploit the benefits of a hierarchy.
If you are upgrading from a previous version, you can still run SQLXML 3.0 side by side with your current version. (See the sidebars "Side-by-side Support" and "Evolution of XML Support" for more information.)

Querying SQL Server with XML
The fastest way to begin accessing SQL Server 2000 using XML is through your browser. This is a great way to check whether you have everything set up correctly, and is also your first means of diagnosing problems should they appear. To access SQL Server using a URL via the browser or any HTTP client, you must first set up a virtual directory for SQL Server using the Microsoft?Management Console (MMC) snap-in provided with any of the releases.
If you want to set up a virtual directory to perform template queries, you can still use the MMC snap-in provided with the original installation of SQL Server. This can be found in the SQL Server 2000 program group under Configure SQL XML Support in IIS. However, to take advantage of SQLXML 3.0 features, I recommend selecting the MMC snap-in found in the SQLXML 3.0 program group under Configure IIS Support. Here you can configure all features up to and including those of version 3.0.
To set up a virtual directory, first you need to set up a directory structure with a main directory (I called mine projects) that has two subdirectories: template and SOAP. The template directory will contain your XML template files and will be used for all template operations (for example, file-based SQL, XPath, updategrams, and so on). The SOAP directory will contain all files required for accessing SQL Server via Web Services. If you want to experiment with mapping schemas (via the schema type) and/or direct database object access (via the dbobject type), then you may add directories for each of those as well. Follow these steps for testing your installation with a simple XML query.
  • To create the template virtual directory in the MMC, select Default Web Site, then New Virtual Directory.
  • On the General tab, name the virtual directory to match the database you will be accessing. I simply use Northwind (see Figure 1). This becomes the virtual directory upon which you will access any XML feature. Set this root directory to contain all templates.

    Figure 1 Good Ol'Northwind
    Figure 1 Good Ol'Northwind

  • On the Security tab, select the authentication scheme you will use to access the database.
  • On the Data Source tab, select your data source.
  • On the Settings tab, select "Allow sql= ..." and select "Allow template queries." These two will be enough to get you going. Later you will select "Allow Post" to enable calls to SQL Server as a Web Service.
  • On the Virtual Names tab (see Figure 2), select <New virtual name>, call it "template," specify the template type, and point it to the template subdirectory that should now reside under your main directory.

    Figure 2 Defining a New Virtual Name
    Figure 2 Defining a New Virtual Name

  • Name the template "Customers.xml" and save it under your template subdirectory. Any SQL command can be added to this file. Both updategrams and bulk loading can be used for updates or inserts from the template directory as well. Here you can see a sample XML query template for retrieving all customers from the Northwind database:
       <ROOT xmlns:sql="urn:schemas-microsoft-com:xml-sql">
         <sql:query client-side-xml="0">
           SELECT *
           FROM   Customers
           FOR XML AUTO
  • Now execute the following in your browser: http://localhost/northwind/template/customers.xml. You should see the XML query results shown in Figure 3 (not fancy but functional). If so, your queries are working and now you can proceed to the more advanced features of SQLXML 3.0.
Getting Started with SQLXML Web Services
If you are already doing .NET development, then you know that building Web Services is quite simple. Through Visual Studio?.NET and the runtime's use of attributes such as WebService and WebMethod, you can quickly produce reliable Web Services. Even more advanced functionality such as passing SOAP headers or hooking SOAP requests passed into a .NET Web Service (trace extensions) becomes less daunting with .NET.
If you aren't using the .NET runtime in your environment yet (sense my bias?), a little more elbow grease may be required. You can use the SOAP Toolkit 2.0, but that requires more background in how SOAP is used to send and receive data from a Web Service. Overall, however, building a non-.NET client is very similar to working with a Web Service proxy in .NET. If you don't have .NET, or you don't want to build an entire data access/Web Services framework, SQLXML 3.0 is for you.
SQLXML 3.0 provides a Web Service middle tier in the form of an ISAPI library (sqlis3.dll). All you need to do is configure SQLXML and provide a Web Services client. With SQLXML you can now send SOAP HTTP requests to a server running SQLXML 3.0 to execute a stored procedure, XML template, or UDF directly. The requested operation is executed at the data source and a SOAP response is returned to the client. The Web Services magic, at least on the server, is all taken care of by SQLXML. Just configure the Web Service using the same MMC snap-in as I demonstrated in the previous section for templates. The only code required is on the client. This can be an ASP or ASP.NET application, a Microsoft Windows?application, a console application, or whatever. The client can be built using C#, a standard SOAP client using straight XML, or even the SOAP Toolkit 2.0. In this article I will demonstrate client development by building a simple C# client (using the Visual Studio-generated Web Services proxy) and a Visual Basic?client (using the SOAP Toolkit).

Setting Up a SQLXML Web Service
If you are following along with my sample, use these steps to configure the Web Service:
  • Select the Northwind virtual directory that you created in the previous section and display its properties.
  • Select the Settings tab and make sure Allow Post is checked so that SOAP requests can be posted from the client.
  • Select the Virtual Names tab and select <New virtual name> as you did to create the template type.
  • Select the SOAP type and give it a name. I called mine "soapprocedures." You can name it anything you want and you can have as many defined SOAP types as you like. For each defined SOAP type, SQLXML creates a corresponding configuration file (.ssc) and a Web Services Description Language (WSDL) file that are used to access the Web Service. It is important to note that these files are named after the Web Service you provided, not the SOAP type. The SOAP type's name is used to retrieve the generated WSDL file, which describes the service and the operations (stored procedures, UDFs, and templates) that a client can then request.
  • Select a directory to map this SOAP type. Use the SOAP directory created earlier. This is where the .ssc and WSDL files will be created. Select Save.
  • Finally, give your Web Service a name. I called mine "procedures." This is the name you will use from your client code to instantiate the Web Service using the proxy in .NET. Figure 4 shows the WSDL output for this Web Service. You'll notice that under IIS, your virtual directory (Northwind) will have a SOAP directory and two files: procedures.ssc and procedures.wsdl. Note that by default you can't select the WSDL file directly from the browser. You need this URI: http://localhost/northwind/SOAPprocedures?wsdl.
  • When the new SOAP type is selected, select Configure.
  • Under the Soap Virtual Name Configuration dialog, select <New method mapping>.
  • Select a mapping type (SP for stored procedures and user-defined functions).
  • Select the stored procedure using the browse button, and give it a method name. The name will be the invokable Web method you will use from the client. Keep the remaining defaults. For my example I selected two stored procedures from the Northwind database, SalesByCategory and CustOrderHist, and kept the default, which simply uses the stored procedure name.
  • Test the WSDL file that contains the Web methods created from your browser as you did in the section "Setting Up a SQLXML Virtual Directory." Now let's build the clients.
A SQLXML Web Services Client Using C#
The quickest way to get up and running with Web Services is to write your client using the .NET Framework. As you will see, it isn't the amount of code saved that makes .NET simpler to use. Most of you can get away without knowing the underpinnings of the SOAP protocol since the proxy generated from Visual Studio does all of the work. However, learning some of the basic elements of SOAP would be smart. For my simple example, I use C# to call the newly configured Web Service.
I created a new client application using Visual Studio .NET. The client can be any type of application. For this example, I am using a C# application for Windows. SQLXML Web Services can be called like any other Web Service. Add a Web reference from the Add Web Reference dialog type in the same URL you used to test the WSDL file (http://localhost/northwind/SOAPprocedures?wsdl). In Figure 5 the GetAllCustomers template has been called as a Web Service and its XML results used in a DataSet grid. Figure 6 shows the sample client using ASP.NET.
The WSDL output should appear in the left pane of the Visual Studio IDE. From here, you can add the reference to your project. I added the procedures.wsdl reference, allowing me to declare a variable of this Web reference type. Once declared, I treat this type like any other class type in .NET by instantiating it. After the Web Service object is created, I can invoke its operations by calling any of its exposed methods. IntelliSense?should now display each of these Web methods in the editor.
The following C# code shows how to call a stored procedure wrapped as a Web Service. I've omitted a few details that I will explain shortly. You can see that calling a Web Service at this point is very similar to calling into any other object type:
localhost.procedures oWSProcs = new localhost.procedures();
int nReturnValue;
= oWSProcs.CustOrderHist("ALFKI", out nReturnValue);
You'll notice that this call differs from standard calls to Web Services in the return values. When using SQLXML Web Services, the data returned from the Web method takes the form of an object array, which must then be cast into a workable type like XMLElement or SqlMessage.
XMLElement objects include the result that is successfully returned by SQLXML after executing any operations (stored procedure, template, or UDF). In the WSDL file this is defined as having a SqlXML complex type. Error messages returned from SQLXML are of type SqlMessage. If SQL Server returns one or more errors, this SqlMessage complex type is returned as part of the object array and is also defined in the WSDL file. (More on this later.)
The System.XML.XMLElement complex type maps directly into an XML node class type from the .NET class library. If you have worked with .NET and XML you should already be familiar with this stock type. SqlMessage is a custom type specific to SQLXML and contains any error messages generated during transport. To make sense of the returned object array from a SQLXML Web Service, I created the XMLElement method. In Figure 7 you can see how the object array is handled.
This method takes any returned object array and either returns an array of XMLElement types or throws an exception, filling in the values from the SqlMessage type. To determine if the object array contains an error or XML instance data, the type is determined by using GetType and the value is cast appropriately. XMLElements are simply returned to the caller. Figure 8 shows the calling code in its entirety. (This is slightly different from this article's downloadable code for clarity.)
I have not yet mentioned the System.Data.DataSet type. Just because data is being transported via XML, SOAP, and ultimately SQLXML doesn't mean you cannot use DataSets to your advantage. DataSets are terrific at providing the perfect data container, not to mention being handy for purposes such as displaying data in a grid.
It's easy to return XML instance data from a stored procedure (callable from a SQLXML Web Service) and turn it into an XML schema-based DataSet, ready to be consumed as you please. To perform this conversion I created a method called GetDataSetFromXMLFragment which takes any XML fragment, infers an XML schema, and hydrates its data. The managed SQLXML classes can also be used in similar fashion.
The following code shows how the System.XML.XMLReader and the DataSet's ReadXML work together to fill a DataSet:
public static DataSet GetDataSetFromXmlFragment(XmlElement oXml)
DataSet ds = new DataSet();
    XmlTextReader oReader = new XmlTextReader(oXml.OuterXml,
      XmlNodeType.Element, new XmlParserContext(null, null, null,
    // now lets create a schema off of the instance data
    ds.ReadXml(oReader, XmlReadMode.InferSchema);
    return ds;
Don't forget, value types such as integer and float cannot be passed or returned as a null value when using the proxy classes that are generated by Visual Studio .NET. To do so, you must create your own Web Service proxy class (which is not recommended). Reference types and string types can be null.

Calling Templates and UDFs as Web Services
Along with stored procedures, SQLXML also allows Web Services to call XML templates and UDFs. Configuring these types is not very different from working with stored procedures. The configuration process establishes the necessary mapping in a WSDL file as before. Once configured, the mapping is used to execute the corresponding template or UDF just like you do with stored procedures. If you want to configure a template to use with my sample, complete the following steps:
  • Go to the properties dialog of the Northwind virtual directory.
  • On the Virtual Names tab, select the soapprocedures SOAP type created earlier and select Configure.
  • Select template as the Edit/New mapping type.
  • Select the browse button. From there you can find any previously built XML template.
  • Select the customers.xml template that you have used already to test the installation of SQLXML 3.0 and call it GetAllCustomers.
That's it. You can now call GetAllCustomers as a Web Service just like you'd call the stored procedures. GetAllCustomers will return all of the records from the Customers table as XML, but instead of using a browser I can now capture this in code. I believe this is where this release really shines. Those of you who have invoked templates in code via HTTP or through one of the OLE DB providers as I discussed in my article "BizTalk and XML: Add E-Commerce to Your App with XML and SQL Server 2000," (MSDN Magazine January 2002) will now appreciate the simplicity of uniformly invoking all operations as Web Services.
Invoking a UDF is no different. You can build the UDF shown in Figure 9 by following the same steps just outlined and selecting SP as the Edit/New mapping type as you did when configuring a callable stored procedure. All UDFs and stored procedures should appear in the browse dialog. Make sure you update your Web reference from Visual Studio .NET. (IntelliSense will tell you when it is there, or you can look at the generated WSDL.)

Using the SOAP Toolkit 2.0
Many of you may not yet have the option of using .NET technology in your development environment. If that's the case, you can invoke any SQLXML feature using plain old Visual Basic?6.0. The only additional component required prior to running the following sample code is the SOAP Toolkit 2.0. I invoke the exact same operations I created here already except I will do it from Visual Basic 6.0. Familiarity with the MSXML Document Object Model (DOM) would be helpful, but it's not required. The only two interfaces that are required are the IXMLDOMNodeList and IXMLDOMNode interfaces from MSXML 4.0.
Figure 10 looks amazingly similar to the C# sample. The major difference here is that I am doing this from a Visual Basic 6.0-based client and I am using the soapclient component from the Soap Toolkit 2.0 for the proxy. Soapclient is used exactly like the generated proxy from Visual Studio .NET. Instead of binding the return values from an object array to a data type, you will always be using an IXMLDomNodeList from MSXML 4.0 to iterate through each returned IXMLDOMNode. Here you are simply working with the MSXML Node interfaces. The output from running this code is not quite as neat as you saw in the .NET example. It could be much improved with a little XSL. I'll leave the rest up to you.

In this article I introduced SQLXML 3.0 and its most powerful application: Web Services using SOAP. For environments not ready for .NET, or those of you without the inclination to build a custom middle tier, SQLXML 3.0 provides a simple yet effective way to access SQL Server over the wire. Hierarchical data in the form of XML has become the data format of choice among developers. XML and SOAP will give you an advantage in the loosely coupled world of Web Services. To download the latest Web release (SQLXML Version 3.0) or to find more information on the new features offered in the XML for SQL Server Web Releases, see
  • 0
  • 0
    觉得还不错? 一键收藏
  • 打赏
  • 0
### 回答1: 数据驱动的电池循环寿命预测在电池容量退化之前起到了重要作用。电池的循环寿命是指电池在充放电过程中可以循环使用的次数。然而,电池容量会随着循环次数的增加而逐渐下降,最终导致电池无法继续使用。 实时监测和分析电池运行数据可以帮助我们预测电池的循环寿命。通过收集电池内部的各种参数数据,如电压、电流、温度等,可以建立一个数据模型来预测电池容量的退化趋势。这个模型可以根据历史数据和算法进行训练和优化,从而提高预测的准确性。 在预测电池的循环寿命之前,我们首先需要对电池进行较长时间的循环测试,以获取足够的数据量。然后,通过将这些实际测试数据与模型进行比对,我们可以了解电池在不同循环次数下的容量退化情况。根据这些数据,我们可以建立一个预测模型,通过监测电池的循环次数和实时数据来预测电池的剩余循环寿命。 数据驱动的电池循环寿命预测可以帮助我们及时了解电池的健康状态,并在容量退化之前采取相应的措施,如调整充电和放电策略,延长电池的使用寿命和性能。这对于一些依赖电池供电的设备和系统尤为重要,如电动汽车、无人机和可穿戴设备等。通过预测电池的循环寿命,我们可以减少电池的更换频率和维修成本,提高电池的可持续使用性。 ### 回答2: “数据驱动的电池循环寿命预测在容量降解之前”是一种利用数据分析和模型预测电池在经历一定循环充放电后容量降解之前的寿命。这种方法通过分析电池的充放电循环数据,结合模型和算法,能够预测电池在未来的循环中容量下降的时间和程度。 在这种方法中,首先收集电池的充放电循环数据,并通过数据处理和分析,提取有关电池性能和容量变化的特征。特征可以包括电池循环次数、充放电电流大小、温度变化等。然后,建立一个预测模型,利用这些特征来预测电池的寿命。 预测模型可以使用机器学习算法,如回归模型、支持向量机、深度学习网络等。这些模型可以根据已有的大量数据进行训练,并根据特征来预测电池的寿命。模型可以考虑多个因素,例如电池的类型、制造商、使用条件等。 通过数据驱动的电池循环寿命预测,在容量降解发生之前,可以提前预测电池的寿命,为电池的管理和维护提供依据。这样可以减少电池的寿命损失,并确保电池在关键应用中的长时间可靠运行。 总之,数据驱动的电池循环寿命预测是一种利用数据分析和模型预测电池寿命的方法。通过收集和分析电池的充放电循环数据,并建立适当的预测模型,能够提前预测电池容量降解的时间和程度,为电池管理和维护提供依据。 ### 回答3: 数据驱动预测电池循环寿命在容量降解之前的情况成为了一种越来越重要的方法。随着电动汽车和可再生能源的快速发展,电池的寿命成为了一个关键的问题。传统上,电池寿命的预测主要依赖于试验数据和经验法则。然而,这种方法往往需要耗费大量的时间和资源,而且无法明确地确定电池的寿命。 数据驱动的预测方法通过分析电池的运行数据和性能参数,利用机器学习和数据挖掘的技术来建立模型,并预测电池循环寿命。这种方法基于大规模的数据集和复杂的算法,可以快速准确地预测电池的寿命。同时,该方法还能够捕捉到电池性能的微小变化,提前发现电池的降解趋势,从而采取相应的维护措施。 数据驱动的预测方法具有以下优点。首先,它不需要对电池进行试验和评估,节省了时间和成本。其次,它可以根据电池实际运行的情况进行预测,更加符合实际应用环境。此外,数据驱动的预测方法还具有较高的准确性和可靠性,能够预测电池的寿命和性能。 当然,数据驱动的预测方法也面临一些挑战。首先,它需要大量的电池运行数据和性能参数,才能建立准确的预测模型。其次,预测模型的复杂性可能导致计算成本的增加。此外,预测结果的可解释性也是一个问题,因为数据驱动的模型通常很难解释其预测的原因。 总的来说,数据驱动的预测方法在预测电池循环寿命上具有重要的意义。尽管面临一些挑战,但它仍然是未来电池寿命预测的一个重要方向,可以为电动汽车、可再生能源等领域的发展提供技术支持。


  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助




当前余额3.43前往充值 >
领取后你会自动成为博主和红包主的粉丝 规则




¥1 ¥2 ¥4 ¥6 ¥10 ¥20



钱包余额 0