DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. Deployment
  4. Unboxing Software Integrations

Unboxing Software Integrations

It is important to follow the best practices in software integration to achieve quality. Look at 3 types of software integrations.

Lokesh Raj user avatar by
Lokesh Raj
·
Jan. 04, 19 · Opinion
Like (2)
Save
Tweet
Share
13.41K Views

Join the DZone community and get the full member experience.

Join For Free

Software Integration is one of the most common practices in all types of software platforms. Instead of reinventing the wheel, it is always recommended to integrate with the available robust and well-proven partner/component.

It is important to follow the best practices in software integration to achieve quality. Otherwise, there are chances of fragile integration leading to production issues.

I will be discussing 3 types of software integrations

  • Integration with third-party partners
  • Integration with third-party components
  • Integration between modules

Each one in the above list is different in nature. One common practice to follow is making it loosely coupled. The code related to integration should be abstracted from the main component or module.

Let’s understand a little more on the concept of loosely coupled in all of the integrations.

Integration With Third-Party Partners

Integration with third-party partners will have two-way communication with the consumer software system. In such cases, the logical architecture of consuming software system should have two components exclusively for the integration. One for the outgoing calls, it is called outbound, and another one for the incoming calls, it is called inbound.

Abstracting the integration code in consumer software system will avoid direct dependency with the integration partner. The communication between the two systems will involve various complexities like authentication, authorization, and other service communications. Such complexities must be separated from the core system and hand over them to outbound and inbound components. We will be achieving two design patterns here viz. Single responsibility and loosely coupling.

Integration With Third-Party Components

Similarly, the design principles like Single Responsibility and loosely coupling are also valid for the integration with third-party components.

Let’s take an example to understand this better. Software systems will use some third-party components or libraries like log4net to do application logging. In such scenarios, instead of directly referring the log4net library all over the places, it is important to put a wrapper (project/class) around that. All code related to application logging will be calling the wrapper project/class instead of the log4net library.

By doing this abstraction, application code is not directly dependent on Log4net library. In the future, it is an easy switch over from the log4net library to some other libraries.

Apart from log4net example, for other scenarios, the wrapper class gives the flexibility to add in more functionality in the overloaded method.

Integration Between Modules

This is one of the most often used integrations in all our software development. The software system will have many modules. The communication between the modules is a pretty common scenario. In such scenarios, avoid directly integrating another module function in multiple places. If we do so, it will create multiple direct dependencies on the integration module. Any change in the integration module method might impact all integration points in the consumer module.

The recommended approach is to have a wrapper class that coordinates the communication between the modules. All integration points in module 1 will always go through this wrapper class to communicate with Module 2 method.

As all integration points go through the single wrapper class/project, and it is possible to implement best practices like exception handling, instrumentation, and retry logic in a single place. It is better to integrate this wrapper class through an interface. This way, it is possible to support backward compatibility easily for the integration points, those who would want to use the old integrations.

All these benefits are applicable to all types of integrations explained above.

Dot Net core is one of the best examples for the design principles viz. single responsibility, abstraction, and loosely coupled. Dot Net core achieves this using dependency injection and CLEAN architecture. With the dependency injection, it abstracts the concrete class integration by injecting them at runtime using interface reference. Also, it achieves loosely coupling with concrete classes.

Using CLEAN architecture, the different layers like the Service, business, and infrastructure layers are not dependent on each other. Rather, all of them are dependent on the domain entity project, which is termed as the core of the project.

Also, it ensures all external communications like database, file system, and external services communication are grouped under “Infrastructure project.” It implies all external communication is isolated from all layers of the project. This way, the infrastructure project is made responsible to take care of the nitty-gritty things related to external communication.

Key takeaways for software integration:

  • It is highly recommended to isolate the code related to external communication in separate projects.
  • Put a wrapper for integrating any third party components or services integration.
  • Ensure there is proper data exchange document for any third party partner integration. This should be maintained for all subsequent updates. It will be the system of record for all the communications between two software systems.
  • Validate all incoming request data before proceeding further down the integration. If it does not match with data exchange specification document then abort it and return an appropriate error code.
  • Ensure all data interchange communication events are logged.

I have tried to list a few best design principles and best practices above for integrating third-party partners, components, and modules. These will make your software integration more smooth and flawless.

Integration Software system

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • What Is Policy-as-Code? An Introduction to Open Policy Agent
  • What Was the Question Again, ChatGPT?
  • Taming Cloud Costs With Infracost
  • The Importance of Delegation in Management Teams

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: