Methods and systems for delivering a Java application to a requestor device are described. A request for the Java application is received at a node between the requestor device and a source of the Java application. A request for the Java application is sent to the source. The Java application is received from the source at the Intermediate node, which transforms the Java application according to attributes of the requester device. The transformed Java application is then sent to the requestor device.
|
15. A computer-usable medium storing computer-readable program code embodied therein for causing a computer system to perform a method for delivering an application from a source to a receiver, said method comprising:
instructing said source to deliver to said computer system a platform-independent version of said application;
transforming said platform-independent version of application at said computer system to create a transformed version, wherein said transformation is performed according to at least one attribute of a communication channel to said receiver;
sending said transformed version to said receiver; and
placing information specific to said receiver and provided by said receiver into memory, wherein said information specific to said receiver is stored subsequent to said sending of said transformed version.
1. In a network device, a method of delivering an application to a requestor device, said method comprising:
sending a request identifying said application to a source of said application;
receiving information for a platform-independent version of said application from said source;
transforming said information for said platform-independent version of said application according to at least one attribute of a communication channel to said requestor device;
sending transformed information comprising a platform-dependent version of said application to said requestor device; and
storing information specific to said requestor device comprising said transformed information, wherein said information specific to said requestor device instead is stored on said network device, to said requestor subsequent to said sending of said transformed information.
8. A computer system comprising:
a communication link to an application source and a communication link to a client device;
a memory unit coupled to said communication links; and
a processor coupled to said memory unit, said processor for executing a method for delivering an application, said method comprising:
receiving a request for said application from said client device;
sending a request for a platform-independent version of said application to said application source;
receiving said platform-independent version of said application from said application source;
creating a transformed application from said platform-independent version of said application, wherein said creation of the transformed application transforms said platform-independent version of said application according to at least one attribute of a communication channel to said client device transformed;
sending said transformed application to said client device; and
storing information specific to said client device comprising said transformed application, wherein said information specific to said client device is stored on said computer system information is subsequent to said sending or said transformed application.
2. The method of
3. The method of
compiling said information for said platform independent version of said application into native instructions for said requestor device using an ahead-of-time compiler.
4. The method of
condensing said information for said platform dependent version of said application to reduce it in size.
5. The method of
verifying said information for said platform-independent version of said application using a verification program.
6. The method of
caching said transformed information for said platform-dependent version of said application.
7. The method of
9. The computer system of
10. The computer system of
compiling said platform-independent version of said application into native instructions for said client device using an ahead-of-time compiler.
11. The computer system of
condensing said transformed application to reduce it in size.
12. The computer system of
verifying said platform-independent version of said application using a verification program.
13. The computer system of
storing said transformed application; and
sending a stored transformed application to another client device that has said attributes in response to a request from said other client device for said application.
14. The computer system of
16. The computer-usable medium of
17. The computer-usable medium of
compiling said platform-independent version of said application into native instructions for said receiver using an ahead-of-time compiler.
18. The computer-usable medium of
condensing said transformed application to reduce it in size.
19. The computer-usable medium of
using a verification program to verify said transformed application.
20. The computer-usable medium of
placing said transformed application into memory.
21. The computer-usable medium of
|
Embodiments of the present invention relate to the delivery of Java applications over a network.
Computer system components continue to become smaller and less expensive, and as a result portable devices such as cell phones and personal digital assistants have become more powerful. As portable devices grow in capability, so too does the complexity of applications developed for use on such devices.
The Java programming language is a popular tool for writing these applications because it is platform-independent, an advantage considering the many different types of portable devices that are in use. However, platform-independent Java applications can be relatively large. Although current generation portable devices are more powerful than their predecessors, they still have their limitations. Hence, a platform-independent Java application can be relatively slow to run.
One way to make a platform-independent Java application smaller in size and quicker to run is to modify it into a version that is somewhat, if not entirely, device-specific. For example, a Java application can be made to run more efficiently on a particular brand of portable device by stripping out parts of the application not used by that brand of device.
There are technologies available to help developers of Java applications take a platform-independent application and make it more specific to a particular target device. However, the applications produced by these technologies are no longer platform-independent. Developers have to apply these technologies over and over to produce many different versions of the Java application in order to accommodate the wide variety of possible targets. In essence, the advantage of platform-independence is negated. Instead, application developers are faced with the burden of creating, providing and maintaining many different device-specific Java applications.
Consider the effort associated with updating a particular Java application, perhaps to incorporate a new feature or to correct a flaw. The developer has to either update many different device-specific versions, or generate anew many different device-specific versions once the platform-independent version has been updated.
In addition, new devices are continually being designed and brought to market. Again, the application developer is faced with the task of creating and maintaining another device-specific version each time a new type of device is introduced.
Therefore, a method and/or system that can facilitate the marriage of platform-independent Java applications and the variety of devices that implement such applications would be of value. A method and/or system that can accomplish this without overly burdening application developers or taxing the resources of portable devices would also be valuable. Embodiments of the present invention provide these advantages.
Embodiments of the present invention pertain to methods and systems for delivering a Java application to a requester device are described. A request for the Java application is received at a node between the requestor device and a source of the Java application. A request for the Java application is sent to the source. The Java application is received from the source at the intermediate node, which transforms the Java application according to attributes of the requestor device. The transformed Java application is then sent to the requester device.
The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention:
The drawings referred to in this description should not be understood as being drawn to scale except if specifically noted.
Reference will now be made in detail to various embodiments of the invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with these embodiments, it will be understood that they are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, in the following description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. In other instances, well-known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the present invention.
It is also appreciated that the elements illustrated in
The functionality of each of these elements is described by way of example in conjunction with
Referring first to
In one embodiment, intermediate node 120 is some type of proxy device, server (e.g., a Wireless Access Protocol server), gateway or the like. Requestor device 130 can be a computer system (such as a laptop, desktop or notebook), a hand-held device (such as a personal digital assistant), a cell phone, a set top box, a watch, or another type of device that, in general, provides the capability for users to execute a Java application. As mentioned above, there actually may be many requester devices with access to intermediate node 120. Such devices can also be referred to as client devices. In a heterogeneous network, each of these requestor devices can have different attributes or profiles. These attributes include, but are not, limited to, the display, power, communication and computational capabilities and characteristics of the various requester devices.
Communication can occur directly between elements, or indirectly through intermediary devices or nodes that are not shown. Also, communication can be wired or wireless, or a combination of wired and wireless. This communication can occur over the World Wide Web (or Internet), over an Intranet, over a service provider network, or by other means.
There can actually be many communication channels downstream of the intermediate node 120. In a heterogeneous network, each of these communication channels (exemplified by communication channel 125) can have different attributes. For example, one channel may be characterized as having a higher bandwidth (higher data transfer rate) than another channel.
By way of background, Java source code is compiled into a format that can be referred to as bytecode. The compiled Java code is run on a device using an interpreter commonly referred to as a Java Virtual Machine (JVM). The Java Archive (JAR) file format is useful for bundling multiple files into a single archive file. Typically, a JAR file will contain the class files and auxiliary resources associated with Java applets and applications.
In the present embodiment, Java application source 110 is a source of Java applications including applets and libraries, in the form of bytecode and perhaps embodied as JAR files. In particular, the Java applications at Java application source 110 can be platform-independent. That is, each application can be written so that it will run on different types of requestor or client devices (exemplified by requestor device 130). Thus, according to the embodiments of the present invention, the writer (or developer or vendor) of the Java application does not need to produce a different version for each of the various types of requestor devices, nor does the writer/developer/vendor have to modify a platform-independent Java application according to the requirements or attributes of the different types of requester devices. Developer of Java applications can instead produce and maintain a platform-independent version of each application.
In one embodiment, in response to the request from intermediate node 120, Java application source 110 sends information for the application of interest to intermediate node 120 (3). Alternatively, there can be instances in which intermediate node 120 prefetches the application information from Java application source 110.
The information received from Java application source 110 can include the bytecode application for the application in entirety, one or more applets, or one or more libraries. What is of significance is that the information received from Java application source 110 is platform-independent.
According to the various embodiments of the present invention, intermediate node 120 transforms the platform-independent Java application information received from application source 110 into information specific to the type of requester device (exemplified by requestor device 130). Intermediate node 120 can execute a JVM to interpret the application of interest. The bytecode can be condensed (reduced in size) using techniques known in the art. The bytecode can be converted from its platform-independent format into a format that is specific to the device that is requesting the Java application (e.g., specific to requester device 130). Techniques for accomplishing this are known in the art. Bytecode can also be converted into machine (assembly) language or into native language using a just-in-time (JIT) or ahead-of-time compiler known in the art.
Thus, a platform-independent Java application is transformed when requested. If a particular type of device does not request the application, then it is not necessary to transform the application. As new types of devices are introduced, versions for these new devices are produced if and when a new type of device requests the application. The transformation of the platform-independent version is performed by intermediate node 120, reducing the burden on application developers. In addition, the amount of effort is reduced overall because, in general, each device-specific version is produced only when requested. In other words, many different device-specific versions do not need to be produced anticipating their need; instead, a device-specific version is produced when the need is realized.
Also of significance, intermediate node 120 is a trusted device from the perspective of requester device 130. That is, there is a trusted relationship between intermediate node 120 and requestor device 130. For example, consider a scenario in which requester device 130 is a cell phone and intermediate node 120 is a Wireless Access Protocol (WAP) server. The cell phone service provider ensures that a trusted relationship exists between the cell phone and the WAP server.
A trusted relationship can also exist between Java application source 110 and intermediate node 120, although this may not be the case. As mentioned above, intermediate node 120 can execute a JVM for the different Java applications received from Java application source 110. The code produced by the JVM is safe for use on requestor device 130. Thus, if malicious code was received from Java application source 110, the JVM executed by intermediate node 120 would prevent the malicious code from reaching requestor device 130.
Once the Java application is transformed, intermediate node 120 sends the transformed Java application to requester device 130 (4). In one embodiment, the transformed Java application is cached at intermediate node 120. If another request for the Java application is received from a requester device that is the same or substantially the same as requester device 130, the cached (and transformed) Java application can be sent in lieu of retrieving and transforming the platform-independent version.
The requester device 130 can then execute the transformed version of the Java application. In essence, according to the various embodiments of the present invention, all or a portion of the Java technology is implemented at the intermediate node 120 instead of at requestor device 130. Thus, according to the embodiments of the present invention, the use of the Java bytecode on the requestor device is obviated because the Java application is compiled beforehand. In addition, it is not necessary for a JVM to be present on the requestor device, at least for those Java applications received from Java application source 110 via intermediate node 120.
Because the transformed version is specific to requester device 130, and because the application does not have to run using a JVM on requestor device 130, the application can run more efficiently and more quickly on the requestor device. In other words, some of the processing work has been performed by intermediate node 120, leaving less processing to requester device 130. Moreover, by virtue of its reduced (e.g., condensed) size, the application can be transferred more quickly over communication channel 125, and downloaded more quickly by requestor device 130. In sum, less of the resources available on requester device 130 are consumed, and the resources that are used are used more efficiently.
According to other embodiments of the present invention, additional services or functions can be performed by intermediate node 120. In one embodiment, intermediate node 120 utilizes a Java verification program to verify the Java application.
In another embodiment, intermediate node 120 can be used to supplement the memory capacity of requestor device 130. Because intermediate node 120 is a trusted node, information that would otherwise be stored on requestor device 130 can instead be stored at intermediate node 120. A memory management scheme can be implemented on requestor, device 130 so that the device knows where the information is stored. The information can later be accessed or retrieved regardless of the actual physical location of the requestor device 130. When information is to be retrieved from intermediate node 120, requestor device 130 can identify its location to intermediate node 120. In some implementations—for instance, when requester device 130 is a cell phone—the location of requester device 130 can automatically be made known to intermediate node 120.
In step 410 of
In step 420, information for the Java application is received from the source. The information can include, for example, the bytecode for the application, a JAR file, one or more applets, or one or more libraries.
In step 430, the information for the Java application is transformed according to attributes of the requester device. Techniques for recognizing the type of requester device and its attributes are known in the art. These attributes can include, for example, the display, power, communication and computational capabilities and characteristics of the requestor device. The transforming can include, for instance, compiling the information for the Java application into native instructions for the requestor device using an ahead-of-time Java compiler, or condensing the information for the Java application to reduce it in size. Optionally, the information for the Java application can be verified using a Java verification program.
The information for the Java application can also be transformed according to the attributes of the communication channel to the requestor device (e.g., communication channel 125 of
In step 440, the transformed information for the Java application is sent to the requestor device.
In step 450, in one embodiment, the transformed information for the Java application is cached at intermediate node 120 (
In summary, embodiments of the present invention provide methods and systems for delivering a Java application to a requestor device. These methods and systems facilitate the marriage of platform-independent Java applications and the variety of devices that implement such applications. These methods and systems accomplish this without overly burdening application developers or taxing the resources of portable devices.
Embodiments of the present invention are thus described. While the present invention has been described in particular embodiments, it should be appreciated that the present invention should not be construed as limited by such embodiments, but rather construed according to the following claims.
Krishnan, Venkatesh, Bedner, Ilja
Patent | Priority | Assignee | Title |
11194603, | Nov 16 2018 | Samsung Electronics Co., Ltd. | User equipment, server, control method of the user equipment and control method of the server for performing ahead-of-time (AOT) compilation of an application based on usage frequency |
7949998, | Apr 20 2007 | Microsoft Technology Licensing, LLC | Programming framework for closed systems |
8458676, | Jun 30 2009 | International Business Machines Corporation | Executing platform-independent code on multi-core heterogeneous processors |
8539464, | Oct 30 2008 | ServiceNow, Inc; International Business Machines Corporation | Distributed just-in-time compilation |
8966458, | Jun 30 2009 | International Business Machines Corporation | Processing code units on multi-core heterogeneous processors |
Patent | Priority | Assignee | Title |
5842017, | Jan 29 1996 | Hewlett Packard Enterprise Development LP | Method and apparatus for forming a translation unit |
6324685, | Mar 18 1998 | Implicit, LLC | Applet server that provides applets in various forms |
6477543, | Oct 23 1998 | Alibaba Group Holding Limited | Method, apparatus and program storage device for a client and adaptive synchronization and transformation server |
6959307, | Feb 26 1999 | International Business Machines Corporation | Process and system for a client object to perform a remote method invocation of a method in a server object |
6976248, | Mar 18 1998 | Implicit, LLC | Application server facilitating with client's computer for applets along with various formats |
7133894, | Mar 12 2002 | WRP IP MANAGEMENT, LLC | Method, apparatus, and program for synchronous remote builds |
20020131405, | |||
20020184618, | |||
20030056029, | |||
20040015852, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
May 07 2003 | BEDNER, ILJA | HEWLETT-PACKARD DEVELOPMENT COMPANY, L P | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 014056 | /0801 | |
May 13 2003 | KRISHNAN, VENKATESH | HEWLETT-PACKARD DEVELOPMENT COMPANY, L P | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 014056 | /0801 | |
May 16 2003 | Hewlett-Packard Development Company, L.P. | (assignment on the face of the patent) | / | |||
Oct 25 2011 | HEWLETT-PACKARD DEVELOPMENT COMPANY, L P | Google Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 027661 | /0258 | |
Oct 25 2011 | Hewlett-Packard Company | Google Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 027661 | /0258 | |
Sep 29 2017 | Google Inc | GOOGLE LLC | CHANGE OF NAME SEE DOCUMENT FOR DETAILS | 044101 | /0610 |
Date | Maintenance Fee Events |
Jan 03 2013 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Jan 16 2017 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Jan 14 2021 | M1553: Payment of Maintenance Fee, 12th Year, Large Entity. |
Date | Maintenance Schedule |
Jul 14 2012 | 4 years fee payment window open |
Jan 14 2013 | 6 months grace period start (w surcharge) |
Jul 14 2013 | patent expiry (for year 4) |
Jul 14 2015 | 2 years to revive unintentionally abandoned end. (for year 4) |
Jul 14 2016 | 8 years fee payment window open |
Jan 14 2017 | 6 months grace period start (w surcharge) |
Jul 14 2017 | patent expiry (for year 8) |
Jul 14 2019 | 2 years to revive unintentionally abandoned end. (for year 8) |
Jul 14 2020 | 12 years fee payment window open |
Jan 14 2021 | 6 months grace period start (w surcharge) |
Jul 14 2021 | patent expiry (for year 12) |
Jul 14 2023 | 2 years to revive unintentionally abandoned end. (for year 12) |