Method of deriving web service interfaces from form and table metadata

(54) Title: METHOD OF DERIVING NETWORK SERVICES INTERFACES FROM TABLE AND FORMS METADATA (51) Int. Cl .: G06F 17/00 (30) Unionist Priority: 27/04/2007 US 11 / 741,318 (73 ) Holder (s): MICROSOFT CORPORATION (72) Inventor (s): ROGNVALDUR KRISTINN RAFNSSON (74) Attorney (s): ALEXANDRE FERREIRA (86) International Application: PCT US2008059197 of 03/04/2008 (87) International Publication: WO

2008/134187 of 11/06/2008

<img file="BRPI0809915A2_D0001.tif" />

“METHOD OF DERIVING NETWORK SERVICES INTERFACES FROM

TABLE AND FORMS METADATA ”

Foundation

This Plea is intended to provide the basic context for this patent application and is not intended to describe a specific problem to be solved.

Computer applications that are designed to work in one environment, often need to work in a different environment. For example, a computer application can be designed to be installed on a computer's hard drive, in such a way that data is readily available. However, due to changes, a different environment may be desired. For example, it may be desirable to have an application available on the Internet, in which case the application could not be installed on each hard drive on each computer using the application. Modifying the application to be made available over the Internet requires careful review and modification, although data are available, which describe the forms and tables used in the application.

summary

This summary is provided for introducing a selection of concepts in a simplified way, which are further described below in the Detailed Description. This summary is not intended to identify the key characteristics or essential characteristics of the claimed object, nor is it intended to be used to limit the scope of the claimed object.

Many applications are data driven applications, where data abstractions, such as forms and tables, are the driving forces behind application design. Considerable effort has been made to define the metadata behind these abstractions (tables, forms, etc.) in applications. Metadata describes an interface with applications, such as which fields are significant and which interactions are available. For example, metadata for a sales order form contains the fields in a header (buyer, date, terms of delivery, etc.) and lines to create the form. Metadata can also contain what the user can do with the form, such as saving, submitting, browsing, etc. By using this data, programmatic access can be granted through a simple object access protocol or SOAP.

A system and method of deriving network service interfaces from table and form metadata are described. The method uses a discovery subsystem to discover the services that are available on an application server. The method retrieves metadata descriptions for services on the application server. The method uses discovered services and metadata descriptions to create network service interfaces so that the service is available using the network service description language.

graphics

Figure 1 is a block diagram of a computing system that can operate according to the claims;

Figure 2 is an illustration of a flowchart of a method of deriving network service interfaces from table and form metadata;

Figure 3 is an illustration of a system that applies the method of Figure 2; and

Figure 4 is an illustration of the parts of the method that aid the system's implementation.

description

Although the following text presents a detailed description of several different modalities, it should be understood that the legal scope of the description is defined by the expression of the claims presented at the end of the present patent. The detailed description should be interpreted as exemplary only and does not describe each possible modality, since describing each possible modality would be impractical, if not impossible. Various alternative modalities could be applied, using the current technology or technology developed after the filing date of this patent, which would still be within the scope of the claims.

It should also be understood that, unless a term is expressly defined in the present patent using the phrase As used herein, the term ““ is defined to mean ... or a similar phrase, there is no intention to limit the meaning of such term, expressly or implicitly, beyond its literal or common sense, and such term should not be interpreted in a limited scope, based on any statement made in any section of this patent (other than the language of the claims). To the extent that any term presented in the claims at the end of this patent is referred to in this patent in a manner consistent with a unique meaning, which is done for the sake of clarity just so as not to confuse the reader, it is not intended that such claim will end with limitation, by implication or otherwise, for this the one-way. Finally, unless a claim element is defined by citing the word “means and a function without citing any structure, the scope of any claim element is not intended to be interpreted based on the request of 35 USC § 112 , sixth paragraph.

Figure 1 illustrates an example of a suitable computing system environment 100 in which a system for the claimed method and equipment steps can be applied. The computing system environment 100 is just one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the equipment method of the claims. Also, computing environment 100 should not be construed as having any dependency or requirement on any or a combination of components illustrated in the exemplary operating environment 100.

The steps of the claimed method and equipment are operational with various other environments or computer system configurations with general or special purposes. Examples of well-known computing systems, environments and / or configurations, which may be suitable for use with the methods or equipment of the claims, include, but are not limited to, personal computers, server computers, handheld or portable devices, systems multiprocessor systems, microprocessor-based systems, set top boxes, programmable electronic devices, network computers, minicomputers, processing unit computers, distributed computing environments that include any of the above systems or equipment, and the like.

The steps of the claimed method and equipment can be described in the general context of instructions executable by computer, such as program modules, being executed by a computer. Program modules generally include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement particular types of abstract data. Methods and equipment can also be practiced in distributed computing environments, where tasks are performed by remote processing devices that are connected via a communications network. In a distributed computing environment, program modules can be located on either the remote or local computer storage media, including memory storage devices.

With reference to Figure 1, an exemplary system for performing the steps of the claimed method and apparatus includes a general purpose computing device in the form of a computer 110. The components of computer 110 may include, but are not limited to, a unit of processing 120, a memory system 130 and a system bus 121 that couples various components of the system, including the system memory to the processing unit 120. The system bus 121 can be any of several types of bus structures, including a memory bus or a memory controller, a peripheral bus, and a local bus, using any of a variety of bus architectures. For example, and not by way of limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA bus (EISA), Video Electronics Standards Association (VESA) local bus, Peripheral Component Interconnect bus (PCI) also known as Mezzanine bus, and Peripheral Component Interconnect Express (PCI-E).

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 include both volatile and non-volatile media, removable and non-removable media. By way of example, and not as a limitation, the computer-readable medium may include computer storage media and communication media. Computer storage media includes both volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable instructions, data structures, program modules or other data. Computer storage support includes, but is not limited to, RAM, ROM, EEPROM, flash or other memory technology, CD-ROM, versatile digital discs (DVD) or other optical storage disc, magnetic tapes, magnetic tape , magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by computer 110. The communication medium typically incorporates computer-readable instructions, data structures, program modules or other data into a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery medium. The term modulated data signal means a signal that has one or more of its characteristics defined or changed, in such a way as to encode the information in the signal. By way of example, and not as a limitation, communication media includes 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 situations should also be included in the scope of computer-readable support.

System memory 130 includes computer storage media, in the form of volatile and / or non-volatile memory, such as read-only memory (ROM) 131 and random access memory (RAM) 132. The basic storage system input / output 133 (BIOS), which contains the basic routines that help the transfer of information between the elements inside the computer 110, such as during initialization, it is normally stored in ROM 131. RAM 132 typically contains data and / or program modules that are immediately accessible to and / or currently operated by processing unit 120. As an example, and not as a limitation, Figure 1 illustrates operating system 134, application programs 135 , other program modules 136, and program data 137.

Computer 110 may also include other non-removable / removable, volatile / non-volatile computer storage media. By way of example only, Figure 1 illustrates a hard disk drive 140 that reads or writes on non-removable, non-volatile non-volatile magnetic media, a magnetic disk drive 151 reads or writes on a removable, non-volatile magnetic disk 152, and an optical disc drive 155 that reads or writes to a removable, non-volatile optical disc 156, such as a CD ROM or other optical media. Other removable / non-removable, volatile / non-volatile computer storage media that can be used in the example's operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, versatile digital discs, digital video tape , Solid state RAM, solid state ROM, and the like. Hard disk 141 is typically connected to system bus 121 via a non-removable memory interface, such as interface 140, and magnetic disk unit 151 and optical disk unit 155 are normally connected to the system bus. 121 via a removable memory interface, such as interface 150.

The drives and their associated computer storage media discussed earlier and illustrated in Figure 1 provide the storage of computer-readable instructions, data structures, program modules and other data for computer 110. In Figure 1, for example, the hard drive 141 is illustrated as storage operating system 144, application programs 145, other program modules 146, and program data 147. Note that these components can be the same or different from operating system 134, application programs 135, other program modules 136, and program data 137. Operating system 144, application programs 145, other program modules 146, and data of program 147 have different numbers here to illustrate that, at the very least, they are different copies. A user can enter commands and information for computer 20 via input devices, such as a keyboard 162 and a pointing device 161, commonly referred to as a mouse, pointing device or touch pad. Other input devices (not shown) may include a microphone, remote control, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to processing unit 120 via a user input interface 160 which is coupled to the system bus, but can be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190. In addition to the monitor, computers can also include other peripheral output devices, such as speakers. speakers 197 and printer 196, which can be connected via a peripheral output interface 190.

Computer 110 can operate in a network environment, using logical connections to one or more remote computers, such as a remote computer 180. Remote computer 180 can be a personal computer, a server, a router, a network PC, a point device or other common network node, and typically includes many or all of the elements described above in relation to computer 110, although only one memory storage device 181 has been illustrated in Figure 1. The logical connections shown in Figure 1 include a local area network (LAN) 171 and a broadband network (WAN) 173, but can also include other networks. Such network environments are common in offices, image communication computer networks, intranets and the Internet.

When used in a LAN network environment, computer 110 is connected to LAN 171 through a network interface or adapter 170. When used in a WAN network environment, computer 110 generally includes a 172 modem or other means for establishing communications over WAN 173, such as the Internet. Modem 172, which can be internal or external, can be connected to system bus 121 via user interface input 160, or another appropriate mechanism. In a network environment, the module program described in relation to computer 110, or parts of it, can be stored on the remote memory storage device. By way of example, and not by way of limitation, Figure 1 illustrates remote application programs 185 as resident in memory device 181. It will be appreciated that network connections are indicated as exemplary and other means of establishing a communication link between computers can be used.

Figure 2 is an illustration of a method of deriving network service interfaces from table and form metadata. As more and more applications are being diverted from the local base to the network base, there has been a need to automate the process of converting local-based applications to applications available over a wider network, such as the Internet. Most business applications are data driven applications, where data abstractions, such as forms and tables, are the driving forces behind application design. Considerable effort has been made to define the metadata behind these abstractions (tables, forms, etc.) in applications. Metadata describes an interface with applications, such as which fields are significant and which interactions are available. For example, metadata for a sales order form contains the fields in a header (buyer, date, terms of delivery, etc.) and lines to create the form. Metadata can also contain what the user can do with the form, such as saving, submitting, browsing, etc. By using this data, programmatic access can be granted through a simple object access protocol or SOAP.

In some applications, tables can be considered the lowest level of abstraction. For example, a table can define a set of fields that are related to an entity and these fields can contain the value or be calculated from the values ​​both with that table or in other tables. The field can also have properties, such as the type of value (string, integer, etc.) and its size (string length of 50, for example). In addition, a table can also include indexes to optimize the location of entities and triggers / events for the validation logic in insert, update and delete.

Code unit abstraction is a standard method-oriented procedural abstraction that defines an interface to a method in a similar way to program languages ​​such as visual basic.

Form abstraction defines the user interfaces for an application. Groups of forms abstraction next to fields for users and shows only those fields that are relevant to the user. Form abstraction can also provide the means for a user to interact with data, such as viewing, entering and modifying, as well as accessing system functionality, such as submitting an order or generating a shipping notice. The form defines an entity's external view (such as a sales order), defines the fields in the view and whether the view authorizes or allows functions such as reading, modifying, inserting, deleting, as well as defining which fields are read-only and which fields are editable. By deriving from the user interface for an application, the application can be made available via remote technology, such as network service technology.

Referring again to Figure 2, in block 200, a discovery subsystem can be used to discover the services that are available on an application server. Figure 3 can be an illustration of a method sampling system implementation. A 305 service customer can be a consumer or developer of the service. Service client 305 can communicate a discovery request 310 to an application server 315 via communication cloud 320. In one embodiment, the communication cloud is the internet and communication takes place using HTTP over TCP / IP. Of course, other modalities are possible. For example, the client and the server can be local, such as on an intranet.

In block 210, service client 305 (Figure 3) can request metadata descriptions 325 of services on application server 315. Server 315 can return request for metadata 325 using communication cloud 320. In another embodiment, metadata are retrieved through a network service definition language request. Service requests 330 can also use communication cloud 320.

At block 220, discovered services 310 and metadata descriptions 325 are used to create network service interfaces so that the service is available using network service description language. Communication from the service client to the application server can use SOAP over http for service interactions, such as entering and updating.

Figure 4 is an illustration of how the various requests can be handled. As mentioned earlier, a 405 customer or developer can request 410 metadata from an application. The request can be delivered by the server infrastructure (US) 415 to the service broker 420. The service broker 420 can then determine what the order type is and then forward it to an applicable subsystem. Individual subsystems handle requests.

A subsystem is the discovery subsystem 425. The discovery subsystem allows developers / customers to discover what services are available in the system. The answer can be in a variety of formats, including Microsoft Corporation's DISCO format. Once a Network Service has been deployed, potential users must be able to find out where it is and how it works. DISCO is a Microsoft ® technology for publishing and discovering Network Services. Universal Description, Discovery and Integration (UDDI) is an industry-wide initiative that defines a SOAP-based protocol for updating and consulting Network Services information repositories. Like DISCO, UDDI allows you to publish and discover a Network Service, maximize the reach of the site and ultimate success.

The Network Services Description Language (WSDL) is an ongoing initiative that attempts to standardize the way in which Network Services can be described in XML format. A WSDL document describes the operations of a service in terms of messages and (usually) XML Schema definitions, as well as how they are connected to various protocols and endpoints. Since a customer can hold a WSDL document, he must have enough information to know how to interact with the Network Service objective. If the customer knows where the WSDL document resides, he can simply request it via HTTP. However, if the customer does not know where the WSDL resides, a discovery mechanism is necessary.

DISCOVERY WITH DISCO

In the past, most consumers have discovered new Network Services (and their terminal addresses) by browsing the Web, receiving an email, or by word of mouth. DISCO can define a document format, along with an interrogation algorithm, doing its best to discover the network services exposed on a given server. DISCO also makes it possible to discover the capabilities of each network service (through documentation) and how to interact with it (via WSDL). To publish a network service implemented using DISCO, a user needs to register for the service with an application server.

The disk response is an XML document that simply contains links to other resources that describe the Network Service, as well as an HTML file that contains human-readable documentation or a WSDL file containing the interface contract.

Abstractions of data underlying the application intended to be accessible over the network, such as a network service, such as forms 430 tables 435 are recorded in a database table. Discovery subsystem 425 is populated from the database table. Each record in the database becomes a network service entry with the DISCO response in the response if a user has marked it as a service. Each entry in the response can contain a uniform resource locator (URL) that points to the network service description language (WSDL) description of the service.

Metadata Provider

The metadata provider 440 can provide the description of the service interface that can be used by standard tools, such as tools that can understand the WSDL format. A customer / developer can request a description of a specific service. The system loads metadata 427 that describe this service, such as forms 430 and tables 435. Metadata 427 is then used to define the types of values ​​that are passed to the service, as well as messages.

The value type portion of the WSDL is derived from metadata 427 described in both forms 430 and tables 435. The system begins to load form 427 metadata and form 427 metadata contains information on which tables 435 form 430 saves to. Dice. The metadata 427 of form 430 also points out which fields in table 435 are shown in form 430. The metadata in table 437 contains the fields and their properties such as type (and size) and name. An XML type is constructed from 427 metadata information, in addition to the service name. The service name is the name of the value type, then each field in the form appears as the value type field, where the field name and type are used.

Said application has a table 435.

Table id = l =&gt; Consumers {

Field id = l =&gt; Name: string (100),

Field id = 2 =&gt; Telephone Number: string (I 6),

Field id = 3 =&gt; Classification: int}

And a form 430:

Form id = 2 =&gt; Customer Card {

Table - Ref I,

Field - Ref I,

Field - Ref 2,

You can read the truth,

You can enter truth,

You can modify truth,

Can delete false}

This form 430 can insert a new record in the Customers table. This form 430 can also edit and read the name and phone number fields, but you cannot delete a record or read or edit the classification field. It would be desirable to have access to this view / form 430 as a programmatic construction. For this, the view / form 430 can be registered as a service.

Form Registration: 2 as a Customer

When registering the 430 Customer Card form as a service, the WSDL description can be retrieved and services can be invoked described in the WSDL. The WSDL file contains the following information:

The methods: Find, Insert, Update and Receive,

This contains a type called Customer that has 2 fields: Name and

Phone number.

This type is the parameter for the methods.

Shipping device

The shipping device 445 receives the present service requests. The service request is formatted to the specification provided in the WSDL provided by the metadata provider 440. The basic operation of the 445 shipping device is to send a message by filling in the form 430 virtually and consulting the correct methods of the form 430 or filling the reply with the information on Form 430.

Although the text above presents a detailed description of several different modalities, it should be understood that the scope of the patent is defined by the expression of the claims presented at the end of the present patent. The detailed description should be interpreted as exemplary only and does not describe each possible modality because describing each possible modality would be impractical, if not impossible. Various alternative modalities could be applied, using either current technology or technology developed after the date of filing this patent, which would still be within the scope of the claims.

Thus, many modifications and variations can be made to the techniques and structures described and illustrated in this document without departing from the spirit and scope of the present claims. Thus, it should be understood that the methods and equipment described in this document are merely illustrative and are not limited to the scope of the claims.