Understanding How Applications Locate Foundation Services

Overview of How Applications Locate Foundation Services

Applications can access services that are deployed locally or remotely.

Note: Your application can be either a standard client application or a Web client application that runs in a servlet container.

To locate local and remote services, perform the following steps:

The application uses a service loader to instantiate and initialize local services, including its local Discovery Service.
The application initializes and registers the local Discovery Service with a remote Discovery Service. The application locates the remote Discovery Service by obtaining the Remote Method Invocation (RMI) registry location from a SAS Metadata Repository (or XML file that contains exported metadata) and performing an RMI name lookup on the remote Discovery Service. The remote Discovery Service enables the client to locate remotely deployed SAS Foundation Services.
When the application requests a service, its local Discovery Service first checks whether the service is a locally registered service.
- If the requested service is a locally registered service, then the application binds to the local service.
- If the requested service is not a locally registered service, then the local Discovery Service uses the remote Discovery Service to search the remote services deployment for the requested service.
  
  If the requested service is not registered with the remote Discovery Service, an error is returned.
  
  If the requested service is registered with the remote Discovery Service, a stub to the remote service is returned and the application can then use the remote service.

For example, in A Remote Service Configuration, if an application requests the Logging Service, the application binds to the local Logging Service. If an application requests the Session Service, the application uses the remote Discovery Service to locate and bind to the remote Session Service.

Note: If the application that deploys the remote services also starts the service registry, then the service registry must exist on the same machine as that application.

The following scenarios show examples of local and remote service deployment and access.

Scenario: Stand-alone Application

A stand-alone application deploys services locally, uses the services, and terminates the services when they are no longer needed. If an application does not need to interact with any other applications, then it can be a stand-alone application with its own exclusive local service deployment. Services locally deployed by this application are not available to any other application. In addition, no remote services are available.

Note: An application can be either a standard client application or a Web client application that runs in a servlet container.

To deploy local services for its own exclusive use, the application does the following:

uses the service loader to query service deployment metadata from either a SAS Metadata Server or XML file (that contains exported metadata)
uses the service loader to instantiate services that are defined in the service deployment metadata and registers them with the local Discovery Service
uses the local Discovery Service to find services according to their service interfaces and optional service attributes

When the application no longer needs the services or is ready to exit, it terminates the local Discovery Service. The local Discovery Service then destroys all locally instantiated services.

The following figure shows a stand-alone application that accesses a service deployment from a local SAS Metadata Repository:

Stand-alone Application Accessing Local Deployment from a SAS Metadata Repository

The following figure shows a stand-alone application that accesses a service deployment from an XML file:

Stand-alone Application Accessing Local Deployment from an XML File

The following figure shows two stand-alone Web applications that access their service deployments from a SAS Metadata Repository and each deploy their own local services for their own exclusive use:

Two Stand-alone Web Applications Accessing Local Deployments from a SAS Metadata Repository

Scenario: Services That Can Be Accessed Remotely

To enable applications to access remote services, one application must deploy the remote services. (The application that deploys the remote services can then access the services as local services). Instead of deploying their own set of local services, other applications can access the remote services. To access the remote service deployment, applications locate the deploying application's remote Discovery Service in order to locate and access the deployed remote services. This scenario is useful if one or more client applications need to use the same set of services.

In this scenario, Application 1 deploys the remote services and accesses them as local services. Applications 2, 3, and 4 locate Application 1's remote Discovery Service in order to access the remote services. Note that Applications 2 and 3 are Web client applications that run in the same servlet container and each deploy their own local services for their own exclusive use.

Applications Accessing SAS Foundation Services Remotely

To deploy remote services, Application 1 does the following:

uses the service loader to query service deployment metadata from either a SAS Metadata Server or an XML file (that contains exported metadata).
uses the service loader to instantiate services that are defined in the service deployment metadata and to register them with the local Discovery Service.

Note: In this scenario, these services must be configured as accessible to remote applications.
uses its local Discovery Service to find services according to their service interfaces and optional service attributes.

To locate the remote-accessible services (that were deployed by Application 1), Applications 2, 3, and 4 do the following:

Use the service loader to query service deployment metadata from either a SAS Metadata Server or an XML file (that contains exported metadata).
Use the service loader to obtain a name binding to the remote-accessible Discovery Service instantiated by Application 1.
Register the remote Discovery Service with their own local Discovery Service.
Use their own local Discovery Service to find services according to their service interfaces and optional service attributes. The local Discovery Service uses the remote Discovery Service to locate the remote-accessible services.

Note: In this scenario, Applications 2, 3 and 4 do not deploy any services themselves. They locate only services that are instantiated by Application 1.
When Applications 2, 3, and 4 no longer need the services, they each terminate their own local Discovery Service.

When Application 1 exits, it terminates its local Discovery Service. The local Discovery Service then terminates all locally instantiated services. After all services are terminated, no services are available to any other applications.

Scenario: Local and Remote-accessible Services

To enable other applications to access remote services, one application must deploy the remote services. (The application that deploys the remote services can then access the services as local services). Instead of deploying their own set of local services, other applications can access the remote service deployment. To access the remote service deployment, applications locate the deploying application's remote Discovery Service in order to locate and access the deployed remote services. In addition, these applications can each have their own set of locally deployed services to which each application has its own exclusive access. This example is useful when client applications need to have both of the following:

services deployed locally for exclusive use
use of the same set of remote services

Note: A foundation service-enabled application can be either a standard client application or a Web client application that runs in a servlet container.

In this scenario, Application 1 deploys the remote services and accesses them as local services. Application 2 locates Application 1's remote Discovery Service in order to access the remote services. Application 2 also deploys local services for its own exclusive use.

A Scenario in Which Applications Access Both Local and Remote Service Deployments

To deploy remote services and access these services locally, Application 1 does the following:

uses the service loader to query service deployment metadata from either a SAS Metadata Server or an XML file (that contains exported metadata).
uses the service loader to instantiate services that are defined in the metadata and to register them with the local Discovery Service.

Note: These services must be configured for remote access.
uses its local Discovery Service to find services according to their service interfaces and optional service attributes.

To deploy local services and access remote services, Application 2 does the following:

uses the service loader to query service deployment metadata from either a SAS Metadata Server or an XML file (that contains exported metadata).
uses the service loader to instantiate services that are defined in the metadata and to register them with the local Discovery Service.

Note: Because these services are used only by Application 2, they are not configured for remote access.
uses the service loader to query service deployment metadata from either a SAS Metadata Server or an XML file (that contains exported metadata).
uses the service loader to obtain a binding to the remote Discovery Service that is instantiated by Application 1.
uses its local Discovery Service to find services based on their service interfaces and optional service attributes.

Note: Application 2 has access to both local services and remote services. When services are located, the local Discovery Service first tries to find a service locally before it looks for a remote-accessible service.
When Application 2 no longer needs the services, it terminates its local Discovery Service. This causes its locally instantiated services to be destroyed and its bindings to Application 1's remote services to be terminated.

When Application 1 exits, it terminates the local Discovery Service. The local Discovery Service then terminates all locally instantiated services. After all services are terminated, no services are available to any applications.