0% found this document useful (0 votes)
32 views3 pages

Aspect Directory

The Aspect Directory is a core component of the DCS Core System, managing the storage, creation, and deletion of system objects and aspects. It supports redundancy through a configuration of multiple machines, ensuring transactions can be processed even if one service fails. The document also outlines operations for redundancy management, including commands for cold resets and session management.

Uploaded by

rubhernandez
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
32 views3 pages

Aspect Directory

The Aspect Directory is a core component of the DCS Core System, managing the storage, creation, and deletion of system objects and aspects. It supports redundancy through a configuration of multiple machines, ensuring transactions can be processed even if one service fails. The document also outlines operations for redundancy management, including commands for cold resets and session management.

Uploaded by

rubhernandez
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 3

1.

1 Aspect Directory

1.1.1 General
The Aspect Directory is the main component of the DCS Core System
and of System 800xA as a whole.
It holds and defines the System in which all objects and aspects reside. It
handles the storage, creation and deletion of aspects and objects as well
as keeping track of the associations between aspects and objects.

Client processes that want to access the aspect directory create an


Object Manager. The object manager provides access to objects and
aspects and their interfaces as well as many other services in the system.
Included in the Object Manager is the Structure And Name Server, SNS.
The SNS provides the translations between the GUID’s used internally
and aspect and object names.
(From a more strict architectural view both the SNS and the Object
Manager has corresponding server side components included in the
Aspect Directory process. But from a pure functional point of view they
can both be considered as client components)
Example, when a user starts a Plant Explorer workplace he selects which
system, if more than one available, he wants to work against. The
workplace will then in the initial phase create a client Object Manager that
will set up a session towards the Aspect Directory that holds the chosen
system. The setting information contains language, current node and
user. When initializing the session the user credentials are checked so
that the correct privileges and roles are provided to the user.

1.1.2 Architecture for redundancy


The aspect directory can be made redundant by using 2 or 3 connected
machines in parallel doing the same task. The machine must also be
connected with a redundant network connection to avoid a single point of
failure.
One of the machines is the Master, i.e. all transaction goes through that
machine. A typical configuration with three Aspect Directory service
providers and one client:

Figure 1 Redundant Aspect Directory Servers


All services are kept in the same state by a replication schema. The
following happens when the Client connection to the Aspect Directory
marked A is making a transaction:
AD-service A sends the transaction to the Master AD-service, marked
C(M) in the figure above.
The Master AD-service sends the complete transaction to the AD-service
B and a subset of the transaction back to AD-service A (sends the
transaction id without the data, since the data is already present).
When the Master AD-service C(M) gets an answer from both AD-service
A and B that the replication is complete it sends a commit transaction
back to AD-service A and B.
The AD-service A sends the commit back to the client and the transaction
is complete.
The replication schema is built on a majority schema, i.e. if a majority of
the services in a redundant configuration answers OK, the transaction is
committed. In the case described above the AD-service B may be down
and the system will still work correctly, since 2 services out of 3 services
is answering OK.
If two services goes down the system will still work for read transactions,
but since there is no majority it is not possible to make a transaction that
modify the contents of the aspect directory.
In the case of 1 out of 2 redundancy the schema is a little bit different. If
one of the services goes down the remaining service will still be up and
running in read/write state. When the failing service comes up it will do a
synch against the other node. The replication works the same way as for
2 out of 3 redundancies.
The 1 out of 2 schema may give a problem for a double error in the
communication, i.e. when all available communication networks between
the two services are broken. Both services will then be up and running
and allow read/write transaction. When the communication network
between the two services is fixed and inconsistencies in the content of the
two services are detected, one of the services will, randomly selected, go
to error state..

1.1.2.1 Redundancy operations


The following table shows information about operations that may be
useful in a redundant system.
Command Description
Cold Reset Cold Reset is the same as starting over with an
empty system. For the aspect directory it
means to remove all aspect directory data and
do a total synchronization. Cold Reset should
only be done on a failing service when there is
redundancy and one or more other services are
up and running in service state. Cold Reset on
a single node will remove all aspect directory
data, i.e. the application data, and a restore has
to be done to get back in operation again.
New When a service starts the first time is a Session
Session identifier created. This session identifier is
persistently stored for rest of the service life
time. When a redundant service is added it will
get the same Session identifier. Only services
with the same session identifier can be
redundant to each other. The New session
command will start create a new Session
identifier. The command is necessary to
perform in some error situations. See the
support cases for details.
Reset Force synchronization, but only for changed
data.
Run Go to the target state specified.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy