10.1 Overview

This section provides a conceptual overview about the interoperability between Novell Teaming and remote applications. If you prefer to learn by doing, you may want to skip this section and begin with Section 10.2, Creating a Remote Application.

Here are the very high level steps for setting up a customization based on a remote application:

  1. A site administrator registers a remote application, specifying a name and a URL for the application (for more information, see Section 10.3.1, Registering a Remote Application).

  2. After using configuration or designer tools to include HTML from a remote application, a page in Teaming performs an HTTP POST operation to the application’s URL and provides user-context information.

  3. As an option, the remote application can use Web services to obtain Teaming data needed to generate its section of the page.

  4. The remote application responds, providing its HTML to the Teaming code that is drawing the page.

    Because Teaming has already begun to draw the page, providing structuring HTML tags (such as html, title, head, and body), the remote application should not specify those tags.

In Teaming, a remote application is treated as a principal; examples of other principals are users and groups. So, Teaming treats the application like a user, and users are subject to access control.

When Teaming makes a request of the remote application, it provides the user identifier for the user currently viewing the page, and it provides a security token. Depending upon the type of Teaming page that incorporates HTML from the remote application, the security token may be session based (valid until the user signs out) or request based (invalid immediately after the remote application responds to the request). In most cases, Teaming uses a combination of the registration information for the remote application, rights assigned to the user currently viewing the page, and rights granted to the remote application itself.

Here are ways to apply HTML generated from remote applications:

This section contains these subsections:

10.1.1 Processing Flow for a Remote Accessory

This section describes the flow of information when someone configures an accessory to use HTML from a remote application to provide its content. Consider the numbers in this graphic and the descriptions that follow it:

Figure 10-1 Conceptual Diagram for an Accessory Calling a Remote Application

  1. The enclosing rectangle in the graphic represents a workspace or folder page.

    Teaming draws the page until it encounters the accessory.

  2. The enclosed rectangle represents an accessory that is configured to use HTML generated from a remote application.

  3. Teaming calls the remote application using the HTTP POST method, and it provides the user ID of the person viewing the page and a security token.

    The gray portion of the diagram indicates that control has been passed to the remote application, which may be located on a server machine separate from the one running Novell Teaming.

  4. The rectangle in the gray area represents the remote application.

    Notice that the remote application can access databases external to Teaming as part of its process for constructing the HTML needed to generate the accessory. The remote application can run in any environment that can generate an HTML response (for example, using PHP or Pearl scripts in its application environment).

  5. As an option, the remote application can use the Teaming user ID and security token to log into the Teaming Web services and make calls, which can gather Teaming data in preparation for generating the HTML for the accessory.

  6. This rectangle represents Teaming Web services.

    In the graphic, both Web services and the Teaming user interface have access to information in the Teaming database.

After the remote application responds by returning HTML for the accessory, Teaming adds the HTML to the output stream and completes the drawing of the page. Then, Teaming revokes the security token so that it can no longer be used.

10.1.2 Processing Flow for a Remote Form

This section describes the flow of information when someone uses the Teaming designers to specify that a remote application provides the HTML for the form used to create an entry. Consider the numbers in this graphic and the descriptions that follow it:

Figure 10-2 Conceptual Model for an Add-Entry Form Generated Remotely

  1. The enclosing rectangle represents the add-entry page.

  2. The enclosed rectangle represents the form used to add an entry.

  3. Teaming does an HTTP POST to the remote application, sending the folder ID of the enclosing folder, the user ID of the person currently viewing the add-entry page, and a session-level security token.

  4. The remote application builds the HTML needed to construct the form to be displayed on the Teaming page. The URL specified to the action element in the form tag points to the remote application.

  5. The remote application can use the user ID and security token to log into Teaming Web services, which can gather data used to construct the form.

  6. This rectangle represents the Teaming Web services.

After the remote application responds by returning HTML for the form, Teaming adds the HTML to the output stream and completes the drawing of the page. The user completes and then submits the form. Information on the form goes directly to the remote application, which then uses the folder ID, user ID, and security token to make Web services calls, which, in turn, create a new entry in the folder based on the information provided in the form.

When the user logs out, Teaming revokes the security token.

10.1.3 Setting Access Control

As mentioned, Teaming treats a remote application as if it was a Novell Teaming user, which allows for the application of access control. However, for non-workflow uses of remote applications, Teaming considers these factors when determining access control:

  • Rights granted to the user currently viewing the page that contains HTML from the remote application.

  • Rights granted to the remote application by the owner of the containing binder (workspace or folder).

  • The Trusted designation, which a Site Administrator can grant to a remote application upon registration.

Teaming considers the role of the user viewing the page and the role assigned to the remote application, and Teaming grants the less powerful role to the application. For example, if the user viewing the page is in the role of a Visitor, and if the workspace or folder owner placed the remote application in the role of Participant, then the application has the rights associated with a Visitor. As another example, if the user is a Site Administrator, and if the application is a Participant, then the application has the rights associated with a Participant.

When the site administer selects the Trusted check box while registering a remote application, then Teaming disregards any access control applied to the application and uses only the access control granted to the user viewing the page.

Finally, if Teaming calls a remote application as the result of a workflow state change, then access control is determined by settings in the workflow definition, which can result in the application having the rights of either the entry owner or the folder owner.

NOTE:Unless you are certain that an application is Trusted (for example, an application that you maintain and run on the same server machine as Novell Teaming), strongly consider placing access controls on the remote application itself. For example, if the site administrator uses the access-control tools to place the remote application into the Participant role in the top Workspace, then all workspaces and folders that inherit access control automatically apply the same restrictions on the remote application. Then, if a site administrator views a page calling the remote application, the application is restricted to the rights granted to a Participant instead of those granted to a Site Administrator.

If you do not make any attempt to restrict the rights of a remote application, then the remote application has the same rights as the user viewing the page that calls the application. For example, if a site administrator views the page, then the remote application can use Site Administrator rights to do anything in Teaming using Web services calls.

10.1.4 Reviewing Supporting Source Code

To learn more details about the interaction between Novell Teaming and a remote application, you can look at example source code. To download the Kablink Teaming code base, visit the Open Source Community page.

![Rework to accommodate Novell Teaming]

After downloading the Kablink Teaming sources, review this code:

  • SOAP wrappers for objects: These wrappers are located within the Kablink Teaming source code here:/ssf/samples/wsclient/src/com/sitescape/team/samples/wsclient/TeamingServiceClientWithStub.java.

    For more information about Web services and SOAP wrappers, see Section 4.0, Web Services Overview.

  • Passed information: To see details about the information passed between Kablink Teaming and a remote application, see this file: /ssf/main/src/com/sitescape/team/remoteapplication/impl/RemoteApplicationManagerImpl.java.