Your Partner for IT Integration
Whatever the trend of industry 4.0, whether SOA, Microservices, IoT, Big Data or digitization – they will all bring about even more data being exchanged between software systems in the future. But what kind of message exchange is future-proof? How can two or more applications be best integrated with one another? Or is a larger – possibly company-wide – integration architecture possibly more advantageous? Have I considered all technical aspects?
ConSol is your partner in all questions of IT integration – from a thorough requirements analysis of individual interfaces to the development of a company-wide integration architecture. In exactly this field, our experience grew wide over many years and with far more than 200 software systems connected. We will select the right system for your application. From our project practice, we know possible stumbling blocks and can help you to avoid them in the shortest time possible.
The ConSol Integration Solution
You do not yet have a precise idea of your integration architecture? Well, just use ours as a blueprint to reach your goal quickly. We recommend a microservice architecture & with open source tools like Spring Boot, Apache Camel, Freemarker, Kafka, Artemis and Zookeeper – cloud-native, of course. Based on this architecture, ConSol has developed more than 100 microservices, all in productive use with our customers. Around the clock, supervised by ConSol.
Keeping An Eye on Every Detail
Before an architecture can be operated successfully, numerous technical aspects must be clarified during requirements analysis and consistently implemented with up-to-date technologies. If you fail to see only one of the following details, the entire integration project might fail. Therefore, the design of ConSol’s solution architecture covers all these questions and services entirely.
Available Interfaces
Which interfaces do the systems to be integrated offer? Can information be pushed or does it have to be polled?
Message Format(s)
How do the messages to be exchanged look like? XML, JSON, plaintext, binary data, or proprietary protocols? Is message transformation from one format to another necessary?
Routing
To which target system is data forwarded? Is the routing static or dynamic based on the message content?
Security
What are the requirements? Is the communication encrypted? How is the sender authenticated? Is authorization necessary? Do incoming and outgoing messages need to be signed?
Dealing with Errors
Which error scenarios can occur in the systems involved and if errors occur, how should the system react? How are network problems handled? Should automatisms such as retries be used?
Network Topology
Are the systems located in the same or in different network zones? Which elements e.g. firewalls, routers, load balancers, proxies etc. are involved in the communication?
Performance
What are the requirements in terms of message size, total data volume, capacity, and latency?
Specification and Documentation
What is the scope of an interface specification – depending on the technology used? What does a perfect and maintainable documentation look like?
Central Middleware Software
Is a point-to-point connection with adjustments in the source or target system sufficient or is a central integration platform necessary? In case of the latter, is an integration product (e.g. ESB) or a lean individual solution recommended?
Versioning
Are interfaces continuously maintained? Can source and target systems always be installed parallelly in production or are all versions always downward compatible? Which other solutions do exist?
Maintenance and Operation
Which know-how is necessary for the later operation and support? Are there requirements with regard to monitoring, alerting and troubleshooting error scenarios?
Auditing
Do messages have to be recorded individually? How easily can they be tracked throughout the overall architecture? Are statistics related to desired KPIs?
Most Important Technologies Compared
Messaging, SOAP and REST web services – these are the methods we usually choose, depending on the application. The following table illustrates their strengths and weaknesses.
| SOAP Web Services | REST Web Services | Messaging | |
|---|---|---|---|
| Message Format | Native only XML | XML, JSON, Plaintext | XML, JSON, plaintext, binary data |
| Routing | 1-to-1 synchronous communication only | 1-to-1 synchronous communication only | Synchronous and asynchronous 1-to-1 communication possible |
| Security | TLS, basic and digest authentication, WSS | TLS, basic and digest authentication, JWT | Mostly native |
| Network Topology | Standard HTTP(S) | Standard HTTP(S) | Special protocols and ports (e.g. JWS) |
| Performance | Performance-intensive | Little performance overhead | Maximum capacity (if asynchronous) |
| Specification / Documentation | Defined specification language (WSDL) | Non-binding standards | No specification syntax specified |
| Software | Web server with SOAP endpoints | Standard web server is sufficient | Central broker and client libraries required |
| Maintenance and Operation | HTTP and XML know-how is sufficient | HTTP and XML know-how is sufficient | Product specialists needed |
Project Profiles
ConSol stands for technological excellence and practical expertise. We draw on three decades of cross-industry project experience – in medium-sized companies as well as in DAX corporations and with other heavyweights. We support you in important software architecture decisions and place your solution on a solid, future-proof foundation.
Technologies / Competences
![[Translate to English:] ConSol Labs](/fileadmin/images/monitoring/logo-consol-labs.gif "[Translate to English:] ConSol Labs"){kind=logo}
![[Translate to English:] Christian Wied](/fileadmin/images/Ansprechpartner/christian_wied.png "Christian Wied")