User Tools

Site Tools


tanszek:oktatas:iss_t:software_integration

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
tanszek:oktatas:iss_t:software_integration [2026/02/15 21:53] – [Lock File Mechanism] kneheztanszek:oktatas:iss_t:software_integration [2026/02/15 22:18] (current) – [Data Sharing] knehez
Line 208: Line 208:
 ===== Data Sharing ===== ===== Data Sharing =====
  
-A simple approach to integration is data sharing. +A simple approach to integration is data sharing. Data sharing–based integration aims to transfer and share data between systems. This enables individual systems to access and utilize data stored in other systems.
- +
-Data sharing–based integration aims to transfer and share data between systems.  +
-This enables individual systems to access and utilize data stored in other systems.+
  
 Data sharing can take several forms: Data sharing can take several forms:
Line 222: Line 219:
 ===== File-Based Data Sharing ===== ===== File-Based Data Sharing =====
  
-The most fundamental method of data sharing. +The most fundamental method of data sharing. One application writes data, while another application reads data from the same file. The data files are stored in a central location — such as a shared folder (e.g., NFS) or an (S)FTP server. The information flow is unidirectional: A → B.
- +
-One application writes data, while another application reads data from the same file. +
- +
-The data files are stored in a central location — such as a shared folder (e.g., NFS)  +
-or an (S)FTP server. +
- +
-The information flow is unidirectional: A → B.+
  
  
Line 327: Line 317:
 process synchronization and coordination in file-based integration. process synchronization and coordination in file-based integration.
  
 +===== Limitations of File-Based Integration =====
 +
 +This method remains widely used today, but it has several significant disadvantages:
 +
 +  * The data sharing is not real-time. It is typically suitable for daily, weekly, or monthly batch data exchange. If data is modified between cycles — for example, if a customer changes their address — the invoicing application may still send the invoice to the old address because it receives the update only later.
 +  * It may become unreliable when transferring a large number of files (although tools such as rsync can help).
 +  * Successful integration requires that developers of both applications (in most cases) agree on and understand:
 +    - the file format
 +    - file naming conventions
 +    - file storage location
 +    - how file deletion is handled
 +    - the lock mechanism used
 +    - the file transfer method
 +
 +----
 +
 +===== Database-Based Data Sharing =====
 +
 +Database-based integration is a method that enables data sharing and synchronization between different systems directly through databases.
 +
 +In this approach, multiple applications and systems use either:
 +
 +  * a shared database, or
 +  * database replication
 +
 +to access and manage data.
 +
 +<mermaid>
 +flowchart LR
 +
 +    A[Application A]
 +    B[Application B]
 +    DB[(Shared Database)]
 +
 +    A <--> DB
 +    B <--> DB
 +</mermaid>
 +----
 +The same system with db replication:
 +<mermaid>
 +flowchart LR
 +
 +    A[Application A]
 +    C[Application C]
 +    DB1[(Primary Database)]
 +
 +    B1[Application B]
 +    B2[Application B]
 +    DB2[(Replica Database)]
 +
 +    A <--> DB1
 +    C <--> DB1
 +
 +    DB1 -- replication --> DB2
 +
 +    B1 <--> DB2
 +    B2 <--> DB2
 +</mermaid>
 +==== Example ====
 +
 +E-commerce platform and Warehouse Management System:
 +The e-commerce platform can be directly integrated with the warehouse database to provide real-time inventory information.
 +
 +==== Similarities to File-Based Integration ====
 +
 +  * Platform-independent connectivity (e.g., JDBC, ODBC)
 +  * Multiple instances of identical components may access the same database
 +    * Synchronization issue: Who processes the next record in the queue?
 +    * However, it can be an ideal solution for data collection scenarios.
 +
 +==== Limitations ====
 +
 +  * Not real-time by default. If one application writes to the database, another application does not automatically receive notification.
 +    * Possible solutions:
 +      * Database notification mechanisms (e.g., PostgreSQL LISTEN and NOTIFY)
 +      * Triggers
 +      * Polling mechanisms
 +  * Security considerations: Properly defined access rights are required (table access, permitted operations). Developers often restrict direct visibility of database structures.
 +  * Lack of well-defined interfaces — this approach provides only data-level integration.
 +
 +==== When to Use Database-Based Integration? ====
 +
 +Database-based integration is appropriate in the following scenarios:
 +
 +  * When multiple applications need direct access to the same structured data.
 +  * When strong transactional consistency is required.
 +  * When systems operate within the same organizational or security boundary.
 +  * When the data model is stable and well-defined.
 +  * When high-performance querying and reporting are necessary.
 +  * When database replication can support load balancing or read scalability.
 +
 +However, it may NOT be the best choice:
 +
 +  * In loosely coupled, distributed architectures (e.g., microservices).
 +  * When clear service-level interfaces are required.
 +  * When strict decoupling between systems is a design goal.
 +  * In highly scalable cloud-native environments where message-based communication is preferred.
 +
 +===== Integration Strategy Comparison =====
 +
 +^ Aspect ^ File-Based Integration ^ Database-Based Integration ^ Message Queue-Based Integration ^
 +| Coupling | Tight coupling (shared file format) | Tight to medium coupling (shared schema) | Loose coupling |
 +| Communication Style | Batch, unidirectional | Data-level sharing | Asynchronous message exchange |
 +| Real-Time Capability | No | Not by default | Yes (naturally asynchronous) |
 +| Scalability | Limited | Moderate | High |
 +| Monitoring | Difficult | Database-level monitoring | Built-in queue monitoring (DLQ, metrics) |
 +| Complexity | Low initial complexity | Medium | High |
 +| Transaction Support | No native support | Strong ACID support | Depends on message broker |
 +| Typical Use Case | Periodic data exchange | Shared enterprise systems | Distributed / cloud-native systems |
 +| Interface Definition | File format agreement | Shared database schema | Message contract / schema definition |
 +| Cloud-Native Suitability | Low | Medium | High |
  
tanszek/oktatas/iss_t/software_integration.1771192422.txt.gz · Last modified: 2026/02/15 21:53 by knehez