1 / 49

No Integration Without Tiers

No Integration Without Tiers. Brock Shaw Torridon Associates. Objective. To look at the opportunities for distributed application integration using IDMS. Consider the alternative strategies available and where these should be used.

orsin
Télécharger la présentation

No Integration Without Tiers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. No Integration Without Tiers Brock Shaw Torridon Associates

  2. Objective • To look at the opportunities for distributed application integration using IDMS. • Consider the alternative strategies available and where these should be used. • Examine the three most common protocols from the designer and the programmers perspective.

  3. Topics • What is Integration • What are the technology options • Issues of integration • SQL Call interfaces (ODBC/JDBC) • Message Queue Processing (MQ) • Program to Program interfaces (TCP/IP) • Summary

  4. No Integration without Tiers Client Server Mainframe Midrange

  5. Types of Integration Client Server Mainframe Midrange

  6. SQL Level (Client) Client Server ODBC Mainframe Midrange

  7. SQL Level (Server) Client Server Internet ODBC Mainframe Midrange

  8. Transaction Streams Client Server Posting Transactions AppA AppB Mainframe Midrange

  9. Program to Program Client Server Send & Receive PrgA PrgB Mainframe Midrange

  10. Program to Program Client Server PrgA PrgB Mainframe Midrange

  11. Program to Program Client Server PrgA PrgB Mainframe Midrange

  12. The Integrated IT World Client Server Mainframe Midrange

  13. The Technology Available • ODBC • JDBC • MQ Series • LU6.2 • TCP/IP • SNA • VTAM   

  14. ODBC/JDBC • “Open” protocol for real-time DB access • ODBC built as general SQL access tool • JDBC equivalent for Java • Windows or J2EE support • The Calling Program issues an SQL request • Request is linked to a “Data Source” • Response from request as normal SQL • Synchronous

  15. MQ Series • A Message • A Message Queue (Named Entity) • Initiating task “Pushes” message on queue • MQ Software handles all delivery issues • Receiving task “Pops” message from queue • Asynchronous (usually)

  16. TCP/IP • Compare APPI and LU6.2 • TCP/IP and sockets are simpler • Initiating task connects and sends • Receiving task confirms and receives • Message is internally free-format • Receiver unrestricted in message handling • Synchronous or Asynchronous

  17. Issues for Design • Synchronicity • Real-time vs Pseudo-converse • Processing latency • Recoverability • Coordinating Commits • Process efficiency

  18. ***Design Case 1***SQL Processing • Program seeks to have direct access to a DB through an SQL command. • Single record processing • Multi-record processing • Efficiency requires maximising each call • What is the call really accessing

  19. SQL Request Architecture • All calls are based on Dynamic SQL

  20. Non-SQL IDMS using SQL Define SQL version of the network schema Take a non-SQL record e.g. CUSTOMER Create SQL Select CREATE SCH CREATE SCHEMA sqlname FOR NONSQL SCHEMA disctnam2.schmname; SELECT * FROM customer WHERE customer_id = “ABC Corp”;

  21. Maximising SQL Power • Design access for probable need • Minimise number of calls for a process • Make access efficient for non-SQL • Normal database efficiency issues • Avoid non-SQL by going Network

  22. Table Procedures and QuickBridge • Define a Table Procedure • Receiving Program Parameter List CREATE TABLE PROCEDURE schmname.table_name ( <normal table element definitions> ); IDENTIFICATION Division . . . PROCEDURE DIVISION USING <same list of element definitions> . . . .

  23. Table Procedure Logic SQL Request QuickBridge template (USING parameter list) BIND RUN-UNIT . . . OBTAIN … . . . FINISH Virtual Table

  24. IDMS Server Architecture Data Source

  25. Designing Transactions • Minimise SQL calls • Preload data where possible • Minimise setup times • Make Table Procedures to handle DML • Ensure SQL compatibility of the network schema

  26. Programming Concerns • Each environment has a protocol to package an SQL call for the ODBC processor. • Call, class method or graphical • Simple SQL handled within IDMS • Table procedure template (QuickBridge) • Error response of a Table Procedure must match that of a real SQL call

  27. ***Design Case 2*** Transaction Streams • This is like feeding a batch process • One message at a time • Where is it likely to be found? • Not time critical (i.e. synchronous) • Pushing a message onto a queue • Popping a message off a queue • Asynchronicity

  28. MQ Architecture App A Message Local Queue Message Message Message Message Message Message MQ Routing Information Message Message Message Remote Queue Message Message Message Message App B Message

  29. MQ Calls The calls in the MQI can usefully be grouped as follows: | MQCONN, MQCONNX, and MQDISC | Use these calls to connect a program to (with or without | options), and disconnect a program from, a queue manager. Writers of CICS for MVS/ESA programs or OS/400 programs do not need to use these calls. However, you can use them if you want your application to be portable to other platforms. MQOPEN and MQCLOSE Use these calls to open and close an object, such as a queue. MQPUT and MQPUT1 Use these calls to put a message on a queue. MQGET Use this call to browse messages on a queue, or to remove messages from a queue. MQINQ Use this call to inquire about the attributes of an object. MQSET Use this call to set some of the attributes of a queue. You cannot set the attributes of other types of object. | MQBEGIN, MQCMIT, and MQBACK | Use these calls to start and commit a global unit of work (where | coordination is performed by MQSeries) and indicate to the queue | manager that all messages put or retrieved as part of a unit of | work since the last syncpoint are to be backed out. The MQI calls are described fully in the MQSeries Application Programming Reference manual.

  30. Programming MQ MOVE MQMT-REQUEST TO MQMD-MSGTYPE. MOVE MQCI-NONE TO MQMD-CORRELID. MOVE MQMI-NONE TO MQMD-MSGID. MOVE W02-TEMPORARY-Q TO MQMD-REPLYTOQ. MOVE SPACES TO MQMD-REPLYTOQMGR. MOVE 5 TO MQMD-PRIORITY. MOVE MQPER-NOT-PERSISTENT TO MQMD-PERSISTENCE. COMPUTE MQPMO-OPTIONS = MQPMO-NO-SYNCPOINT + MQPMO-DEFAULT-CONTEXT. MOVE LENGTH OF CSQ4BIIM-MSG TO W03-BUFFLEN. * CALL 'MQPUT' USING W03-HCONN W03-HOBJ-INQUIRY MQMD MQPMO W03-BUFFLEN W03-PUT-BUFFER W03-COMPCODE W03-REASON. IF W03-COMPCODE NOT = MQCC-OK

  31. MQ and DC MQ IDMS-DC Prg 1 Prg 2

  32. MQ and DC MQ IDMS-DC DCMQ Handler Prg 2 Prg 1

  33. MQ and UCF/CICS IDMS-UCF MQ CICS CICSMQ Handler

  34. MQ and DC Queues IDMS-DC MQ Batch DC GET QUEUE . . . PUT QUEUE MQPUT DCRUN

  35. Issues of MQ • Audit issues (Did message arrive?) • Commit issues (like 2PC) • MQ has robust error handling • “Somebody Else’s Problem” • Asynchronicity

  36. ***Design Case 3*** Program to Program • Two co-operating processes • Really more like peer to peer • Passing data or messages • Using data to trigger secondary processes • Getting feedback on results • Each process operates within its own view • Problem: coordinating recovery

  37. TCP/IP Architecture Linux TCP/IP Socket API Task A Port 1 Task B Port 2 CICS … … IDMS Advantage CA-IDMS region

  38. Functional View Initiator Listener Process A Process B Create socket Bind Listen

  39. Functional View Initiator Listener Process A Process B Create socket Connect Accept Send Receive Receive Send Close Close

  40. Pseudo Conversations Initiator Listener Process A Process B Create socket Connect Accept Send Receive (Setup Listener) Close (Process data)

  41. Pseudo Conversations Listener Initiator Process A Process B Create socket Connect Accept Send Receive Close Close (Process data)

  42. Its Good to Talk • Where application programs talk directly • Functional orientation • Synchronicity • Pseudo-conversations • Interface independent of data structure • Recovery and commit issues

  43. Programming TCP/IP IF ( SOCKET( SOCKET-FUNCTION-WRITE SOCKET-RETCD, SOCKET-ERRNO, SOCKET-RSNCD, SOCKET-LISTENER-SOCKDESC, BUFFER-ARRAY(WK-SUBSCRIPT), WK-LENGTH, RETLEN) NE 0) THEN DO. WRITE TO LOG MESSAGE TEXT = 'TCPADSL1: WRITE ERROR'. CALL TCPERROR. CALL TCPCLOSE. LEAVE ADS. END.

  44. Best Solution Examples? • Windows app wants to check stock level • Web app wants to do a complex update • Updates need to be applied to other DB • Access to “foreign” system required • Load balancing required for back-end • Cooperating processes - different platforms

  45. Choice of Technology • Horses for courses • Define the applications requirements: • Platforms involved • Best platform for a function • Synchronicity requirements • Latency tolerance • Recoverability • Platform synchronisation (like 2PC)

  46. Objectives Revisited • To look at the opportunities for distributed application integration using IDMS. • Consider the alternative strategies available and where these should be used. • Examine the three most common protocols from the designer and the programmers perspective.   

  47. Conclusion Client Server IDMS will survive only if it works well in this context! This is our IT World! Mainframe Midrange

  48. Conclusion Client Server If we don’t embrace these changes, the IT world may just look like this. Midrange

  49. Questions ?

More Related