Quest Q and A Spring 2010 : Page 17
A DOzEn IBM i IntEgRAtIOn PAttERnS thAt YOuR I.t. SYStEMS ShOuLD BE ABLE tO WORk WIth noThing fruSTraTeS erP uSerS more Than DuPliCaTe DaTa enTry, miSmaTCheD DaTa anD laCk of aCCeSS To neeDeD informaTion. The PurPoSe of SySTem inTegraTion iS To avoiD TheSe iSSueS anD enSure SmooTh running buSineSS ProCeSSeS aCroSS mulTiPle SySTemS. To Do ThiS, an i.T. DeParTmenT neeDS To be armeD WiTh inTegraTion anD buSineSS ProCeSS managemenT ToolS ThaT Can reCognize all of The neeDeD inTegraTion PaTTernS for your environmenT. If you are running applications on IBM i for Power Systems including AS/400, iSeries and System i, then your systems are in a unique and powerful environment that requires special integration capabilities. IT managers overseeing an IBM i-based I.T. environment well understand the advantages of IBM’s midrange platform: excellent middleware, superior scalability, top-level security, superior reliability and resilience, and straightforward operations and storage management. For some years, however, IBM and the IBM i user community seem to be on different tracks when it comes to application development and integration. Every few years, IBM introduces a new approach that never fully takes hold in the user community: Java and PHP are the most obvious examples when it comes to application modernization. Various iterations of the WebSphere brand come to mind when EAI and BPM requirements have been in focus. This has created a layering of application logic capabilities and integration modes between legacy RPG and COBOL and newer approaches to development and integration that some might even call a fracturing of business logic. Add to this the normal application integration disparities inherent to every platform and you find challenges in identifying optimal integration patterns for IBM i. Each application, whether a home-grown application or an off-the-shelf application such as JD Edwards, will typically present a number of unique integration patterns of its own. The IBM i operating system or platform provides a rich variety of integration patterns that can be used for various aspects of an integration project. We take time here to identify available IBM i integration patterns and consider the strengths, weaknesses and best-use of each approach. Our Table of IBM i Integration Patterns identifies twelve important integration requirements for IBM i. At a high level, these requirements address unique needs for composite business processes and application logic through remote procedure calls, capabilities for system level commands, attribute string manipulation, access to the user space, manipulation of the data queue, access to spool files, working with IFS Objects, working with Java, database access (DB2400 and SQL databases), multi-platform integration, Web services and other requirements. Reduce the Level of Coupling. The integration patterns that you ultimately select will be based on a number of considerations including available patterns, technical knowledge, and access to metadata. Ideally, the decision should also be driven by an evaluation of the level of coupling that takes place between the components to be integrated. Loose coupling is desirable because it means that there is less interdependency between any two elements -- a change in one component is less likely to require a change in the other. Next Steps. Existing patterns for IBM i integration will ideally support as many of these patterns as possible while providing an EAI and BPM orchestration architecture that allows for loose coupling. For our FREE White Paper, Twelve IBM i Integration Patterns That You Should Be Prepared to Access, Manipulate and Control, click here or find other resources at www.magicsoftware.com. 17
Magic Software
a Dozen ibm i integration PatternS that your i.t. SyStemS ShoulD be able to Work With
NoThing fruSTraTeS erP uSerS more Than DuPliCaTe DaTa enTry, miSmaTCheD DaTa anD laCk of aCCeSS To neeDeD informaTion. The PurPoSe of SySTem inTegraTion iS To avoiD TheSe iSSueS anD enSure SmooTh running buSineSS ProCeSSeS aCroSS mulTiPle SySTemS. To Do ThiS, an i.T. DeParTmenT neeDS To be armeD WiTh inTegraTion anD buSineSS ProCeSS managemenT ToolS ThaT Can reCognize all of The neeDeD inTegraTion PaTTernS for your environmenT.
If you are running applications on IBM i for Power Systems including AS/400, iSeries and System i, then your systems are in a unique and powerful environment that requires special integration capabilities. IT managers overseeing an IBM i-based I.T. environment well understand the advantages of IBM’s midrange platform: excellent middleware, superior scalability, top-level security, superior reliability and resilience, and straightforward operations and storage management. For some years, however, IBM and the IBM i user community seem to be on different tracks when it comes to application development and integration. Every few years, IBM introduces a new approach that never fully takes hold in the user community: Java and PHP are the most obvious examples when it comes to application modernization. Various iterations of the WebSphere brand come to mind when EAI and BPM requirements have been in focus. This has created a layering of application logic capabilities and integration modes between legacy RPG and COBOL and newer approaches to development and integration that some might even call a fracturing of business logic. Add to this the normal application integration disparities inherent to every platform and you find challenges in identifying optimal integration patterns for IBM i. Each application, whether a home-grown application or an off-the-shelf application such as JD Edwards, will typically present a number of unique integration patterns of its own.
The IBM i operating system or platform provides a rich variety of integration patterns that can be used for various aspects of an integration project. We take time here to identify available IBM i integration patterns and consider the strengths, weaknesses and best-use of each approach. Our Table of IBM i Integration Patterns identifies twelve important integration requirements for IBM i. At a high level, these requirements address unique needs for composite business processes and application logic through remote procedure calls, capabilities for system level commands, attribute string manipulation, access to the user space, manipulation of the data queue, access to spool files, working with IFS Objects, working with Java, database access (DB2400 and SQL databases), multi-platform integration, Web services and other requirements.
Reduce the Level of Coupling. The integration patterns that you ultimately select will be based on a number of considerations including available patterns, technical knowledge, and access to metadata. Ideally, the decision should also be driven by an evaluation of the level of coupling that takes place between the components to be integrated. Loose coupling is desirable because it means that there is less interdependency between any two elements -- a change in one component is less likely to require a change in the other.
Next Steps. Existing patterns for IBM i integration will ideally support as many of these patterns as possible while providing an EAI and BPM orchestration architecture that allows for loose coupling. For our FREE White Paper, Twelve IBM i Integration Patterns That You Should Be Prepared to Access, Manipulate and Control, click here or find other resources at www.magicsoftware.com.
Publication List
