WO2014092803A1 - Generalized data services infrastructure - Google Patents

Abstract

A system and method for generating an object including create, read, update, and delete (CRUD) operations includes receiving a request message. A portion of the request message is determined to be used for generating an object model. The object model is generated based on the determined portion of the request message. At least one object is generated according to the object model. The object includes CRUD operations, and the CRUD operations may be implemented by a context class. The context class may be a generic class that provides CRUD operations. The CRUD operations of the object are mapped to the CRUD operations of the context class according to the object model.

Description

GENERALIZED DATA SERVICES INFRASTRUCTURE

CROSS-REFERENCE TO RELATED APPLICATIONS

[00011 This U.S. non-provisional patent application claims priority under 35 U.S.C.

§ 1 19 to U.S. provisional Patent Application No. 61/736,070, filed on December 12, 2012, the entirety of which is incorporated by reference herein.

BACKGROUND

[00021 The example embodiments disclosed herein relate to web and intranet structure, and more particularly, a system and method to convert and/or use any kind of datastore for Representational State Transfer (REST) services.

[00031 REST is an architecture style that is utilized for designing networked applications, which relies on a stateless, client-server, and cacheable communications protocol. Most REST applications utilize Hypertext Transfer Protocol (HTTP) requests for create, read, update, and delete (CRUD) operations. CRUD operations are the basic functions necessary for persistent data storage operations. REST is considered a lightweight alternative to mechanisms like RPC (Remote Procedure Calls) and Web Services (e.g., SOAP), which may contain extra Extensible Markup Language (XML) syntax, both of which are discussed below. In addition, REST web services are human readable. However, REST does not have built-in security features, for example, encryption, session management, QoS, etc., which can be found in other software architectural paradigms.

[00041 HTTP uses uniform resource identifiers (URIs) for identifying web resources. Each unique URI includes a string of characters that represents an object, which may be created, modified, or deleted using HTTP's CRUD operations (i.e., the standard HTTP operations of get, put, post, and delete). More specifically, the contents of objects may be acquired through the use of an HTTP read request. Alternatively, the object may be posted through an HTTP create or update request. And, finally, the object may be deleted through the use of an update or delete request. [00051 Windows Communication Foundation (WCF) Data Services (formerly known as "ADO.NET Data Services") is a component of the .NET Framework that allows for the creation and consumption of data services for the Web or intranet through the use of the Open Data Protocol (OData). OData enables users to present data as resources that are addressable as URIs. The URIs contain the physical location of a service and the service name. This allows users to access and change data by using the semantics of REST, specially the standard HTTP operations of get, put, post, and delete. Data Services can be configured to return the data in either Extensible Markup Language (XML), JavaScript Object Notation (JSON), or RDF/XML.

[00061 Remote Procedure Call (RPC) allows for a subroutine or procedure to be executed at another address space without the requirement of the details of the remote interaction being coded. This address space is often on another computer found within a shared network. RPC utilizes XML as its message format. The client initiates the RPC by sending a "request message" to the known remote server. The remote server responds to the client, while the specified procedure and its parameters are processed. Great variation has been observed in RPC implementation that has resulted in numerous RPC protocols, which may or may not be compatible with each other.

[00071 Simple Object Access Protocol (SOAP) is a protocol specification that is utilized for the implementation of Web Services on computer networks. SOAP utilizes XML as its message format. However, SOAP usually relies upon other application layers protocols for negotiations and transmission. For example, HTTP or Simple Mail Transfer Protocol (SMTP).

[00081 Although other application layer protocols could have been utilized, XML was chosen because of its wide spread use as well as its open source development efforts. However, there are disadvantages to using XML. First, its lengthy syntax can slow processing speed. And second, the lengthy syntax may be cumbersome. Thus, converting from a RPC based service infrastructure, for example SOAP, to a REST based services can be problematic. For example, some may create models without the implementation of the Data Services interfaces. This results in a read only model, which would be useless for applications that require the full suite of CRUD operations. This could be overcome, by coding a great deal of the domain knowledge or resources and relationships.

[00091 Alternatively, Data Services can be created through Entity Framework integration (such as, through the ADO.NET Entity Framework). This requires a database to be designed and implemented with the Entity Framework in mind. This may be disadvantageous because it could require the recreation of the database, and therefore the duplication of work, to facilitate this method of conversion.

[00101 Thus, there exists a demand for a solution allowing an improvement over existing methods of converting RPC based services to REST based services. There is a demand to create a framework that can offer reusable code, reduce complexity and test coverage, and enhance product quality when converting infrastructure using RPC based services to REST based services.

SUMMARY

[00111 Example embodiments provide systems and/or methods for converting developer-created objects utilizing a REST based data services to RPC based data services.

[00121 According to an example embodiment, a method of generating an object including create, read, update, and delete (CRUD) operations includes receiving a request message. A portion of the request message is determined to be used for generating an object model. The object model is generated based on the determined portion of the request message. At least one object is generated according to the object model. The object may include CRUD operations, and the CRUD operations may be implemented by a context class. The context class may be a generic class that provides CRUD operations. The CRUD operations of the object are mapped to the CRUD operations of the context class according to the object model.

[00131 In one example embodiment, the CRUD operations of the context class may include post, get, put, and delete operations of the Hypertext Transfer Protocol (HTTP).

[00141 In another example embodiment, the method may include generating at least one service operation for the object according to the object model. The service operation may be implemented by a service class. The service class may be a class that provides at least one service operation. [00151 In another example embodiment, the object model may map the service operation of the object to the service operation of the service class.

[00161 In another example embodiment, the service operation may be a domain specific operation including at least one of creating a data entry, creating a relationship between data entries, creating metadata, session validation, data encryption, session management, and quality of service (QoS) management.

[00171 In another example embodiment, the object model may include a format. The format may define a programming language to be mapped to the service operation of the service class.

[00181 In another example embodiment, the object is based on the Representational

State Transfer (REST) architecture and the context class is based on the Remote Procedure Call (RPC) architecture.

[00191 In another example embodiment, the method may include generating an object map. The object map may reference a memory location for the object.

[00201 In another example embodiment, the request message is a Hypertext Transfer

Protocol (HTTP) request message.

[00211 Another example embodiment provides a server that is part of a communications network and is configured to communicate with a client device. The server may be configured to receive a request message. The server may be configured to determine that a portion of the request message is to be used for generating an object model. The server may be configured to generate the object model based on the determined portion of the request message. The server may be configured to generate at least one object according to the object model. The at least one object may include CRUD operations. The CRUD operations may be implemented by a context class. The context class may be a generic class that provides CRUD operations. The server may be configured to map the CRUD operations of the object to the CRUD operations of the context class according to the object model.

[00221 In another example embodiment, the CRUD operations of the context class may include post, get, put, and delete operations of the Hypertext Transfer Protocol (HTTP).

[00231 In another example embodiment, the server may be configured to generate at least one service operation for the object according to the object model. The service operation may be implemented by a service class. The service class may be a class that provides at least one service operation.

[00241 In another example embodiment, the object model may map the service operation of the object to the service operation of the service class.

[00251 In another example embodiment, the service operation may be a domain specific operation including at least one of creating a data entry, creating a relationship between data entries, creating metadata, session validation, data encryption, session management, and quality of service (QoS) management.

[00261 In another example embodiment, the object model may include a format. The format may define a programming language to be mapped to the service operation of the service class.

[00271 In another example embodiment, the object is based on the Representational

State Transfer (REST) architecture and the context class is based on the Remote Procedure Call (RPC) architecture.

[00281 In another example embodiment, the server may be configured to generate an object map. The object map may reference a memory location for the object.

[00291 In another example embodiment, the request message is a Hypertext Transfer

Protocol (HTTP) request message.

BRIEF DESCRIPTION OF THE DRAWINGS

[00301 The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate one or more embodiments and, together with the description, explain these embodiments. In the drawings:

[00311 FIG. 1 illustrates an example of a communications network, according to an example embodiment;

[00321 FIG. 2 illustrates the components of a network element being employed by a communication network according to an example embodiment;

[00331 FIG. 3 illustrates a system diagram according to an example embodiment; and

[00341 FIG. 4 illustrates an object generation routine according to an example embodiment. DETAILED DESCRIPTION OF THE EMBODIMENTS

[00351 Various example embodiments will now be described more fully with reference to the accompanying drawings in which some example embodiments of the invention are shown.

[00361 Detailed illustrative embodiments are disclosed herein. However, specific structural and functional details disclosed herein are merely representative for purposes of describing example embodiments of the present invention. This invention may, however, may be embodied in many alternate forms and should not be construed as limited to only the embodiments set forth herein.

[00371 Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this inventive concepts belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

[00381 It will be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element, without departing from the scope of example embodiments of the present invention. As used herein, the term "and/or," includes any and all combinations of one or more of the associated listed items.

[00391 The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments of the invention. As used herein, the singular forms "a," "an," and "the," are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises," "comprising," "includes," and/or "including," when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

[00401 It should also be noted that in some alternative implementations, the functions/acts noted may occur out of the order noted in the figures. For example, two operations shown in succession may in fact be executed substantially concurrently or may sometimes be executed in the reverse order, depending upon the functionality/acts involved.

[00411 Specific details are provided in the following description to provide a thorough understanding of example embodiments. However, it will be understood by one of ordinary skill in the art that example embodiments may be practiced without these specific details. For example, systems may be shown in block diagrams in order not to obscure the example embodiments in unnecessary detail. In other instances, well-known processes, structures and techniques may be shown without unnecessary detail in order to avoid obscuring example embodiments.

[00421 Also, it is noted that example embodiments may be described as a process depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations may be performed in parallel, concurrently or simultaneously. In addition, the order of the operations may be re-arranged. A process may be terminated when its operations are completed, but may also have additional steps not included in the figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to a return of the function to the calling function or the main function.

[00431 Moreover, as disclosed herein, the term "memory" may represent one or more devices for storing data, including random access memory (RAM), magnetic RAM, core memory, and/or other machine readable mediums for storing information. The term "storage medium" may represent one or more devices for storing data, including read only memory (ROM), random access memory (RAM), magnetic RAM, core memory, magnetic disk storage mediums, optical storage mediums, flash memory devices and/or other machine readable mediums for storing information. The term "computer-readable medium" may include, but is not limited to, portable or fixed storage devices, optical storage devices, wireless channels, and various other mediums capable of storing, containing or carrying instruction(s) and/or data.

[00441 Furthermore, example embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine or computer readable medium such as a storage medium. A processor(s) may perform the necessary tasks.

[00451 A code segment may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.

[00461 Exemplary embodiments are discussed herein as being implemented in a suitable computing environment. Although not required, exemplary embodiments will be described in the general context of computer-executable instructions, such as program modules or functional processes, being executed by one or more computer processors or CPUs. Generally, program modules or functional processes include routines, programs, objects, components, data structures, etc. that performs particular tasks or implement particular data types. The program modules and functional processes discussed herein may be implemented using existing hardware in existing communication networks. For example, program modules and functional processes discussed herein may be implemented using existing hardware at existing network elements or control nodes. Such existing hardware may include one or more digital signal processors (DSPs), application-specific-integrated-circuits, field programmable gate arrays (FPGAs) computers or the like.

[00471 Exemplary embodiments as discussed herein are described as being implemented using Data Services. However, the original code for Data Services does not allow for the generalized infrastructure that is easily implemented across multiple domains. To overcome this, the example embodiments as disclosed herein, allow for a developer to utilize any kind of datastore for REST services. The developer need only override a context class' CRUD operations.

[00481 FIG. 1 illustrates an example of a communications network, according to an example embodiment. A communications network 100 includes client 1 10, server 1 15, database 120, and network 105.

[00491 According to various embodiments, client 1 10 may be a hardware computing device capable of communicating with a server (e.g., server 1 15), such that client 1 10 is able to receive services from the server 1 15. Client 1 10 may include memory, one or more processors, and (optionally) transceiver. Client 1 10 may be configured to send/receive data to/from network devices, such as a router, switch, or other like network devices, via a wired or wireless connection. Client 1 10 may be designed to sequentially and automatically carry out a sequence of arithmetic or logical operations; equipped to record/store digital data on a machine readable medium; and transmit and receive digital data via one or more network devices. Client 1 10 may include devices such as desktop computers, laptop computers, cellular phones, tablet personal computers, and/or any other physical or logical device capable of recording, storing, and/or transferring digital data via a connection to a network device. Client 1 10 may include a wireless transceiver configured to operate in accordance with the IEEE 802.1 1-2007 standard (802.1 1) or other like wireless standards.

[00501 According to various embodiments, server 1 15 may include a physical computer hardware system that is configured to provide services for client devices (e.g., client 1 10) connected to a network (e.g., network 105). Server 1 15 may employ one or more connection-oriented protocols such as Session Initiation Protocol (SIP), HTTP, and TCP/IP, and includes network devices that use connectionless protocols such as User Datagram Protocol (UDP) and Internet Packet Exchange (IPX). Server 1 15 may be configured to establish, manage, and terminate communications sessions, for example between server 1 15 and client 1 10. Server 1 15 may also be configured to establish, manage, and terminate communications sessions two or more client devices. To this end, server 1 15 may be configured to receive/send communication requests from/to client devices. [00511 According to various embodiments, server 115 is connected to one or more local and/or remote databases 120. In various embodiments, database 120 may include a database management system ("DBMS"). Database 120 may include a relational database management system ("RDBMS") database. In other embodiments, alternate DBMS may also be used, such as an object database ("ODBMS"), column-oriented DBMS, correlation database DBMS, and the like.

[OOOl] In various embodiments, network 105 may be the Internet. In other embodiments, network 105 may be may be a Wide Area Network (WAN) or other like network that covers a broad area, such as a personal area network (PAN), local area network (LAN), campus area network (CAN), metropolitan area network (MAN), a virtual local area network, or other like networks capable of physically or logically connecting computers.

[00521 As shown in FIG. 1, only a single client 110, a single server 115, and a single database 120 are present. According to various embodiments, multiple client devices (e.g., client 110), multiple servers (e.g., server 115), and/or multiple databases (e.g., database 120) may be present. Additionally, in some embodiments, client 110, server 115, and database 120 may be virtual machines, and/or they may be provided as part of a cloud computing service.

[00531 FIG. 2 illustrates the components of server 115 an example embodiment. As shown, server 115 includes central processing 210, bus 220, network interface 230, and memory 255. During operation, memory 255 includes operating system 260, and object generation routine 400. In some embodiments, server 115 may include many more components than those shown in FIG. 2. However, it is not necessary that all of these generally conventional components be shown in order to disclose the illustrative embodiment. For example, server 115 may also include a display, a transceiver, and/or other like components.

[00541 Memory 255 may be a computer readable storage medium that generally includes a random access memory (RAM), read only memory (ROM), and a permanent mass storage device, such as a disk drive. Memory 255 also stores operating system 260 and program code for object generation routine 400. These software components may also be loaded from a separate computer readable storage medium into memory 255 using a drive mechanism (not shown). Such separate computer readable storage medium may include a floppy drive, disc, tape, DVD/CD-ROM drive, memory card, or other like computer readable storage medium (not shown). In some embodiments, software components may be loaded into memory 255 via network interface 230, rather than via a computer readable storage medium.

[00551 Central processing unit 210 may be configured to carry out instructions of a computer program by performing the basic arithmetical, logical, and input/output operations of the system. Instructions may be provided to central processing unit 210 by memory 255 via bus 220.

[00561 Bus 220 enables the communication and data transfer between the components of server 1 15. Bus 220 may comprise a high-speed serial bus, parallel bus, storage area network (SAN), and/or other suitable communication technology.

[00571 Network interface 230 is a computer hardware component that connects server 1 15 to a computer network (e.g., internet 120). Network interface 230 may connect server 1 15 to a computer network via a wired or wireless connection.

[00581 FIG. 3 illustrates a system diagram of system 300 according to an example embodiment. According to various embodiments, developers utilizing system 300 are able to create their own REST services on top of already existing RPC services, such that the developer-created REST services "override" the existing RPC services (or "RPC framework").

[00591 As discussed above, the original code for Data Services does not allow for generalized infrastructure to be easily implemented across multiple domains. To overcome this, in accordance with various embodiments, the declaration of a custom data service "wasodified" is provided to public abstract class DSPDataService: DataService, IServiceProvider, each of which accepts a parameter "T". T is C Sharp (C#) programming language syntax for a generic type. In this case, T is a class definition called "context" or "context class".

[00601 According to an example embodiment, IServiceProvider is utilized as a primary interface. IServiceProvider is well known in the art and therefore, described only briefly. IServiceProvider is a generic access mechanism for retrieving a service object— an object that provides custom support to other objects. The customer service provider is derived from the class DataService, where T is the content under which the data service runs.

[00611 According to various embodiments, the context class supports Create, Read,

Update, and Delete (CRUD) operations. This results in the context declaration being: public class Context : IDataProvider where IDataProvider has the following declaration: public interface IDataProvider { void Update(object entity); object Create(object entity); void Delete(object entity); IList GetResourceSetEntities(string resourceSetName); void UpdateProperty(object entity, object propertValue, ResourceProperty resourceProperty); bool IsNewItem(object item); } . The interface methods implemented by the context class may be virtual.

[00621 The infrastructure of system 300 allows for the programmatic creation of domain specific REST services by allowing the created REST services to become the service declaration class and the model. The model defines the specific objects to be used by the server and the client, and overrides the context class and/or virtual context class. It should be noted that the terms "model" and "object model" have the same meaning, and thus, may be used interchangeably.

[00631 This system allows for the user to declare their services in a very specific manner. For example, assume a public class VisualFragmentService : DSPDataService, is defined where VisualFragmentContext has the declaration: public class VisualFragmentContext. The generic DSPDataService knows about the context methods, and VisualFragmentContext overrides the context methods. As such, it is the domain- specific VisualFragmentContext implementation that gets called.

[00641 This framework for custom Data Services offers a reusable code that reduces complexity and test coverage, while enhancing product quality through the minimization of errors. The framework disclosed herein will allow for faster and more efficient construction of new services, allows for a developer to maintain security and domain knowledge between users and a database while using the REST services. [00651 Referring to FIG. 3, services 305 includes model 310. As discussed above, developers utilizing system 300 are able to create their own REST services on-top of already existing RPC services. Accordingly, a developer utilizing system 300 defines a model 310 to be used for generating objects. A model is made up of a number of parameters, such as generic functions, classes, messaging, inheritance, polymorphism, data encapsulation, and the like. The developer may then define Create, Read, Update, and Delete (CRUD) operations and/or other services according to the parameters of model 310. The CRUD operations of the model 310 may then be mapped to the CRUD operations of the context class 325. The DataProvider Implementation 320 receives the CRUD operations defined by the model 310, which are then implemented by the context class 325.

[00661 According to various embodiments, model 310 may include entities. The term "entities" refers to a runtime version of the model 310 built using the existing RPC framework (e.g., .Net Entity Framework) concepts. An entity framework enables developers to work with data in the form of domain-specific objects and properties, without having to concern themselves with the underlying database tables and columns where the data is stored. Accordingly, the entities included with model 310 map the CRUD operations defined by the model to the CRUD operations of the context class 325.

[00671 In various embodiments, services 305 may optionally include Simple Visual

Compiler (SVC) 315. According to various embodiments, system 300 may utilize Data Services. As such, a Data Services service is defined by a file with the file extension ".svc". SVC files may also have an associated code behind file, such as, ".svc.cs". In this code behind file, a developer may create a service based on the DSPDataService 335 (e.g., DSPDataService), which is discussed below.

[00681 Referring to FIG. 3, the DataProvier Implementation 320 includes six components: context class 325, DSPResourceQueryProvider 330, DSPSDataService 335, DSPMetadata 340, DSPUpdateProvider 345, and JSONSupportBehavior 350. In various embodiments, RESTSecurity 355 may also be included with the DataProvider Implementation 320

[00691 The context class 325 is a class that provides generic data store operations

(i.e., CRUD operations) that are overridable by developer-defined data store operations (e.g., CRUD operations defined by model 310). Because the context class 325 has a generic definition, an existing RPC framework may accept or receive developer-defined services and implement services of the context class 325 without requiring a definition of the developer-defined services. In this way, the CRUD operations of context class 325 may be overridden by the CRUD operations of the model 310. Context class 325 may be implemented using an RPC framework, such as Data Services Framework, and the like.

[00701 According to various embodiments, DSPResourceQueryProvider 330 provides methods for resolving queries to entities, resolves service provider entries, to get entities, and to execute service providers. In various embodiments, DSPResourceQueryProvider 330 implements the well-known IDataServiceQueryProvider, which is used in conjunction with the HTTP protocol's get, put, post, and delete operations.

[00711 According to various embodiments, the DSPSDataService 335 provides a calling mechanism, such that a developer-defined object implements the necessary methods to create the runtime entity of the model. DSPDataService 335 accepts a parameter "T", where T is the context based class (i.e., model 310) that the developer created. This code implements the well-known interface IServiceProvider, which is used to map the HTTP request message to the appropriate developer-created code.

[00721 According to various embodiments, the DSPMetadata 340 provides methods to create metadata for domain-specific services, including adding entities, relationships, and service operations.

[00731 According to various embodiments, the DSPUpdateProvider 345 provides methods to update, create, and delete entities.

[00741 According to various embodiments, the JSONSupportBehavior 350 provides the ability for a developer to use JavaScript Object Notation (JSON) syntax for creating objects, in addition to using JSON with padding (JSONP) type calls and formatting. In such embodiments, the syntax "$format=json" may be used in the request message (e.g., a URI). The Data Services framework does not natively support the $format option.

[00751 According to various embodiments, RESTSecurity 355 provides services for enforcing security policies, validating communication sessions, and the like. [00761 FIG. 4 illustrates an object generation routine 400 according to an example embodiment. Object generation routine 400 may be used create REST based service objects that override existing RPC based service objects. For illustrative purposes, the operations of object generation routine 400 will be described as being performed by server 1 15.

[00771 As shown in step S405, server 1 15 receives a request message. According to various embodiments, a developer using a client device (e.g., client 1 10) may send a request message to the server 1 15 that may indicate a model to be used for generating objects, in addition to defining one or more objects and their properties. The request message may be a HTTP request message, such as a uniform resource identifier (URI), or other like string of characters used to identify a resource.

[00781 As shown in step S410, server 1 15 determines which portion of the request message is to be used for generating a model. As discussed above, the request message received in step S405 may indicate a model to be used for generating objects. Models typically require objects to be defined using specific computer programming language, notation, or other like methodology. For instance, the object model for Java may require a developer to define objects according to a specified syntax, whereas the Component Object Model (COM) may require a different syntax to be used. In such embodiments, a developer may choose a model and define properties for objects when sending a request message to the server 1 15. In embodiments where the client device sends a HTTP request message to the server 1 15, server 1 15 may be configured to determine which a portion of the URI indicates a model to be used for generating objects, and extract the determined portion of the URI in order to generate the model.

[00791 As shown in step S415, server 1 15 generates the model from the portion of the request message. According to various embodiments, the server 1 15 generates a model as indicated by the received request message. The generated model may define rules for generic functions, classes, messaging, inheritance, polymorphism, data encapsulation, and the like.

[00801 As shown in step S420, server 1 15 builds at least one object based on the generated model. As discussed above, the request message may indicate a model to be used for generating objects, in addition to defining one or more objects and their properties. Accordingly, server 1 15 may be configured to generate objects, as defined by the request message, and according to the model generated in step S415. According to various embodiments, the object may be generated using the .NET framework or other like software frameworks. The .NET framework includes a class library, which includes reusable class types. In such embodiments, the object may derive functionality from the class library provided by the .NET framework.

[00811 As shown in step S425, server 1 15 generates an object map with a reference to a memory location of the object. According to various embodiments, server 1 15 may be configured to store the object created in step S420 in memory. Accordingly, server 1 15 may be configured to create a map, table, or other like logical representation of data that indicates or otherwise points to a location in memory where the generated object is stored.

[00821 As shown in step S430, server 1 15 generates CRUD operations for the object according to the model. As discussed above, the request message received in step S405 may indicate a model to be used for generating objects, in addition to defining objects and their properties. In such embodiments, the properties may include CRUD operations. The CRUD operations of the object may be used to implement generic data store operations according to a developer-defined programming language or syntax.

[00831 As shown in step S435, server 1 15 associates the CRUD operations of the object with the CRUD operations of a context class. The context class is a class that provides generic data store operations (i.e., CRUD operations). In embodiments where the context class implements HTTP, the CRUD operations of the object may be mapped to the post, get, put, and delete operations, respectively. In other embodiments where the context class implements SQL, the CRUD operations of the object may be mapped to the insert, select, update, and delete operations, respectively. Although the above examples describe the context class as implementing HTTP and SQL operations, example embodiments are not limited thereto, and the context class may implement various other protocols as are known.

[00841 As shown in step S440, server 1 15 generates service operations for the object according to the object model. As discussed above, the request message received in step S405 may indicate a model to be used for generating objects, in addition to defining objects and their properties. In such embodiments, the properties may include CRUD operations and/or service operations. In various embodiments, service operations may include encryption, session management, session validation, QoS, and/or other like services found in other software architectural paradigms.

[00851 As shown in step S445, server 1 15 associates the service operations of the object with the service operations of a service class. In various embodiments, the context class may implement other services in addition to CRUD operations. In such embodiments, server 1 15 may map the service operations of the object with service operations of the context class. However, in some embodiments, the context class may not have the ability to implement the service operations of the object. For instance, where the context class is based on the RPC framework, the context class may not be able to provide services such as session validation, data encryption, session management, and/or quality of service (QoS) management. In such embodiments, the server 1 15 may be configured to identify other generic service classes, and map the service operations of the object with service operations of one or more other generic service classes.

[00861 As shown in step S499, object generation routine 400 ends.

[00871 As will be appreciated, example embodiments as described above provide a framework that offers reusable code, reduces complexity and test coverage, and/or enhances product quality when converting infrastructure using RPC based services to REST based services. This allows for the full suite of CRUD methods, not read only. Furthermore, example embodiments do not require a database to be specifically designed and implemented with using the Entity Framework.

[00881 This written description uses examples of the subject matter disclosed to enable any person skilled in the art to practice the same, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the subject matter is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims. The invention being thus described, it will be obvious that the same may be varied in many ways. Such variations are not to be regarded as a departure from the invention, and all such modifications are intended to be included within the scope of the present invention.

Claims

WE CLAIM:

1. A method of generating an object including create, read, update, and delete (CRUD) operations, the method comprising:

receiving, by a server, a request message;

determining, by the server, a portion of the request message to be used for generating an object model;

generating, by the server, the object model based on the determined portion of the request message;

generating, by the server, at least one object according to the object model, the object including CRUD operations, the CRUD operations being implemented by a context class, the context class being a generic class that provides CRUD operations; and

mapping, by the server, the CRUD operations of the object to the CRUD operations of the context class according to the object model.

2. The method of claim 1, wherein the CRUD operations of the context class include post, get, put, and delete operations of the Hypertext Transfer Protocol (HTTP).

3. The method of claim 1, further comprising:

generating at least one service operation for the object according to the object model, the service operation being implemented by a service class, the service class being a class that provides at least one service operation.

4. The method of claim 3, wherein the object model maps the service operation of the object to the service operation of the service class.

5. The method of claim 4, wherein the service operation is a domain specific operation including at least one of creating a data entry, creating a relationship between data entries, creating metadata, session validation, data encryption, session management, and quality of service (QoS) management.

6. The method of claim 4, wherein the object model includes a format, the format defining a programming language to be mapped to the service operation of the service class.

7. The method of claim 1, wherein the object is based on the Representational State Transfer (REST) architecture and the context class is based on the Remote Procedure Call (RPC) architecture.

8. The method of claim 1, further comprising:

generating an object map, the object map referencing a memory location for the object.

9. The method of claim 1 , wherein the request message is a Hypertext Transfer Protocol (HTTP) request message.

10. A server configured to :

receive a request message;

determine that a portion of the request message is to be used for generating an object model;

generate the object model based on the determined portion of the request message; generate at least one object according to the object model, the at least one object including CRUD operations, the CRUD operations being implemented by a context class, the context class being a generic class that provides CRUD operations; and

map the CRUD operations of the object to the CRUD operations of the context class according to the object model.

11. The server of claim 10, wherein the CRUD operations of the context class include post, get, put, and delete operations of the Hypertext Transfer Protocol (HTTP).

12. The server of claim 10, further configured to:

generate at least one service operation for the object according to the object model, the service operation being implemented by a service class, the service class being a class that provides at least one service operation.

13. The server of claim 12, wherein the object model maps the service operation of the object to the service operation of the service class.

14. The server of claim 13, wherein the service operation is a domain specific operation including at least one of creating a data entry, creating a relationship between data entries, creating metadata, session validation, data encryption, session management, and quality of service (QoS) management.

15. The server of claim 13, wherein the object model includes a format, the format defining a programming language to be mapped to the service operation of the service class.

16. The server of claim 10, wherein the object is based on the Representational State Transfer (REST) architecture and the context class is based on the Remote Procedure Call (RPC) architecture.

17. The server of claim 10, further configured to:

generate an object map, the object map referencing a memory location for the object.

18. The server of claim 10, wherein the request message is a Hypertext Transfer Protocol (HTTP) request message.