Business Semantics comparing to XML files exchange
Well-known integration methods
Currently, application integration in most cases is implemented using one of the following methods:
- Point-to-point. May be implemented using many technological methods, but, in most cases, it is a simple XML or CSV files transfer. One module, from first system's side, exports information to the file, another module - at another side - reads this file and interprets it. Another way is the direct database access. Anyway, data is being transferred using custom logic implemented in the program code.
- SOA (service-oriented architecture). Each application offers a set of web services, containing some methods, that can be invoked by other applications. Each method allows to execute a certain operation: for example, to retrieve customer's contact info, or add a new customer, etc.
Well-known tecnologies drawbacksThe methods listed above are not standartized, and they are used in a wide range of environments. Their drawbacks are described below.
- These methods are completely dependent of the data model used in applications interconnected. For example, if one of the applications stores information concerned customers in a database table, it (most likely) will export this information into the file, having the same, or at least dependent, structure. If another application has another view of customers, it will be forced to convert data at the import. This may be done only using custom program code, which, in turn, is strictly structure-dependent. Obviously, if data model in one of the applications is changed, exchange procedures needs to be amended. Web-services also has this drawback, because both the set of methods, and its input-output parameters are model-dependent.
- In case if two application stores information about the same objects, and both allows user to change it, this inevitably leads to conflicts and possible data loss at exchange. These problems are being solved - if solved at all - by writing a custom code, which is, again, model-dependent.
- In case if two application stores information about the same objects, these objects has different unique identifiers in both applications. When, during data integration, an integration procedure will find these objects duplicating, it must store one object's ID from one application to another. It is not a problem for two applications, but imagine there are three, four or more... Moreover, in some cases some applications may not have unique identifiers for some kind of data at all. All this leads, once again, to an intensive programming.
- Frequency. Usually, data exchange is done not in the real time, but with some intervals. One application collects data that has to be transferred, then pushes it to another application in a bulk package. This strengthens risk of failures described above, and cannot ensure that user is working with actual data.
"Business Semantics" is developed to avoid all these drawbacks and problems, allowing to set up model-independent data synzhronization in any number of applications, in online mode.
Advantages of Semantic Web technologies for data exchange
Using Semantic Web technologies for integration implies that all the data transferred between applications is encoded in semantic form (RDF triples). This makes transferred data completely independent of each system's internal data structure. RDF triple is a "statement", expressing information using some "dictionary", or ontology. Exchanging applications are sending and receving such messages using any available method. Business Semantics's task is to provide an exchange method, which allow to fully explore potential of Semantic Web technologies. Our software acts like an exchange bus (Enterprise Service Bus, ESB), connection applications in real-time mode. Information is transferred using customizable access rights and rules, set up by administrator. Business Semantics Server guarrantees robust exchange, manages ID assignement, restores information integrity etc. All these functions are creating our product's advantages listed below:
- It's easy to set up exchange between three, four or more applications simultaneously;
- Exchange is not breaking if data structure is changing in one of them;
- Developers or supporting personnel of each application are dealing only with their own, "native" application, disregarding other application's structures and formats;
- It is possible to establish interfacing between applications, having completely different "views" of the same objects, without writing huge amount of custom code;
- It is possible to create a unified data view in semantic form in SPARQL server. This view will provide unexcelled analytic features, that are impossible in any of source applications.