Patent Application
20050091231
A portion of the disclosure of this patent document may contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. The following notice shall apply to this document: Copyright @ 2003, Microsoft Corp.
The present invention relates to data storage in a computer system, and more particularly, to a system and method for storing and retrieving XML data in a database store as a field of a user defined type.
Microsoft SQL SERVER is a comprehensive database management platform that provides extensive data management and development tools, a powerful extraction, transformation, and loading (ETL) tool, business intelligence and analysis services, and other capabilities. Two improvements to SQL SERVER have recently been implemented. First, the Microsoft Windows .NET Framework Common Language Runtime (CLR) has been integrated into the SQL SERVER database, and second, a new object, referred to as a User Defined Type (UDT), can now be created with managed code in the CLR environment and persisted in the database store.
The CLR is the heart of the Microsoft .NET Framework, and provides the execution environment for all NET code. Thus, code that runs within the CLR is referred to as “managed code.” The CLR provides various functions and services required for program execution, including just-in-time (JIT) compilation, allocating and managing memory, enforcing type safety, exception handling, thread management and security. The CLR is now loaded by SQL SERVER upon the first invocation of a .NET routine.
In previous versions of SQL SERVER, database programmers were limited to using Transact-SQL when writing code on the server side. Transact-SQL is an extension of the Structured Query Language as defined by the International Standards Organization (ISO) and the American National Standards Institute (ANSI). Using Transact-SQL, database developers can create, modify and delete databases and tables, as well as insert, retrieve, modify and delete data stored in a database. Transact-SQL is specifically designed for direct structural data access and manipulation. While Transact-SQL excels at data access and management, it is not a full-fledged programming language in the way that Visual Basic .NET and C# are. For example, Transact-SQL does not support arrays, collections, for each loops, bit shifting or classes.
With the CLR integrated into the SQL SERVER database, database developers can now perform tasks that were impossible or difficult to achieve with Transact-SQL alone. Both Visual Basic NET and C# are modern programming languages offering full support for arrays, structured exception handling, and collections. Developers can leverage CLR integration to write code that has more complex logic and is more suited for computation tasks using languages such as Visual Basic NET and C#.
In addition to CLR integration, SQL SERVER also adds support for User Defined Types (UDT)—a new mechanism that enables a developer to extend the scalar type system of the database. UDTs provide two key benefits from an application architecture perspective: they provide strong encapsulation (both in the client and the server) between the internal state and the external behaviors, and they provide deep integration with other related server features. Once a UDT is defined, it can be used in all the contexts that a system type can be used in SQL SERVER, including in column definitions, variables, parameters, function results, cursors, triggers, and replication.
The process of defining a UDT on a database server is accomplished as follows:
When a UDT definition is created in managed code, the type must meet the following requirements:
Co-pending, commonly assigned, patent application Ser. No. ______ filed Oct. 23, 2003, entitled “System And Method For Object Persistence In A Database Store” (Attorney Docket: MSFT-2852/306819.1), which is hereby incorporated by reference in its entirety, describes another feature of UDTs in which the fields and behaviors of a CLR class definition for a UDT are annotated with storage attributes that describe a layout structure for instances of the UDT in the database store. Specifically, each field of a CLR class that defines a UDT is annotated with a storage attribute that controls the storage facets of the type, such as size, precision, scale, etc. In one embodiment, this is achieved by annotating each field with a custom storage attribute named SqlUdtFieldo. This attribute annotates fields with additional storage directives. These directives are enforced when the object is serialized to disk. In addition, every managed behavior (e.g., a method that can be invoked on the UDT object, for example, to return the value of a field) defined in the CLR class is annotated with an attribute that denotes an equivalent structural access path for that managed behavior. In one embodiment, the custom attribute used for this purpose is named SqlUdtProperty( ), and the database server (e.g., SQL SERVER) assumes that the implementation of properties annotated with this custom attribute will delegate to a field specified as part of the attribute definition. This lets the server optimize access to the property structurally without creating an instance and invoking the behavior on it.
The CLR class that defines the UDT is then compiled into a dynamic link library (dll). An Assembly containing the compiled class may then be created using the following T-SQL script commands:
The following T-SQL script commands may then be used to create the UDT on the server:
Once the UDT has been created on the server, a table (e.g., “MyTable”) can be created defining an attribute of the table as the UDT type, as follows:
A new item can be added to the table, as follows:
The UDT expression can then be used in a query such as: SELECT Item.ID, Item.Name FROM MyTable.
With the integration of the CLR into SQL SERVER and the ability to define UDTs from a class definition in managed code, applications can now instantiate objects of the type defined by the managed code class and have those objects persisted in the relational database store as a UDT. Moreover, the class that defines the UDT can also include methods that implement specific behaviors on objects of that type. An application can therefore instantiate objects of a type defined as a UDT and can invoke managed behaviors over them.
When an object of a class that has been defined as a UDT is instantiated in the CLR, the object can be persisted in the database store through the process of object serialization, wherein the values of the variables of the class are transferred to physical storage (e.g., hard disk).
Referring again to
The eXtensible Markup Language (XML) is a World Wide Web Consortium (W3C) endorsed standard for document and data representation that provides a generic syntax to mark up data with human-readable tags. XML does not have a fixed set of tags and thus allows users to define such tags as long as they conform to the XML standard. Data may be stored in XML documents as strings of text that are surrounded by text markup. The W3C has codified XML's abstract data model in a specification called the XML information set (XML Infoset). XML Schemas also may be used to apply a structure to the XML format and content. In the case of an XML Schema, a diagram, plan, or framework for XML data in a document may be defined. Although XML is a well-known format that may easily describe the contents of a document, other non-XML formatted data may be desirable in the same database. This produces a potential querying problem because of the inherent incompatibility. An example of such an incompatibility is the presence of XML content in a relational database.
Existing database management systems provide support for storing XML data in a relational database store. For example, Microsoft's SQL SERVER provides support for XML data type columns, variables and parameters. You can create a table with one or more XML columns, store XML values in the XML columns, type an XML column using an XML schema namespace, index the XML column, and query into the XML values. However, while it has been possible in the past to store XML data in a relational data base in these instances, it would be desirable to be able to embed XML data in a field of a user defined type that is created in managed code. The present invention provides this ability.
The present invention is directed to a system and method for storing XML data in a field of a user defined type (UDT). One or more fields of a UDT can be defined as an XML data type; the UDT can have other non-XML fields, as well. Data conforming to the XML data model can be stored in the XML fields, while non-XML data is stored in the non-XML fields. Thus, the properties of the XML data model—such as document order and document structure are preserved within instances of a UDT. Moreover, code representing object behavior (i.e., methods that can be invoked on an object in managed code) can be added to the UDT to operate on an XML field, as well as non-XML fields of the UDT. This enables a framework for adding business logic to semi-structured data with XML markup. Additionally, the content model of the XML data can be optionally described using XML schema documents associated with the XML fields of the UDT.
Further according to the invention, to introduce an XML field in a UDT, a common language runtime (CLR) programming model is provided that exposes the XML field as a suitable CLR type. Preferably, this is modeled as a class called SqlXml. For an XML data type field, the SqlXml member allows a new attribute called “XmlSchemaCollection” within the SqlUDTField annotation. The SqlXml class is useful in ADO.NET access to XML data types at the server.
Other features and advantages of the invention may become apparent from the following detailed description of the invention and accompanying drawings.
The foregoing summary, as well as the following detailed description of the invention, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there is shown in the drawings exemplary embodiments of various aspects of the invention; however, the invention is not limited to the specific methods and instrumentalities disclosed. In the drawings:
The subject matter of the present invention is described with specificity to meet statutory requirements. However, the description itself is not intended to limit the scope of this patent. Rather, the inventors have contemplated that the claimed subject matter might also be embodied in other ways, to include different steps or elements similar to the ones described in this document, in conjunction with other present or future technologies. Moreover, although the term “step” may be used herein to connote different aspects of methods employed, the term should not be interpreted as implying any particular order among or between various steps herein disclosed unless and except when the order of individual steps is explicitly described.
As stated above, the present invention is directed to a system and method for storing XML data in a field of a user defined type (UDT). A field of a UDT can be defined as an XML data type; the UDT can have other non-XML fields, as well. Data conforming to the XML data model can be stored in the XML fields, while non-XML data is stored in the non-XML fields. Thus, the properties of the XML data model—such as document order and document structure—are preserved within instances of a UDT. Moreover, code representing object behavior (i.e., methods that can be invoked on an object in managed code) can be added to the UDT to operate on an XML field, as well as non-XML fields of the UDT. This enables a framework for adding business logic to semi-structured data. Additionally, the content model of the XML data can be optionally described using XML schema documents associated with the XML fields of the UDT.
Further according to the invention, to introduce an XML field in a UDT, a common language runtime (CLR) programming model is provided that exposes the XML field as a suitable CLR type. Preferably, this is modeled as a class called SqlXml. For an XML data type field, the SqlXml member allows a new attribute called “XmlSchemaCollection” within the SqlUDTField annotation. The SqlXml class is useful in ADO.NET access to XML data types at the server.
The SqlXml Class
According to one aspect of the present invention, a new class is defined to support the storage of XML data in a field of a CLR class. In the present embodiment, this class is called SqlXml, it being understood that the particular name is not critical to the present invention.
As shown in
The CreateReader( ) method returns an XmlReader through which the (XML) content of SqlXml is retrieved. Supporting XmlReader provides a very flexible mechanism on the XML content. For example, an XPathDocument or XPathNavigator can be instantiated on XML data type values from the server.
The SqlXml class is memoryless, and simultaneous CreateReader( ) calls are allowed. Multiple CreateReader( ) invocations return different instances of XmlReader. Each such instance is initialized to the beginning of the XML content encapsulated by the SqlXml object. This allows an instance of SqlXml to be passed to functions and procedures, in which new instances of XML reader can be created.
To update the value of a SqlXml member M, an XmlWriter is used to write into a stream, instantiate an XmlReader on the stream, and instantiate a new SqlXml object M1 from the XmlReader or the stream. An XmlWriter is a .NET Framework abstract class (or interface) that defines a fast, non-cached, forward-only means of generating (writing) streams or files containing XML data that conforms to the W3C Extensible Markup Language (XML) 1.0 and the Namespaces in XML recommendations. XmlTextWritter is a NET Framework class that implements the XmlWriter interface. The following XML string:
can be generated by the following C# code fragment:
The SqlXml object M1 is then assigned to M. This copies the current state of the source object M1 into M. Other methods on SqlXml are also possible, such as CreateWriter( ) that returns an XmlWriter object, which can be used to update the XML content.
Using SqlXml in a CLR Class
Further according to the present embodiment of the invention, one or more members of a CLR class can be defined as the new SqlXml type. The native CLR type backing SqlXml is one that provides a stream from which XmlReader can be obtained; the stream cannot be accessed directly but only through the XmlReader. It also supports two constructors, one of which accepts an XmlReader and the other a stream.
Creating a User-Defined Type with a SqlXml Field
As described above in the Background section, to create a user-define type in SQL from a managed class in a NET programming language, a user first registers the assembly containing the definition of the type using a CREATE ASSEMBLY statement. Then the user-defined type is created using a CREATE TYPE statement as follows:
According to the present invention, the SQL user-defined type udt-name may have one or more fields X1, X2, . . . of (untyped) XML data type, corresponding to SqlXml fields M1, M2, . . . in the CLR class C for the UDT. Serialization and deserialization of instances of type udt-name into class C is performed in the usual manner, as described above and illustrated in
Once the user-defined type has been created, it can be used as a column type in a table or view, and as SQL variables and parameters, just like any user-defined type without XML fields. As an example, a UDT based on the Employee class defined above, called udtEmp, is created as follows:
An employee table tabEmployee can be created with an integer column, ID, and an udtEmp column, Employee, as follows:
At the instance level, an Employee object is serialized into an instance of udtEmp, with the SqlXml member Employee.Resume stored in the field EmpCol.Resume. Conversely, an instance of EmpCol is deserialized into an Employee object, with the value of the EmpCol.Resume field loaded into the Employee.Resume member.
By way of further example, suppose the following T-SQL statement is executed:
Semantically, each value in column EmpCol (of type udtEmp) is deserialized into an object of type Employee in the CLR. In particular, the XML data type field EmpCol.Resume is loaded into the SqlXml member Employee.Resume, which is returned to the T-SQL layer as XML data type. One optimization is to extract the value of EmpCol.Resume directly and avoid deserialization for extracting the value of the Employee.Resume member.
The XML content is copied using the XmlReader into the internal storage of the Resume field. The retrieval through the reader causes well-formedness checks on the XML content. Any object from which a XmlReader can be obtained will suffice. Thus, you can read from a file or get the XmlReader from some other SqlXml instance.
Typed XML
According to a further aspect of the present invention, an XML field in a UDT can be bound to an XML schema collection at the server. XML schema collections are a new concept in SQL SERVER that allow data instances associated with different XML Schemas to be stored in the same column of a relational database. In accordance with the present invention, the XML schema collection concept is extended to fields of a UDT that have been defined a SqlXml (i.e., fields defined to contain XML data), as described above.
By way of further background regarding XML schema collections, recall from the Background section that XML is a meta-mark-up language for text documents. Data is included in XML documents as strings of text, and the data is surrounded by text markup that describes the data. A particular unit of data and markup is called an element. The XML specification defines the exact syntax this markup must follow: how elements are delimited by tags, what a tag looks like, what names are acceptable for elements, where attributes are placed, and so forth.
XML is flexible in the elements it allows to be defined, but it is strict in many other respects. It provides a grammar for XML documents that regulates placement of tags, where tags appear, which element names are legal, how attributes are attached to elements, and so forth. This grammar is specific enough to allow development of XML parsers that can read and understand any XML document. Documents that satisfy this grammar are said to be well-formed.
To enhance interoperability, individuals or organizations may agree to use only certain tags. These tag sets are called XML applications. An XML application is not a software application like MICROSOFT WORD or MICROSOFT EXCEL. It is a tag set that provides for enhanced functionality of XML for a specific purpose, such as vector graphics, financial data, cooking recipes, or publishing.
An XML schema is a type of XML application, namely one that can describe the allowed content of documents conforming to a particular XML vocabulary. For example, consider the case of a book publisher. The publisher may use an XML application for its business, so that when it provides data (about books, sales, customers, etc.) to other publishers, authors, and customers, they benefit from the increased functionality provided by the XML application, which may be standard in the industry. In addition, the publisher may adopt an XML schema for books, so that every time its computers (and those of his cohorts) access information on books, they access the same information. The information is configured and constrained by the XML schema such that it is uniform for all books.
As further mentioned in the Background, relational databases, such as SQL SERVER, currently provide the ability to store XML data in a relational table like any other data. For example, a table can be created with one or more XML columns, XML values can be stored in those columns, the XML columns can be indexed, and the XML values in those columns can be queried. In addition, an XML column can be “typed” using an XML schema to conform XML data values in that column to the schema. When an XML data value conforming to a given XML schema is found in a relational database, the data is accessed according to the contours of the schema, and as a result, the data can be effectively interpreted.
A problem arises, however, when one attempts to store XML data values conforming to not just one, but several schemas, in the same column of a relational database. One value may be XML data about a book specifying the title of the book, the author of the book, the publishing house, the Copyright year, and so on. Another value may be XML data about a DVD specifying the title of the DVD, the actors and actresses, the director, the genre, the rating, the year released, etc. Assuming it is desirable to store both books and DVDs in a certain columns for data processing efficiencies associated with making determinations for all media, i.e., books and DVDs, at once, the question arises as to which schema should be used to understand and enforce rules on the XML data in the column. Previously, only data conforming to one schema could be stored in a single column. The schema to be used to identify the column would be identified at the top of the column, and any data instance that did not conform to the identified schema would generate an error.
The new concept of XML schema collections solves this problem by allowing XML data associated with multiple, different schemas to be stored in the same column of a relational database via an XML schema collection object. XML schema collections are first class SQL SERVER objects that act as a container for XML schema namespaces. Users can constrain a XML column, parameter and variable using an XML schema collection. This allows them to store instances of XML data conforming to any one of the XML schema namespaces within the constraining XML schema collection.
Thus, an XML schema collection object is a first class SQL object which is a container for XML schema namespaces. In one non-limiting implementation, it is identified by a three part name. The scope of a SQL identifier for XML schema collection is the relational schema within which it is created. Each XML schema collection can contain multiple XML schema namespace universal resource identifiers (URIs). The XML schema namespace is unique within a XML schema collection object, and users can constrain an XML column using an XML schema collection. This allows them to constrain documents against potentially unrelated XML schemas which belong to the XML schema collection.
As mentioned above, in accordance with an aspect of the present invention, the concept of XML schema collections is extended to the fields of a UDT; that is an XML field in a UDT can be bound to an XML schema collection at the server. Binding an XML field in a UDT to an XML schema collection at the server means that each instance of the XML field is valid according to one of the XML schemas in the schema collection. Furthermore, storage is optimized based on the XML schemas, while queries using XML data type methods are optimized using XML schemas for type inference.
The following are the requirements of supporting typed XML in .NET languages. First, the XML schemas typing a class member can be specified at class definition time and not at runtime. That is, the definition should be declarative. Second, the XML schema set associated with an XML reader must be a dynamic set. That is, a schema in the set may be modified (e.g. a new element is added, which corresponds to the creation of a custom property in Windows shell). Deleting an element from a schema should be allowed. Also, a new XML schema may be added to the schema set (e.g. a newly installed application such as PowerPoint adds it own schema to the schema set). Additionally, a schema may be removed from a schema set (e.g. PowerPoint is uninstalled, causing its schema to be dropped from the XML schema collection). A schema may also be replaced with a new version.
To support the binding of an XML field in a UDT to an XML schema collection at the server, in the present embodiment of the invention, a new attribute called “XmlSchemaCollection”, whose value is a string, can be specified on a SqlXml member using the SqlUDTField annotation discussed in the Background section. The value of this attribute denotes the name of an XML schema collection at the server that types the corresponding XML field in the UDT. This is a 1-part name (as opposed to a multipart name), which gives the flexibility of using the class definition with any database and any relational schema. In native CLR context, the SqlUDT annotation on the SqlXml member is ignored. Alternatively, it can be a 3-part name specifying a database, relational schema, and an XML schema collection name.
In the present embodiment, “XmlSchemaCollection” is the only attribute allowed on a SqlXml member; other attributes, if specified, result in the usual error that the attribute is disallowed. Other attributes can be allowed within this document. The syntax of a SqlXml member M specifying the “XmlSchemaCollection” attribute is as follows:
The “XmlSchemaCollection” attribute does not cause binding of the SqlXml member M to any XML schema. If an application wants to obtain a validating XmlReader from M, it has the responsibility of associating XML schemas with the validating XmlReader. That is, the SqlXml class continues to provide a non-validating XmlReader on M, and not validating XmlReader, in spite of the presence of the “XmlSchemaCollection” attribute. Alternatively, the attribute can cause XML schema binding and return a validating reader.
An XML schema collection with the name XML-Schema-Collection-Name specified as the value of the “XmlSchemaCollection” attribute must exist in server meta-data. In particular, it must exist in the same relational schema as that in which the UDT udt-name is created. A schema binding is established on “XML-Schema-Collection-Name” from udt-name. If XML-Schema-Collection-Name does not exist, then the CREATE TYPE statement fails to create the user-defined type udt-name.
In the present embodiment, two SqlXml members with the same value for the “XmlSchemaCollection” attribute will share the XML schema collection at the server. This allows applications to optimize storage. The design is more general, allowing an XML schema collection to be shared across multiple members of multiple classes in multiple assemblies.
An instance of CLR class is serialized in the usual way for all class members, including the SqlXml members with “XmlSchemaCollection” attribute specification. These SqlXml members are stored in typed XML fields of the UDT instance; validation against the XML schema collection occurs during insertion and data modification.
For UDT serialization, only the XML content of each SqlXml member is serialized; the XML schemas in the XmlSchemaSet are not. XML schemas must be separately added to or removed from the XML schema collection at the server.
During deserialization, fields of the UDT are loaded into the corresponding members of the CLR class. For a typed XML field, the instance data is exposed as SqlXml objects. The associated XML schema collection is not used. Users can load the XML schema collection into an XmlSchemaSet object in the client, as discussed below.
The following sequence of operations is used to create a UDT with the typed XML field:
XML Schema Validation
In the present embodiment, XML Schema Document (XSD) validation can occur at the client when the XML content is retrieved through a validating XmlReader or XML content is written using a validating XmlWriter. At the server, in the present embodiment, XSD validation occurs when an UDT instance is inserted into a column or updated. Thus, in this embodiment, no XSD validation occurs when a new SqlXml object is constructed over a non-validating XmlReader and assigned to a SqlXml member with the “XmlSchemaCollection” attribute specified.
By way of further example, a developer or other user may want to create a new instance of a TypedEmployee class without client-side validation. In such a case, the program code is exactly the same as that for a SqlXml member without SqlUdt annotation (see
According to another aspect of XML Schema validation, in the present embodiment, it is possible to obtain the XML schema collection name specified in the “XmlSchemaCollection” attribute from a class definition. The exemplary program code listing of
Once the XML schema collection name is known from a class definition as illustrated in
A database connection is required to retrieve the XML schema collection from the server. For an in-process provider, it is obtained from a SqlContext object. For out-of-process providers, the application supplies the connection (which can be different from the one the data is retrieved through). The SQL statement is executed on the catalog views using the specified XML schema collection name as a parameter. The intrinsic function XML_SCHEMA_COLLECTION( ) is used to retrieve schema documents in a XML data type column, which is deserialized into the SqlXml class. Each schema document is added to the XmlSchemaSet object via XmlReader obtained from the SqlXml object.
To obtain a non-validating reader from the SqlXml member TypedEmployee.TypedResume, the program code is the same as for a SqlXml member without the SqlUdt annotation (see
When updating an existing XML value, in the present embodiment, a Sqlxml member can be updated without client-side validation using the same code as that for a SqlXml member without SqlUdt annotation (see
Manipulation of XML Field in UDT
Further according to the present invention, it is possible to query into and update an XML field of a UDT. For example, it is possible to query into the XML field Resume in the employee table tabEmployee (see example above) as follows:
The expression EmpCol.Resume leads to an XML data type field in the UDT, so the “query” and “value” functions on XML data type can be used to drill down into the XML instance. The non-XML fields are accessed in the usual way. This query also shows an invocation of a function AnnualSalary( ) on the user-defined type udtEmp.
As an example of an update, suppose the zip code of an employee whose first name is “John” changes to 98052. This update can be achieved using the following statement:
As the foregoing illustrates, the present invention provides a framework and methodology for modeling structured, semi-structured, and unstructured data all within a single instance of a user defined type (UDT). In particular, the present invention extends the XML data model to fields of a UDT. Thus, the properties of the XML data model—such as document order and document structure—can be preserved within instances of a UDT. As further described above, the content model of the XML data can be optionally described using XML schema documents associated with the XML fields of the UDT.
Moreover, because a UDT is defined by a class in managed code, code representing object behavior (i.e., methods that can be invoked on an object in managed code) can be added to the UDT to operate on an XML field, as well as non-XML fields of the UDT. This enables a framework for adding business logic to XML data.
As is apparent from the above, all or portions of the various systems, methods, and aspects of the present invention may be embodied in hardware, software, or a combination of both. When embodied in software, the methods and apparatus of the present invention, or certain aspects or portions thereof, may be embodied in the form of program code (i.e., instructions). This program code may be stored on a computer-readable medium, such as a magnetic, electrical, or optical storage medium, including without limitation a floppy diskette, CD-ROM, CD-RW, DVD-ROM, DVD-RAM, magnetic tape, flash memory, hard disk drive, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer or server, the machine becomes an apparatus for practicing the invention. A computer on which the program code executes will generally include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. The program code may be implemented in a high level procedural or object oriented programming language. Alternatively, the program code can be implemented in an assembly or machine language. In any case, the language may be a compiled or interpreted language.
The present invention may also be embodied in the form of program code that is transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, over a network, including a local area network, a wide area network, the Internet or an intranet, or via any other form of transmission, wherein, when the program code is received and loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention.
When implemented on a general-purpose processor, the program code may combine with the processor to provide a unique apparatus that operates analogously to specific logic circuits.
Moreover, the invention can be implemented in connection with any computer or other client or server device, which can be deployed as part of a computer network, or in a distributed computing environment. In this regard, the present invention pertains to any computer system or environment having any number of memory or storage units, and any number of applications and processes occurring across any number of storage units or volumes, which may be used in connection with processes for persisting objects in a database store in accordance with the present invention. The present invention may apply to an environment with server computers and client computers deployed in a network environment or distributed computing environment, having remote or local storage. The present invention may also be applied to standalone computing devices, having programming language functionality, interpretation and execution capabilities for generating, receiving and transmitting information in connection with remote or local services.
Distributed computing facilitates sharing of computer resources and services by exchange between computing devices and systems. These resources and services include, but are not limited to, the exchange of information, cache storage, and disk storage for files. Distributed computing takes advantage of network connectivity, allowing clients to leverage their collective power to benefit the entire enterprise. In this regard, a variety of devices may have applications, objects or resources that may implicate processing performed in connection with the object persistence methods of the present invention.
It can also be appreciated that an object, such as 110c, may be hosted on another computing device 10a, 10b, etc. or 110a, 110b, etc. Thus, although the physical environment depicted may show the connected devices as computers, such illustration is merely exemplary and the physical environment may alternatively be depicted or described comprising various digital devices such as PDAs, televisions, MP3 players, etc., software objects such as interfaces, COM objects and the like.
There are a variety of systems, components, and network configurations that support distributed computing environments. For example, computing systems may be connected together by wired or wireless systems, by local networks or widely distributed networks. Currently, many of the networks are coupled to the Internet, which provides the infrastructure for widely distributed computing and encompasses many different networks. Any of the infrastructures may be used for exemplary communications made incident to the present invention.
The Internet commonly refers to the collection of networks and gateways that utilize the TCP/IP suite of protocols, which are well-known in the art of computer networking. TCP/IP is an acronym for “Transmission Control Protocol/Internet Protocol.” The Internet can be described as a system of geographically distributed remote computer networks interconnected by computers executing networking protocols that allow users to interact and share information over the network(s). Because of such wide-spread information sharing, remote networks such as the Internet have thus far generally evolved into an open system for which developers can design software applications for performing specialized operations or services, essentially without restriction.
Thus, the network infrastructure enables a host of network topologies such as client/server, peer-to-peer, or hybrid architectures. The “client” is a member of a class or group that uses the services of another class or group to which it is not related. Thus, in computing, a client is a process, i.e., roughly a set of instructions or tasks, that requests a service provided by another program. The client process utilizes the requested service without having to “know” any working details about the other program or the service itself. In a client/server architecture, particularly a networked system, a client is usually a computer that accesses shared network resources provided by another computer, e.g., a server. In the example of
A server is typically a remote computer system accessible over a remote or local network, such as the Internet. The client process may be active in a first computer system, and the server process may be active in a second computer system, communicating with one another over a communications medium, thus providing distributed functionality and allowing multiple clients to take advantage of the information-gathering capabilities of the server. Any software objects utilized pursuant to the persistence mechanism of the invention may be distributed across multiple computing devices.
Client(s) and server(s) may communicate with one another utilizing the functionality provided by a protocol layer. For example, HyperText Transfer Protocol (HTTP) is a common protocol that is used in conjunction with the World Wide Web (WWW), or “the Web.” Typically, a computer network address such as an Internet Protocol (IP) address or other reference such as a Universal Resource Locator (URL) can be used to identify the server or client computers to each other. The network address can be referred to as a URL address. Communication can be provided over any available communications medium.
Thus,
In a network environment in which the communications network/bus 14 is the Internet, for example, the servers 10a, 10b, etc. can be servers with which the clients 110a, 110b, 110c, 110d, 110e, etc. communicate via any of a number of known protocols such as HTTP. Servers 10a, 10b, etc. may also serve as clients 110a, 110b, 110c, 110d, 110e, etc., as may be characteristic of a distributed computing environment.
Communications may be wired or wireless, where appropriate. Client devices 110a, 110b, 110c, 110d, 110e, etc. may or may not communicate via communications network/bus 14, and may have independent communications associated therewith. For example, in the case of a TV or VCR, there may or may not be a networked aspect to the control thereof. Each client computer 110a, 110b, 110c, 110d, 110e, etc. and server computer 10a, 10b, etc. may be equipped with various application program modules or objects 135 and with connections or access to various types of storage elements or objects, across which files or data streams may be stored or to which portion(s) of files or data streams may be downloaded, transmitted or migrated. Any computer 10a, 10b, 110a, 110b, etc. may be responsible for the maintenance and updating of a database, memory, or other storage element 20 for storing data processed according to the invention. Thus, the present invention can be utilized in a computer network environment having client computers 110a, 110b, etc. that can access and interact with a computer network/bus 14 and server computers 10a, 10b, etc. that may interact with client computers 10a, 110b, etc. and other like devices, and databases 20.
Although not required, the invention can be implemented via an operating system, for use by a developer of services for a device or object, and/or included within application or server software that operates in accordance with the invention. Software may be described in the general context of computer-executable instructions, such as program modules, being executed by one or more computers, such as client workstations, servers or other devices. Generally, program modules include routines, programs, objects, components, data structures and the like that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments. Moreover, the invention may be practiced with other computer system configurations and protocols. Other well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers (PCs), automated teller machines, server computers, hand-held or laptop devices, multi-processor systems, microprocessor-based systems, programmable consumer electronics, network PCs, appliances, lights, environmental control elements, minicomputers, mainframe computers and the like.
With reference to
Computer 110 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media include both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CDROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer 110. Communication media typically embody computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and include any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132. A basic input/output system 133 (BIOS), containing the basic routines that help to transfer information between elements within computer 110, such as during start-up, is typically stored in ROM 131. RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120. By way of example, and not limitation,
The computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only,
The drives and their associated computer storage media discussed above and illustrated in
The computer 110 may operate in a networked or distributed environment using logical connections to one or more remote computers, such as a remote computer 180. The remote computer 180 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110, although only a memory storage device 181 has been illustrated in
When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via the user input interface 160, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 110, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,
As the foregoing illustrates, the present invention is directed to a system and method for storing and retrieving XML data as a field of an instance of a user defined type within a database store. It is understood that changes may be made to the embodiments described above without departing from the broad inventive concepts thereof. For example, while an embodiment of the present invention has been described above as being implemented in Microsoft's SQL SERVER database management system, it is understood that the present invention may be embodied in any database management system that supports the creation of user defined types. Accordingly, it is understood that the present invention is not limited to the particular embodiments disclosed, but is intended to cover all modifications that are within the spirit and scope of the invention as defined by the appended claims.
