Polaris is a simple application developed to test and illustrate the ActiveNaming and Grid functions. For more information about the ActiveNaming and Grid functions read the Grid document.
Polaris is made of two parts:
There are two versions of Polaris:
Polaris A uses the ActiveNaming Web service to implement data-dependent routing (the target Web service is chosen after the request parameters) and location-dependent routing (the target Web service is chosen after the requestor location). Polaris A also implements load balancing and is fault tolerant. The client part is used in combination with a Login control that authenticates users and a Commit control that triggers the Web service updates. The inter-control communication uses the Coordinator API.
Polaris B is based on Polaris and uses the PageBox Grid API. The server part of Polaris B uses the Grid API to replicate the database updates onto other server instances. The control part of Polaris B caches the results and uses the Grid API to synchronize the cache with other control instances. Polaris B is a superset of Polaris A.
The diagram shows an example of configuration:
The Polaris Web service and the Polaris client can be published on different repositories:
Polaris A only implements the orange part:
Polaris A uses the ActiveNaming Web service embedded in PageBox.
Polaris B uses the Grid API
Subscribes to a Repository
Install the Web service archive or the client archive
Implements the ActiveNaming Web service
The Web service and the client Web application can retrieve the PageBox that installed them, the controlling PageBox.
The Web service Web application calls the ActiveNaming instance of its controlling PageBox to register an object that contains:
The Web service Web application uses the SetKeyRange method of the ActiveNaming Web service and can set a different object for each Web service.
The client Web application calls the ActiveNaming instance of its controlling PageBox to get the list of possible Web service instances. It uses the GetCandidate method of the ActiveNaming Web service.
The Polaris client part is designed to be used in combination with something that authenticates the user and something that commits the changes. These entities are typically other controls, however Polaris makes no assumption about the way they can be implemented.
The page designer adds the Polaris, the authentication and the commit control to its page.
It can define which ID Polaris will use to retrieve authentication information and the ID of the transaction requestor. Here is an example of Polaris definition in an ASPX page:
<%@Register tagprefix="polaris" Tagname="shoppingBasket" src="ShoppingBasket.ascx" %>
<polaris:shoppingBasket runat="server" TitleCss="map-title" StatusCss="timestamp"
CopyrightCss="copyright" MinWidth="500" MaxWidth="500" DgHeaderCss="datagrid-header"
DatagridCss="datagrid" DgAltCss="datagrid-alt" Css="map-table"
LoginID="Login" SourceID="Commit" ID="Basket" Timeout="0"
WSArchive="PolServer.zip" WSName="ShoppingOrder" Location="Eden" />
This definition is divided in three sections:
Style definition: the user defines here the CSS classes to use to display the different elements of the Polaris control. We presented such definitions in the Control and the GoogleControl documentation
Coordinator definition: the user defines here the ID of the Polaris control, the ID of the authentication source (LoginID), the ID of the transaction source (SourceID) and if the Prepare result should be cached (Timeout). See the Coordinator documentation for more information.
ActiveNaming definition: the user defines here the Repository where the Web service should be deployed from, the Web service name and archive. The user also defines the client location used for location-dependent routing.
The Polaris control first registers for transaction commit coming from sourceID:
PageBoxGrid.TransactionCoordinator.Subscribe(sourceID, Session.SessionID, ID, this, timeout);
this is the callback object that the Polaris control provides to get notified about transaction commit. This callback object implements the Transaction interface. When the control whose ID is sourceID commits the transaction, the Coordinator first invokes the Prepare method.
The Prepare method:
Get the authentication data from the Heap (with a LoginID source)
Uses the ActiveNaming Web service to retrieve the available Web service instance.
Selects a Web service instance depending on the request data and the instance location
Returns true if it found an active and suitable Web service instance
Then the Coordinator invokes the Commit method that invokes the selected Web service instance.
To demonstrate the use of the Coordinator the Polaris client contains
An Example of ASPX page
The Polaris control called ShoppingBasket.ascx
A Login control called PolLogin.ascx
A Commit control called PolCommit.ascx
The Web service of Polaris B
Creates an instance of the Grid object
Calls its Scatter method with the SMTP transport mode to broadcast the database updates to the other Web service instances that manage the same key range
Calls its Receive method to get notified of the change occurred in the other Web service instances. Then it updates the local database
The Polaris B client
Creates an instance of the Grid object
Keeps a Candidate cache
Keeps a cache of its Web service invocations
Calls its Scatter method with the UDP transport mode to broadcast the cache changes to the other client instances with the same location
Calls its Receive method to get notified of the change occurred in the other client instances. Then it updates the local cache
The Polaris documentation includes:
©2001-2004 Alexis Grandemange.