Patent Application
20100250653
The disclosures made herein relate generally to enabling cross-domain Internet communication, more particularly, to enabling cross-domain communication between Internet content and server APIs such as SCORM-complaint and AICC-compliant learning management systems.
Internet applications are typically served as a mix of HTML, JavaScript, CSS, Adobe Flash files, and other files and formats. A web browser takes these files, delivered by the server in response to an HTTP request (or similar protocol request), and executes them within the browser, thus delivering the server's content and functionality to the user. In the early days of the Internet, these files and other information were stored as static files on the server, and the server merely accessed and delivered the files to web browser clients upon request. More recently, it has become common for web servers to deliver both static files as well as files that were constructed by web server software on-the-fly, customized to the user's specific requirements or session state. Even so, all static files and application logic for serving a web browser's request typically resided on one server, or at least within a cluster of servers that were all working together to satisfy the requests sent to a given Internet domain (i.e., network domain). Internet domain refers to a realm of administrative autonomy, authority, or control in the Internet. Internet domains are identified by names in accordance with the Domain Name System (DNS), which is a hierarchical naming system for computers, services, or any resource connected to the Internet or certain private networks.
In current-day web applications, it is much more common that a given application will access content, data and functionality from multiple, distributed sources (i.e., hybrid applications). For example, a web application can allow users to post items that include videos hosted on other web domains, like YouTube, thus creating a compound page. Or, a financial news website might pull real-time financial data from another web application so that news articles that reference a company might be accompanied by a real-time stock quote for that company. As these kinds of hybrid applications became more popular, web application and information providers began to provide and support Application Programming Interfaces that make integration of web application services easier and faster. An application programming interface (API) is an interface implemented by a software program to enable interaction with other software. An API is an abstraction that defines and describes an interface for the interaction with a set of functions used by components of a software system. The software that provides the functions described by an API is said to be an implementation of the API. One result was the “mashup”, which is a web application that combines data and/or functionality from more than one source (e.g., more than one domain).
The creation of hybrid applications has become relatively common and straightforward for the typical scenario where the web application designer makes use of an API that allow a server-side application to pull content, data and functionality from other web domains, combine them with its own content, data and functionality, and then deliver the combined application and/or content to web clients. Simple embedding of discrete content and functionality such as, for example, images, videos or plug-in-enabled applications like Adobe Flash applications are simple, straightforward and common as well.
One specific type of hybrid application remains challenging. As web browser security models have matured, almost all of them have established and subsequently strengthened “same origin” security policies in response to cross-site scripting (XSS) attacks. These prohibitions prevent executable code (e.g., JavaScript) from injecting, controlling and/or accessing executable code originating from a different domain than the executable code itself. For a web application designer who completely controls the server environment, this restriction is rarely problematic because there is no same origin security policy with respect to server-side code, thereby allowing the server application to access third-party services at will and combine them in any way necessary to support application goals and requirements. However, the web application cannot typically construct a web application that will cause the user's browser to perform the act of contacting and communicating with executable code that the browser must access from a different domain. For the above referenced security reasons, browsers now enforce a strict separation between content provided by different domains (i.e., same origin security policy).
Same origin security policy can cause significant problems for at least two classes of online applications. The first one of these classes of online applications includes applications where a web application designer does not fully control the server-side environment. The second one of these classes of online applications includes applications where the application designer does not fully control the domain from which an application will be launched and/or served.
For such first class of online application, a web application designer sometimes does not fully control or otherwise have access to the server environment and, thus, may be restricted on the ability to connect to cross-domain services only on the server. An example of this is an application developer who creates a web application that will be deployed in a shared hosting environment. Such a developer may have limited rights or knowledge to use certain services of the server and may have little or no access to server-side programming services or ability. Such a developer would like to be able to write, for example, JavaScript that executes within the browser client that accesses the needed content or functionality, rather than writing and executing server-side code to accomplish the same goal. To this end, designers of APIs to service these types of applications have developed interesting and useful approaches for supporting this goal. One example of these approaches is JavaScript Object Notation (JSON), which is a lightweight data-interchange format. Another example of these approaches, which is implemented by Facebook and other heavily-used APIs, includes a mechanism involving hidden iFrames and uniform resource locator (URL) fragments to achieve cross-domain communication. Generally speaking, an iFrame refers to an HTML document embedded inside another HTML document on a website. It should be noted that browser plug-ins can and do implement certain mechanisms for achieving cross-domain communication. For example, Adobe Flash allows servers to allow cross-domain communication across Flash objects via a cross-domain policy file.
For such second class of online applications, the web application designer will have full access to the server environment, but the application must be launched from and integrate with a separate server-side environment on a different domain. An example of this is a web application that needs to launch within and integrate with an enterprise content management system of some kind. The application must launch from and communicate with the domain serving the content management system, but the web application designer actually controls the server environment of an entirely different domain. This type of situation is particularly common in the case of legacy architectures, specifications, protocols and applications that were originally designed in a manner where content and functionality of a web application were assumed to reside within a single server-side environment. Specific example of this second class of online applications includes Sharable Content Object Reference Model (SCORM) and Aviation Industry CBT (Computer-Based Training) Committee (AICC). SCORM refers to a collection of standards and specifications for web-based e-learning and defines communications between client side content and a host system called the run-time environment, which is often implemented by a learning management system (LMS). (AICC) refers to standards for web-based e-learning applications and is an international association of technology-based training professionals that develops training guidelines for the aviation industry. These standards expect that a single compressed archive of static files will be loaded into the SCORM-compliant or AICC-compliant LMS server, where the archive will be unpacked and served to web browsers upon request. SCORM-compliant and AICC-compliant web applications typically must communicate with the SCORM-compliant or AICC-compliant LMS server via a JavaScript object. If the web application is served from a different domain than the LMS, browser same-origin policies normally prevent such communication.
It is known that in the aforementioned types of server-side environments, and in SCORM and AICC environments in particular, several workarounds have been proposed and implemented for overcoming adverse issue resulting from same origin security policy. However, such workarounds exhibit drawbacks that limit their effectiveness and/or desirability. For example, some of these workarounds rely upon client browser configuration or exploitation of browser security holes that have since been rectified and some workarounds require LMS server configuration or participation in the communication scheme, which generally make such workarounds ineffective and/or undesirable. It is also recognized that various standards bodies such as, for example, the International Federation for Learning-Education-Training Systems Interoperability (LETSI)), which is primarily responsible for the SCORM standard, recognize the disadvantages of such workarounds and are, therefore, still in need of a preferred solution to the associated problems.
Embodiment of the present invention are configured for providing communication across domains (i.e., network domains) between web applications and server-side functionality, including server-side APIs. More specifically, embodiments of the present invention advantageously overcome one or more shortcomings associated with conventional approaches for resolving adverse issues related to same origin security policies as applied to cross-domain communication. To this end, embodiment of the present invention allow a web service provider to provide access to defined web services to application developers, and specifically to allow designers of SCORM-like and/or AICC-like standards compliant packages with the ability to allow their remote domain applications to access and communicate with LMS domain objects and services. Furthermore, embodiment of the present invention can also be applied to situations where a designer of web services wants to make desired remote-domain services available as if they were local to an environment of the application designer or end-user.
In one embodiment of the present invention, a method begins with at least one data processing device accessing, from memory coupled to said at least one data processing device, instructions causing said at least one data processing device to utilize programming interface functionality of a first domain for accessing a remote resource of a second domain different than the first domain. Thereafter, said at least one data processing device performs an operation for accessing, from said memory, instructions causing said at least one data processing device to provide the remote resource to a system having requested the remote resource. Causing said at least one data processing device to provide the remote resource includes causing said at least one data processing device to provide the remote resource through the first domain utilizing client-side services of said programming interface functionality.
In another embodiment of the present invention, a client-server system comprises at least one data processing device, instructions processable by said at least one data processing device, and an apparatus from which said instructions are accessible by said at least one data processing device. The instructions are configured for enabling said at least one data processing device to facilitate utilizing an application programming interface of a first domain for accessing an application of a second domain different than the first domain and to facilitate providing the application to a client system. Providing the application includes providing the application through the first domain utilizing client-side services of said programming interface functionality.
In another embodiment of the present invention, a computer-readable medium having tangibly embodied thereon and accessible therefrom a set of instructions interpretable by at least one data processing device. The set of instructions is configured for causing said at least one data processing device to carry out operations for utilizing an application programming interface of a first domain for accessing an application of a second domain different than the first domain and for providing the application to a client system. Providing the application includes providing the application through the first domain utilizing client-side services of said programming interface functionality.
These and other objects, embodiments, advantages and/or distinctions of the present invention will become readily apparent upon further review of the following specification, associated drawings and appended claims.
Embodiments of the present invention advantageously provide for cross-domain communication by APIs. Specifically, instead of launching API-domain services and web applications on separate domains (e.g., network domains) and requiring mechanisms to get around same-origin policy restrictions, embodiment of the present invention provide a mechanism whereby one or more API data structures (e.g., API objects) provide for execution of remote code (i.e., an application) within the API's domain (i.e., API remote code functionality). In other words, an API provider would give developers who want to integrate their code (e.g., remote resource such as an application) with the provider's API a mechanism to have the API locate the remote code and, once accessed, serve and execute that remote code (e.g., remote resources and/or assets thereof) from within the API's domain instead of within the domain of the remote code developer. That way, the remote code would have direct access to API capabilities without needing to rely on the cross-domain scripting techniques described above. In the case of a SCORM-complaint or AICC-compliant server, a properly configured generic content package can add this functionality to the LMS server without further LMS server-side coding or configuration. A package is defined herein to include a data structure including information therein accessible by a data processing device or process.
Cross-domain communication carried out in accordance with the present invention can be implemented through various approaches using, for example, browser plug-in technology that offers a method for cross-domain communication (e.g., Adobe Flash and its cross-domain policy file) or using standard browser technologies (e.g., JavaScript and URL manipulation). In one implementation of the present invention, an API domain provides server-side programming (e.g., an API data structure) that loads in remote resources (e.g., an application and/or information derived therefrom) dynamically and serves them to users along with its own local API capabilities. In this case, the remote code has direct access to the API object(s). Additional programming instructions alter links in the remote application so that the user is sent to the proper (API domain) location instead of to the remote application domain, and references to other application resources or functionality can be dynamically re-written to maintain proper application references and state. In another implementation of the present invention, the API domain can load the remote application into a window or frame that still loads directly from the remote domain, but that is supplemented by enabling technologies that support communication from the remote domain to the API domain in a way that mimics local access to the API object (i.e., a mirror object). This mirror object can be instrumented statically to provide API services and/or can be built dynamically via introspection of the remote API object. Such a mixture of both static and dynamic application is particularly useful to provide immediate initialization and baseline and/or bootstrap services to the remote application while the initialization and introspection process completes.
These implementations for carrying out cross-domain communication are particularly useful for providing online applications with functionality that supports communication with a SCORM-compliant or AICC-compliant LMS. Thus, in one embodiment of the present invention, such embodiment includes a SCORM-compliant package (e.g., software) or AICC-compliant package that contains a Flash application and, optionally, supporting Javascript code that launches from the LMS domain, establishes communication with the LMS API object, loads an external Flash application and facilitates communication between the external Flash application and the API object. In another embodiment of the present invention, such embodiment includes a SCORM-compliant or AICC-compliant package that contains a generic Javascript wrapper that works with supporting generic page on an external content server that creates a mirror object within the external content server that an API object can access directly. The mirror object can communicate with the API object via a mechanism such as disclosed above (e.g., JSON-P, URL manipulation of iFrames, or Adobe Flash objects with cross-domain policy support). The external content server can communicate directly with the mirror object as if the mirror (i.e., remote) object were local. Preferably, a utilized framework handles such communication(s) transparently. Furthermore, a domain that serves the API object and that loads and executes the remote application code must be mindful of the fact that the intent of doing so is to side-step the browser's same origin security policy. As such, embodiments of the present invention are preferably implemented with remote domain trust policies and/or sandboxing technique (e.g., a restricted environment in which certain functions are prohibited thereby providing limitations on what system resources an application can request or access).
Embodiments of the present invention can include a web server that serves resources from a domain that provides access to certain software services. Examples of such software services include but are not limited to calculation, database, or communication services. For illustration purposes, the domain from which the web server that serves resources will be referred to herein as “apidomain.com”. A remote application developer that desires to deploy a static or dynamic web browser application on a different domain, which will be referred to herein as “application.com” that will connect to and utilize the services provided by one or more objects from apidomain.com. It is assumed that the remote application developer desires or is required to implement the connection to apidomain.com without utilizing standard server-side techniques. Examples of reasons for which the remote application developer desires or is required to implement the connection to apidomain.com without utilizing standard server-side techniques include, but are note limited to, the remote application developer being unqualified to do so, application.com being hosted by another party who does not provide or authorize server-side capabilities, or it is otherwise inconvenient or ineffective to do so.
In a first embodiment of developing and deploying API remote code functionality in accordance with the present invention, as shown in
In a second embodiment of developing and deploying API remote code functionality in accordance with the present invention, as shown in
Presented now are several preferred embodiments of implementing API remote code functionality in accordance with development and deployment functionality disclosed herein. Such embodiments each provide a respective approach enable an API to provide for execution of remote code within the API's domain. In this manner, the remote code will have direct access to API capabilities without being adversely impacted by issues typically associated with cross-domain functionality.
Referring to
Referring to
Referring to
Referring to
Referring now to instructions processable by a data processing device, it will be understood from the disclosures made herein that methods, processes and/or operations adapted for carrying out API remote code functionality as disclosed herein are tangibly embodied by computer readable medium having instructions thereon that are configured for carrying out such functionality. In one specific embodiment, the instructions are tangibly embodied for carrying out the functionality disclosed in reference to preferred embodiments 1-4 disclosed above and/or
In the preceding detailed description, reference has been made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the present invention may be practiced. These embodiments, and certain variants thereof, have been described in sufficient detail to enable those skilled in the art to practice embodiments of the present invention. It is to be understood that other suitable embodiments may be utilized and that logical, mechanical, chemical and electrical changes may be made without departing from the spirit or scope of such inventive disclosures. To avoid unnecessary detail, the description omits certain information known to those skilled in the art. The preceding detailed description is, therefore, not intended to be limited to the specific forms set forth herein, but on the contrary, it is intended to cover such alternatives, modifications, and equivalents, as can be reasonably included within the spirit and scope of the appended claims.
This patent application claims priority from co-pending United States Provisional Patent Application having Ser. No. 61/206,352; filed 29 Jan. 2009; entitled “Application Programming Interface Software”, having a common applicant herewith and being incorporated herein in its entirety by reference.
| Number | Date | Country | |
|---|---|---|---|
| 61206352 | Jan 2009 | US |
