Versions Compared

Version Old Version 64 New Version 65
Changes made by

John Mertic

Tim Brooks

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

NOTE: This is a sample template for the purpose collaborating and soliciting feedback. The actual Zowe Participation Form will involve a DocuSign Form (or equivalent) provided by the Linux Foundation to enable a digital submission.


Complete this form for each Participant (e.g., company or other entity) that desires to participate in the Zowe Conformance Program and to use the Conformance Marks. The Project Word Mark and the Conformance Marks are trademarks of The Linux Foundation. Capitalized terms used herein and not otherwise defined shall have the same meanings set forth in the Program Terms.

By signing below and submitting this form to The Linux Foundation:

  1. The Participant agrees to the Terms and Conditions of the Zowe Conformance Program (the “Program Terms”), available at Zowe Conformance Program Terms and Conditions
  2. The Participant confirms that the products and services identified below as Qualifying Offerings either (a) have passed all of the tests described in the Test Evaluation Guide, and are Qualifying Offerings under the Program Terms; or (b) prior to usage of the Conformance Marks, will passall of the tests described in the Test Evaluation Guide, and will be Qualifying Offerings under the Program Terms.
  3. The Participant confirms that it has submitted, or will submit, to The Linux Foundationthe results of the tests prior to its first public use of the Conformance Marks associated with the corresponding version of the Test Evaluation Guide.
  4. The Participant confirms that it will either (a) maintain conformance of the Qualifying Offerings with the Test Evaluation Guide, or (b) cease use of the Conformance Marksif the products or services cease to be Qualifying Offerings.
  5. The Participant confirms that it will promptly submit an updated Participant Form to The Linux Foundationprior to using the Conformance Marks with Qualifying Offerings not listed here.
  6. I confirm that I am authorized to make the above statements and to submit this form on behalf of the Participant.

Participant Information
Company / entity name:___________________________________________________
Contactaddress:________________________________________________________________________________________________________
Contact telephone:___________________________________________________
Contact email:___________________________________________________
Select one:

  •  Participant is a member of Open Mainframe Project
  •  Participant is NOT a member of the Open Mainframe Project
  •  Participant is a non-profit organization.

Participation in the Zowe Conformance Program is free for members of Open Mainframe Project. Other potential Participants should contact the Open Mainframe Project for more information about participation fees.

Qualifying Offerings
Name, brief description and URLs for more information: ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Conformance Details
Initial Version and Components of Zowe Conformance Program testsfor Conformance. If you believe that a criteria is Not Applicable please describe why in the comment sections:

  • Zowe API Mediation layer - 2019

    Please verify and comment where needed that the participating offering has achieved the conformance criteria for Zowe API Mediation Layer Conformance Criteria: Test Evaluation Guide

    Zowe API Mediation Layer Conformance Criteria Check-list:

    1) Application Service

    •  An application provides at least one service or UI

                     Comments:


    2) Register with discovery services

    Select all that apply:

    •  All exposed services of the application are discoverable by the API Mediation Layer Discovery Service
      •  The service is registered by dynamic registration (preferred)
      •  The service is registered by static definition (minimum requirement)
    •  The service provides a default service ID that is prefixed by the provider name (for example: ca, ibm, rocket)
    •  The service ID must be configurable externally after deployment
    •  The service ID is lower case, contain no symbols, and is limited to 64 characters
    •  The API ID follows the same rules as for Java packages, for example org.zowe.apiml.apicatalog
    •  The published service URL follows the gateway URL conventions:
      •  For versioned APIs, api/v1/{serviceId} is reserved for REST APIs
      •  For versioned APIs, ui/v1/{serviceId} is reserved for UIs
      •  For versioned APIs, ws/v1/{serviceId} is reserved for WebSockets
      •  For non-versioned APIs, api/{serviceId} is reserved for REST APIs
      •  For non-versioned APIs, ui/{serviceId} is reserved for UIs
      •  For non-versioned APIs, ws/{serviceId} is reserved for WebSockets

    Comments:


    3) API Documentation

    Select all that apply:

    •  Documentation is Swagger/Open API 2.0 compliant
    •  Every public resource is documented with a description of each resource
    •  Every method of each REST endpoint is documented
    •  Every method of each REST endpoint is demonstrated by an example
    •  

      Every parameter (headers, query parameters, payload, cookies, etc.) is documented with definitions of all possible values and their associated meanings

    •  Every error code, including errors returned in the payload is documented

    Comments:


    4) API naming and addressing

    Select all that apply:

    •  Encoded slash is not used
    •  The service interprets values independent of their URL encoding
    •  lowerCamelCase is used for names of resources, parameters, and JSON properties (preferred)

    Comments:


    5) Service requests and responses

    Select all that apply:

    API -

    •  Request and response payloads are in JSON or binary data format (preferred)
    •  In JSON format, links are relative, and must not contain the schema, hostname, and port

    WebSocket -

    •  Service URIs contained in WebSocket messages payload are addressed through the API ML Gateway

    UI -

    •  UI uses relative links and does not contain the schema, hostname, and port

                     Comments:


    6)Authentication and Authorization

    Select all that apply:

    •  Resources are protected by mainframe credentials
    •  Services accept basic authentication (minimum requirement)
    •  Services accept Zowe JWT token in the cookie (preferred)

    Comments:


    7) Versioning and Support

    Select all that apply:

    •  Service implementation follows the semantic versioning model (preferred)
    •  The service provider agrees that at least the last two major versions are supported by API services
    •  The service provider agrees to support the major service version for at least two years from its release

    Comments:

    8) UI

    •  UI uses only relative URLs

                    Comments:


    9) WebSocket Services

    Select all that apply:

    •  

      WebSocket connection creation, all subsequent communication between WebSocket client, and server is routed through the API ML Gateway.

    •  WebSocket connections are closed by the initiator through API ML Gateway.

                  Comments


    10) Zowe Version Compatibility

    •  

      The service provider agrees to re-certify when a new version of the conformance criteria is released within 60 days

                                                                                                                                    


  • Zowe CLI - 2019

    Please verify and comment where needed that the participating offering has achieved the conformance criteria for Zowe Command Line Interface Conformance Criteria: Test Evaluation Guide

    Summary:

    1) Infrastructure

    Select all that apply:

    •  Plug-in is constructed on the Imperative CLI Framework
    •  Plug-in is NOT run as a standalone CLI
    •  Plug-in commands write to stdout or stderr via Imperative Framework response.console APIs

    Comments:


    2) Installation

    Select all that apply:

    •  Plug-in is installable with the zowe plugins install command.
    •  Plug-in is installable into the @lts-incremental version of the core Zowe CLI and follows semantic versioning
    •  Plug-in is uninstallable via the zowe plugins uninstall command

    Comments:


    3) Naming

    •  If the plug-in introduces a command group name, it does not conflict with existing conformant plug-in group names.

    Comments:


    4) Profiles

    Select all that apply:

    •  If the plug-in has unique connection details, it introduces a profile that lets users store these details for repeated use.        
    •  (Preferred) Plug-in users are able to override all profile settings via the command line and/or environment variables.

    Comments:




                                                                                                                                    


  • Zowe App Framework - 2019

    Please verify and comment where needed that the participating offering has achieved the conformance criteria for Zowe App Framework Conformance Criteria: Test Evaluation Guide

    Summary:

    1) Packaging:

    Select all that apply:

    •  Every plugin must have a unique ID. The ID format follows java package naming conventions. The Zowe project reserves org.zowe.           
    •  Every plugin and each of its services must have a version.
    •  Directory layout adheres to the ZLUX App filesystem structure.
    •  Source code layout is recommended adheres to the ZLUX App filesystem structure for tooling consistency (preferred)                

    Comments:


    2) Web UIs ALL:

    •  All Apps must contain an icon image file to represent it, located at web/assets/icon.png within the App's package.

    Comments:


    3) Web UI IFrame:

    Comments:


    4) Web UI Non-IFrame:

    Select all that apply:

    •  DOM elements originating from your App should always be a child of the Zowe viewport DOM element, "com-rs-mvd-viewport".
    •  Network requests to the Zowe App Server must never be done without the use of the URI Broker.
    •  Access to resources outside the App Server should also be made through the URI Broker whenever possible (Preferred).
    •  Apps must not pollute the global namespace with regards Javascript, HTML, and CSS
    •  When using a library present in the Zowe App Framework core, you must depend on the same version.
    •  Web apps should extend the framework's default build scripts for webpack and typescript (Preferred).

    Comments:


    5) UI Design:

    •   Apps should follow the UI Design guidelines (Preferred).

    Comments:


    6) Localization and Internationalization (I10n and I18n):

    non-IFrame:

    Select all that apply:

    •  The active language to be used for string selection must be retrieved using ZoweZLUX.globalization.getLanguage(), which determines language by multiple factors.
    •  No strings visible in a UI should be hard-coded, rather resource strings must be used in accordance with one of the existing internationalization support mechanisms (Preferred).

    Comments:


    7) App Server:

    Select all that apply:

    •  Data services should be written such that all synchronous and asynchronous errors are caught. Utilize try-catch and check the existence of error objects from asynchronous calls. Uncaught exceptions effect server responsiveness and disrupt clients.

    Comments:


    8) Documentation:

    Select all that apply:

    •  Every HTTP API must be documented in swagger 2.0. The swagger document must be stored in doc/swagger
    •  In addition, it is recommended to have documentation about the format of any Websocket APIs, to be placed within doc (Preferred)

    Comments:


    9) Logging

    Select all that apply:

    •  An Apps non-IFrame web components, or App Framework dataservices (eg Javascript and Typescript) must log only through the "zlux" logger
    •  ZSS services log only through the Zowe ZSS Logger
    •  Passwords must never be logged
    •  Error reporting should follow the standard tooling (Preferred)

    Comments:


    10) Storage

    •  User preferences, if applicable to a plugin, must be stored through the configuration data service.

    Comments:

                                                                                                                   


Conformance Submission Date: __________________
Signed on behalf of Participant by:__________________________________
Name: ____________________________
Title: ____________________________
Date: ____________________________


*Future* App Directory Conformance
In order for your Zowe Conformant App to appear in the App Directory you must submit the following information along with your completed Zowe Participant Form.

  • Application description
  • Application pre-reqs
  • Application installation pattern???
  • Application architecture???
  • etc.