2.4 Bases of design of dataservices
Various issues related to the design of dataservices are already decided for the architect/developer on X-Road. For example, transport protocol must be HTTP, data exchange protocol must be SOAP, only synchronous messages are supported, and coupling style of WSDL and SOAP must be Document/literal wrapped. In addition, the selection of security protocols and ensuring the authenticity of members is already resolved.
Task of an architect upon designing dataservices of X-Road is to design useful and sustainable dataservices and to use practically dataservices offered by other X-Road members. To fulfil this task, design of dataservices should not be based on the functionality of available software but on actual business needs and functions. Dataservices must enable opening business functions, not internal details of own database/information system. Only when business needs and business functions are mapped, it can be viewed whether the available dataservices can be reused to execute these functions. If reuse is not possible, it must be analysed how much the available software should be updated to offer relevant functionality.
An overview of the design and usage methods of dataservices of X-Road and possible solutions are provided in the directory of interfacing patterns of X-Road at the address: https://moodle.ria.ee/mod/page/view.php?id=236.An overview what should be avoided when designing dataservices of X-Road is provided in the X-Road application guide at the address: https://moodle.ria.ee/mod/page/view.php?id=204.