Русская версия
+7(343) call:2 110 256

How does it work?

Let us describe how application integration using Business Semantics is working.

Let's take as example the case of two applications, using MySQL and Oracle databases. They has to exchange data about customers and contacts (calls, meetings etc) with them. So, if a customer is created in one of the applications, it must immediately be created in another. If customer properties will be edited in one of applications, these changes also must be reflected in another one.

All the actions described below may be done by us, or by customer's IT personnel. So, let' start with setup process.

1. Create ontology

First, we have to create ontology, which will contain all entity types and properties for the information our applications will exchange. In our case, to simplify samples, we will use simple properties set. Let a customer have the "name" property, and a contact - "date" property, and "customer" linkage. "Name" and "date" are literals, "customer" is an entity reference. In a more real case, entities will have much larger properties set, but they all have to be created similarly.

Ontology has to be saved as OWL/RDFS file. We can do it using any ontology editor. There are a wide range of such products available. Some of them are working with "low-level" OWL representation, others are hiding OWL syntax behind visual or verbal modeling tools. One of better examples of software allowing to create OWL ontologies without knowing OWL syntax, is Fluent Editor from Cognitum. It is a Controlled Natural Language (CNL) editor. Below you may see video showing how to create the ontology reqiured in our sample case using this tool.

You may see also how the same task may be performed in TopBraid Composer.

In this sample we've created ontology from the scratch, but we can, of course, import and use any standartized ontologies, such as Dublin Core or ISO 15926.

2. Set up server

Now we have to set up server. It is installed as an usual web application, the process is described in documentation. When server will be running, we have to log into admin panel, and upload ontology. Then we have to create accounts for both applications interconnected. Finally, we have to define access rights for these applications to entity and property types. All these operations are done using server web interface.

3. Set up client modules

Now let's turn to client modules setup (we name them "connectors"). These components are responsive for integration on each application's side. If our applications has connectors from the box, we will have no problems: all we need is to set them up, following instructions. Particularly, we need to upload to them the same ontology (or its subset), that we have loaded into the server. Also we may request onlotogy from the server to the client directly. Then we have to set up mapping between ontology elements (entities and properties), and local date storage structure (database tables and columns). Web-connector, that we will use in this sample, allows to do it using web-interface. If some elements cannot be mapped directly, we shall define program handlers for each of them. Handlers are written using native language for this environment.


We've done! How the data exchange process will run?

4. Transferring data update information

As one of applications creates, changes or removes an object, it have to notify server on this event (if this kind of objects is mapped to any element of ontology). This is done by program instruments, native for client applications environment (for example, database triggers and queue processing). Client module gathers information on every object that has changed, and transfer this data to the server (this can occur, for example, each 2 seconds). Server gets that data, temporarily stores it in the queue, and then notified another application of these changes.

5. Receiving data changes information

As was said above, each 2 seconds (interval may be adjusted), each client module requests server and asks it if there is something new. If there are data changes notifications that has to be processed, server transfers it to client module. Client is transforming these notifications (triple-encoded data, in fact) to the receiving application's data structures. Now the transfer is done, the information has reached destination point.

Now let's see server and clients interaction schema. On this image, at one side there is a web-connector, another side is other platform connector (for example, 1C accounting application).

Of course, Business Semantics Server functionality is not fully described here. Beside said above, there are functions controlling and recovering data integrity, etc.