System-To-System Integration

Large organizations are increasingly faced with the need for systems integration, using a variety of mechanisms.  Some of the more common ones include:

• Database integration – one system writes values to a database, the second system reads them.  The databases may be transactional, or they may be data warehouses;

• Proprietary web services – using a tool like WebMethods, one system may provide a service (for example, an export of data) and the other system may call that service;

• Call integration – one system may export an interface, using SOAP or Java objects or J2EE session beans, that provides a service (for example, an export of data or invocation of an operation) and the other system may call that service;

• File sharing – one system writes values to a file, the second system reads them.  File integration is certainly open, but it has performance implications and is mostly used to integrate legacy applications;

• Memory mechanisms and queuing – one system writes to a queue or sets up data and a semaphore mechanism, the second system is alerted and responds accordingly.  This mechanism is tightly coupled and is most often used to integrate in a real-time environment.

These integration mechanisms are almost always coded and tested using traditional, manual programming methods. However, the architecture of each mechanism is subject to standardization and in fact all integration code that uses one of the above mechanisms should have a similar structure.

ResQSoft® offers an automated approach to meeting system-to-system integration requirements. We can automatically generate source code that fits these or other system integration models, and we can produce this kind of legacy system integration code within a single budget cycle, on a fixed price basis that is less than half of the normal cost of writing the integration code by hand, using our software development tool, ResQSoft™ Engineer, and our standard development process.

We welcome the opportunity to assess your organization’s integration needs. Our team can demonstrate how Engineer, combined with our rapid development methodologies, quickly resolves complex system requirements.

Avoid a Future Legacy Logjam

In the ’60s, ’70s and ’80s, we did not believe that we were writing legacy systems when we developed large business applications in COBOL.  Yet, that’s what happened.  So, how do you avoid creating another such situation?  What happens in four years if, for example, Java does not survive and Microsoft .NET is the new platform — or vice versa? Even these platforms evolve over time, leaving legacy applications in their wake.

Because our process is driven by a representation of your system that is platform independent, we can redevelop our templates for the new platform and you can regenerate the bulk of your system to the new standard using our technology AUTOMATICALLY!