Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

S424. Soa Mainframe Practices Best And Worst

1,877 views

Published on

User experience presentation at the 2011 GSE Nordic Conference in Stockholm

  • Thought-provoking post . Just to add my thoughts , if your company is wanting a a form , my business filled a fillable document here https://goo.gl/cpG5XD.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

S424. Soa Mainframe Practices Best And Worst

  1. 1. S424. Mainframe Service Architecture and Enablement Best and Worst Practices • Michael Erichsen, Chief Consultant, CSC • Stockholm, 8 June 2011CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 0
  2. 2. Main points• Why are we doing this? – We have done integration projects in decades – Service orientation can be a qualitative improvement – The new aspect is open, standardized, loosely coupled interfaces• Best practices are mostly found in the technicalities of service enablement – Case studies of seven different ways of doing it• Best and worst practices are found in the service modelling and in the implementation of models and architectures – Some principles and patterns based on best practices – Worst practices illustrated by ”anti-patterns” and research in what can go wrong and how CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 1
  3. 3. A Conceptual, Technical View of Service Enablement CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 2
  4. 4. A Conceptual, Modelling View of Service Enablement CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 3
  5. 5. SOA Mainframe Practices – Best and Worst To Begin with the ConclusionCSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 4
  6. 6. Why are we doing this?Which problems are we trying to solve? • The world is fast and messy • Businesses and authorities need to adapt very quickly to survive • IT systems are generally heterogeneous • It is a mess - and it will remain so • Service interfaces hope to remove some of the mess – but also introduce new kinds of mess CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 5
  7. 7. Reuse?Oh no, not again! • Software reuse is the process of creating software systems from existing software rather than building software systems from scratch • First proposed in 1968 • Four dimensions: – Abstraction – Selection • Classification • Retrieval • Exposition – Specialization – Integration CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 6
  8. 8. Reuse?Promises, promises, promises…• Over time – Component Libraries with automated customization – Cut and paste of COBOL code – Application Generators – Object orientation – Frameworks – Service interfaces• Reuse is not a technology, but a culture – Why not reward for reuse and reusability? • Otherwise a vendor might earn more money by not reusing CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 7
  9. 9. Overarchitecting and Overengineering• You need an enterprise architecture, an enterprise data model and good business process descriptions to get the full business and economic advantage of such a project• Reuse depends on a higher level of abstraction – But too many levels of abstraction could mean that you can’t use it at all in the first place CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 8
  10. 10. Extending or replacing Mainframe systems? • The mainframe platform is continuously under siege – IBMs monopoly makes it difficult to forge alliances – The only practical solution to the age problems seems to be offshoring – The best way to protect the big investments in mainframe systems is to open them as equal partners in modern architectures • Not COBOL or Java/.Net, but strategy and interfaces – Using zSeries for SOA Infrastructure interesting, but not unproblematic CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 9
  11. 11. The real economy of zIIP’s and zAAPs• MIPS come cheaper, but they are certainly not free – Processor costs – Other operation costs• Investment in real storage – Much more expensive than other memory hardware – Java Virtual Machines need very large heap sizes for many applications, including SOA infrastructure like ESB’s and BPMS’es – Memory overcommit perhaps only 1,5 on new workloads?• Calculate economy very carefully to compare with other platforms CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 10
  12. 12. SOA Mainframe Practices – Best and Worst Lewis et al, SEI-CMM: SMART: The Service- Oriented Migration and Reuse TechniqueCSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 11
  13. 13. SMART: Defining a service• A service is a coarse-grained, discoverable, and self-contained software entity that interacts with applications and other services through a loosely coupled, often asynchronous, message-based communication model – Quoted from Brown et al, Rational: Using Service-Oriented Architecture and Component-Based Development to Build Web Service Applications CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 12
  14. 14. SMART: Defining a SOA – A SOA is a collection of services with well-defined interfaces and a shared communications model. A system or application is designed and implemented to make use of these services • 1. Service interfaces are added to existing enterprise information systems for applications to use, while these systems remain unchanged for internal users • 2. Service-specific code is written to provide functionality for applications to use • 3. Services written by third parties and deployed elsewhere are used within applications. – SOAs also offer the promise of enabling existing legacy systems to expose their functionality as services, without making significant changes to the legacy systems themselves • This is one of the most attractive features of SOA to many organizations that do not wish – and cannot afford – to walk away from their investment in legacy systems or redevelop the same capabilities as services from scratch CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 13
  15. 15. SOA Mainframe Practices – Best and Worst Technical Best Practices: Seven Case StudiesCSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 14
  16. 16. Seven Case Studies1. A Tactical Service Enablement2. A Tactical Service Enablement Evolving into Strategy3. COBOL IMS in a large Scale SOA Environment4. International, multilateral, heterogeneous and data replicating5. XML Services over MQ6. WebSphere ESB on z7. Service Enablement of a Legacy Application Generator System CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 15
  17. 17. Case #1: A Tactical Service Enablement• Back end system – VSE, CICS, a 4GL and a non-relational data base• The business need – Update requests from business partners used in nightly batch runs • No requirement for online updates of the mainframe system • Web Services a mandatory protocol for communication – Security required using TLS and X.509 certificates – Not a general interface to the entire system, but a tactical solution for a single demand• Technical challenges • VSE native SOAP and XML features did not really work for us • No cryptographic hardware on the VSE box CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 16
  18. 18. Case #1: The SolutionThe easiest solution was touse a WebSphereApplication Server onWindowsDaily updating Web Servicerequests from partnersWeekly master data extractsfrom mainframe for eachpartnerQuarterly and semi-annuallycontrol data extracted bymainframe CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 17
  19. 19. Case #2: A Tactical Service EnablementEvolving into a Strategic Solution after a successfulProof-of-Concept• Back end system – An ”i-Case” tool generating COBOL in CICS at the back end and a fat Java client at the front end with required runtimes and a proprietary communication layer – A generic callable interface to the application was already in place• The business need – Online updates from business partners’ own systems – Web Services a mandatory protocol• Technical challenges – Operation and field names had to be mediated between existing WSDL- standard and COBOL restrictions CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 18
  20. 20. Case #2: TechnicalSolutionCICS Web Support (now supersededby Web Services for CICS)An existing COBOL adapter to thecase tool generated code had to bemodified to a dynamic wrapperMapping definitions hand crafted CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 19
  21. 21. Case #2: A Proof of Concept• A Proof of Concept was designed to explore possible problems like how does – Complexity and verbosity of the mandatory XML dialect fit with the tools available? – Internal security fit with this channel of connections? – Digital certificates work in real life in this configuration? – Service Enablement tools fit with exiting interfaces? – Data from different parts of the back end system match to build a meaningful response?• The customer provided the XSD-definitions• CSC built the adapter modules based on these and on the existing structures in the legacy system CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 20
  22. 22. Case #2: Interface Design• Discrepancies between XML data concepts and COBOL data concepts had to be solved• In real life it seems that no interface contract is perfect• Data was defined in DB2, in COBOL, and in XML• Optional and Variable Fields (0..1) (0..n) (0..*)• Strings CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 21
  23. 23. Case #2: COBOL and XML DefinitionsType COBOL XMLString PIC X() StringFloat COMP-1 FloatDouble COMP-2 DoublePacked decimal COMP-3 DecimalBinary COMP-4 Long, short, intDate PIC X(10) in the application, 2000-01-12 Content: 20061016 2000-01-12T12:13:14Z 2000-03-04T23:00:00+03:00 CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 22
  24. 24. Case #2: COBOL and XML Field ExamplesField COBOL XMLa 9(8) Dateb S9(5) unsignedInt totalDigits value="5"c S9(11) COMP-3 Decimal totalDigits value="11" fractionDigits value="2"d S9(10) Double maxInclusive value="9999999999"e x(30) String maxLength value="30"f S9(8) unsignedInt totalDigits value="8"g S9(4) String pattern value="[0-9]{4}"h S9(10) Double maxInclusive value="9999999999" CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 23
  25. 25. Case #2 Version 2:Back End Modernized,Interface SimplifiedOngoing project to migrate casetool to runtime-free COBOL andJava to be maintained in RationalDeveloper for z (RDz)Back end web service interfacecreated bottom-up fromgenerated COBOL code usingRDzProprietary client communicationcode changed to Web Servicesfor CICSFront end client communicationusing Web Services over HTTPSwith generated communicationcode adapted to the WS4Cformat CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 24
  26. 26. Case #3: COBOL IMS in a large scaleSOA Environment – Back end system • Large IMS COBOL system – The business need • Modernizing the entire heterogeneous enterprise portfolio based on SOA integration and supporting a large number of protocols and formats • Service enabling IMS systems with DB2 data bases – Technical challenges • Reusing existing web enablement skills and technology • The new enterprise architecture regards all components on all platforms as both service providers and service providers – Must support both ingoing and outgoing Web Services requests CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 25
  27. 27. Case #3: The SolutionSimple interface to IMSapplicationsReusing large application”motors”OTMA (Open TransactionManager Access)IMS ConnectWebSphere ApplicationServer with the AXISframeworkAlso coding new, outgoingWeb Services requests fromIMS COBOL applications CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 26
  28. 28. Case #3: The challenges – There are limits on the protocol of 400.000-500.000 bytes – Legacy applications used screen oriented logic • Handled by adding new logic on top of legacy applications – Existing web enablement coded in Visual Age for Java using the now obsolete Record Framework – Advantages • The continuing existence of many skilled programmers and designers with deep business knowledge • Experience from an existing, well performing, and very successful web interface to the IMS and DB2 systems CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 27
  29. 29. Case #4: International, Multilateral,Heterogeneous and Data Replicating• Back end system – An IMS DB2 MQ system• The business need – International, multilateral exchange of data, going from data base replication to a service oriented architecture• Technical challenges – Many different data types with big variances – Large binary data items – Consistency checking between central and national data bases CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 28
  30. 30. Case #4: The OriginalSolutionA Web Services Gatewayimplemented as a simpleservlet on WebSphereApplication Server on zMQ communication with IMSCOBOL programs handlingXML and Unicode, storingdata in DB2Consistency checks becametoo complicated and toodifficult to make wellperformingLocal data base solutionsuperseded by direct servicerequests to the centralsystem CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 29
  31. 31. Case #4: Taming the CPU Hog• Technical Challenges – IMS COBOL XML Unicode program was originally coded only for functionality using XML PARSE, not for performance – It used vast amounts of CPU – A code review did not show anything unsound – Transactions were profiled using Compuware STROBE to split CPU-usage into handling of MQ, XML, Unicode and DB2 CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 30
  32. 32. Case #4: Untuned system0.50 CPU-second per transactionMODULE SECTIONNAME NAME PROCEDURE/FUNCTION NAME CPU TIME Interpretation Runtime Storage.LELIB CEEBINIT CEEVGTSI GET A STACK INCREMENT 51.91 allocation IGZCHXP COBOL LIBRARY.COBLIB IGZCPAC SUBROUTIN 31.69 XML CEEVOGTS XTND USR STK/DSA Runtime Storage.LELIB CEEBINIT OPLINK 7.10 allocationCUNMUNI 1.64 Unicode.SVC SVC 228 USER SVC 1.64 IMS CEEVOGSX XTND USR STK/DSA Runtime Storage.LELIB CEEBINIT OPLINK 1.09 allocationRPS000 .55 The ProgramRPS000 .55 The Program System Storage.SVC SVC 120 GETMAIN/FREEMAIN .55 allocation.SVC SVC 013 TERMINATION .55 System CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 31
  33. 33. Case #4: COBOL Working Storage Reduced1M to 100K0.06 CPU-second per transactionMODULE SECTION CPUNAME NAME PROCEDURE/FUNCTION NAME TIME Interpretation CEEVGTSI GET A STACK Runtime Storage.LELIB CEEBINIT INCREMENT 36.17 allocation IGZCHXP COBOL LIBRARY.COBLIB IGZCPAC SUBROUTINE 31.91 XML CEEVOGTS XTND USR STK/DSA Runtime Storage.LELIB CEEBINIT OPLINK 10.64 allocation.XES IXLR1ALR ALTER W/RECORD REQUEST 4.26 SysPlex Services (DB2) System Storage.SVC SVC 120 GETMAIN/FREEMAIN 4.26 allocation.SVC SVC 013 TERMINATION 2.13 System.NUCLEUS CSVEXPR CONTENTS SUPERVISION 2.13 System CEEVOGSX XTND USR STK/DSA Runtime Storage.LELIB CEEBINIT OPLINK 2.13 allocation.DB2 DSNIDM DATA MANAGEMENT DRIVER 2.13 DB2.COBLIB IGZCPAC IGZCVMO VARIABLE LENGTH MOVE 2.13 COBOL Move CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 32
  34. 34. Case #4: Further tuning of LE/370Measurements from the LE/370 Storage Report Before After • The important parameter is “Number of segments allocated:”,Initial stack size: 131072 1048576 which should be 0 or 1Increment stack size: 131072 102400 • Used parameters after tuning:Largest used by any thread: 1010896 1007944Number of segments •ALL31=(ON),allocated: 3 1 STACK=(1M,100K,ANYWHERE, KEEP,512K,128K),Initial heap size: 32768 921600 HEAP=(900K,128K,ANYWHERE,Increment heap size: 32768 131072 KEEP,512K,128K),Total heap storage used(sugg. initial size): 818184 818152 ANYHEAP=(32K,8K,ANYWHERE,Number of segments KEEP),allocated: 2 1 STORAGE=(NONE,NONE,NONE,Initial anyheap size: 16384 32768 0K)Increment anyheap size: 8192 8192Total heap storage used(sugg. initial size): 25648 26456Number of segmentsallocated: 2 1 CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 33
  35. 35. Case #4: Language Environment Parameters Tuned0,03 CPU-second per transactionMODULE SECTIONNAME NAME PROCEDURE/FUNCTION NAME CPU TIME Interpretation IGZCHXP COBOL LIBRARY.COBLIB IGZCPAC SUBROUTINE 46.15 XML.COMMON .COMMONX EXTENDED COMMON AREA 7.69 System CSQQSTUB QUIESCE AFT SYS LOGRPS000 .MQSRIES ERR 5.13 MQCUNMUNI 00D1C0 5.13 Unicode.SVC SVC 013 TERMINATION 5.13 System.DB2 DSNXGRDS RDS ACCESS MODULE GENER 5.13 DB2.DB2 DSNIDM DATA MANAGEMENT DRIVER 5.13 DB2.DB2 DSNGEDM DATA MGT DBD/SKCT RTNS 5.13 DB2RPS000 RPS000 00B380 2.56 The Program.SVC SVC 228 USER SVC 2.56 System CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 34
  36. 36. Case #5: XML services over MQ• Back end system – A merger has created a heterogeneous environment with CICS systems, IMS systems and Wintel systems• The business need – A very big SOA program aims at having a new midrange industry system as the front end and gradually replacing the legacy systems – Service enabling CICS systems• Technical challenges – Generic callable interfaces to CICS and IMS systems are already in place – MQ has been the integration channel for CICS and IMS for a number of years – The enterprise service bus is implemented as Microsoft Biztalk • Tools do not support SOAP over MQ, but SOAP over HTTP and XML over MQ CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 35
  37. 37. Case #5: The SolutionA modified Web Services forCICS implementationReuse existing Biztalk toolingUse RDz tooling to generateWSBIND files for the existingcallable interface CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 36
  38. 38. Case #5: Pipeline Config File<?xml version="1.0" encoding="EBCDIC-CP-DK"?><provider_pipeline xmlns="http://www.ibm.com/software/htp/cics/pipeline" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.ibm.com/software/htp/cics/pipeline provider.xsd "> <service> <service_handler_list> <handler> <program>CSCHDL01</program> <handler_parameter_list /> </handler> </service_handler_list> <terminal_handler> <cics_soap_1.1_handler/> </terminal_handler> </service> <apphandler>DFHPITP</apphandler></provider_pipeline> CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 37
  39. 39. Case #5: Dummy SOAP Header Handler ProgramGET CONTAINER(PI-DFHFUNCTION)IF PI-RECEIVE-REQUEST THEN GET CONTAINER(PI-DFHREQUEST) Remove existing <?XML tag Add a dummy SOAP envelope around the payload PUT CONTAINER(PI-DFHREQUEST) DELETE CONTAINER(PI-DFHRESPONSE)ELSE IF PI-SEND-RESPONSE THEN GET CONTAINER(PI-DFHRESPONSE) add <?XML tag Test each tag in Response-Data to find if it starts with <soap or </soap and then remove PUT CONTAINER(PI-DFHRESPONSE) Move "text/xml" to MEDIATYPE-DATA PUT CONTAINER(DFHMEDIATYPE) CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 38
  40. 40. Case #6: WebSphere ESB on z• Back end system – An IMS COBOL MQ system• The business need – Integration between applications on z, Oracle/Unix and Wintel using Web Services and MQ• Technical challenges – The need for real storage is much larger for JVM’s than for traditional workload – Recycling JVM’s costs hundreds of MIPS in quite extended periods • Even though most of it is offloaded to z**P processors • Z**P processors are not free either CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 39
  41. 41. Case #6: WebSphereESB on z ChallengesAfter a long quiet night thefirst transactions in themorning could take minutescausing client timeoutsDifficult to monitor –compared to CICS, IMS, MQetc.Workload Manager policiesquite complicated CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 40
  42. 42. Case #7: Service Enablement of a LegacyApplication Generator System• Back end system – CICS, DB2, originally coded in the 4GL CSP• The business need – A 20 year old legacy application still represents the core of the business and a long-term investment – Back office and staff can use web and cloud applications, which need access to the core system and its data, both inquiries and updates• Technical challenges – The application was coded in CSP and still has a 3270 user interface CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 41
  43. 43. Case #7: The SolutionWeb Services for CICSdeveloped using EGL toolingin Rational BusinessDeveloper (RBD) and RDzThe first service was used bya web form CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 42
  44. 44. Case #7: The SolutionWeb Services for CICSdeveloped using EGL toolingin Rational BusinessDeveloper (RBD) and RDzThe first service was used bya web formThe second service wasused by a Salesforce cloudapplication The integration from Salesforce was done using a Cast Iron SOA appliance CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 43
  45. 45. Case #7: The Solution• The first service with a single operation just updated a single field in the core data base – The front end is a simple web form, which calls a web service – Very easy to implement – took 20 minutes to code and generate• The second service with half a dozen operations ran into all kinds of technical problems CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 44
  46. 46. Case #7: Modelling the Service• Describe the existing user interaction with the 3270 application• Model this as a business process• Describe the operations needed in the new service to support this process• Define the programs needed to implement the operations and the interface as message structures CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 45
  47. 47. Case #7: Restrictions when developingWeb Services for CICS• If you need to have a structure as a response from an EGL Web Service for CICS the request must be the same structure (Input == output)• A configuration file called the “deployment descriptor” must not have the same name as any EGL program – RBD will quietly generate a COBOL program with the name of the deployment descriptor to overwrite the legitimate program just in case you also wanted to have an outgoing web services request• The predecessors to EGL were COBOL-like in their structures and culture, while EGL is java-like in its structures and culture – This difference can lead to great difficulties when service enabling legacy programs CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 46
  48. 48. Case #7: Restrictions when developingWeb Services for CICS• Do you have arrays in the externally exposed structure definition in the service programs? – Then the structure needs to be an unstructured record to have arrays generated correctly into the WSDL document – The field definitions must not be preceded by level numbers • Otherwise the array will be “flattened” with all occurrences of each subfield • {a1 a2 a3 b1 b2 b3 c1 c2 c3} in stead of {a1 b1 c1 a2 b2 c2 a3 b3 c3} – Note that unstructured records are dynamic • If you do not allocate them yourself they will be empty or even null CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 47
  49. 49. Case #7: Restrictions when developingWeb Services for CICS• A static array like this: 01 MYARRAY ARRAYRECORD[10]; Is allocated in storage like a COBOL program would• A dynamic array, distinguished by not having level numbers: myArray arrayRecord[10]; Is not allocated, but must be explicitly defined to avoid null pointers• EGL generation for COBOL does not support multidimensional, dynamic arrays• All this is not considered an error, but a design, by IBM, even though it is deeply unintuitive for a legacy programmer CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 48
  50. 50. Summing up the case studies• Mainframe service enablement is probably our most important area of mainframe application development in recent years• There are many ways to service enable an existing application• Use your existing skills, tools and methodologies where you can• Make the service interface completely hide what is behind it• Remember: – To be reusable it has to usable in the first place! CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 49
  51. 51. SOA Mainframe Practices – Best and Worst Best and Worst Practices in Service Modelling and ArchitectureCSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 50
  52. 52. Best and WorstPractices•Mark Skilton, CSC: Three simplerules for definition what is a Serviceare•Forrester: North American SOASystems Integrators•Gartner: The 13 least wanted•Ang, Cherbakov & Ibrahim, IBM:SOA Antipatterns•Tarak Modi, Unisys: SOAAntipatterns•IBM on SOA GovernanceNice to have research to quote Rather than admitting your own mistakes"The secret to creativity is knowinghow to hide your sources.“(Albert Einstein) CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 51
  53. 53. SOA Mainframe Practices – Best and Worst Mark Skilton, CSC: Service Oriented ArchitectureCSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 52
  54. 54. Mark Skilton, CSC: Service Oriented Architecture • Three simple rules for definition what a Service is • Five key areas to consider when looking at the granularity of business and IT services • Three key operating principles of SOA/POA underpin these choices CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 53
  55. 55. Mark Skilton, CSC:Three simple rules for definition what a Service is• It is strategic – The capability is critical to your organisation• Composable – The service can be run in its own and be combined with other services to build new services not originally specified• Rule of Three – If an interface and/or message is used in more than three systems CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 54
  56. 56. Mark Skilton, CSC:Five key areas to Consider when looking at theGranularity of Business and IT Services • Performance and size – Neither too big nor too small • Transactionality and state – This audience should know all about that! • Business suitability – One operation for one business step • Safe operations – Read only or reentrant • Idempotency of operations – Can be called again without changing the result CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 55
  57. 57. Mark Skilton, CSC:Three key operating principles of SOA/POAunderpin these choices• Process Integrity – Active – Safe – Idempotent• Data Integrity – Transactionality and states – Data Synchronisation – Logic• Security Integrity – Security policies, processes and technologies CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 56
  58. 58. SOA Mainframe Practices – Best and Worst Forrester: North American SOA Systems IntegratorsCSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 57
  59. 59. Forrester: North American SOA Systems Integrators• In a typical project that uses SOA strategically, there are typically five steps that organizations need to follow to successfully complete the project 1. Develop a future state for the business to evolve toward 2. Map existing business services to current business processes 3. Map business services to IT solutions 4. Map IT assets to IT solutions 5. Design SOA governance and infrastructure CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 58
  60. 60. SOA Mainframe Practices – Best and Worst Gartner: The 13 Least WantedCSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 59
  61. 61. Gartner: The Thirteen Least Wanted1. Starting too big 8. Excessive centralization2. Starting in the wrong place 9. Irrational SOA exuberance3. Leaving SOA to the "techies“ 10. Forgetting to consider the data4. Underestimating the technical 11. "Not invented here" syndrome (and infrastructure) issues 12. Allowing nonshareable services5. Assuming that everyone thinks to proliferate like you 13. "I already have 2006. Selling SOA before youre ready services, now what?”7. Choosing anarchy or dictatorship as leadership styles CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 60
  62. 62. SOA Mainframe Practices – Best and Worst Ang, Cherbakov & Ibrahim, IBM: SOA AntipatternsCSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 61
  63. 63. Patterns and Anti-Patterns• Patterns are a popular way of illustrating best practices – SOA Patterns are used very much in discussions and literature• Anti-patterns are being used more and more to slow down the hype CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 62
  64. 64. Ang, Cherbakov & Ibrahim, IBM:SOA Antipatterns (1) • Adoption – Technology Bandwagon – So, What’s New? – The Big Bang • Design – Blob – Poltergeists • Structure – Spaghetti code – Stovepipe systems CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 63
  65. 65. Ang, Cherbakov & Ibrahim, IBM:SOA Antipatterns (2)• Technology – Wolf ticket – Continuous obsolescence• Reuse – Cut-and-paste – Golden hammer CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 64
  66. 66. Ang, Cherbakov & Ibrahim, IBM:SOA Antipatterns (3) • Identification & Design – Web service = SOA – The Silo Approach – Misbehaving Registries • Realization – Chatty Services – Point-to-point Services – Component-less Services CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 65
  67. 67. SOA Mainframe Practices – Best and Worst Tarak Modi, Unisys: SOA AntipatternsCSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 66
  68. 68. Tarak Modi, Unisys: SOA Antipatterns (1)• The "Same Old, Same Old" Phenomenon• The "Big Bang" Approach• Service Fiefdoms CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 67
  69. 69. Tarak Modi, Unisys: SOA Antipatterns (2) • Technophilia • Bloated Services • Anorexic Services • Hyper Brokerage CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 68
  70. 70. SOA Mainframe Practices – Best and Worst IBM on SOA GovernanceCSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 69
  71. 71. IBM on SOA Governance • "Wild West" or “Rogue” Services – Extremely difficult to gain control over • "Duplicated” Services – Superficially effective but limited real savings • "Shelfware” Services – A waste of resource, won’t deliver benefits CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 70
  72. 72. IBM on SOA Governance• Unsecure Services – Limits service use and business opportunities• Rigid Services – Roadblock to agile, flexible business processes• Ineffective Service Management – Services must be managed as resources CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 71
  73. 73. SOA Mainframe Practices – Best and Worst A few more IssuesCSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 72
  74. 74. Carsten Svensson, EEI: The Cost of SOA• Cost of SOA = (Cost of Data Complexity + Cost of Service Complexity + Cost of Process Complexity + Enabling Technology Solution) CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 73
  75. 75. PerformanceThe daily CPU consumption patternwill change 2500 If you only run an online workload If you run online and a lot of batch 2000 If you run in a service enabled environment, where services are used by a self service web application 1500If you rely on a batch window it might Onlinecollide with the self service window 1000 Self-serviceafter dinner, when the kids are in bed Online & Batch 500 0 1 3 5 7 9 11 13 15 17 19 21 23 CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 74
  76. 76. The culture clash between Java and COBOL • COBOL was born to optimize administrative computing – Java and XML was born for dynamic interfaces – It takes a lot of sweat to reconcile them • Data in COBOL working storage allocated implicitly by the compiler – Data in Java must be allocated explicitly by the programmer CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 75
  77. 77. To Summarize• There are many ways to integrate mainframe systems into service oriented architectures – A lot of best practices are to be found in the technical solutions• You need a close cooperation between business stakeholders, architects, developers and technologists to make it work – The worst practices are found when application, design and architecture on one hand does not take the requirements of the technologies and the infrastructure seriously• All the mistakes have already been made and are extensively documented CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 76
  78. 78. SOA Mainframe Practices – Best and Worst THANK YOUCSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 77
  79. 79. CSC Proprietary and Confidential 6/26/2011 8:47 AM PPT 2003_Toolkit_FMT.ppt 78

×