Topic
  • 6 replies
  • Latest Post - ‏2014-12-24T15:26:55Z by Benny.Higdon
SystemAdmin
SystemAdmin
141 Posts

Pinned topic Customizing WSRR to Support COBOL Service Components

‏2012-03-15T17:04:33Z |
Has anyone explored customizing WSRR to support the registration of COBOL Service Components (or other Mainframe components)?

The way I see it, COBOL services are sometimes exposed for general consumption via Message Broker ( or another ESB) as either RESTful services or SOAP services. This leaves what I refer to as the private service, or the actual COBOL aspect of the service. It seems that we should also register this information in WSRR, however I was looking for some guidance on this. Typically the COBOL service is accessed via MQ, however we do not have any WSDL's for these COBOL services, so loading them into WSRR becomes labor intensive.

I'm battling with whether the COBOL service should be a type of private (internal) Service Version that is not externally exposed but only supporting a Service Version exposed via our ESB, or if the COBOL service would be represented as some form of dependency to the Service Version exposed on the ESB and publicly accessible by our Service Consumers.

I'd be very interested to hear how others may have tackled this challenge...

Thanks,
Chris
Updated on 2012-03-22T13:15:15Z at 2012-03-22T13:15:15Z by SystemAdmin
  • SystemAdmin
    SystemAdmin
    141 Posts

    Re: Customizing WSRR to Support COBOL Service Components

    ‏2012-03-21T13:46:53Z  
    OK, so by the deafening silence I am drawing the conclusion that no one on this forum has any experience with mainframe Services being exposed and registered in WSRR. Really???
  • SystemAdmin
    SystemAdmin
    141 Posts

    Re: Customizing WSRR to Support COBOL Service Components

    ‏2012-03-21T16:54:38Z  
    I've started this activity at my customer and we'll be presenting at IMPACT 2012 (session 1540) that includes this subject. My customer's goal was to capture the relationship of CICS and how to access them (over MQ) from various consuming services or applications. They weren't really interested in operational usage of it, though thinking about what we created, we could do so. I think it's just a matter of creating a WMB flow to leverage such.

    In our case the CICS components are not exposed services, rather they are key back-end applications that provide data to the exposed services. To reflect the CICS/COBOL components, we created a custom model that referenced the GEP model. Among the custom objects we created a CICS object that is sub-classed from "Asset". By sub-classing "Asset" when we create a Service Version that represents this "internal" service and associated MQ Endpoints we leverage the "Dependency" relationship of Service Version (which itself is a sub-class of Asset) to select "CICS" as an Asset dependency.

    I'm attaching pic example of graph showing such relationships. And I'll attach a pic of the model in a separate post (looks like I can attach only a single file).
  • SystemAdmin
    SystemAdmin
    141 Posts

    Re: Customizing WSRR to Support COBOL Service Components

    ‏2012-03-21T16:56:48Z  
    Attachment 2 - the Custom Model
  • SystemAdmin
    SystemAdmin
    141 Posts

    Re: Customizing WSRR to Support COBOL Service Components

    ‏2012-03-21T21:30:08Z  
    I've started this activity at my customer and we'll be presenting at IMPACT 2012 (session 1540) that includes this subject. My customer's goal was to capture the relationship of CICS and how to access them (over MQ) from various consuming services or applications. They weren't really interested in operational usage of it, though thinking about what we created, we could do so. I think it's just a matter of creating a WMB flow to leverage such.

    In our case the CICS components are not exposed services, rather they are key back-end applications that provide data to the exposed services. To reflect the CICS/COBOL components, we created a custom model that referenced the GEP model. Among the custom objects we created a CICS object that is sub-classed from "Asset". By sub-classing "Asset" when we create a Service Version that represents this "internal" service and associated MQ Endpoints we leverage the "Dependency" relationship of Service Version (which itself is a sub-class of Asset) to select "CICS" as an Asset dependency.

    I'm attaching pic example of graph showing such relationships. And I'll attach a pic of the model in a separate post (looks like I can attach only a single file).
    Thanks for your response Guy.

    So if I am understanding your configuration correctly, you do use Service Version to register information about mainframe Service components. This Service Version then captures information about the associated CICS components using a dependency to your custom CICS Asset and captures MQ Endpoint information using the relationship to the ExtendedServiceLevelDefinition. So this Service Version is only available internally unlike the typical SOAP Service Version. Have there been additional customizations made to the Service Version from the GEP model? How is this "internal" Service Version classified to prevent it from being utilized as an exposed Service?

    I'm curious why you chose to customize the relationship to the CICS components with an Asset relationship versus a sub-classed Service Version for the CICS components?

    Also from an MQ perspective, does your customer utilize WSDL's for the MQ information, or do they manually enter all of the MQ information on the cascading forms?
  • SystemAdmin
    SystemAdmin
    141 Posts

    Re: Customizing WSRR to Support COBOL Service Components

    ‏2012-03-22T13:15:15Z  
    Sub-classing SVS for the COBOL or CICS component may be a good idea. I hadn't thought of that, but thinking now I don't know that it would make much difference for our purpose. For my customer's case they have a home grown repositories (and spreadsheets) with service like names with request/reply queues that tie to the backend CICS program. So we leveraged those existing names, the queue defns as endpoints and the CICS information as a dependency. See no reason why you couldn't also do as you suggest.

    We haven't reached the point of internalizing those endpoints. In fact, for our purpose we want to expose this information because WSRR is providing a single place for all the service interactions to be defined providing visibility and impact analysis that wasn't available in their home-grown repositories and spreadsheet sprawl. That's an aspect to consider here. It's not all about operational usage. Your org may benefit from having that end-to-end service connection view.

    For service endpoints that we really do wish to use operationally we can hide the internal/private endpoints by classifying them as such and deciding which role to grant visible permissions on that classification. That's TBD.

    For MQ, TBH I'm waffling between using WSDL form or manual MQ Service Endpoint definitions. WSDL form provide standard places to define info. Challenge is there's no easy way to capture this existing MQ Defn info, evaluate and crank out MQ WSDL for selected definitions. There's the MQ Explorer WSDL wizard, but it's a manual entry tool. We'd have to build our WSDL generator for mass generation. Something we're considering. We're also working on a spreadsheet service creation tool to take as input the many spreadsheets we have here that contain service consumer/provider relationships and drive entry into WSRR. We have to decide if we want the MQ services to use manual endpoints or create MQ wsdl. That doesn't help you much but maybe the ideas we're debating prompt more good ideas of your own.
  • Benny.Higdon
    Benny.Higdon
    9 Posts

    Re: Customizing WSRR to Support COBOL Service Components

    ‏2014-12-24T15:26:55Z  
    Sub-classing SVS for the COBOL or CICS component may be a good idea. I hadn't thought of that, but thinking now I don't know that it would make much difference for our purpose. For my customer's case they have a home grown repositories (and spreadsheets) with service like names with request/reply queues that tie to the backend CICS program. So we leveraged those existing names, the queue defns as endpoints and the CICS information as a dependency. See no reason why you couldn't also do as you suggest.

    We haven't reached the point of internalizing those endpoints. In fact, for our purpose we want to expose this information because WSRR is providing a single place for all the service interactions to be defined providing visibility and impact analysis that wasn't available in their home-grown repositories and spreadsheet sprawl. That's an aspect to consider here. It's not all about operational usage. Your org may benefit from having that end-to-end service connection view.

    For service endpoints that we really do wish to use operationally we can hide the internal/private endpoints by classifying them as such and deciding which role to grant visible permissions on that classification. That's TBD.

    For MQ, TBH I'm waffling between using WSDL form or manual MQ Service Endpoint definitions. WSDL form provide standard places to define info. Challenge is there's no easy way to capture this existing MQ Defn info, evaluate and crank out MQ WSDL for selected definitions. There's the MQ Explorer WSDL wizard, but it's a manual entry tool. We'd have to build our WSDL generator for mass generation. Something we're considering. We're also working on a spreadsheet service creation tool to take as input the many spreadsheets we have here that contain service consumer/provider relationships and drive entry into WSRR. We have to decide if we want the MQ services to use manual endpoints or create MQ wsdl. That doesn't help you much but maybe the ideas we're debating prompt more good ideas of your own.

    Hi.  Any updates on this?  We have a customer who would like to do something similar.

    Also, for some reason, I don't see the attachments that are supposed to be snapshots of the model.  Can anyone else see them?