US8689181B2 - Scripting web services - Google Patents

Scripting web services Download PDF

Info

Publication number
US8689181B2
US8689181B2 US12/952,890 US95289010A US8689181B2 US 8689181 B2 US8689181 B2 US 8689181B2 US 95289010 A US95289010 A US 95289010A US 8689181 B2 US8689181 B2 US 8689181B2
Authority
US
United States
Prior art keywords
script
web service
servers
context
client
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active, expires
Application number
US12/952,890
Other versions
US20120131473A1 (en
Inventor
Joseph L. Biron, III
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
PTC Inc
Original Assignee
Axeda Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US12/952,890 priority Critical patent/US8689181B2/en
Application filed by Axeda Corp filed Critical Axeda Corp
Publication of US20120131473A1 publication Critical patent/US20120131473A1/en
Assigned to AXEDA CORPORATION reassignment AXEDA CORPORATION RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: SILICON VALLEY BANK
Assigned to AXEDA CORPORATION reassignment AXEDA CORPORATION RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: MMV CAPITAL PARTNERS INC.
Assigned to COMERICA BANK reassignment COMERICA BANK SECURITY AGREEMENT Assignors: AXEDA CORPORATION
Assigned to AXEDA CORPORATION reassignment AXEDA CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BIRON, JOSEPH L., III
Priority to US14/170,082 priority patent/US9172745B2/en
Application granted granted Critical
Publication of US8689181B2 publication Critical patent/US8689181B2/en
Assigned to AXEDA CORPORATION reassignment AXEDA CORPORATION RELEASE OF SECURITY INTEREST Assignors: COMERICA BANK
Assigned to PTC INC. reassignment PTC INC. MERGER (SEE DOCUMENT FOR DETAILS). Assignors: AXEDA CORPORATION
Priority to US14/921,182 priority patent/US9712644B2/en
Assigned to JPMORGAN CHASE BANK, N.A., AS ADMINISTRATIVE AGENT reassignment JPMORGAN CHASE BANK, N.A., AS ADMINISTRATIVE AGENT SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: PTC INC.
Priority to US15/649,758 priority patent/US10574790B2/en
Assigned to JPMORGAN CHASE BANK, N.A., AS ADMINISTRATIVE AGENT reassignment JPMORGAN CHASE BANK, N.A., AS ADMINISTRATIVE AGENT SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: PTC INC.
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63Routing a service request depending on the request content or context
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G06F9/45508Runtime interpretation or emulation, e g. emulator loops, bytecode interpretation
    • G06F9/45512Command shells
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/22Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management

Definitions

  • This patent application relates generally to scripting Web services.
  • W3C World Wide Web Consortium
  • 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.”
  • SOAP Simple Object Access Protocol
  • HTTP is the acronym for HypterText Transfer Protocol
  • XML is the acronym for eXtensible Markup Language
  • 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.
  • URI Uniform Resource Indicator
  • URL Uniform Resource Locator
  • the Web service returns data in a format that the requesting client can use. This format is typically XML or JAVA UScript 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.
  • 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.
  • SQL Structured Query Language
  • An example of this is Facebook® Query Language (FQL).
  • SQL Structured Query Language
  • FQL Facebook® Query Language
  • This patent application describes methods and apparatus, including computer program products, for scripting Web services.
  • a user can customize Web services to perform any appropriate functions.
  • 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.
  • 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.
  • 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.
  • API application program interface
  • 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.
  • GUI graphical user interface
  • 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.
  • HTTP HyperText Transfer Protocol
  • 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.
  • All or part of the foregoing may be implemented as a computer program product comprised of instructions that are stored on one or more non-transitory machine-readable storage media, and that are executable on one or more processing devices. All or part of the foregoing may be implemented as an apparatus, method, or system that may include one or more processing devices and memory to store executable instructions to implement functionality.
  • FIG. 1 is a conceptual view of a process for scripting a Web service.
  • FIG. 2 is a conceptual view of a process for using the scripted Web service.
  • FIG. 3 shows a conceptual view of a network on which the processes of FIGS. 1 and 2 may be implemented.
  • FIG. 4 shows a network on which the processes of FIGS. 1 and 2 may be implemented.
  • FIG. 5 is a flowchart showing the processes of FIGS. 1 and 2 .
  • FIG. 6 shows an example of a user interface for entering script for a Web service.
  • 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.
  • a user 10 at a client 12 accesses 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 .
  • GUI graphical user interface
  • 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.
  • 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.
  • the script may be sent to server 16 via Web page 18 . Additional information may be sent with, or before, the script.
  • user 10 may log into server 16 before entering script.
  • 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.
  • 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.
  • 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.
  • 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 .
  • 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 .
  • MRI magnetic resonance imaging
  • HVAC heating, ventilation, and air conditioning
  • 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.
  • 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.
  • Web services 22 to 42 are associated with user account 23 .
  • a user 10 at client 12 accesses user account 23 . This may be done by logging into the account via a Web page or other GUI.
  • 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).
  • Web service 22 may 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 .
  • 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.
  • 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 80 accesses 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.
  • CRM customer relationship management
  • PLM product lifecycle management
  • SCM supply chain management
  • the SCM application could query a database maintained by platform 74 to locate equipment and systems included in the monitored process.
  • platform 74 may analyze the data and flag, to the SCM application, the trouble areas in the process.
  • 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. 3 or 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.
  • LAN local area network
  • WAN wide area network
  • 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.
  • 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
  • LCD Liquid Crystal Display
  • CRT Cathode Ray Tube
  • display on a computer peripheral physically transforms the computer peripheral.
  • 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.
  • 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.
  • 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.
  • OS operating system
  • Computer programs, including applications 106 are stored, e.g., in hard drive 96 , and execute on top of the OS.
  • 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 . Server 90 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.
  • Server 90 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.
  • a storage system 110 e.g., RAID (Redundant Array of Inexpensive Disks)
  • processing device(s) 112 e.g., one or more microprocessors
  • memory 114 e.g., RAM
  • 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.
  • 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.
  • a user at a client 86 may sign onto a Web site hosted by server 90 (or, e.g., for which server 90 is gateway).
  • 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 .
  • monitoring agent 126 may be a wireless device that is configured to communicate over network 94 using one or more wireless protocols.
  • monitoring agent may be a wired device.
  • 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.
  • Data center 130 may be a repository for Web services 132 .
  • 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 .
  • 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).
  • 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 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 140 includes 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 ).
  • client e.g., client 86
  • server e.g., server 90
  • a part 146 that may be performed by a monitoring agent (e.g., agent 126 ).
  • 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.
  • 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.
  • FIG. 6 shows a Web page 150 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 150 also 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.
  • the script runs with the permissions or privileges defined for a specified user.
  • the script runs with privileges and permissions for access to all functionality and database objects (like an administrator).
  • 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.
  • 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.
  • client 86 accesses ( 164 ) Web page 150 through its browser 108 .
  • a user at client 86 may 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.
  • 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.
  • 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.
  • 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.
  • LDAP directory service
  • Active Directory Active Directory
  • 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.
  • 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 agent 126 —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.
  • 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.
  • the computer program may be an application or “app” running on a smartphone, and the monitored system may be an automobile.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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).
  • UI Web user interface
  • 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.
  • the script is saved in the server, its name can be called in the URI of a Web service call.
  • 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:
  • code for a script 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.
  • 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.
  • each call to a Web service may identify an authenticated platform user.
  • 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.
  • 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 perl code.
  • 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:
  • 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.
  • a computer program product i.e., a computer program tangibly embodied in one or more information carriers, e.g., in one or more tangible, non-transitory machine-readable storage media, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers
  • a computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.
  • a computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a network.
  • Actions associated with implementing the processes can be performed by one or more programmable processors executing one or more computer programs to perform the functions of the calibration process. All or part of the processes can be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) and/or an ASIC (application-specific integrated circuit).
  • special purpose logic circuitry e.g., an FPGA (field programmable gate array) and/or an ASIC (application-specific integrated circuit).
  • processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer.
  • a processor will receive instructions and data from a read-only storage area or a random access storage area or both.
  • Elements of a computer include one or more processors for executing instructions and one or more storage area devices for storing instructions and data.
  • a computer will also include, or be operatively coupled to receive data from, or transfer data to, or both, one or more machine-readable storage media, such as mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks.
  • Machine-readable storage media suitable for embodying computer program instructions and data include all forms of non-volatile storage area, including by way of example, semiconductor storage area devices, e.g., EPROM, EEPROM, and flash storage area devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.
  • semiconductor storage area devices e.g., EPROM, EEPROM, and flash storage area devices
  • magnetic disks e.g., internal hard disks or removable disks
  • magneto-optical disks e.g., CD-ROM and DVD-ROM disks.

Abstract

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.

Description

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 JAVA UScript 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.
Any two or more of the features described in this patent application, including those described in this summary section, may be combined to form embodiments not specifically described in this patent application.
All or part of the foregoing may be implemented as a computer program product comprised of instructions that are stored on one or more non-transitory machine-readable storage media, and that are executable on one or more processing devices. All or part of the foregoing may be implemented as an apparatus, method, or system that may include one or more processing devices and memory to store executable instructions to implement functionality.
The details of one or more examples are set forth in the accompanying drawings and the description below. Further features, aspects, and advantages will become apparent from the description, the drawings, and the claims.
DESCRIPTION OF THE DRAWINGS
FIG. 1 is a conceptual view of a process for scripting a Web service.
FIG. 2 is a conceptual view of a process for using the scripted Web service.
FIG. 3 shows a conceptual view of a network on which the processes of FIGS. 1 and 2 may be implemented.
FIG. 4 shows a network on which the processes of FIGS. 1 and 2 may be implemented.
FIG. 5 is a flowchart showing the processes of FIGS. 1 and 2.
FIG. 6 shows an example of a user interface for entering script for a Web service.
Like reference numerals indicate like elements.
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 12 accesses 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 client 12 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 22 may 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 80 accesses 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 74 to 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. 3 or 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. Server 90 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. Server 90 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 86 may 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 agent 126 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 140 includes 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 page 150 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 150 also 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 86 may 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 agent 126—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 perl 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.
All or part of the processes described herein and their various modifications (hereinafter referred to as “the processes”) can be implemented, at least in part, via a computer program product, i.e., a computer program tangibly embodied in one or more information carriers, e.g., in one or more tangible, non-transitory machine-readable storage media, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers
A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a network.
Actions associated with implementing the processes can be performed by one or more programmable processors executing one or more computer programs to perform the functions of the calibration process. All or part of the processes can be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) and/or an ASIC (application-specific integrated circuit).
Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only storage area or a random access storage area or both. Elements of a computer (including a server) include one or more processors for executing instructions and one or more storage area devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from, or transfer data to, or both, one or more machine-readable storage media, such as mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Machine-readable storage media suitable for embodying computer program instructions and data include all forms of non-volatile storage area, including by way of example, semiconductor storage area devices, e.g., EPROM, EEPROM, and flash storage area devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.
In addition, the logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. In addition, other actions may be provided, or actions may be eliminated, from the described flows, and other components may be added to, or removed from, the described systems. Likewise, actions depicted in the figures may be performed by different entities or consolidated.
Elements of different embodiments described herein may be combined to form other embodiments not specifically set forth above. Elements may be left out of the processes, computer programs, Web pages, etc. described herein without adversely affecting their operation. Furthermore, various separate elements may be combined into one or more individual elements to perform the functions described herein.
Elements of different implementations described herein may be combined to form other implementations not specifically set forth above. Other implementations not specifically described herein are also within the scope of the following claims.

Claims (43)

What is claimed is:
1. A method performed on one or more servers, comprising:
receiving, from a device of a client, a call to a Web service run on the one or more servers, the Web service corresponding to a script that was uploaded to the one or more servers by the client to define the Web service, the script comprising a client-modified script that exists in different versions, including a previous version, that are accessible by the client;
authenticating the call to an account;
identifying the script corresponding to the Web service;
executing, on the one or more servers, code corresponding to the script to run the script, the code producing an output, the code defining a context among multiple contexts in which the script should run, the multiple contexts comprising a user context and a system context, in the user context the script running with permissions or privileges defined for a specified user, in the system context the script running with privileges and permissions for access to administrative functionality and database objects, the Web service handling switching contexts after the script runs; and
sending the output to the device.
2. The method of claim 1, wherein the code comprises a complied version of the script, and wherein the script comprises JAVA or Groovy.
3. The method of claim 1, wherein the script has a security context, the security context comprising a JAVA classloader that restricts the script to using an approved set of classes and interfaces.
4. The method of claim 3, wherein authenticating the call comprises authenticating a user who owns the account; and
wherein the security context is modifiable.
5. The method of claim 1, further comprising:
receiving a username and password for an authenticated user; and
returning a session identifier (session ID) token in response to the receiving;
wherein the session ID token is passed with each Web service operation.
6. A method performed on one or more servers, comprising:
configuring the one or more servers to enable script for a Web service to be defined dynamically, the Web service comprising an application program interface (API) for enabling access by, and interaction with, a computer program executing on a device other than the one or more servers;
receiving, from a device of a client, script to define the Web service, the script comprising a client-modified script that exists in different versions, including a previous version, that are accessible by the client;
compiling the script on the one or more servers to produce machine-executable code for the Web service, the machine-executable code defining a context among multiple contexts in which the script should run, the multiple contexts comprising a user context and a system context, in the user context the script running with permissions or privileges defined for a specified user, in the system context the script running with privileges and permissions for access to administrative functionality and database objects, the Web service handling switching contexts after the machine-executable code for the script runs;
receiving a call from the computer program to the Web service;
executing the machine-executable code on the one or more servers in response to the call to produce an output; and
sending the output to the computer program.
7. The method of claim 6, wherein configuring the one or more servers to enable script for the Web service to be defined dynamically comprises storing, in the one or more servers, code to generate a graphical user interface (GUI) into which the script is entered; and
wherein the method further comprises:
receiving a request for the GUI;
outputting the GUI in response to the request; and
receiving the script via the GUI.
8. The method of claim 6, wherein configuring the one or more servers to enable script for the Web service to be defined dynamically comprises:
storing, in the one or more servers, a compiler for compiling the script; and
storing, in the one or more servers, a database to store information corresponding to the machine-executable code.
9. The method of claim 6, wherein configuring the one or more servers to enable script for the Web service to be defined dynamically comprises storing, in the one or more servers, machine-executable code that, when executed, enables receipt of the script.
10. The method of claim 6, wherein the call comprises a HyperText Transfer Protocol (HTTP) command, the HTTP command identifying the script in accordance with a convention defined by a proprietor of the script.
11. The method of claim 6, wherein the computer program passes an argument with the call, the argument being associated with an aspect of an entity being monitored; and
wherein the machine-executable code for the Web service obtains information associated with the argument and uses the information to generate the output.
12. The method of claim 6, further comprising sending the output to a device or system other than the device on which the computer program is executing.
13. The method of claim 6, wherein the computer program communicates with the one or more servers over a communication path that is at least partially wireless.
14. The method of claim 6, wherein the call comprises instructions to access a functionality of the Web service.
15. The method of claim 6, further comprising:
receiving a username and password for an authenticated user; and
returning a session identifier (session ID) token in response to the receiving;
wherein the session ID token is passed with each Web service operation.
16. One or more non-transitory machine-readable storage media storing instructions that are executable on one or more servers to perform operations comprising:
receiving, from a device of a client, a call to a Web service run on the one or more servers, the Web service corresponding to a script that was uploaded to the one or more servers by the client to define the Web service, the script comprising a client-modified script that exists in different versions, including a previous version, that are accessible by the client;
authenticating the call to an account;
identifying the script corresponding to the Web service;
executing code corresponding to the script, the code producing an output, the code defining a context among multiple contexts in which the script should run, the multiple contexts comprising a user context and a system context, in the user context the script running with permissions or privileges defined for a specified user, in the system context the script running with privileges and permissions for access to administrative functionality and database objects, the Web service handling switching contexts after the script runs; and
sending the output to the device.
17. The one or more non-transitory machine-readable storage media of claim 16, wherein the code comprises a compiled version of the script, and wherein the script comprises JAVA or Groovy.
18. The one or more non-transitory machine-readable storage media of claim 16, wherein the script has a security context, the security context comprising a JAVA classloader that restricts the script to using an approved set of classes and interfaces.
19. The one or more non-transitory machine-readable storage media of claim 18, wherein authenticating the call comprises authenticating a user who owns the account; and
wherein the security context is modifiable.
20. The one or more non-transitory machine-readable storage media of claim 16, wherein the operations comprise:
receiving a username and password for an authenticated user; and
returning a session identifier (session ID) token in response to the receiving;
wherein the session ID token is passed with each Web service operation.
21. One or more non-transitory machine-readable storage media storing instructions that are executable on one or more servers to perform operations comprising:
configuring the one or more servers to enable script for a Web service to be defined dynamically, the Web service comprising an application program interface (API) for enabling access by, and interaction with, a computer program executing on a device other than the one or more servers;
receiving, from a device of a client, script to define the Web service, the script comprising a client-modified script that exists in different versions, including a previous version, that are accessible by the client;
compiling the script to produce machine-executable code for the Web service, the machine-executable code defining a context among multiple contexts in which the script should run, the multiple contexts comprising a user context and a system context, in the user context the script running with permissions or privileges defined for a specified user, in the system context the script running with privileges and permissions for access to administrative functionality and database objects, the Web service handling switching contexts after the machine-executable code for the script runs;
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 computer program.
22. The one or more non-transitory machine-readable storage media of claim 21, wherein configuring the one or more servers to enable script for the Web service to be defined dynamically comprises storing, in the one or more servers, code to generate a graphical user interface (GUI) into which the script is entered; and
wherein the method further comprises:
receiving a request for the GUI;
outputting the GUI in response to the request; and
receiving the script via the GUI.
23. The one or more non-transitory machine-readable storage media of claim 21, wherein configuring the one or more servers to enable script for the Web service to be defined dynamically comprises:
storing, in the one or more servers, a compiler for compiling the script; and
storing, in the one or more servers, a database to store information corresponding to the machine-executable code.
24. The one or more non-transitory machine-readable storage media of claim 21, wherein configuring the one or more servers to enable script for the Web service to be defined dynamically comprises storing, in the one or more servers, machine-executable code that, when executed, enables receipt of the script.
25. The one or more non-transitory machine-readable storage media of claim 21, wherein the call comprises a HyperText Transfer Protocol (HTTP) command, the HTTP command identifying the script in accordance with a convention defined by a proprietor of the script.
26. The one or more non-transitory machine-readable storage media of claim 21, wherein the computer program passes an argument with the call, the argument being associated with an aspect of an entity being monitored; and
wherein the machine-executable code for the Web service obtains information associated with the argument and uses the information to generate the output.
27. The one or more non-transitory machine-readable storage media of claim 21, further comprising sending the output to a device or system other than the device on which the computer program is executing.
28. The one or more non-transitory machine-readable storage media of claim 21, wherein the computer program communicates with the one or more servers over a communication path that is at least partially wireless.
29. The one or more non-transitory machine-readable storage media of claim 21, wherein the call comprises instructions to access a functionality of the Web service.
30. One or more servers comprising:
memory to store instructions that are executable; and
one or more processing devices to execute the instructions to perform operations comprising:
receiving, from a device of a client, a call to a Web service run on the one or more servers, the Web service corresponding to a script that was uploaded to the one or more servers by the client to define the Web service, the script comprising a client-modified script that exists in different versions, including a previous version, that are accessible by the client;
authenticating the call to an account;
identifying the script corresponding to the Web service;
executing code corresponding to the script, the code producing an output, the code defining a context among multiple contexts in which the script should run, the multiple contexts comprising a user context and a system context, in the user context the script running with permissions or privileges defined for a specified user, in the system context the script running with privileges and permissions for access to administrative functionality and database objects, the Web service handling switching contexts after the script runs; and
sending the output to the device.
31. The one or more servers of claim 30, wherein the code comprises a compiled version of the script, and wherein the script comprises JAVA or Groovy.
32. The one or more servers of claim 30, wherein the script has a security context, the security context comprising a JAVA classloader that restricts the script to using an approved set of classes and interfaces.
33. The one or more servers of claim 32, wherein authenticating the call comprises authenticating a user who owns the account; and
wherein the security context is modifiable.
34. The one or more servers of claim 30, wherein the operations comprise:
receiving a username and password for an authenticated user; and
returning a session identifier (session ID) token in response to the receiving;
wherein the session ID token is passed with each Web service operation.
35. One or more servers comprising:
memory to store instructions that are executable; and
one or more processing devices to execute the instructions to perform operations comprising:
configuring the one or more servers to enable script for a Web service to be defined dynamically, the Web service comprising an application program interface (API) for enabling access by, and interaction with, a computer program executing on a device other than the one or more servers;
receiving, from a device of a client, script to define the Web service, the script comprising a client-modified script that exists in different versions, including a previous version, that are accessible by the client;
compiling the script to produce machine-executable code for the Web service, the machine-executable code defining a context among multiple contexts in which the script should run, the multiple contexts comprising a user context and a system context, in the user context the script running with permissions or privileges defined for a specified user, in the system context the script running with privileges and permissions for access to administrative functionality and database objects, the Web service handling switching contexts after the machine-executable code for the script runs;
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 computer program.
36. The one or more servers of claim 35, wherein configuring the one or more servers to enable script for the Web service to be defined dynamically comprises storing, in the one or more servers, code to generate a graphical user interface (GUI) into which the script is entered; and
wherein the method further comprises:
receiving a request for the GUI;
outputting the GUI in response to the request; and
receiving the script via the GUI.
37. The one or more servers of claim 35, wherein configuring the one or more servers to enable script for the Web service to be defined dynamically comprises:
storing, in the one or more servers, a compiler for compiling the script; and
storing, in the one or more servers, a database to store information corresponding to the machine-executable code.
38. The one or more servers of claim 35, wherein configuring the one or more servers to enable script for the Web service to be defined dynamically comprises storing, in the one or more servers, machine-executable code that, when executed, enables receipt of the script.
39. The one or more servers of claim 35, wherein the call comprises a HyperText Transfer Protocol (HTTP) command, the HTTP command identifying the script in accordance with a convention defined by a proprietor of the script.
40. The one or more servers of claim 35, wherein the computer program passes an argument with the call, the argument being associated with an aspect of an entity being monitored; and
wherein the machine-executable code for the Web service obtains information associated with the argument and uses the information to generate the output.
41. The one or more servers of claim 35, further comprising sending the output to a device or system other than the device on which the computer program is executing.
42. The one or more servers of claim 35, wherein the computer program communicates with the one or more servers over a communication path that is at least partially wireless.
43. The one or more servers of claim 35, wherein the call comprises instructions to access a functionality of the Web service.
US12/952,890 2010-11-23 2010-11-23 Scripting web services Active 2032-01-18 US8689181B2 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US12/952,890 US8689181B2 (en) 2010-11-23 2010-11-23 Scripting web services
US14/170,082 US9172745B2 (en) 2010-11-23 2014-01-31 Scripting web services
US14/921,182 US9712644B2 (en) 2010-11-23 2015-10-23 Scripting web services
US15/649,758 US10574790B2 (en) 2010-11-23 2017-07-14 Scripting web services

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US12/952,890 US8689181B2 (en) 2010-11-23 2010-11-23 Scripting web services

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/170,082 Continuation US9172745B2 (en) 2010-11-23 2014-01-31 Scripting web services

Publications (2)

Publication Number Publication Date
US20120131473A1 US20120131473A1 (en) 2012-05-24
US8689181B2 true US8689181B2 (en) 2014-04-01

Family

ID=46065583

Family Applications (4)

Application Number Title Priority Date Filing Date
US12/952,890 Active 2032-01-18 US8689181B2 (en) 2010-11-23 2010-11-23 Scripting web services
US14/170,082 Active US9172745B2 (en) 2010-11-23 2014-01-31 Scripting web services
US14/921,182 Active US9712644B2 (en) 2010-11-23 2015-10-23 Scripting web services
US15/649,758 Active 2031-06-06 US10574790B2 (en) 2010-11-23 2017-07-14 Scripting web services

Family Applications After (3)

Application Number Title Priority Date Filing Date
US14/170,082 Active US9172745B2 (en) 2010-11-23 2014-01-31 Scripting web services
US14/921,182 Active US9712644B2 (en) 2010-11-23 2015-10-23 Scripting web services
US15/649,758 Active 2031-06-06 US10574790B2 (en) 2010-11-23 2017-07-14 Scripting web services

Country Status (1)

Country Link
US (4) US8689181B2 (en)

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9098312B2 (en) 2011-11-16 2015-08-04 Ptc Inc. Methods for dynamically generating an application interface for a modeled entity and devices thereof
US20150244811A1 (en) * 2012-09-17 2015-08-27 Tencent Technology (Shenzhen) Company Limited Method, device and system for logging in unix-like virtual container
US9158532B2 (en) 2013-03-15 2015-10-13 Ptc Inc. Methods for managing applications using semantic modeling and tagging and devices thereof
US9348943B2 (en) 2011-11-16 2016-05-24 Ptc Inc. Method for analyzing time series activity streams and devices thereof
US9350812B2 (en) 2014-03-21 2016-05-24 Ptc Inc. System and method of message routing using name-based identifier in a distributed computing environment
US9350791B2 (en) 2014-03-21 2016-05-24 Ptc Inc. System and method of injecting states into message routing in a distributed computing environment
US9401908B1 (en) * 2015-01-22 2016-07-26 Oracle International Corporation Authentication interworking in communications networks
US9462085B2 (en) 2014-03-21 2016-10-04 Ptc Inc. Chunk-based communication of binary dynamic rest messages
US9467533B2 (en) 2014-03-21 2016-10-11 Ptc Inc. System and method for developing real-time web-service objects
US9560170B2 (en) 2014-03-21 2017-01-31 Ptc Inc. System and method of abstracting communication protocol using self-describing messages
US9576046B2 (en) 2011-11-16 2017-02-21 Ptc Inc. Methods for integrating semantic search, query, and analysis across heterogeneous data types and devices thereof
US9712644B2 (en) 2010-11-23 2017-07-18 Ptc Inc. Scripting web services
US9762637B2 (en) 2014-03-21 2017-09-12 Ptc Inc. System and method of using binary dynamic rest messages
US9961058B2 (en) 2014-03-21 2018-05-01 Ptc Inc. System and method of message routing via connection servers in a distributed computing environment
US10025942B2 (en) 2014-03-21 2018-07-17 Ptc Inc. System and method of establishing permission for multi-tenancy storage using organization matrices
US10237372B2 (en) * 2017-05-01 2019-03-19 Adtran, Inc. Scalable programming architecture for telecommunications devices
US10305734B2 (en) 2016-04-07 2019-05-28 General Electric Company Method, system, and program storage device for customization of services in an industrial internet of things
US10313410B2 (en) 2014-03-21 2019-06-04 Ptc Inc. Systems and methods using binary dynamic rest messages
US10338896B2 (en) 2014-03-21 2019-07-02 Ptc Inc. Systems and methods for developing and using real-time data applications
US11474845B2 (en) * 2020-09-09 2022-10-18 Servicenow, Inc. System and method for versioned script management
US20220413977A1 (en) * 2021-06-25 2022-12-29 Palantir Technologies Inc. Systems and methods for monitoring software services

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130103744A1 (en) * 2011-10-24 2013-04-25 Electronics And Telecommunications Research Institute Method and apparatus for executing web service program based on javascript
US8671417B2 (en) 2011-12-12 2014-03-11 Microsoft Corporation Lightweight framework for web applications
GB2509723A (en) 2013-01-10 2014-07-16 Ibm Invoking web services that are determined at the time of execution
CN104348803B (en) * 2013-07-31 2018-12-11 深圳市腾讯计算机系统有限公司 Link kidnaps detection method, device, user equipment, Analysis server and system
US9910660B2 (en) * 2013-08-05 2018-03-06 Harman International Industries, Incorporated Operating system replacement for in-vehicle computing system
US9697108B2 (en) * 2013-08-12 2017-07-04 International Business Machines Corporation System, method, and apparatus for automatic recording and replaying of application executions
US10771366B2 (en) * 2013-09-04 2020-09-08 Unisys Corporation Data rate monitoring to determine channel failure
CN105094786B (en) * 2014-05-21 2019-05-28 广州市动景计算机科技有限公司 Method and system based on JavaScript customized web page
DE102014114585A1 (en) 2014-10-08 2016-04-14 Océ Printing Systems GmbH & Co. KG Method for operating a control panel for a production system and control system for a production system
DE102014114584A1 (en) 2014-10-08 2016-04-14 Océ Printing Systems GmbH & Co. KG Method for operating a control panel for a production system and control system for a production system
DE102014114586B4 (en) 2014-10-08 2020-08-20 Canon Production Printing Germany Gmbh & Co. Kg Method for operating a control panel for a production system and control device for a production system
US10282267B2 (en) * 2016-06-23 2019-05-07 Hewlett Packard Enterprise Development Lp Monitor peripheral device based on imported data
US10650621B1 (en) 2016-09-13 2020-05-12 Iocurrents, Inc. Interfacing with a vehicular controller area network
JP7197574B2 (en) * 2017-10-17 2022-12-27 テレフオンアクチーボラゲット エルエム エリクソン(パブル) Service registration in communication networks
CN107832161A (en) * 2017-11-06 2018-03-23 东软集团股份有限公司 Service calling method and device, storage medium, electronic equipment
US10657317B2 (en) 2018-02-27 2020-05-19 Elasticsearch B.V. Data visualization using client-server independent expressions
US11586695B2 (en) * 2018-02-27 2023-02-21 Elasticsearch B.V. Iterating between a graphical user interface and plain-text code for data visualization
US10931675B2 (en) * 2018-04-10 2021-02-23 Microsoft Technology Licensing, Llc Local API access authorization
US10997196B2 (en) 2018-10-30 2021-05-04 Elasticsearch B.V. Systems and methods for reducing data storage overhead
US11301221B2 (en) * 2019-12-13 2022-04-12 Sap Se Rapid code compiling system
CN113590187B (en) * 2021-07-13 2023-11-17 青岛海尔科技有限公司 Method and device for acquiring codes and electronic equipment
US11436362B1 (en) * 2021-10-29 2022-09-06 Snowflake Inc. Native applications using database roles

Citations (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6154751A (en) * 1998-05-14 2000-11-28 International Business Machines Corporation Method for executing a user-requested CGI program in a new authentication context while protecting operation of a default web server program
US20030023957A1 (en) 2001-07-02 2003-01-30 David Bau Annotation based development platform for stateful web services
US6631512B1 (en) * 1999-01-15 2003-10-07 Gillis E Onyeabor Method and system for database-driven, scalable web page development, deployment-download, and execution
US20050086297A1 (en) 2003-10-16 2005-04-21 Grand Central Communications, Inc. Managing virtual business instances within a computer network
US6968539B1 (en) * 1999-09-30 2005-11-22 International Business Machines Corporation Methods and apparatus for a web application processing system
US7117239B1 (en) 2000-07-28 2006-10-03 Axeda Corporation Reporting the state of an apparatus to a remote computer
US20070016949A1 (en) * 2005-07-15 2007-01-18 Microsoft Corporation Browser Protection Module
US7178149B2 (en) 2002-04-17 2007-02-13 Axeda Corporation XML scripting of soap commands
US7185014B1 (en) 2000-09-22 2007-02-27 Axeda Corporation Retrieving data from a server
US20070136579A1 (en) * 2005-12-09 2007-06-14 University Of Washington Web browser operating system
US20080301701A1 (en) * 2007-05-31 2008-12-04 Microsoft Corporation Detecting and modifying security settings for deploying web applications
US20090031006A1 (en) * 2000-06-07 2009-01-29 Johnson William J System and method for alerting a first mobile data processing system nearby a second mobile data processing system
US20090300596A1 (en) * 2008-05-29 2009-12-03 Research In Motion Limited Method and system for performing a software upgrade on an electronic device connected to a computer
US7636852B1 (en) * 2004-10-07 2009-12-22 Sprint Communications Company L.P. Call center dashboard
US20110035486A1 (en) * 2008-11-02 2011-02-10 Observepoint, Inc. Monitoring the health of web page analytics code
US20110055912A1 (en) * 2009-08-25 2011-03-03 Sentillion, Inc. Methods and apparatus for enabling context sharing
US20110167156A1 (en) * 2008-10-03 2011-07-07 Computer Associates Think, Inc. Monitoring related content requests
US20110214182A1 (en) * 2010-02-26 2011-09-01 Mykonos Software, Inc. Methods for proactively securing a web application and apparatuses thereof
US20110239270A1 (en) * 2010-03-26 2011-09-29 Nokia Corporation Method and apparatus for providing heterogeneous security management
US20110283363A1 (en) * 2009-01-19 2011-11-17 Koninklijke Philips Electronics N.V. Browser with dual scripting engine for privacy protection
US20120016983A1 (en) * 2006-05-11 2012-01-19 Computer Associated Think, Inc. Synthetic Transactions To Test Blindness In A Network System
US8108543B2 (en) 2000-09-22 2012-01-31 Axeda Corporation Retrieving data from a server
US20120041752A1 (en) * 2010-04-12 2012-02-16 Yong-Gang Wang Extension framework for input method editor
US20120089570A1 (en) * 2009-10-21 2012-04-12 Delphix Corp. Virtual Database System
WO2012071037A2 (en) 2010-11-23 2012-05-31 Biron Joseph L Scripting web services
US8406119B2 (en) 2001-12-20 2013-03-26 Axeda Acquisition Corporation Adaptive device-initiated polling

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5867647A (en) * 1996-02-09 1999-02-02 Secure Computing Corporation System and method for securing compiled program code
US6816880B1 (en) * 1997-03-26 2004-11-09 Concerto Software, Inc. Browser user inter face for client workstation
US6571290B2 (en) * 1997-06-19 2003-05-27 Mymail, Inc. Method and apparatus for providing fungible intercourse over a network
US6704873B1 (en) * 1999-07-30 2004-03-09 Accenture Llp Secure gateway interconnection in an e-commerce based environment
US7162649B1 (en) * 2000-06-30 2007-01-09 Internet Security Systems, Inc. Method and apparatus for network assessment and authentication
US20020156870A1 (en) * 2000-11-08 2002-10-24 Equate Systems, Inc. Method and apparatus for dynamically directing an application to a pre-defined target multimedia resource
US7483915B2 (en) * 2003-08-21 2009-01-27 Microsoft Corporation Systems and method for representing relationships between units of information manageable by a hardware/software interface system
US7349913B2 (en) * 2003-08-21 2008-03-25 Microsoft Corporation Storage platform for organizing, searching, and sharing data
US7668939B2 (en) * 2003-12-19 2010-02-23 Microsoft Corporation Routing of resource information in a network
US9202084B2 (en) * 2006-02-01 2015-12-01 Newsilike Media Group, Inc. Security facility for maintaining health care data pools
US7949529B2 (en) * 2005-08-29 2011-05-24 Voicebox Technologies, Inc. Mobile systems and methods of supporting natural language human-machine interactions
US20130191323A1 (en) * 2005-10-26 2013-07-25 Cortica, Ltd. System and method for identifying the context of multimedia content elements displayed in a web-page
US20070162456A1 (en) * 2005-12-30 2007-07-12 Shai Agassi Method and system for providing context based content for computer applications
US8291377B2 (en) * 2006-01-25 2012-10-16 Microsoft Corporation External configuration of processing content for script
WO2008010875A2 (en) * 2006-07-17 2008-01-24 Wayv Corporation Systems, methods, and computer program products for the creation, monetization, distribution, and consumption of metacontent
US8484718B2 (en) * 2006-08-03 2013-07-09 Citrix System, Inc. Systems and methods for enabling assured records using fine grained auditing of virtual private network traffic
US8413229B2 (en) * 2006-08-21 2013-04-02 Citrix Systems, Inc. Method and appliance for authenticating, by an appliance, a client to access a virtual private network connection, based on an attribute of a client-side certificate
US8655939B2 (en) * 2007-01-05 2014-02-18 Digital Doors, Inc. Electromagnetic pulse (EMP) hardened information infrastructure with extractor, cloud dispersal, secure storage, content analysis and classification and method therefor
US8677141B2 (en) * 2007-11-23 2014-03-18 Microsoft Corporation Enhanced security and performance of web applications
US8578487B2 (en) * 2010-11-04 2013-11-05 Cylance Inc. System and method for internet security
US8689181B2 (en) 2010-11-23 2014-04-01 Axeda Corporation Scripting web services
US9430291B2 (en) * 2010-12-30 2016-08-30 International Business Machines Corporation Distributed topology enabler for identity manager
US8713679B2 (en) * 2011-02-18 2014-04-29 Microsoft Corporation Detection of code-based malware
US8973136B2 (en) * 2011-08-02 2015-03-03 Quick Heal Technologies Private Limited System and method for protecting computer systems from malware attacks
US8739280B2 (en) * 2011-09-29 2014-05-27 Hewlett-Packard Development Company, L.P. Context-sensitive taint analysis
US9003381B2 (en) * 2012-08-14 2015-04-07 Derek J. Conrod Context-specific optimized code
US9100387B2 (en) * 2013-01-24 2015-08-04 Oracle International Corporation State driven orchestration of authentication components in an access manager
US9438625B1 (en) * 2014-09-09 2016-09-06 Shape Security, Inc. Mitigating scripted attacks using dynamic polymorphism
US10193894B2 (en) * 2017-02-15 2019-01-29 At&T Intellectual Property I, L.P. Enabling access to restricted data using geofences

Patent Citations (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6154751A (en) * 1998-05-14 2000-11-28 International Business Machines Corporation Method for executing a user-requested CGI program in a new authentication context while protecting operation of a default web server program
US6631512B1 (en) * 1999-01-15 2003-10-07 Gillis E Onyeabor Method and system for database-driven, scalable web page development, deployment-download, and execution
US6968539B1 (en) * 1999-09-30 2005-11-22 International Business Machines Corporation Methods and apparatus for a web application processing system
US20090031006A1 (en) * 2000-06-07 2009-01-29 Johnson William J System and method for alerting a first mobile data processing system nearby a second mobile data processing system
US20100131584A1 (en) * 2000-06-07 2010-05-27 Johnson William J Mobile data processing system moving interest radius
US7117239B1 (en) 2000-07-28 2006-10-03 Axeda Corporation Reporting the state of an apparatus to a remote computer
US8108543B2 (en) 2000-09-22 2012-01-31 Axeda Corporation Retrieving data from a server
US7185014B1 (en) 2000-09-22 2007-02-27 Axeda Corporation Retrieving data from a server
US20030023957A1 (en) 2001-07-02 2003-01-30 David Bau Annotation based development platform for stateful web services
US8406119B2 (en) 2001-12-20 2013-03-26 Axeda Acquisition Corporation Adaptive device-initiated polling
US7178149B2 (en) 2002-04-17 2007-02-13 Axeda Corporation XML scripting of soap commands
US20050086297A1 (en) 2003-10-16 2005-04-21 Grand Central Communications, Inc. Managing virtual business instances within a computer network
US7636852B1 (en) * 2004-10-07 2009-12-22 Sprint Communications Company L.P. Call center dashboard
US20070016949A1 (en) * 2005-07-15 2007-01-18 Microsoft Corporation Browser Protection Module
US7836303B2 (en) * 2005-12-09 2010-11-16 University Of Washington Web browser operating system
US20070136579A1 (en) * 2005-12-09 2007-06-14 University Of Washington Web browser operating system
US20120016983A1 (en) * 2006-05-11 2012-01-19 Computer Associated Think, Inc. Synthetic Transactions To Test Blindness In A Network System
US20080301701A1 (en) * 2007-05-31 2008-12-04 Microsoft Corporation Detecting and modifying security settings for deploying web applications
US20090300596A1 (en) * 2008-05-29 2009-12-03 Research In Motion Limited Method and system for performing a software upgrade on an electronic device connected to a computer
US20110167156A1 (en) * 2008-10-03 2011-07-07 Computer Associates Think, Inc. Monitoring related content requests
US20110035486A1 (en) * 2008-11-02 2011-02-10 Observepoint, Inc. Monitoring the health of web page analytics code
US20110283363A1 (en) * 2009-01-19 2011-11-17 Koninklijke Philips Electronics N.V. Browser with dual scripting engine for privacy protection
US20110055912A1 (en) * 2009-08-25 2011-03-03 Sentillion, Inc. Methods and apparatus for enabling context sharing
US20120089570A1 (en) * 2009-10-21 2012-04-12 Delphix Corp. Virtual Database System
US20110214182A1 (en) * 2010-02-26 2011-09-01 Mykonos Software, Inc. Methods for proactively securing a web application and apparatuses thereof
US20110239270A1 (en) * 2010-03-26 2011-09-29 Nokia Corporation Method and apparatus for providing heterogeneous security management
US20120041752A1 (en) * 2010-04-12 2012-02-16 Yong-Gang Wang Extension framework for input method editor
WO2012071037A2 (en) 2010-11-23 2012-05-31 Biron Joseph L Scripting web services

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
Cho et al., "JWS: A Flexible Web Service," Department of Computer Science, University of Auckland, Jan. 25, 2008, XP002680608, Retrieved from the Internet: URL: http://129.96.12.107/confpapers/CRPITV-74Cho.pdf [retrieved on Jul. 23, 2012] the whole document.
Cho et al., "JWS: A Flexible Web Service," Department of Computer Science, University of Auckland, Jan. 25, 2008, XP002680608, Retrieved from the Internet: URL: http://129.96.12.107/confpapers/CRPITV—74Cho.pdf [retrieved on Jul. 23, 2012] the whole document.
International Preliminary Report on Patentability issued in correspondence PCT Application No. PCT/US2010/057874 mailed Jun. 6, 2013 (7 pages).
International Search Report and Written Opinion issue Aug. 2, 2012 in international application No. PCT/US2010/057874, 10 pgs.

Cited By (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10574790B2 (en) 2010-11-23 2020-02-25 Ptc Inc. Scripting web services
US9712644B2 (en) 2010-11-23 2017-07-18 Ptc Inc. Scripting web services
US9576046B2 (en) 2011-11-16 2017-02-21 Ptc Inc. Methods for integrating semantic search, query, and analysis across heterogeneous data types and devices thereof
US9348943B2 (en) 2011-11-16 2016-05-24 Ptc Inc. Method for analyzing time series activity streams and devices thereof
US9098312B2 (en) 2011-11-16 2015-08-04 Ptc Inc. Methods for dynamically generating an application interface for a modeled entity and devices thereof
US10025880B2 (en) 2011-11-16 2018-07-17 Ptc Inc. Methods for integrating semantic search, query, and analysis and devices thereof
US9965527B2 (en) 2011-11-16 2018-05-08 Ptc Inc. Method for analyzing time series activity streams and devices thereof
US9578082B2 (en) 2011-11-16 2017-02-21 Ptc Inc. Methods for dynamically generating an application interface for a modeled entity and devices thereof
US20150244811A1 (en) * 2012-09-17 2015-08-27 Tencent Technology (Shenzhen) Company Limited Method, device and system for logging in unix-like virtual container
US9609063B2 (en) * 2012-09-17 2017-03-28 Tencent Technology (Shenzhen) Company Limited Method, device and system for logging in Unix-like virtual container
US9158532B2 (en) 2013-03-15 2015-10-13 Ptc Inc. Methods for managing applications using semantic modeling and tagging and devices thereof
US10025942B2 (en) 2014-03-21 2018-07-17 Ptc Inc. System and method of establishing permission for multi-tenancy storage using organization matrices
US9350791B2 (en) 2014-03-21 2016-05-24 Ptc Inc. System and method of injecting states into message routing in a distributed computing environment
US9467533B2 (en) 2014-03-21 2016-10-11 Ptc Inc. System and method for developing real-time web-service objects
US9762637B2 (en) 2014-03-21 2017-09-12 Ptc Inc. System and method of using binary dynamic rest messages
US9961058B2 (en) 2014-03-21 2018-05-01 Ptc Inc. System and method of message routing via connection servers in a distributed computing environment
US9462085B2 (en) 2014-03-21 2016-10-04 Ptc Inc. Chunk-based communication of binary dynamic rest messages
US9350812B2 (en) 2014-03-21 2016-05-24 Ptc Inc. System and method of message routing using name-based identifier in a distributed computing environment
US9560170B2 (en) 2014-03-21 2017-01-31 Ptc Inc. System and method of abstracting communication protocol using self-describing messages
US10432712B2 (en) 2014-03-21 2019-10-01 Ptc Inc. System and method of injecting states into message routing in a distributed computing environment
US10338896B2 (en) 2014-03-21 2019-07-02 Ptc Inc. Systems and methods for developing and using real-time data applications
US10313410B2 (en) 2014-03-21 2019-06-04 Ptc Inc. Systems and methods using binary dynamic rest messages
US9401908B1 (en) * 2015-01-22 2016-07-26 Oracle International Corporation Authentication interworking in communications networks
US10305734B2 (en) 2016-04-07 2019-05-28 General Electric Company Method, system, and program storage device for customization of services in an industrial internet of things
US10237372B2 (en) * 2017-05-01 2019-03-19 Adtran, Inc. Scalable programming architecture for telecommunications devices
US11474845B2 (en) * 2020-09-09 2022-10-18 Servicenow, Inc. System and method for versioned script management
US20220413977A1 (en) * 2021-06-25 2022-12-29 Palantir Technologies Inc. Systems and methods for monitoring software services

Also Published As

Publication number Publication date
US10574790B2 (en) 2020-02-25
US20180007167A1 (en) 2018-01-04
US9172745B2 (en) 2015-10-27
US20140297725A1 (en) 2014-10-02
US20120131473A1 (en) 2012-05-24
US20160234338A1 (en) 2016-08-11
US9712644B2 (en) 2017-07-18

Similar Documents

Publication Publication Date Title
US10574790B2 (en) Scripting web services
US20210224122A1 (en) Techniques for utilizing directed acyclic graphs for deployment instructions
JP6574479B2 (en) Services in the reverse proxy server
JP6661620B2 (en) Efficient and intuitive data binding for mobile applications
US9866640B2 (en) Cookie based session management
US8799988B2 (en) Document communication runtime interfaces
KR102427276B1 (en) Pre-formed commands for mobile cloud service
US11281763B2 (en) Integrated development environment information sharing for authentication provisioning
US10496837B2 (en) Support sharing the same table for protected and non-protected data columns
US20170118268A1 (en) Self describing configuration
US10592684B2 (en) Automatic operation detection on protected field
US20130086630A1 (en) Dynamic identity switching
US10735375B2 (en) Web application security with service worker
EP3365831B1 (en) Automatic operation detection on protected field with support for federated search
US11055367B2 (en) Web application architecture for information management
JP2023511114A (en) Techniques for Utilizing Directed Acyclic Graphs for Deployment Instructions
US11120108B2 (en) Managing security artifacts for multilayered applications
US20210226929A1 (en) Techniques for transferring data across air gaps
WO2012071037A2 (en) Scripting web services
US20230359508A1 (en) Remote cloud function invocation service
Schmitz Design of a SaaS cloud platform for a medium-sized company with focus on multi-instance support
WO2023219773A1 (en) Remote cloud function invocation service
CN111181907A (en) Host side plug-in login method, device and equipment and storage medium
Arman RESTful Mobile Application for Android: Mobile Version of Inspectera Online
Cosmina et al. Spring Web Flow

Legal Events

Date Code Title Description
AS Assignment

Owner name: AXEDA CORPORATION, MASSACHUSETTS

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:SILICON VALLEY BANK;REEL/FRAME:028558/0744

Effective date: 20120713

AS Assignment

Owner name: AXEDA CORPORATION, MASSACHUSETTS

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MMV CAPITAL PARTNERS INC.;REEL/FRAME:028563/0446

Effective date: 20120713

AS Assignment

Owner name: COMERICA BANK, MICHIGAN

Free format text: SECURITY AGREEMENT;ASSIGNOR:AXEDA CORPORATION;REEL/FRAME:028629/0538

Effective date: 20120713

AS Assignment

Owner name: AXEDA CORPORATION, MASSACHUSETTS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BIRON, JOSEPH L., III;REEL/FRAME:029574/0012

Effective date: 20110222

STCF Information on status: patent grant

Free format text: PATENTED CASE

CC Certificate of correction
AS Assignment

Owner name: AXEDA CORPORATION, MASSACHUSETTS

Free format text: RELEASE OF SECURITY INTEREST;ASSIGNOR:COMERICA BANK;REEL/FRAME:033608/0704

Effective date: 20140822

AS Assignment

Owner name: PTC INC., MASSACHUSETTS

Free format text: MERGER;ASSIGNOR:AXEDA CORPORATION;REEL/FRAME:035719/0680

Effective date: 20150309

AS Assignment

Owner name: JPMORGAN CHASE BANK, N.A., AS ADMINISTRATIVE AGENT, ILLINOIS

Free format text: SECURITY INTEREST;ASSIGNOR:PTC INC.;REEL/FRAME:037046/0930

Effective date: 20151104

Owner name: JPMORGAN CHASE BANK, N.A., AS ADMINISTRATIVE AGENT

Free format text: SECURITY INTEREST;ASSIGNOR:PTC INC.;REEL/FRAME:037046/0930

Effective date: 20151104

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551)

Year of fee payment: 4

AS Assignment

Owner name: JPMORGAN CHASE BANK, N.A., AS ADMINISTRATIVE AGENT, ILLINOIS

Free format text: SECURITY INTEREST;ASSIGNOR:PTC INC.;REEL/FRAME:047480/0888

Effective date: 20180913

Owner name: JPMORGAN CHASE BANK, N.A., AS ADMINISTRATIVE AGENT

Free format text: SECURITY INTEREST;ASSIGNOR:PTC INC.;REEL/FRAME:047480/0888

Effective date: 20180913

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8