Abstract:
Application programs delivered from one or more cloud computing systems (“clouds” or “CCSs”) are integrated into a desktop being delivered/hosted by another cloud (“primary” CCS). In one respect, the integration includes integration of controls for directly launching a separately hosted application program from a desktop hosted by the primary CCS, such as by selection of a start menu entry or activation of a “shortcut” icon that points to the application program. In another respect, a separately hosted application program is launched based on a user opening or accessing content (e.g. data file) that is specifically associated with the separately hosted application program but residing more locally, such as in the hosted desktop. In this aspect, the content is seamlessly redirected to the other cloud without requiring any direct network connectivity between the clouds.

Description:
BACKGROUND 
       [0001]    The invention is related to the field of remotely hosted computing, commonly referred to in the information technology industry as “cloud computing”. 
       SUMMARY 
       [0002]    A primary cloud computing system (CCS) provides a cloud-hosted desktop, in some embodiments employing software known by the name Citrix XenApp™ or Citrix XenDesktop™ A cloud-hosted desktop typically includes off-the-shelf application programs like Microsoft Office®, Adobe Reader® etc. However, there may be other application programs that are not offered by the primary CCS. There may be a variety of reasons as follows: 
         [0003]    1. The application program may be a specialized line-of-business application program that a service provider operating the primary CCS doesn&#39;t want to provide (e.g., it may be very specialized and used by few customers). 
         [0004]    2. The customer wants to host the application program in their own datacenter for some reason, such as security/compliance. 
         [0005]    3. The application program is only available from a separate source, such as an organization that developed the application program and offers it as a service. In this case, the application may be delivered by a separate CCS (may be referred to as a secondary CCS). 
         [0006]    Thus in some situations, a desktop is being delivered from one cloud, and application programs are being delivered from other clouds (i.e., an in-premise cloud, or a cloud operated by an Internet service provider (ISV cloud). When the user is accessing the cloud-hosted desktop, the user needs a way to access such separately delivered (or “separately hosted”) application programs, preferably in a manner seamlessly integrated into the cloud-hosted desktop. This way the user can access a wider variety of computing resources from one hosted desktop provided by a primary CCS, even resources that are made available to the user by a different computing system such as a secondary CCS. The user is not burdened with maintaining and switching between different interfaces to different systems to access desired resources. 
         [0007]    In general, the present disclosure is directed to techniques for integrating application programs being delivered from one or more cloud computing systems (“clouds” or “CCSs”) into a desktop being delivered/hosted by another cloud. Two separate aspects are described. One is the integration of controls for directly launching a separately hosted application program from a desktop hosted by a primary CCS, such as by selection of an entry in a start menu or activation of a “shortcut” icon that points to the application program. Another aspect is the desire to indirectly launch such a separately hosted application program based on a user opening or accessing content (e.g. data file) that is specifically associated with the separately hosted application program but residing more locally, such as in the hosted desktop. In this aspect, the challenge includes seamlessly redirecting the content to the other cloud without requiring any direct network connectivity between the clouds. As an example, a user may receive a file as an attachment in an e-mail program running in the cloud-hosted desktop, while the application program needed to open the content is hosted in a separate cloud. This kind of task is enabled by the presently disclosed techniques. 
         [0008]    Generally, the disclosed techniques provide a way to integrate application programs from multiple clouds (public or private) without certain performance and other issues associated with known approaches and providing a seamless user experience. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0009]    The foregoing and other objects, features and advantages will be apparent from the following description of particular embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of various embodiments of the invention. 
           [0010]      FIG. 1  is a block diagram of a heterogeneous cloud computing system having separate cloud computing systems providing application services to a client computer; 
           [0011]      FIG. 2  is a block diagram showing more detail of components of the cloud computing system; 
           [0012]      FIGS. 3 and 4  are depictions of window-type graphical user interface displays; 
           [0013]      FIGS. 5-8  are flow diagrams depicting system functionality. 
       
    
    
     DETAILED DESCRIPTION 
       [0014]    The entire disclosure of U.S. Provisional Application 61/551,390 filed Oct. 25, 2011 is incorporated by reference herein. 
         [0015]      FIG. 1  shows a computing environment including a primary cloud computing system (primary CCS)  10  and a secondary cloud computing system (secondary CCS)  12 , along with a client computer (CLT)  14  operating in an organization computing system  16 . As shown, the primary CCS  10  has a functional connection  13  to the client computer  14  over which the primary CCS  10  provides computing services including a hosted desktop user interface (“hosted desktop”) and (optionally) one or more primary-hosted application programs (“apps”) to the client computer  14 . The secondary CCS  12  has a functional connection  15  to the client computer  14  over which it provides computing services including one or more secondary-hosted application programs to the client computer  14 . The application programs from the primary CCS  10  and secondary CCS  12  are provided as application services, meaning that they are executed at the respective system  10 ,  12  on behalf of and under control of the client computer  14 , typically including user input/output via one or more windows or similar user interfaces displayed at the client computer  14 . 
         [0016]    The primary CCS  10 , secondary CCS  12 , and organization computing system  14  are all generally realized as networked computer systems having computers and other hardware resources interconnected by computer network connections. In a typical case the computers include so-called “server” computers each having memory, computer program instruction processing circuitry, and input/output circuitry for interfacing the server computer to one or more networks, to local storage devices, and to other peripheral devices or systems. Other hardware resources can include network-attached storage systems and other specialized systems and components. The computers execute computer program instructions that cause the computers to perform methods or functions as generally known in the art. The description herein is primarily at a functional level, and it will be understood that the functions are realized by the computers and other hardware resources executing corresponding sets of computer instructions referred to as “programs”, “routines”, etc. as generally known. 
         [0017]    The organization computing system  16  may be organized in a conventional manner to include both user-associated “client” computers as well as sets of server computers, which may be physically located in one or more datacenters for example. The primary and secondary cloud computing systems  10 ,  12  are distinguished as such by virtue of their ability to provide computing services to external clients (such as client  14 ) without exposing underlying low-level details about the specific hardware or software structure and organization. A client  14  can be configured with minimal information to enable it to obtain a desired service from either the primary or secondary CCS  10 ,  12 , leaving the details of much of the underlying structure and functionality to software tailored for the purpose. As an example, from a user perspective a hosted desktop may be accessed by clicking on an icon, and it appears and functions in the same way as a local desktop presented by a user&#39;s personal computer (PC), for example. The user relies on hosting and virtualization software to provide the underlying functions and interactions that achieve this operation. 
         [0018]    The term “desktop” herein refers to functionality typically provided by a personal computer operating system such as Windows®, Unix® or Mac OS®, including a graphical user interface employing the “desktop” paradigm in which items (icons, windows) are arrayed on a background. Typically the desktop interface also includes system-level control regions such as task bars, docks, menu bars, etc., with these regions including user-activatable controls such as icons, menus, etc. A “hosted desktop” is a desktop provided to a client computer  14  by another computer, typically a server that is said to “host” the desktop. This can be seen as a type of virtual PC executing in the server computer and presenting its graphical user interface to a separate real PC or other client machine. Known software of this type is sold under the names XenApp™ and XenDesktop™ by Citrix Systems, Inc. 
         [0019]    The terms “primary” and “secondary” with respect to the CCSs  10 ,  12  are used as convenient labels for a specific purpose, which is to identify the primary CCS  10  as that which provides the hosted desktop to the client computer  14 . No other meanings are intended. This distinction is necessary for the description of the system and its functionality presented below. Additionally, while in the description below the secondary CCS  12  provides a “separately hosted” application program that is to be integrated into the hosted desktop, in general the separately hosted application program need not be provided by a separate CCS or even by a cloudlike system. For example, it may be provided by the organization computing system  16 , presumably in a server or other computer separate from the client computer  14 . 
         [0020]      FIG. 2  shows portions of the computing systems  10 ,  12  and  16  and their interconnection in pertinent detail. The primary CCS  10  includes a desktop hosting program shown as a hosted desktop  20 , and optionally one or more primary-hosted application programs (apps)  22 . Also included is a desktop delivery program  23  that “delivers” the functionality of the primary-hosted application program(s)  22  and hosted desktop  20  to the client computer  14  as though they were being executed locally by the client computer  14 . One example of a desktop delivery program  23  is software known as Citrix XenApp™. The primary CCS  10  has a hosted desktop interface  24  to the client computer  14  over which the hosted desktop functionality is provided. The primary CCS  10  also includes a launcher  26  that provides functions of starting execution of (“launching”) application programs. Both the hosted desktop  20  and launcher  26  are connected to a control channel  28  to which an agent  30  of the client computer  14  is also connected. The agent  30  also communicates with the desktop delivery program  23  and application delivery program  34  by other connections not shown in  FIG. 2 . 
         [0021]    The secondary CCS  12  includes one or more secondary-hosted application programs  32  and a hosted application delivery program  34  that delivers the functionality of the secondary-hosted application program(s)  32  to the client computer  14  as though they were being executed locally by the client computer  14 . One example of a hosted application delivery program  34  is the above-referenced Citrix XenApp™ software. A secondary-hosted application program  32  is also referred to as a “separately” hosted application program herein, referring to the fact that it is hosted outside the hosted desktop  20 . 
         [0022]    The client computer  14  includes hosted-desktop client software (Desktop Client)  36  connected to the application delivery program  34  of the secondary CCS  12  as well as to the hosted desktop  20  via the hosted desktop interface  24 . The desktop client  36  includes functionality referred to as “local access” that enables local client resources to be accessible in the hosted desktop  20 . In one embodiment this local access functionality may be in the form of so-called “reverse seamless” or “virtual desktop extender” software. The client computer  14  may also include locally installed applications (apps)  38 . The client computer also includes some form of storage for data referred to as “application program metadata” (App Prog M-D)  40  that contains information about application programs used by the client computer, as described in more detail below. The application program metadata  40  is accessible by the desktop client  36  as well as the agent  30 . 
         [0023]      FIGS. 3 and 4  depict computer screen displays for two distinct type of client computers  14 .  FIG. 3  is a display for a so-called “fat” or “thick” client, which is a client computer  14  having substantial computing resources (memory, processing capability, etc.) and typically a complex, robust operating system capable of supporting a variety of intensive computing tasks. A good example of a fat client computer  14  is a personal computer.  FIG. 4  is a display for a so-called “thin” client, which is a client computer  14  usually having more limited computing resources used primarily to provide a graphical user interface to access external computing resources (such as those of a separate server computer). The graphical user interface may be provided, for example, in the form of one or more browser-type windows that display hypertext pages served by external server computers. More detail is provided below. 
         [0024]    Referring to  FIG. 3 , the fat client computer  14  provides a user interface in the form of a local desktop  42  having a background and control areas as described above. In particular,  FIG. 3  shows a start menu  44  included in the local desktop  42 . The start menu  44  presents a listing of one or more application programs (shown as APP 1  and APP 2 ) that are installed on the client computer  14  (i.e., locally installed applications  38  of  FIG. 2 ) or otherwise executable by the client computer via the local desktop  42 . In the present context, the start menu  44  includes one or more entries for the secondary-hosted application program(s)  32  hosted by the secondary CCS  12 . This functionality of integrating application programs of the secondary CCS  12  into the local desktop  42  is provided in part by the application delivery program  34  in concert with the local desktop  42 . 
         [0025]    In the present description, the term “application program metadata” is used to refer to the name, appearance, location and other information about an application program. The entry for an application program in the start menu  44  forms part of the application program metadata for that application program. Also included is underlying information, normally not visible in the user interface, such as the path or location in the file system of the executable image of the application program. Application program metadata may also be included in items referred to as “shortcuts”, which include graphical icons that can be placed on the background of the local desktop  42 . An application program can be executed or “launched” by user selection of the application program name from the start menu  44  and/or user activation of a shortcut icon. It will be appreciated that the start menu  44   s  an example of an application-launching interface that is integral to the local desktop  42 . 
         [0026]    Returning to  FIG. 3 , also shown is a window (“hosted desktop”)  46  which is the local presentation of the hosted desktop  20  from the primary CCS  10 . Like the local desktop  42 , the hosted desktop  46  has a background and a control area, including its own start menu  48  which is an integral application-launching interface. The items in start menu  48  are those configured in the hosted desktop  20 , which may include for example entries for the primary-hosted application programs  22 . Examples of these items are shown as APP 3  and APP 4 . As shown, the start menu  48  also includes the same entries APP 1  and APP 2  that appear in the local desktop start menu  44 . Thus the user of the client computer  14  has the ability to work entirely within the environment of the hosted desktop  20  (via window  46 ) while also being able to access application programs that are provided from outside that environment. In particular, as described in more detail below, the user is able to access the secondary-hosted application program(s)  32  provided by the secondary CCS  12 . While in  FIG. 3  this functionality is shown vis-à-vis the start menus  44  and  48 , it may also be provided using shortcut icons on the respective desktops  42 ,  46  or more generally anywhere in an underlying directory or folder structure. Additionally, as described in more detail below, this functionality can be extended to enable a separately-hosted application program to be invoked by opening a data file for which an association with the separately-hosted application program has been established. 
         [0027]    Referring to  FIG. 4 , the thin client computer  14  provides a user interface in the form of a window or frame  50  of a browser or similar terminal-like user interface program, where “terminal-like” refers to a primary or exclusive capability for user interface functions (graphical display, user input etc.) on behalf of a separate computer that executes a virtualized computer instance and/or application programs. In particular,  FIG. 4  shows a pair of icons or other application-launching controls  52  included in the browser window  50 . In this case, the controls  52  are for one or more application programs (identified as A- 1  and A- 2 ) that are executable by a separate server on behalf of this thin client  14 . Similar to the fat client, the controls  52  include one or more controls for the secondary-hosted application program(s)  32  hosted by the secondary CCS  12 . The functionality of integrating application programs of the secondary CCS  12  into the browser  50  is provided in part by the application delivery program  34  in concert with browser  50 . 
         [0028]      FIG. 4  also shows a window (“hosted desktop”)  54  which is the local presentation of the hosted desktop  20  from the primary CCS  10 . The hosted desktop  54  has a background and a control area, including its own start menu  56 . The items in start menu  56  are those configured in the hosted desktop  20 , which may include for example entries for the primary-hosted application programs  22 . Examples of these items are shown as APP 3  and APP 4 . As shown, the start menu  56  also includes entries APP 1  and APP 2  which correspond to the controls  52  for A- 1  and A- 2  that appear in the browser window  50 . Thus the user of the client computer  14  has the ability to work entirely within the environment of the hosted desktop  20  (via window  54 ) while also being able to access application programs that are provided from outside that environment. In particular, as described in more detail below, the user is able to access the secondary-hosted application program(s)  32  provided by the secondary CCS  12 . Additionally, as described in more detail below, this functionality can be extended to enable a separately-hosted application program to be invoked by opening a data file for which an association with the separately-hosted application program has been established. 
         [0029]      FIG. 5  is a flow chart describing a first aspect of operation of the system of  FIGS. 1-2 , in particular for the case of a fat client as described with reference to  FIG. 3 . At  60 , the secondary CCS  12  is configured to deliver a secondary-hosted application program  32  to the client computer, meaning that the application program  32  is executed at the secondary CCS  12  on behalf of and under the control of the client computer  14 . As described above, this configuration includes use of the application delivery program  34 . 
         [0030]    For description purposes, an example will be referred to in which the secondary-hosted application program  32  is a specialized program such as AutoCad®, a well known design automation program. It is assumed that the user of the client computer  14  has need for the hosted desktop  20  from the primary CCS  10 , but also has need to run an application program such as AutoCad that is not available in the primary CCS  10 . As mentioned above, one major purpose of the presently disclosed technique is to enable such a user to work within his/her hosted desktop environment and still be able to access such separately-hosted application programs (i.e., those hosted or otherwise provided outside of the hosted desktop environment of the primary CCS  10 ). 
         [0031]    Referring again to  FIG. 5 , at  62  the agent  30  at the client computer  14  collects or “aggregates” information about application programs available to the client computer  14  and uses the information to populate the start menu  44  of the fat client. In one embodiment, the agent  30  may be realized using software known by the name Citrix Receiver™, which has a formal user interface and employs a user login to associate cloud computing resources with the user of the client computer  14 . In general, the agent  30  is in communication with some or all cloud computing systems used by the client computer  14  and can obtain information about the application programs that are hosted thereby. These include the delivery programs  23 ,  34  of the primary CCS  10  and secondary CCS  12  respectively. Aggregation of the application program information may be by a variety of methods including a web interface or installed services. The application information, which forms part of application program metadata as discussed above, is used to create entries for the Start Menu, shortcut icons, etc. in the user&#39;s local desktop  42 . It should be noted that the user&#39;s local desktop  42  will also include a control for launching the hosted desktop  20  at the primary CCS  10 . 
         [0032]    At  64  there is a startup phase of operation begun when the user launches the hosted desktop  20 . Once the hosted desktop  20  is launched, as part of the startup process, the hosted desktop  20  sends a message over the control channel  28  to fetch the application program metadata as aggregated by the agent  30 . Upon receiving the application program metadata, the hosted desktop  20  uses it to populate the hosted desktop window  46  with corresponding controls, such as entries in the hosted desktop start menu  48 , shortcuts, etc. These items may appear along with information identifying where the programs are hosted, e.g., “AutoCad on secondary CCS”, to help keep the user oriented. 
         [0033]    At  66  is a use phase, which may start when a user at the client computer  14  activates a control for the application program (such as selecting a start menu entry or clicking on a shortcut icon on the hosted desktop  20 ). When this occurs, the hosted desktop  20  invokes the launcher  26  with information (such as a path specification) for the separately hosted application program  32 , and the launcher  26  sends a command to the client computer  14  over the control channel  28  instructing the agent  30  to launch the application program from the client computer  14 . The agent  30  does so, in communication with both the desktop client  36  and the application delivery program  34  of the secondary CCS  12 . It should be noted that the application program may be delivered by the secondary CCS  12  in either a streamed or hosted manner. 
         [0034]    At  68 , the user interface functions of the application program are provided in the hosted desktop window  46 . For example, if the application program generates a window or accepts user input, the window will appear in the hosted desktop window  46  and input will be accepted from an input device (keyboard, mouse) when that window has the input device focus. This functionality is provided by the local access functionality of the desktop client  36  in conjunction with the hosted desktop  20 . 
         [0035]    Referring back to the aggregating of application programs at  62 , this activity may be performed on the basis of user-subscribed applications (potentially using a “self-service” plug-in module on the client computer  14  enabling a user to obtain application programs via an online service) or system-delivered applications (potentially using an administratively controlled application program delivery system). 
         [0036]      FIG. 6  is a flow chart describing the same aspect of operation as above for the case of a thin client such as described with reference to  FIG. 4 . In this case, the functions at  70 ,  74  and  76  are similar to their respective fat-client counterparts  60 ,  66  and  68  of  FIG. 5 . At  72  is the startup phase, which differs in a couple of respects from the combination of functions at  62  and  64  of  FIG. 5 . Specifically, at  72  the client computer  14  first initializes into its terminal-like interface represented by browser window  50 , for example ( FIG. 4 ). At this point the user may see a hypertext page provided by a web interface server, which may be a login page for example Once the user logs in, the user sees controls for application programs  32  and the hosted desktop  20  in the browser window  50 . The user then launches the hosted desktop  20 . As part of its startup process, the hosted desktop  20  sends one or more messages over the control channel  28  to cause the agent  30  to obtain and record the application metadata for the application programs available to the client computer  14 , including the secondary-hosted application program(s)  32 . In the case that a program such as Citrix Receiver is being used, the messages may include a command to launch a Receiver logon dialog on the thin client, where this logon dialog appears integrated in the hosted desktop window  46  using the local access functionality. After the logon is completed, Receiver enumerates the application programs available to the client computer  14  including the secondary-hosted application programs  32 . The application metadata for the enumerated application program is stored in a data file, such as an XML or similar hypertext file, in the file system of the client computer  14 . For application programs made available using a delivery service as described above, it may be necessary for Receiver to first authenticate itself to the delivery service in order to obtain information from the delivery service. 
         [0037]    Continuing with the functions at  72 , after a pre-set waiting period (e.g., 1-2 seconds), the hosted desktop  20  sends a command over the control channel  28  to retrieve the contents of the data file (e.g., XML file) in which the application metadata is stored. The retrieved contents are used to populate the start menu  56  of the hosted desktop  54 . It may be desirable to include a retry or polling mechanism to accommodate a case in which the preceding enumeration takes longer than the waiting period. 
         [0038]    Upon completion of the functions at  72  the system is ready for the use phase of  74  and  76 , which as indicated above are similar to their respective counterparts  66  and  68  in the fat-client process of  FIG. 5 . 
         [0039]      FIGS. 7 and 8  illustrate another aspect of integrating a separately provided application program (e.g., secondary-provided application program  32 ) into a hosted desktop  20 , namely the ability to launch the separately provided application program when a data file having a file type associated with the application program is opened. Referring to the above example of AutoCad®, this application generates drawing files that have a file extension of DWG (e.g., system.dwg). An operating system (e.g., Windows®) typically maintains an association, referred to herein as a “file type association” or FTA, between a file type as indicated by its file extension and the application program that operates on files of that type. Thus in a Windows environment, for example, an FTA may be established between the file type DWG and the application program AutoCAD®, so that when a file of that type is opened the system automatically launches AutoCAD with the name and location of the file as a parameter to enable AutoCAD to open the file immediately upon being launched. As mentioned above, this functionality becomes complicated in the heterogeneous cloud computing environment such as depicted in  FIG. 1 , because the application to be launched (e.g., AutoCAD) may be provided by the secondary CCS  12  while the file is located elsewhere, such as in the hosted desktop  20 . 
         [0040]      FIGS. 7 and 8  depict the function of FTA-based application launching for a fat client and thin client respectively. The differences between the two cases are similar or analogous to the differences between  FIGS. 5 and 6 . It should be noted that  FIGS. 7 and 8  include the functionality of  FIGS. 5 and 6  respectively and add in additional functions for the FTA-based application launching. 
         [0041]    Referring to  FIG. 7 , the functions at  80  and  88  are similar to their counterparts at  60  and  68  respectively in  FIG. 5 . At  82  the agent  30  performs the same aggregation as at  62  in  FIG. 5 , and also fetches existing FTAs that are configured in the secondary CCS  12  and updates the registry of the client computer  14  to record which hosted application program should be used for a specific file type. It is assumed that there is such a specific file type for one or more of the secondary-hosted application programs  32 , such as in the above AutoCAD example. The recording is made in the form of a command line that will be used when a file of a particular type is open. The following is an example of a command line that might be used in association with a file of type DWG (i.e., an AutoCAD file): 
         [0000]    
       
         
               
             
           
               
                   
               
             
             
               
                   “C:\Program Files (x86)\Citrix\ICA Client\Agent.exe” /qlaunch 
               
               
                 “XenApp6 :AutoCAD” /param:“\\Client\%1” 
               
               
                   
               
             
          
         
       
     
         [0042]    The above command line includes a path on the client computer  14  to the agent  30  with an instruction “qlaunch” to perform an application launch function, with the application to be launched identified as AutoCAD on a server farm identified as XenApp6 (in this example located in the secondary CCS  12 ). The agent  30  is also to be invoked with a parameter identified as \\Client\% 1, which refers to a location on the client computer  14  that will be specified at call time (passed in as the value % 1). The use of this command line is described below. 
         [0043]    At  84 , the user launches the hosted desktop  20 . Once the desktop is launched, as part of the startup process, the hosted desktop  20  sends a message over the control channel  28  to fetch the application metadata and uses this to populate the start menu  48  of the hosted desktop window  46  as described above with reference to step  64  of  FIG. 5 . As part of this exchange, the hosted desktop  20  also receives details about the file extensions (.cad, .pptx, etc.) that have been configured to be launched with the application programs for which it has obtained the application metadata. The extension information is determined by scanning the registry on the client computer  14 . These details include the recorded command lines as described above. The hosted desktop  20  uses this information to create FTA-like registry entries in the registry of the hosted desktop  20 . In particular, each entry associates a file type extension with a command line for invoking a “handler” routine, which in the present description corresponds to the launcher  26  ( FIG. 2 ). An example of such a command line for a file type of DWG (AutoCAD file) is as follows: 
         [0000]    
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                   ″C:\Program Files (x86)\Citrix\Launcher.exe” ″C:\Program 
               
               
                   
                 Files (x86)\Citrix\ICA Client\Agent.exe″ /qlaunch 
               
               
                   
                 ″XenApp6:AutoCAD″ /param:″\\Client\%1″ 
               
               
                   
                   
               
             
          
         
       
     
         [0044]    This command line includes the above command line for the agent  30  (referred to below as an “inner” command line) preceded by a specification of the path to the launcher  26  in the primary CCS  10 . It indicates that when a file of type DWG is opened, the launcher  26  is to be invoked with the inner command line for the agent  30  as an input parameter. The use and effect of this command line is described below. 
         [0045]      FIG. 7  shows two use cases. The functions at  86 - 1  correspond to the use functions at  66  in the process of  FIG. 5 , i.e., the launching of a secondary-hosted application program  32  by activation of a control such as an item in the start menu  48  of the hosted desktop window  46 . 
         [0046]    At  86 - 2  are the functions for the second use case, which is initiated when the user opens a file of a given type in the hosted desktop  20 . The hosted desktop  20  consults its registry and obtains the corresponding command line, then invokes the specified handler routine. Continuing with the above example, the command line causes the hosted desktop  20  to invoke the launcher  26  with the inner command line “C:\Program Files (x86)\Citrix\ICA Cnt\Agent.exe”/qlaunch “XenApp6:AutoCAD”/param:\\Client\% 1 being passed to the launcher  26  as a parameter. The hosted desktop  20  also provides the name and path of the document being opened, which will be passed as the % 1 parameter. Note that the document will generally need to be accessible to both the hosted desktop  20  as well as locally at the client computer  14 . 
         [0047]    Continuing with  86 - 2 , the handler routine (e.g., launcher  26 ) sends a command over the control channel  28  to the client computer  14  to launch the agent  30  with the remaining part of the command line, e.g., “qlaunch “XenApp6:AutoCAD” /param:\\Client\doc-path”, where doc-path refers to the document path provided by the hosted desktop  20  when invoking the launcher  26 . The agent  30  then initiates the application launch (e.g., for AutoCAD on the secondary CCS  12 ) from the client computer  14  with the path to the document. From this point operation is as described above with reference to step  68  of  FIG. 5 . 
         [0048]      FIG. 8  describes the thin-client counterpart of the process of  FIG. 7 . The functions at  90  and  96  are similar to their counterparts at  70  and  76  in  FIG. 6 . The startup functions  92  include the functions at  72  of  FIG. 6  augmented in the same manner as described above with reference to step  84  in  FIG. 7 . In particular, the hosted desktop  20  also receives details about the file extensions (.cad, .pptx, etc.) that have been configured to be launched with the application programs for which it has obtained the application metadata. In this case the file extension information may be stored as part of the application metadata in the same data file (e.g., XML file) referred to in connection with step  72  of  FIG. 6 . The hosted desktop  20  again uses the information to create FTA-like registry entries in the registry of the hosted desktop  20 , and the remaining operation (user cases at  94 - 1  and  94 - 2  can be as described above for the counterpart functions at  86 - 1  and  86 - 2  of  FIG. 7 . 
         [0049]    While in the above description of  FIGS. 6 and 8 , the hosted desktop  20  uses two separate commands to obtain the application metadata (at both  72  and at  92 ), in alternative embodiments this function may require only one command from the hosted desktop  20  and a compound response by the client computer (i.e., both gathering the metadata and returning it to the hosted desktop  20  in one compound action). 
         [0050]    While various embodiments of the invention have been particularly shown and described, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims.