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)
- the consumption of the routes
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.