S111 cics connectivity in devops

S111 cics connectivity in devops

• 1.
  CICS Connectivity inDevOps Dan Millwood CICS - S111
• 2.
  © 2015 IBMCorporation IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM’s sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion. Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon many factors, including considerations such as the amount of multiprogramming in the user’s job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here. Please note…
• 3.
  © 2015 IBMCorporation Agenda • What is DevOps? • Improving the services CICS provides • Communication • Interface Design • Extending SOAP / JSON interfaces • How to create an interface • The power of JAX-RS • Connectivity choice factors • Comparison of connectivity options • Recommendations •
• 4.
  © 2015 IBMCorporation What is DevOps? Development Operations “The operations team take an age to do anything. It really impacts our ability to deliver” “I dont trust the developers. I must protect the production systems from their poor code”
• 5.
  © 2015 IBMCorporation See the bigger picture Development Operations “We are all driving towards a common goal” “To deliver the software and services needed to meet the business objectives for our company”
• 6.
  © 2015 IBMCorporation Or the even bigger picture Mobile Team Middleware Team CICS Team Service Provider CICS provides services CICS consumes services
• 7.
  © 2015 IBMCorporation How can we improve our services to help consumers? • How can we deliver services faster? • How can we deliver better quality services? • How can we ensure the services we deliver meet the needs of our consumers? • How can we ensure that we can update the service to meet the continued needs of our consumers? • Good communication between the service consumers and the service provider • Good interface design • Good choice of connectivity protocol and data format • 7
• 8.
  © 2015 IBMCorporation Good communication • What we do in CICS – Design Partnerships with customers help us to ● Understand our customers needs better ● Design a solution that meets those needs – We try to “Fail Fast” ● Every few weeks we playback to the customers on what we are doing ● If we get it wrong, we can change it before the design is finalised ● • How does this relate to designing service interfaces? – Talk to the service consumers regularly to understand their needs – Design the high level interface interactions on paper first and review it with consumers, reworking as needed – Design the data layout and field names for the various interface calls ● Can the consumer correctly guess the meaning of fields unaided? – Then think about implementing a first pass at the interface so the consumer can try it out – 8
• 9.
  © 2015 IBMCorporation Good Interface Design • A well thought out interface is: – Easy to understand ● Can I correctly guess meanings of fields? – Easy to consume ● Is the interface using a protocol I can work with? – Easy to extend ● Can an update be rolled out without breaking clients? Take the time to design your interface. It is the key to your service being useful! • 9
• 10.
  © 2015 IBMCorporation Wsbind based web services development 10 Bottom up – Start with a language structure and convert it into a form usable as a CICS web service Top down – Start with a WSDL or JSON schema document and convert it into a form usable as a CICS web service. CICS Bottom up Top down WSDL or JSON schema Language Structures e.g. COPYBOOK
• 11.
  © 2015 IBMCorporation Wsbind based web services development 11 Bottom up – Start with a language structure and convert it into a form usable as a CICS web service Top down – Start with a WSDL or JSON schema document and convert it into a form usable as a CICS web service. CICS Bottom up Top down WSDL or JSON schema Language Structures e.g. COPYBOOK A generated interface is unlikely to be as easy to use as one you designed
• 12.
  © 2015 IBMCorporation Catalog Manager Sample * Catalogue COMMAREA structure 03 CA-REQUEST-ID PIC X(6). 03 CA-RETURN-CODE PIC 9(2) DISPLAY. 03 CA-RESPONSE-MESSAGE PIC X(79). * Fields used in Inquire Catalog 03 CA-INQUIRE-REQUEST. 05 CA-LIST-START-REF PIC 9(4) DISPLAY. 05 CA-LAST-ITEM-REF PIC 9(4) DISPLAY. 05 CA-ITEM-COUNT PIC 9(3) DISPLAY. 05 CA-CAT-ITEM OCCURS 15. 07 CA-ITEM-REF PIC 9(4) DISPLAY. 07 CA-DESCRIPTION PIC X(40). 07 CA-DEPARTMENT PIC 9(3) DISPLAY. 07 CA-COST PIC X(6). 07 IN-STOCK PIC 9(4) DISPLAY. 07 ON-ORDER PIC 9(3) DISPLAY. Bottom up will create A web service that expects all the fields as input and returns all the fields as output Variable names that are hard to understand What does CA-LIST-START-REF mean?
• 13.
  © 2015 IBMCorporation Use a meet-in-the-middle approach to expose existing applications as Web services Design the interface to the service New CICS program Existing business application (COBOL, C, C++, PLI) Meet in the middle Map and Generate 1) Design the new interface 2) Top-down generation of language structures for the new interface 3) Write new program to map between existing business applications interface and the newly generated interface.
• 14.
  © 2015 IBMCorporation Use a top-down approach to expose new applications as Web services 1) Design the new interface 2) Top-down generation of language structures for the new interface 3) Write new business application that uses the generated language structures for its input and output New business application (COBOL, C, C++, PLI, Java) Design the interface to the service Top-down Generate
• 15.
  © 2015 IBMCorporation How to create an interface • SOAP Web services using WSBind files – Design the layout of the SOAP data, variable names etc – Create a WSDL file using a WSDL Editor • JSON Web services using WSBind files – Design the layout of the JSON data, variable names etc – Create a JSON schema • JSON Web services using JAX-RS in Liberty – Design the layout of the JSON data, variable names etc – Implement using annotations on variables in a Java class – Optionally create a JSON schema for consumers of service to use • SOAP Web services using JAX-WS in Liberty – Design the layout of the SOAP data, variable names etc – Create a WSDL file – Use WSImport tool to create Web service interface then create class that implements the interface • Commarea / Channel exposed to client – Design and create data structure(s) representing the data •
• 16.
  © 2015 IBMCorporation The power of JAX-RS (and JAXB) • Restful services from Liberty in CICS • Both JSON and XML supported • Built from annotations in Java source code @XmlRootElement @XmlAccessorType(XmlAccessType.FIELD) public class Customer { private String name; private String company; private int age; public void setName(String s) { name = s; } public void setCompany(String s) { company = s; } public void setAge(int i) { age = i; } } XML <?xml version="1.0" encoding="UTF-8"?> <customer> <name>John Smith</name> <company>General Insurance</company> <age>40</age> </customer> JSON { “name”:”John Smith”, “company”:”General Insurance”, “age”:40 }
• 17.
  © 2015 IBMCorporation The power of JAX-RS (and JAXB) @ApplicationPath("/CustomerApp") @Path("/query") public class CustomerApplication extends Application { @GET @Path("/customer") @Produces({"application/xml","application/json"}) public Customer getCustomer() { Customer customer = new Customer(); customer.setName("John Smith"); customer.setCompany("General Insurance"); customer.setAge(40); return customer; } } A http GET request to .../CustomerApp/query/customer returns the XML variant A http GET request to .../CustomerApp/query/customer with http header Accept: application/json returns the JSON variant You could map a COMMAREA to Java using J2C or JZOS, then expose a new JSON service using JAX-RS and JAXB.
• 18.
  © 2015 IBMCorporation Designing an extensible SOAP interface • SOAP messages must conform to a schema – Adding a new field to a SOAP message will break its conformity to the schema – You can plan ahead by use of the xsd:any tag <xsd:element name="Customer"> <xsd:complexType> <xsd:sequence> <xsd:element name="Title" type="xsd:string"/> <xsd:element name="FirstName" type="xsd:string"/> <xsd:element name="Surname" type="xsd:string"/> <xsd:any minOccurs="0" maxOccurs=”unbounded”/> </xsd:sequence> </xsd:complexType> </xsd:element> – In this instance, any data elements following Surname will be accepted so a future update to the Customer element could be made without breaking existing clients – Most useful for enabling the service consumer to ignore additional data added by the provider
• 19.
  © 2015 IBMCorporation Designing an extensible JSON interface • JSON often used informally (without a schema) • A lot of JSON consumers are based off of example messages and documentation. – They will typically just look for the fields they want, therefore sending new properties in the response to them isn't a problem • The top down WSBind tooling does require a JSON schema – Whilst the schema allows for extensions, the WSBind tooling does not. – If CICS is the service provider, you will probably be able to extend the response message without breaking consumers – If CICS is a WSBind based requester and the service provider extends the response data, the CICS requester will need updating
• 20.
  © 2015 IBMCorporation Connectivity Choice Factors • Client/server coupling – Tightly or loosely coupled? • Synchronous or asynchronous invocation – Request/reply or event-based? • Application development tools – Depends on preference or what you already have • Security – Does choice support your security requirements? • Transactional scope – 2PC or not 2PC (that is not the only question!) • High availability and scalability – Who doesn’t want high availability and scalability? 20
• 21.
  © 2015 IBMCorporation Connectivity Choice Factors • Client needs – What are the clients preferred connectivity options? – What would tempt the clients to use this service? – How quickly is the service required, and for how long? • How easily can the service interface be extended? – What are the impacts on the clients to extending the interface? • What development skills are available? – Is there time to train people in something new, or funding to bring in new skills to the team? • What is the required service response time? – Response time can impact the decision as to where to host the service • Anticipated load – Can the load requirements be met? •
• 22.
  © 2015 IBMCorporation Comparison of connectivity options SOAP/ HTTP or WMQ JSON/ HTTP CTG HTTP WMQ WOLA Sockets Security Message + TLS + client auth + basic auth + asserted id TLS + client auth + basic auth TLS + client auth + basic auth + asserted id TLS + client auth + basic auth Queue + TLS + AMS + basic auth + asserted id (TLS not required) + asserted id TLS + client auth Transactionality 2 PC / Local Local 2 PC / 1 PC / Local Local Queue 2 PC / Local Local Binary data Yes Base64 Yes Yes Yes Yes Yes Required middleware None None (or zOS Connect) CTG + JEE server None WMQ on z/OS WAS on z/OS None
• 23.
  © 2015 IBMCorporation Comparison of connectivity options SOAP/ HTTP or WMQ JSON/ HTTP CTG HTTP WMQ WOLA Sockets Inbound / Outbound Both with CICS API for outbound Both Inbound Both Both Both Both Easy to extend Depends on interface design Probably able to add new fields without client changes Depends on interface design Depends on interface design Depends on interface design Depends on interface design Depends on interface design Standard for reporting errors SOAP Fault No defined standard No defined standard Status code No defined standard No defined standard No defined standard
• 24.
  © 2015 IBMCorporation Recommendations • Web services – Should be first consideration for service enabling CICS applications, particularly when you need to support multiple service requester types or need bi-directional support – SOAP ● A mature set of standards with high QoS via WS-* specifications ● Widely supported across the industry, with good tooling support ● Strict, well defined data structures ● Best for enterprise application to enterprise application communication – JSON ● Easy to integrate into JavaScript applications, making it a preferred data format for many mobile application developers ● A simpler way of representing data than SOAP, but with fewer qualities of service and less tooling support ● Use when providing services for mobile applications, web pages, or when the market demands it
• 25.
  © 2015 IBMCorporation Recommendations • CTG – Most appropriate solution when service requester is JEE component and when high QoS required • WOLA – Particularly useful for JCA access to and from CICS, and for very high throughput and performance requirements between WebSphere Application Server for z/OS and CICS • HTTP – Use with web services, RESTful services, and ATOM feeds, or when remote client/server only supports HTTP. • WebSphere MQ for z/OS – Exploit MQ for basic messaging, asynchronous services and flowing web services. • CICS Sockets – Use when remote client/server only supports TCP/IP sockets communication •
• 26.
  © 2015 IBMCorporation Questions
• 27.
  © 2015 IBMCorporation