The services

Akwatype services are components that expose and consume APIs and receive and send messages. The data exchanges modeled in Akwatype are structured around these services.

 

 

The association of the facades with APIs and Messages

Once defined, the facades will be able to be associated with routes and messages to describe the transported data. This approach keeps a simple description of the model at the level of each Route or message while keeping a strong link with the type model to ensure the overall consistency of the descriptions.

 

Basic service description

A service is a component, which exposes one or more resources for which routes are declare.

Services, resources and routes have a name and attributes (label, comment, url, responses ...)

In this very simple example we declare a Person service, which exposes a persons resource with a person route.

The route takes as parameter an id and returns a response to which we have associated the SimplePersonDTO facade (just with name and firstname fields)

 

service Person{
    url:"person"
    expose persons{
        url:"persons"
        route person{
            url:"person/id:String"
            response:VerySimplePersonDTO
        }
    }
}

 

At this point we already have the minimum information to generate an OpenAPI description for this service

Read related articles to see how to associate properties with services, resources and routes

 

More advanced example

Note: The functionalities related to messages and the generation of sequence graphs are only accessible from the Akwatype Start plan.

In the example below, we declare a channel (Payment) to broadcast the message (payment) with the content PaymentDTO.

The Customer service exposes two resources (customers and invoices) with several routes. this service also subscribes to the payment message on the Payment channel(receive Payment.payment)

The Payment.payments.payInvoice route of service Payment is particularly interesting

  • The HTTP method is specified (POST)
  • The PaymentDTO facade is associated with the request
  • The call of this route triggers
    • the consumption of the routes
      • Customer.invoices.getInvoice
      • Risk.authorization.getAuthorisation
    • the sending of the message
      • Payment.payment (Channel.message)

 

channel Payment
message payment{
    payload:PaymentDTO
}

service Customer{
    url:"customer"
    expose customers{
        url:"customers"
        route getCustomer{
            url:"customer/id:String"
            response:CustomerDTO
        }
    }
    expose invoices{
        url:"invoices"
        route getInvoice{
            url:"invoice/num:String"
            response:InvoiceDTO
        }
        route invoicePaid{
            method: PUT
            url:"invoice/paid/num:String" 
        }
    }
    receive Payment.payment   
}


service Payment{
    url:"payment"
    expose payments{
        route payInvoice{
            method: POST
            url:"payments/numInvoice:String/"
            request: PaymentDTO
            consume Customer.invoices.getInvoice
            consume Risk.authorisation.getAuthorisation
            send Payment.payment
        }        
    }
}


service Risk{
    url:"risk"
    expose authorisation{
        url:"authorisation"
        route getAuthorisation{
            method: POST
            consume Customer.customers.getCustomer
            request: PaymentDTO
            response: Boolean
        }
    }
}

service Bank{
    receive Payment.payment
}

 

As we can see on this sequence graph, generated by Akwatype, all the consumption links between services and publish/subscribe messages are indexed and restituted through the different flow graphs.