Skip to content

Service Contract Definition

Concept Description

The Service Contract refers to the micro-service interface contract based on the OpenAPI specification. The interface definition between the server and the consumer. The java chassis provides two ways to define the contract: 'code first' and 'contract first'.

  • Code first
    The Producer use of Jax-RS or SpringMVC's RESTful annotation declares the input and output parameters of the interface, or with the OpenAPI annotations, to add human-readable information, such as sample code, text descriptions, etc.; when the ServiceComb engine starts, according to these annotations generate a contract description and automatically upload it to the service center.
    The producer can also be developed using the transparent RPC model, but since there is no RESTful annotation to guide how to generate the contract, at this time, the automatically generated contract very non-standard and not recommended. The consumer is called with a transparent RPC or RestTemplate.
    Under the code first development model, developers do not have to handwritten contracts.

  • Contract first
    In this scenario, instead of using the contract automatically generated by the framework, the contract file provided by the developer is directly used, which requires the developer to ensure the consistency of the contract and the code.

Scenario

The service contract is used for decoupling between the server and the consumer. The server implements the service around the contract. The consumer invokes the service according to the contract, which can support the server and the consumer to implement in different programming languages.

Description: The service provider registers the interface contract with the service center at startup, which can be downloaded and used by the service consumer. The interface contract is micro-service-version level information. When multiple micro-service instances are started, if an instance registers the contract with the service center, the service center will not overwrite the existing contract with the contract information registered by the latecomer. Therefore, only modifying the service provider's interface information will not change the contract stored by the service center. For the service consumer, the acquired interface information is still old. To update the interface contract in the service center, you can choose to upgrade the microservice version number or delete existing microservice information (the latter is not recommended for use in a production environment).

Configuration

ServiceComb defines API in a .yaml file. It's recommended to use Swagger Editor to define the APIs. This tool can check syntax and automaticlly generate an API document. For details about the API definition file format, see Official OpenAPI documentation。

The API definition file is located in "resources/microservices" or "resources/applications" directory. The directory structure is as follows:

resources
  - microservices
    - serviceName #Microservice name
      - schemaId.yaml #schema ID
  - applications
    - appId #Application ID
      - serviceName #Service name
        - schemaId.yaml #Schema ID

Note:

  • ServiceComb's Swagger contract file should be saved using the UTF-8 character set. If the user saves the contract file with a different character set and the file contains Chinese characters, it may cause an unknown error.

Sample Code

The contents of the schemaId.yaml file in the resources/microservices directory and the resources/application directory are as follows. The interface definitions in the file need to match the actual interface of the service.

swagger: '2.0'
info:
  title: hello
  version: 1.0.0
  x-java-interface: org.apache.servicecomb.samples.common.schema.Hello
basePath: /springmvchello
produces:
  - application/json

paths:
  /sayhi:
    post:
      operationId: sayHi
      parameters:
        - name: name
          in: query
          required: true
          type: string
      responses:
        200:
          description: return value
          schema:
            type: string
        default:
          description: return a default result
          schema:
            type: string
  /sayhello:
    post:
      operationId: sayHello
      parameters:
        - name: person
          in: body
          required: true
          schema:
            $ref: "#/definitions/Person"
      responses:
        200:
          description: return value
          schema:
            type: string
        default:
          description: return a default result
          schema:
            type: string
definitions:
  Person:
    type: "object"
    properties:
      name:
        type: "string"
        description: "person name"
    xml:
      name: "Person"

NOTE：
* Contract in ServiceComb, it is recommended that basePath not include the web root of the web container, and the url pattern of the servlet.

Because ServiceComb supports deployment decoupling, it can be deployed independently from the servlet container, or deployed to the servlet container using the war, or it can be run using the embedded servlet container. As long as the base path does not contain the web root and the url pattern, the actual url changes caused by the deployment mode modification, the ServiceComb consumer business code does not need to be perceived, and the framework will automatically adapt.

  • info.x-java-interface needs to indicate the specific interface path, depending on the actual situation of the project.
  • SchemaId can contain "." characters, but it is not recommended. This is because the configuration file used by ServiceComb is in yaml format. The "." symbol is used to split the configuration item name. If the SchemaId also contains ".", some configurations that support the contract level may not be recognized correctly.
  • The "." character cannot be included in the naming of the OperationId.