Xephr® Interconnect

The Xephr® interconnect facility (Xephr networking) operates through the Xephr Administration tool via a publish / subscribe mechanism. This facility permits Xephr instances to act as “proxies” to permit remote Xephr instances to access databases that they can not “see” through the normal datasource connection process.

Consider, for example, two databases that are remote from each other in the sense that ordinary database connections can not be used to retrieve data from both simultaneously. We might wish to present a combined view of both sets of data in a single report (or web page, or spreadsheet, etc...). We might wish to transfer all or part of the data from one database to another. Xephr provides the option to manage that data as if it were all in the same location.

Publication

The first step is to define the data which is to be exposed for use by a remote connection.

Xephr instance Xa studio has an entity (E1) which is to be made available to other Xephr instances. This entity is defined to retrieve data from one or more local datasources (any datasource, including other published interconnect entities). The data is returned as an xml document.

  1. The entity header for E1 is set to “publish” and the “run as” user is assigned. The entity outline and publication date/time are stored by the Interconnect Manager (IM). If the entity is modified later, the new outline and update date/time are sent automatically to the Interconnect Manager.

  2. The IM acknowledges successful receipt.

Subscription

The second step is to combine the previously exposed data with the data available locally.

In Xephr instance Xb studio, an entity E2 needs to include data from a remote interconnect. The query is defined as a web service provided by the Xephr Interconnect service. The list of available entities is retrieved and the appropriate one chosen (in the example, E1). The column list for the selected entity is provided and required fields selected. To the studio user, the interconnect entity looks just like a local database query.

  1. Request list of published entities

  2. Receive list of available entities

  3. Request structure outline for selected entity

  4. Receive structure outline

Runtime

The end user runs the report (or web page, spreadsheet, etc...) on request or on a schedule or in response to a defined event.

Xephr instance Xb is requested to run the entity E2, which was defined in the example above to include an interconnect query E1.

  1. Xephr instance Xb requests a token from the Interconnect Manager for interconnect query E1 at Xephr instance Xa. The IM verifies that instance Xb is permitted to make such requests.

  2. The Interconnect Manager logs into instance Xa as the entity E1 “run as” user.

  3. Xephr instance Xa authenticates the IM request, creates a session and returns a “hash” of the session ID to the IM.

  4. The IM returns the hash to instance Xb, together with any updates to the published entity E1 structure which have been recorded since Xb subscribed to E1.

  5. Xephr instance Xb verifies that any structure changes can be accomodated without problems, and requests the query result directly from Xephr instance Xa, using the hash as a token.

  6. Xephr instance Xa returns the data requested in Xephr internal DOM format. Xephr instance Xb processes the query result set.

Xephr is a registered trademark of NDS Systems, LC.