Global Object Integration Infrastructure Supplementing SOA with Data Management: Perspectives of Creation

The current level of IT-technologies enables advanced solutions: complex systems intercommunicating one with another using open standards. IT industry has evolved a lot during the last one-two decades; however information itself still remains fragmented in the Net. There are mature tools for human-convenient information representation by means of a single program - WEB browser. But you understand that it has nothing in common with a consistent integration on the level of information/data; it's only accessing to systems through one window. Absence of consistent integration is apparent when a user, taking some data from one system, tries to look for related data in an adjacent system. This is impossible if only both vendors do not endow the systems with appropriate functionality initially.

If we would have said that IT society did nothing to overcome the problem, we would be wrong. Many things are being done: general system intercommunication standards (SOA, for instance) as well as particular integration standards for specific application domains are being developed. However, current efforts do not seem to be enough since standard development is complicated by two factors: considerable quantity of interested parties and high complexity of system integration technologies.

In this connection the question arises as to whether the technological component can be simplified by creating infrastructure for consistent system integration? Of course, you can say that the infrastructure already exists - SOA. Indeed, SOA may be used for high-quality integration of a number of systems under one program interface, but efficient solution of the task is only possible on basis of open standards for the appropriate application domain, which do not always exist. If there is no standard, each system vendor has to rely upon their own solutions. As a result, we acquire a set of separate systems, and intercommunication between every pair of them should be developed anew on both sides.

SOA gives facilities for system integration, but integration can not always be done in sufficiently simple and scalable manner. Real simplification of system integration process may be achieved only when systems being integrated start working in one object space with common mechanisms for accessing and referring to objects. Only this space may eliminate boundaries between systems by making the systems operate on common data with no need to develop separate modules for intercommunications of adjacent systems. The integrated object (data) space may simplify the system integration process significantly. In fact, an integrated meta-system is being created by that.

Apparently, this data-oriented approach and SOA, being behavior-oriented, do not contradict but supplement each other. The integrated object space brings data-oriented system integration up to the new technological level since it hides all the data access specifics and gives the unified interface for object processing. The space can be extended in flexible and transparent manner without implementation of complex integration projects within existing systems. By the same reasons every SOA service benefits from the object space: services can use common data without any restrictions.

The approach of object space creation is not new. The very approach is used in solutions integrating several relational schemas into one. In this case a user interface developer can use the integrated schema to create seamless GUI and do other data processing in sufficiently simple manner. But these solutions have scalability restrictions bounded by a company or a holding company. It is impossible to extend the set of spanned systems endlessly; it will result in efficiency degradation for the whole integrated system sooner or later. But we tell here about the integrated object space with unrestricted scalability which is able to publish any quantity of objects and systems.

Of course the scale of tasks to be solved for creation of such global object space raises doubts in their principal feasibility. First, we should prove that the space may be created technically. Intuitively, it seems apparent that it is impossible. Second, organizational steps of such project are infinite. For such system to start operating in full, many vendors should be involved, which requires enormous efforts from the whole IT society.

We should note that further reasoning about the integrated object space is not only theoretical. Ideas discussed here underlie the product EntryService of Fusionsoft Company which is accessible here: http://www.fusionsoft-online.com/entryservice.php.

Let's consider the main doubts arising when we start talking about the integrated object space on a global scale. The first doubt is how to ensure sufficient scalability for such space if there are so many, inestimable, objects to publish? Whether the space preserves its efficiency during extension? The apprehension can only be dispelled in more detailed discussion below. Here we can give the short answer: hierarchical organization of objects and systems, like it is done in X.500/LDAP and DNS, gives all necessary means to solve the scalability problem.

The second doubt is what to do with those objects which are already stored in different data bases and used within existing systems? For the objects to be used in creation of new integrated systems, they should be logically mapped to the integrated object space without physical copying. In this case, actions over the objects done within the space will be immediately mapped to actions over the stored objects, ensuring information consistency. This approach lets create new systems which are initially integrated with other systems without a separate integration project.

The third doubt is whether it is possible to ensure the sufficient level of information security for such integrated object space? The short answer is yes since objects can be published at an information owner's place, and so both special security facilities as well as standard ones (VPN, etc.) can be employed.

And the main doubt is how can the object space be useful for resolving integration problems? If two systems were created separately, then the answer is not comforting: they can not communicate one with another without revising. Revision is necessary regardless of an integration technology used since data relations should be created between objects of different systems.

Then why we introduce some object space if existing systems can be only integrated using replication, ETL and other means as before? First, the approach being discussed is mainly oriented at development of new systems integrated initially by the fact of creation. Systems created newly and working with objects through the object space are seamlessly integrated with all systems worked with the same objects before. This is apparent from the fact that any system may read, modify and refer to objects regardless of how and where they are stored, and so end users can get any interesting information from any system without restrictions.

The above does not mean that the approach can not be effectively employed for integration of existing systems which was not built over the integrated object space initially. Besides data integration for some systems itself, new user interfaces are required to work with integrated data as a whole, only then end users can benefit from it. Of course, modules for existing applications, working with data of adjacent system directly, can be created, but this functionality should be added twice for every pair of systems being integrated, to applications of both systems. It is often so even if a user interface is built for WEB browsers.

This problem can be solved by creation of the integrated object space over the systems and by development of user interfaces and data processing algorithms over the space. Doing so, we achieve integrity of user interfaces and make it simple to extend the cluster of integrated systems. When other systems are added into the cluster, their objects are to be published in the object space for end users to become able to work with them. If new objects are of the types being already shown in GUI, then no additional programming is necessary. Of course, if some types are not covered, then GUI should be revised once for every new object type added.

There is no need in the integrated object space when isolated systems are created. But when we concern integration of several systems into one meta-system, a consistent object space, based on one or another technology, becomes needed, especially when systems being integrated are created at different time. Having no such integrated object space, solutions will be scrappy to a greater or lesser extent.

There may be a lot of different approaches to organization of an object space. Some of them are implemented as high-quality products (for instance, approaches to relational schema integration). Further we will discuss our vision of this complex question and try to disclose motives for every architectural decision made, not claming to uniqueness of solution.

The key property of our approach is its unrestricted scalability which can be useful within one company as well as within the Net as a whole. Organizational problems concerning the global character of the object space should be considered separately and are not discovered here.