Scalability of the Integrated Object Space

Unrestricted scalability of the integrated object space was declared above. How can we achieve that extension of the space will not result in its degradation in time? Such scalability is possible only in case of complete diversification of information flows between the object space and clients using it. It means that if all data flows go through one or bounded set of network nodes, then scalability of such solution will be limited by bandwidth to these nodes. The limit will be reached sooner or later. So we conclude that there should not be such nodes. But how this decision goes with object space connectedness? Does not it mean that the object space will become fragmented?

We use the following terminology in our solution. A part of the integrated object space placed at one host is an object service providing the program interface being general for all such services. Every service manages its own part of the object space and implements functions for accessing, modification and referring to objects published with it. Integrity of the object space goes from hierarchical service organization with a single root, which helps to find any service when necessary.

The service hierarchy has part-whole relationship semantics: a service may be terminal one working with stored objects directly or intermediate one combining some other services. Terminal services manages their objects exclusively, one object can not be managed by several terminal services. Intermediate services combine subordinate services just logically and do all work on them through subordinate services rather than directly. One subordinate service may be part of an only intermediate service.

So all services are parts of the root service directly or indirectly. Does it mean that we violate our requirement and the root service is the one participating in all information flows between clients and the object space? No, it does not. Existence of the root service does not forbid using the service containing an interesting object directly. Then does it mean that a client should know the service managing the interesting object before using it? It's not true as well.

The program interface of all services has two parts: inter-service and client. The inter-service part backs service hierarchy and inter-service communication, while the client part does not concern inter-service organization mechanisms at all. From the client's point of view every service gives means to use any object of the object space with no any restriction: it is sufficient to connect to any service to get access to any object published. How can we achieve both accessibility of all objects and absence of a single node transmitting all information flows through?

Accessibility of objects through any service is backed by inter-service communication when an unknown object requested by a client is to be found. After an object is found, it is accessed through the terminal service where the object is stored, which gives significant diversification of access ways to objects with known placement. Therefore the object search algorithm gets critical importance: scalability of the whole object space depends on diversification of information flows in the search process.

One of solutions could be creation of object registries for every service. Terminal services could have the registry of objects stored in it directly, and intermediate services could have the registry of objects stored in nested services. But this solution does not provide the necessary level of diversification for access ways, and here is the reason.

On the one hand, such registries could ensure for an object to be found in sufficiently efficient manner since we could go up the service hierarchy to the service where the placement of the object is registered (like searching an address for a domain in DNS). As a result, the root service would be used only when objects to be found and the client are in "opposite" sides of the object space.

On the other hand, this approach does not give the necessary level of information flow diversification. If the "opposite" part of the object space contain a considerable amount of objects looked for, then density of data flows to the root service and its nearby services will rise significantly. As a result, when clients show noticeable activity, then the object space will degrade inevitably. Moreover, objects are not as permanent as associations between domains and addresses. Objects can be created, deleted, or modified actively. And having taken into account that this approach requires to propagate object registries from terminal services toward the root one, we conclude that this propagation itself will result in absolute efficiency degradation for the object space regardless of any other aspects.

Therefore this approach, based on object registries, can not be used in the integrated object space being global. But is there any alternative which does not result in the object space's degradation during extension? Yes, there is.

The key to alternative solution is such way of object identification within the integrated object space which ensures efficiency of looking for the terminal service storing the object. Of course, the simplest decision here is to use a terminal service's address as a part of object identification. But this decision will impose strict restrictions on object space flexibility. For instance, if one decides to split one service on two or to move some objects between services, then it will require modification of all references to the objects being moved, which is impossible in general case since the amount of references may be enormous and their placement is not always known. Therefore we can not use the terminal service as a part of object identification.

But how else can we structure object identifiers to find their terminal services efficiently? The answer is usage of hierarchical identification where all object identifiers form a tree from one root, and every node of the tree knows the service managing objects identified by this node and nodes nested to it directly or indirectly.

How efficient can be search in case of hierarchical identifier, will it degrade like the version with object registries? First, the search is done once for every identification tree node and not for every object covered by the node, which reduces information flows significantly. And second, nodes rarely change association to the services backing them. It enables local caching of this information within any service placed on the way between a client and the root service. Therefore we can conclude that services can be found using the similar algorithm as looking for domain in DNS. So service search efficiency is comparable with domain search efficiency for DNS.

So the hierarchical identification solution gives diversification of information flows during search for a service as well as during work with final objects. The level of diversification is sufficient for the integrated object space to function efficiently with unrestricted scalability.

And now the question arises: how to implement the identifier hierarchy in the most rational way, so that efforts for its creation could be minimized and identifiers could remain stable when moving objects? When answering the question, we use one apparent observation: objects and object properties form the part-whole hierarchy. For instance, an object of the type "person" can have the property "passport" which in its turn is an object and can have its own property "passport number". So any object can be considered as a node being parent for all its nested properties, and each property, in such interpretation, is an object, and so it can be a parent node for other properties. And so forth.

If we build such hierarchy from one root object, then hierarchical identifier of an arbitrary object may be formed as the path from the root object to the given one. How should we identify each step оf the path in that case? If we talk about objects and their properties, then it is natural to use property name since it is well-known that properties have unique names within objects, and so they identify each branch of the tree unambiguously. Therefore, the unique identifier for the object "passport number" may be /People/Vladimir/Passport/Number, where "People" is the property of the root object, "Vladimir" is the property of the object "People", and so on.

Such approach let us reduce the identifier hierarchy to the object hierarchy and to avoid artificiality of the identifier hierarchy. Identifiers acquire substantial meaning and may be used for referring by systems as well as by people. Efforts for creation of such hierarchy are equal to efforts for creation of the object structure, no more.

So, taking into account these additions concerning identifier organization, we can ascertain that the whole object space, being the object hierarchy now, can be split on several sub-trees having its root object associated with some service used to store this root and nested objects. Sub-trees can be extracted in arbitrary way with the single restriction: every object should be associated with one of services directly or through its ancestors. Therefore, it is possible the situation when sub-trees form another tree, where some branches give rise to other sub-trees for other services. As a result, the same service may be intermediate, having some subordinate services, as well as terminal, storing some objects directly. It gives significant flexibility of distribution of objects among services, and so it gives load-balancing flexibility and high scalability of the object space as a whole.

Sub-trees may be joined and split on parts without changes in object identification. As a result, identifiers remain stable when moving objects. It is sufficient to assign a new service to some higher object to get access to it and all subordinate objects through this service, without changes of identifiers. By that we acquire higher flexibility of object distribution among services.

Also it is important consequence that the object hierarchy can be used to solve research tasks and not only getting of specific objects by known identifiers. Thus a user can browse the object tree investigating what objects exist and what properties they have. Moreover, the hierarchy can be overbuilt with a query language like X-Path/X-Query. Efficient execution of queries of such language is a separate question, and it requires of course corrections in light of global character of the object space.