Scripting web services

A process performed on a server includes configuring the server to enable script for a Web service to be defined dynamically, where the Web service includes an application program interface (API) for enabling access by, and interaction with, a computer program executing on a device other than the server. The process also includes compiling the script to produce machine-executable code for the Web service, receiving a call from the computer program to the Web service, executing the machine-executable code in response to the call to produce an output, and sending the output to the device.

TECHNICAL FIELD

This patent application relates generally to scripting Web services.

BACKGROUND

The World Wide Web Consortium (W3C) defines a Web service as "a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically Web Services Description Language WSDL). Other systems interact with the Web Service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards." Many Web services today are now REST-compliant. In REST-compliant Web services, the services manipulate XML representations of Web resources using a uniform set of stateless operations. As is generally known, SOAP is the acronym for Simple Object Access Protocol; HTTP is the acronym for HypterText Transfer Protocol; XML is the acronym for eXtensible Markup Language; and REST is the acronym for Representational State Transfer.

Web services include application programming interfaces (API) or Web APIs that are accessible via HTTP and that are executed on a server hosting the services. A Web service may receive an HTTP request at a server, and send a reply that can be consumed by a computer program rather than a person. The HTTP request may include a Uniform Resource Indicator (URI) that identifies the Web service operation and may include Uniform Resource Locator (URL) parameters. In its reply, the Web service returns data in a format that the requesting client can use. This format is typically XML or JavaScript Object Notation (JSON), but can be comma-separated variables, or other formats.

Web services may be statically defined. That is, a Web service may be programmed to receive one or more arguments, to perform a function using those arguments, and to provide a reply. By way of example, a Web service can be called, over the Internet, by a computer program running on a remote device. The computer program can call the Web service to request the weather, for example. The computer program may pass, as arguments to the Web service, a location and a time period. The Web service receives these arguments, obtains the weather for that location and time period, e.g., from a local or remote network resource, and returns the weather at the location for the time period.

Each service that exposes Web services faces the challenge of defining a set of services that are easy enough to use, and powerful enough to solve real problems. Some more complex applications expose Web services that are not statically-defined. Those applications use query languages similar to Structured Query Language (SQL) to query for data. An example of this is Facebook® Query Language (FQL). Languages such as these allow Web services to query database tables in ways that may be more flexible than the more classic scenario described above. Although the languages provide flexibility in using Web services, the Web services themselves remain unchanged.

SUMMARY

This patent application describes methods and apparatus, including computer program products, for scripting Web services. By virtue of the scripting technology described herein, a user can customize Web services to perform any appropriate functions. Thus, instead of creating and loading all Web services when a server is configured for a user, the techniques described herein allow a user, at will, to upload their own scripts to the server to define Web services on the server. The Web services are therefore customized for the user. The same processes may be used for Web services on a server that is accessible to multiple users.

Accordingly, described herein is a method performed on a server, which comprises receiving, from a client, a call to a Web service run on the server, where the Web service corresponds to a script that was uploaded to the server by the client to define the Web service. The method also comprises authenticating the call to an account, identifying a script corresponding to the Web service, executing code corresponding to the script, which code produces an output, and sending the output to the client.

The code may comprise a compiled version of the script. The script may comprise Java or Groovy. The script may have a security context. The security context may comprise a Java classloader that restricts the script to using an approved set of classes and interfaces. The security context may be modifiable. Authenticating the call may comprise authenticating a user who owns or otherwise controls the account.

Also, described herein is a method performed on a server that comprises configuring the server to enable script for a Web service to be defined dynamically. The Web service includes an application program interface (API) for enabling access by, and interaction with, a computer program executing on a device other than the server. The method also comprises compiling the script to produce machine-executable code for the Web service, receiving a call from the computer program to the Web service, executing the machine-executable code in response to the call to produce an output, and sending the output to the device.

Configuring the server to enable script for the Web service to be defined dynamically may comprise storing, in the server, code to generate a graphical user interface (GUI) into which the script is entered. The method may further comprise receiving a request for the GUI, outputting the GUI in response to the request, and receiving the script via the GUI.

Configuring the server to enable script for the Web service to be defined dynamically may comprise storing, in the server, a compiler for compiling the script, and storing, in the server, a database to store information corresponding to the machine-executable code. Configuring the server may also comprise storing, in the server, machine-executable code that, when executed, enables receipt of the script.

The call to the Web service may comprise a HyperText Transfer Protocol (HTTP) command. The HTTP command may identify the script in accordance with a convention defined by a proprietor of the script. The device designated by the script may be an entity other than the entity on which the computer program runs. The computer program may pass an argument with the call. The argument may be associated with an aspect of an entity being monitored. The machine-executable code for the Web service may obtain information associated with the argument and uses the information to generate the output.

The device may communicate with the server over communication path that is at least partially wireless. The call may comprise instructions to access a functionality of the Web service.

DETAILED DESCRIPTION

This patent application describes processes for scripting Web services. An example process includes configuring a server to enable script for a Web service to be defined dynamically. The Web service includes an application program interface (API) for enabling access by, and interaction with, a computer program executing on a device other than the server. The script is compiled to produce machine-executable code (or simply "code") for the Web service. The resulting code is stored in association with an account. The process also includes receiving, from a client, a call to the Web service, authenticating the call to the account, identifying a script that corresponds to the account, executing code that corresponds to the script to produce an output, and sending the output to the requesting client.

FIGS. 1 and 2 show an example of the foregoing processes conceptually. As shown in FIG. 1, a user 10 at a client 12accesses a Web server application 14 running on server 16. Web server application (or simply "Web server") 14 outputs a graphical user interface (GUI), which is typically a Web page 18. Web page 18 allows client 12 to define a Web service dynamically. That is, the Web service may be defined by user 10 to perform whatever functions are programmable. The Web service may be defined using a language, such as Java or Groovy. In this example, client 12 Web services enters script 19 into field 20 of Web page 18. This script programs server 16 with Web service 22 functionality that the user would like to implement and make available.

More specifically, the script may be sent to server 16 via Web page 18. Additional information may be sent with, or before, the script. For example, user 10 may log into server 16 before entering script. In this case, server 16 may know the user's account 23 information, e.g., account number, name, etc., and associate that information with a Web service defined by the script. Alternatively, user 10 may enter this information into other fields (not shown) in Web page 18 or in another Web page or form (not shown). The user may also name the Web service using an alphanumeric identifier or other convention.

In the example of FIG. 1, Web services 22 to 26 are associated with corresponding user accounts. At least some of the associated information, such as the name of the Web service and access to the user account, may be required to access the Web services.

Following receipt of script 19, server 16 compiles the script to generate machine-executable code (or simply "code") for implementing the Web service defined by the script. The code may be stored in a database on server 16 in association with, e.g., account information and/or other identifier(s). The code may be executed on server 16 when Web service 22 is called by a computer program. The code may implement an API, through which other computer programs can access the functionality provided by the Web service. The functionality may include anything that is programmable by the user. For example, the functionality may include calls to other Web services, processing data received from monitoring agents including alarm conditions, selecting a subset of monitored data, accessing tables in a database, processing data from those tables, and so forth.

FIG. 2 shows, conceptually, the operation of a Web service 22 defined according to FIG. 1. In the example of FIG. 2, Web service 22 processes, and reports on, data obtained by a monitoring agent 24. Monitoring agent 24 may include one or more processing devices, such as a microprocessor or a microcontroller. Monitoring agent 24 may be associated with (e.g., embedded in) a system or device that is being monitored. Examples of systems or devices that may be monitored are shown in FIG. 2 and include, but are not limited to, an automobile 26, medical equipment 28 (e.g., a magnetic resonance imaging (MRI) machine), and a building's heating, ventilation, and air conditioning (HVAC) system 30.

In operation, monitoring agent 24 interacts with (32) monitoring program 34, which is running on server 16 in this example, and which itself may be a Web service. Monitoring agent 24 may be configured to report, to monitoring program 34, information about the status and/or operation of the corresponding monitored device and/or system. For example, monitoring agent 24 may report on the number of trips that automobile 26 has taken, with a trip being defined by a start and end of operation, the duration of each trip, and the average speed of each trip. Monitoring agent 24 may also be configured to update itself or its monitored system using information obtained via server 16. For example, monitoring agent 24 may obtain updated parameters for HVAC system 30, such as updated temperature or humidity levels to set and at what times those levels should be set. In another example, monitoring agent 24 may obtain software updates and upgrade the software (e.g., operating system) of its monitored device and/or system using the software updates.

In this example, as a result of the interaction (32) between monitoring agent 24 and monitoring program 34, monitoring agent 24 provides (38) data 40 about the operation and/or status of monitored devices/systems. This data may be stored in server 16, as shown.

In this example, Web services 22 to 42 are associated with user account 23. To access Web service 22, a user 10 at client12 accesses user account 23. This may be done by logging into the account via a Web page or other GUI. Alternatively, a computer program 46 on client 12 calling Web service 22 may log into the user's account without interaction from the user. If there is more than one Web service associated with the user account, as is the case in this example, it may be necessary to identify the Web service that is to be accessed. This may be done via computer program 46. For example, if computer program 46 is designed to obtain information about the operation of automobile 26, computer program 46 will identify Web service 22. This may be done, e.g., by making a call (48) to that Web service and by including a Web service name or other identifier in the call.

Computer program 46 may, to pass Web service 22, one or more arguments, such as an identifier for automobile 26(particularly if, e.g., Web service 22 is configured to work with more than one automobile). In response, Web service 22may retrieve (50) data 40 that has been obtained by monitoring the operation and/or status of automobile 26. This data may be filtered or otherwise processed for presentation to computer program 46. For example, the data may include starting and ending times for a trip, and the length of the trip. Web service 22 may use this information to calculate the average speed over the course of the trip, and return only this average speed. Web service 22 provides (52) its information to computer program 46. This information is then displayed or otherwise presented to user 10. Should user 10 require different or additional information, user 10 can create a new

Web service or edit an existing Web service. This may be done in accordance with the process shown conceptually in FIG. 1.

FIG. 3 shows, conceptually, an example of a system 56 on which the processes shown in FIGS. 1 and 2 may be implemented. As shown in FIG. 3, one or more agents (e.g., devices and/or computer programs) 57 to 62 may be used to monitor the operation and/or status of systems 64 and 66. These monitoring agents may include embedded agents, gateway agents, custom agents (e.g., programmable devices), non-programmable agents, and/or wireless protocol agents. Monitoring agents 57 to 62 communicate with server 68 via a network, such as the Internet 70 and/or a cellular network 72. Server 68 runs a platform 74, which may include an operating system and other functionality to support communication with the monitoring agents. Server 68 also supports Web services 76, including Web services that have been defined according to the process of FIG. 1.

Server 68 may be a central server that is accessible to different clients at different companies, or server 68 may be company-specific, meaning that it is accessible by, and contains Web services for, only a particular company. A client 80accesses Web services 76 via a network 70, such as the Internet. Client 80 may include, but is not limited to, a back-office system, such as a customer relationship management (CRM) system, a product lifecycle management (PLM) system, and/or a supply chain management (SCM) system.

By way of example, consider an SCM application that monitors goods moved between a supplier and a customer. If the SCM application tracks returned goods and determines, through its own analysis, that one process seems to be generating a large number of returned products, the ability to diagnose and fix the process would be beneficial. Using a dynamically-defined Web service of the type described herein, the SCM application could query a database maintained by platform 74to locate equipment and systems included in the monitored process. Using Web services 76, platform 74 may analyze the data and flag, to the SCM application, the trouble areas in the process. In addition, platform 74 could notify and provide technicians with a history of the troubled equipment. In this example, all communications and data transmissions between the SCM system and the platform may be secure.

FIG. 4 shows a more detailed example of a network system 84 on which the processes shown conceptually in FIGS. 1 and 2 may be implemented. It is noted that the network systems shown in FIGS. 3 and 4 are presented merely for illustration. The techniques described herein are not limited to use on a network system having the architectural configuration of FIG. 3or 4. Rather, the processes depicted in FIGS. 1 and 2 can be implemented using any appropriate network, hardware, and/or software architectures.

Network system 84 includes clients 86 to 88 and servers 90 to 92. These clients and servers are connected via network 94. Network 94 may include one or more networks, such as a local area network (LAN), a wide area network (WAN), and/or the Internet. One or more of the networks that make up network 94 may be wireless, such as a cellular telephone network or a Wi-Fi network. Network 94, in conjunction with one or more of the clients and servers, may form a cloud computing system.

Each client may be a computing device, such as desktop, a laptop, a tablet, a smartphone, or the like. Generally, a smartphone is a mobile device that offers advanced computing capabilities, such as the ability to execute applications and to communicate with a server or another appropriate computing device.

Each client, may include a hard drive 96 for storing data and computer programs, and one or more processing devices 98(e.g., a microprocessor) and memory 100 (e.g., RAM) for executing computer programs. A display screen (e.g., 102), such as an LCD (Liquid Crystal Display) or a CRT (Cathode Ray Tube) displays, to a user, images that are generated by the client including, but not limited to, the Web pages and outputs described herein. As is well known, display on a computer peripheral (e.g., a monitor) physically transforms the computer peripheral. For example, if the computer peripheral is LCD-based, the orientation of liquid crystals can be changed by the application of biasing voltages in a physical transformation that is visually apparent to the user. As another example, if the computer peripheral is a CRT, the state of a fluorescent screen can be changed by the impact of electrons in a physical transformation that is also visually apparent. Each display screen may be touch-sensitive, allowing a user to enter information onto the display screen via a virtual keyboard. On some clients, such as a desktop or smartphone, a physical QWERTY keyboard and scroll wheel may be provided for entering information onto the display screen.

Each client may run an operating system (OS) 104, such as a version of MICROSOFT WINDOWS or MAC OSX. Computer programs, including applications 106, are stored, e.g., in hard drive 96, and execute on top of the OS. Among these computer programs may a Web Browser 108, such as MICROSOFT INTERNET EXPLORER, GOOGLE CHROME, or APPLE SAFARI for accessing data from the servers. This data may include Web pages for entering script and other information to generate Web services, and information provided by those Web services, including graphics and alphanumerics.

Each of servers 90 to 92 may have the same, or similar, hardware and/or software configuration. In a case where all of the servers are owned by the same entity, servers 90 to 92 may act together to perform the functions described herein. In the case of multiple servers, server 90 may act as a controller or "load balancer" for the remaining servers 91 and 92. In this role, server 90 may route data, requests, and instructions between a client and a "slave" server, such as server 92. Server90 may store information locally, then route data to another server, such as server 92. For the purposes of the following, such internal communications between server 90 and slave servers will be assumed. In a case where the servers are owned by different entities, a single server may perform all of the server functions.

Since all of the servers may have the same, or similar, architecture only the architecture of server 90 is described. Server90 may be identical in structure and function to server 16 of FIGS. 1 and 2. Server 90 includes a storage system 110, e.g., RAID (Redundant Array of Inexpensive Disks), for storing data and computer programs, and one or more processing device(s) 112 (e.g., one or more microprocessors) and memory 114 (e.g., RAM) for executing computer programs. Each server may run a platform 116, which includes an operating system such as a version of LINUX, and one or more computer programs for interacting with the server's clients. Computer programs, including a Web server 118 and a compiler 120, may be stored, e.g., in storage system 110, and execute on top of the platform to perform the functions described herein. Storage system 110 may also include a database for storing Web services 174. Web services 174 may correspond to Web services 22 of FIGS. 1 and 2. Data for each Web service may include, for example, script that defines the Web service, machine-executable code that is generated by compiling the script, and information associated with the Web service, e.g., to identify the Web service or corresponding account.

Each server may host, or otherwise provide access to, information contained therein. For example, a user at a client 86may sign onto a Web site hosted by server 90 (or, e.g., for which server 90 is gateway). In response, e.g., through an appropriate HTTP exchange, server 90 may provide, to client 86, the Web page (or other GUI) (e.g., Web page 18 of FIG. 1) for entering script to define a Web service, as described in more detail below.

Monitored system 124 may be any type of device and/or system that can be monitored, examples of which include, but are not limited to, the examples shown in FIG. 2. Monitoring agent 126 may be a computer program or a device, such as a microprocessor or microcontroller, that is configured to operate in conjunction with a system to monitor and/or control its status and/or operation. Monitoring agent 126 may correspond to monitoring agent 24 of FIG. 2.

Monitoring agent 126 may be configured to communicate with server 90 over network 94. For example, monitoring agent126 may be a wireless device that is configured to communicate over network 94 using one or more wireless protocols. Alternatively, monitoring agent may be a wired device. For example, monitoring agent 126 may be behind a firewall, may be a device of the type described in one or more of the following, and may be configured to communicate with server 90 via one or more of the techniques described in one or more of the following: U.S. Pat. No. 7,117,239, U.S. Pat. No. 7,185,014, U.S. patent application Ser. No. 10/124,181, and U.S. patent application Ser. No. 11/537,399. The contents of U.S. Pat. No. 7,117,239, U.S. Pat. No. 7,185,014, U.S. patent application Ser. No. 10/124,181, and U.S. patent application Ser. No. 11/537,399 are hereby incorporated by reference into this application as if set forth herein in full. In this regard, any appropriate features described in U.S. Pat. No. 7,117,239, U.S. Pat. No. 7,185,014, U.S. patent application Ser. No. 10/124,181, and U.S. patent application Ser. No. 11/537,399 may be used in conjunction with the techniques described herein.

Data center 130 may be a repository for Web services 132. In this example, data center 130 and server 90 are separate entities; however, in other examples, the two may be combined in a single device or set of devices. Data center 130 may include a storage system (not shown) for storing code and other information for Web services 132, and one or more processing devices (not show) for making the Web services accessible to clients of the data center over network 94. For example, data center 130 may include a library of Web services that are available to clients over network 94. A client may access such a Web service directly from the data center, or it may take code therefor and store that code on its own server(s). Likewise, a client may access script that defines those Web services and modify the script to generate new Web services. The resulting new Web services may be stored either in the client's server(s) or in the data repository library. The library of scripts stored in the data center (or server 16 or 90 to 92) can be versioned, meaning that they can exist in different versions with appropriate version identifiers associated therewith. A client may therefore use, or roll back to, to a previous version of a script (e.g., if undesirable edits were made to a Web services script).

FIG. 5 shows an example of a process 140 for scripting Web services using the techniques described herein. Process 140includes a part 142 that may be performed by a client (e.g., client 86), a part 144 that may be performed by a server (e.g., server 90), and a part 146 that may be performed by a monitoring agent (e.g., agent 126). In this regard, the process shown in FIG. 5 is presented merely for illustration. The techniques described herein for scripting Web services are not limited to the process sequence shown of FIG. 5. Rather, the actions shown in FIG. 5 may be performed in a different sequence by different entities; actions may be added to the sequence; actions may be omitted from the sequence; and/or actions in the sequence may be consolidated.

As part of process 140, server 90 is configured to enable script for a Web service to be defined dynamically. This may be done by storing, in server 90, code to generate a Web page (or other GUI), such as Web page 18 of FIG. 1, into which script that defines the Web service is to be entered. Server 90 hosts (148) this Web page, thereby enabling clients to access it over a network. An implementation of this Web page is shown in FIG. 6. Specifically, FIG. 6 shows a Web page150 that includes a field 152 for defining a name of a Web service, a field 154 for providing a description of the Web service (e.g., it's functionality), and a field 156 for entering script (source code) for implementing the Web service. Web page 150also includes a control 158 that triggers compilation of the script. Web page 150 also includes controls 160 to define parameters in the source code, e.g., "username" and "name filter".

The script may define a context in which it should run. In this example, there are two types of contexts: user and system. Under the user context, the script runs with the permissions or privileges defined for a specified user. Under the system context, the script runs with privileges and permissions for access to all functionality and database objects (like an administrator). For example, if the script needs to perform administrative-type functionality, like determining device group assignments for users or defining data item groups, the script should run under a system context. The context passed by the Web service does not need to be the same context defined for the script. For example, if a Web service is run in a user context, and the script defines a system context, the Web service will handle switching the context back to user context after the script finishes running

In an implementation, the script has a security context. The security context may be a Java classloader that restricts the script to using an approved set of classes and interfaces.

In FIG. 5, client 86 accesses (164) Web page 150 through its browser 108. To access the Web page, a user at client 86may need to sign into his account on server 90; however, this is not a requirement. Script for the Web service is entered (166) into the Web page. The script may be Java or Groovy, for example. Other programming languages may also be entered to define the Web service. Web page 150 may send (168) the uncompiled script to server 90, where it is compiled (170) by compiler 120 and where the resulting machine-executable code is stored for use. Alternatively, the script may be compiled locally and resulting machine-executable code sent to server 90 for storage, with or without the corresponding script. Identifying information for the Web service also may be sent to server 90, and stored in associate with code and/or script for the Web service.

Client 86 may access (172) Web service 174 (FIG. 4). Web service 174 includes a Web API, which allows the Web service to interact with a computer program running on the client. For example, the computer program on client 86 may call the Web service to obtain information therefrom. The call may include one or more arguments that may be used by the Web service to generate its output, or may indicate to the Web service the outputs that are needed. Arguments used for other purposes may also be passed to the Web service.

Code on server 90 may authenticate the call to an account (e.g., the user's account), identify a script (e.g., on server 90) corresponding to the Web service, execute code corresponding to the Web service, and send an output produced by the Web service to the client. In this regard, Web services for the server platform 116 may enable remote users to access and affect information in the platform's database, and to access and perform operations on managed assets. Each Web services call to the platform may specify an authenticated user account. The platform validates the user account provided for an operation against its directory service (LDAP or Active Directory) and user group settings, determining the following: if the user is permitted access to the platform, and if the user has privileges to access the data and perform the operations specified in the Web service call. If an entity does not have privileges to perform an operation, an "Access Denied" message may be returned to client 86 along with information about which privilege is required. Additionally, queries will not return information for any devices to which a user does not have device permissions.

The platform maintains an audit log of significant user actions that occur in the system, including operations performed, or attempted, through Web services. Examples of audited activity include user logins, operations that affect database information (including creating, deleting, updating database objects, or assigning or unassigning associations), agent and device operations, and remote access sessions. Audit information is shown in an audit log, which is available through an administration application. In the example of FIG. 4, server 90 executes (180) code corresponding to the called

Web service, and interacts (182) with a monitoring agent to obtain information about a system being monitored and/or controlled by that agent. Monitoring agent 126 interacts (184) with the Web service to provide whatever information is requested.

Web service 174 provides (186) its information—in this example, information based on that provided by monitoring agent126—to the requesting computer program running in client 86. The computer program receives (190) that information at client 86, and uses that information to generate an appropriate output. For example, the computer program may render graphical information on a machine display (e.g., a computer monitor or cell phone display screen) showing the past, present, and projected states of the monitored system. In another example, the computer program may be an application or "app" running on a smartphone, and the monitored system may be an automobile. In this example, a user on the smartphone may track use of the automobile through graphics, tables, text or the like that is displayed on the smartphone's display screen by the app.

In an alternative implementation, script defining a Web service can be uploaded to server 16 or 90 to 91 through another Web service, rather than through a Web page. For example, script may be entered into a computer program or a template on the client. The script may be passed as an argument in a call to a Web service running on the server. The Web service on the server may cause the script to be compiled and the resulting code stored, thereby allowing the resulting new Web service to be accessed at the server. In another example, script for the Web service may be entered into a computer program or interface at the client. A Web service running on the server may query the computer program or interface (e.g., periodically) for new script. If there is new script, the Web service may retrieve that script and cause it to be compiled and the resulting code to be stored on the server, thereby allowing the resulting new Web service to be accessed at the server. The Web service may query the client in accordance with any appropriate processes, such as those described in U.S. Pat. No. 7,185,014, U.S. patent application Ser. No. 10/124,181, and U.S. patent application Ser. No. 11/537,399 incorporated by reference above.

A particular implementation of Web services scripting is provided below. In this implementation, a server stores a platform for creating applications via the Internet. The interactions can be complex, and may include multiple actions and/or branching logic. The platform supports flexible, customer-programmed Web services. Each customer creates their own set of Web services and uses them in their applications. A customer can also publish the Web services and allow others to create clients that use those Web services.

A server, which may be hosted in a data center, provides an Internet service and publishes Web services in addition to a Web user interface (UI). Customers login to the UI and define their Web services, which are then published to Web service clients.

The UI includes field(s) to enter script that defines a Web service. The script has a unique name, a set of parameters, and programming language code. When the script is saved in the server, its name can be called in the URI of a Web service call. For example, a script like:

	script name: HelloWorld
	parameters: planet
	code:
	def result = "Hello ${parameters.planet}"
	return ['Content-Type':'text/plain', 'Content':result.toString( )]

can be called with an HTTP POST to URI, as follows:

• http://server.axeda.com/services/v1/rest/Script/HelloWorld 
  with the POST parameter planet=Pluto, and the response would be "Hello Pluto".

When code for a script is executed, it can call allowed server APIs to query, modify or take actions. For security, each script is executed in a secure environment that restricts what the script code can do. Scripts are thus not able to harm the server or perform unauthorized actions. When a client calls a Web service, user credentials may be required. User permissions are applied to APIs that the script can call, thereby limiting the script to safe actions based on the permissions given to that user by an administrator.

In this regard, each call to a Web service may identify an authenticated platform user. To do this, the computer program making the call must first login to the platform via an authentication service login operation. If a username and password for an authenticated user are provided to the login operation, it will return a SessionId token. That token is cached and then passed with each subsequent Web service operation. If an invalid SessionId is passed to an operation, or the SessionId that was passed has timed out, the platform will ignore the operation request. The user account passed to the login operation should authenticate to an existing user with sufficient privileges. Each Web service may be limited to the actions and objects to which the user has privileges. For example, calling "getDevices" will return only the devices that this user is allowed to see if he or she logs into the platform. A client should use a login that has appropriate privileges for its intended task.

The process of creating a script may include a user logging into the server platform via a UI. The user submits a script as above. The script code is then compiled and may be tested. Generally speaking, scripts need to be managed in development and production. A script may be uploaded to the server for testing. When the testing is successful, that script may be promoted to production. If there are any errors in the compilation or testing of the script, an error message is displayed and the user must correct the script. If there are no errors, the resulting compiled code is stored so that it can be executed relatively quickly. This code may be Java bytecodes or .NET CLR, or it may be that the script is interpreted when it runs, as is the case with per1 code.

In an example, a client computer program calls a Web service that returns the status of some equipment. The client creates a request to a URI, such as:

• http://server.axeda.com/services/v1/rest/Script/GetStatus?user=ted&password=Ty!de88 

The server handles the request by extracting the script name ("GetStatus") and user credentials. The user credentials are authenticated, and if the authentication process fails, an error is returned. For example, if the script name does not reference a legal script in the server, or this user does not have permissions to run this script, an error is returned to the client. Otherwise the named script is loaded into a secure "sandbox" environment and run. In Java, this is done via a custom classloader that has a predefined set of Java classes that are included in its path. References to classes outside the path are not allowed. Parameters in the URL or the HTTP POST body are passed into the script as named parameters.

The script is allowed to call the server's API, and certain external methods. For example, a script can call another server's web services. The APIs in the server may be related to monitored assets (e.g., devices, systems, etc.). A script may query the values of readings associated with those assets and also check if the asset has any recent alarm conditions. The result of running the script is a returned HTTP content-type and content.

SRC=https://www.google.com/patents/US20120131473