Service Description
asrv.aero
Airport Slot Data Service
Version 1.0
Namespace: http://www.asrv.aero/webservices/1.0/AirportSlotDataService
Document revisions
Date | Description | Author |
---|---|---|
2016-08-19 | First complete version of the documentation |
- 1. Introduction
- 2. Service overview
- 3. Service operations
- 3.1. InsertUpdateSlotSchedule (sequenceNumber: SequenceNumber, insertUpdateSlotScheduleInfo: InsertUpdateSlotScheduleInfo): ResponseStatus
- 3.2. DeleteSlotSchedule (sequenceNumber: SequenceNumber, deleteSlotScheduleInfo: DeleteSlotScheduleInfo): ResponseStatus
- 3.3. GetLastSequenceNumber(): SequenceNumber
- 3.4. Heartbeat (): void
- 4. Data entities
- 5. XML Usage
- 6. WSDL and XSDs
1. Introduction
1.1. Overview
This service description defines one service with a set of operations to create, update and flight schedules. The service is airport oriented as the slot allocation is by it's nature airport oriented. The airport implements this service and the slot coordinator uses it.
All data elements are defined by the Airport Data Dictionary.
1.2. Implementation considerations
Any implementation of this service MUST use the WSDL and XSD files provided here: WSDL and XSDs
It is however up to the service provider which data elements to support. To enable this most elements are optional. The user of the service (the slot coordinator) must however provide enough information to make information provided unambiguous and meaningful.
Any service provider (the airport) should make available documentation about the actual implementation, including:
-
- the address of the service.
- the connection detail. As this service updates information at the airport it is expected that a secure communication setup is necessary.
- any limitations in the implementation.
1.3. Purpose of this service description
This service description has the following purpose:
-
-
- Describe of service in enough detail for a service provider to implement it.
- Describe the service so that a client (of this service) developer can use it.
- Make available the WSDL and XSD files necessary to implement and use the service.
-
1.4. Intended readership
-
- IT architects
- Developers
- Business architects
- Interested parties in the aviation community
2. Service overview
2.1. High level
The figure below shows a typical setup.
- The slot coordinator creates client software, the "Slot System AODB Client" below, which is responsible for communicating with the "AirportSlotDataService" provided by the airport. The "AirportSlotDataService" will typically be a front end service for some AODB (Airport Operational DataBase) software.
- Based on events in the "Slot Coordinating System" the "Slot System AODB Client" will insert, update or delete information in the AODB using the "AirportSlotDataService".
2.2. Operations overview
The "AirportSlotDataService" provides 4 operations, as shown below.
2.3. Signatures of the operations
The figure below shows the available operations on the FlightSlotDataService. The operations are described in detail in Service operations.
3. Service operations
3.1. InsertUpdateSlotSchedule (sequenceNumber: SequenceNumber, insertUpdateSlotScheduleInfo: InsertUpdateSlotScheduleInfo): ResponseStatus
Insert a new slot schedule, or updates an existing one.
Parameters:
-
sequenceNumber: SequenceNumber
The sequenceNumber is incremented by 1 on each call to InsertUpdateSlotSchedule. If the has another value than expected the call should fail. The slot coordinator software should then use GetLastSequenceNumber to retrieve the last sequence number/transaction that was successfully processed, and restart from there. -
insertUpdateSlotScheduleInfo: InsertUpdateSlotScheduleInfo
A Schedule pattern with corresponding information describing one or more arrivals or departures at one slot regulated airport that should be created or updated.
Returns: ResponseStatus
Additional codes defined for ResponseStatusCode: None
3.2. DeleteSlotSchedule (sequenceNumber: SequenceNumber, deleteSlotScheduleInfo: DeleteSlotScheduleInfo): ResponseStatus
Used to delete one or more flight schedules at a slot regulated airport.
Parameters:
- sequenceNumber : SequenceNumber
The sequenceNumber is incremented by 1 on each call to InsertUpdateSlotSchedule. If the has another value than expected the call should fail. The slot coordinator software should then use GetLastSequenceNumber to retrieve the last sequence number/transaction that was successfully processed, and restart from there. - deleteSlotScheduleInfo : DeleteSlotScheduleInfo
A Schedule pattern describing one or more arrivals or departures at one slot regulated airport that should deleted.
Returns: ResponseStatus
Additional codes defined for ResponseStatusCode: None
3.3. GetLastSequenceNumber(): SequenceNumber
Return the last sequence number successfully processed by the InsertUpdateSlotSchedule or DeleteSlotSchedule calls.
Parameters: None
Returns: The last sequence number successfully processed.
3.4. Heartbeat (): void
The slot coordinator software call the heartbeat operation regularly to indicate that it is running ok, and that the connection is ok. The actual rate must be agreed upon between the slot coordinator and the airport.
Parameters: None
Returns: Nothing
4. Data entities
4.1. InsertUpdateSlotScheduleInfo
|
4.2. DeleteSlotScheduleInfo
|
|
|
5. XML Usage
5.1. Nil Values in Schema
For any particular data element, there is an important distinction between the following cases:
(a) the element is missing
(b) the element is present but has a 'nil' attribute assigned to it
In the first case, this means that the sender is supplying no information about the element. This would typically be because no information is available, or because there has been no change in the value of the element. A recipient would not be expected to take any action as a result of this. In particular, it would not be expected to clear any existing value.
In the second case, this means that the sender has explicitly cleared the element. As a result of this, a recipient would typically clear any value that it had previously stored for this element.
The following table shows an example sequence of messages, and the expected actions taken by the data recipient. It should be noted, however, that the action is up to the recipient. The message from the sender is a notification, and not a command for the recipient to take action.
Message contents |
Expected action by recipient |
---|---|
aircraftRegistration element missing |
Does not set or change aircraft registration value |
<aircraftRegistration>ABC123</aircraftRegistration> |
Sets the value to ABC123 |
aircraftRegistration element missing |
Does not change the value |
<aircraftRegistration> |
Clears the aircraftRegistration value |
Note that the sender should not use blank data elements such as <aircraftRegistration/> or <aircraftRegistration></aircraftRegistration> as these may cause validation errors. For example, if the schema specifies a format or a minimum length for an element, then a zero-length element will be invalid. This problem does not occur if using the nil attribute.
Note - Where a field is defined as mandatory in the schema, it must not contain a nil value.
6. WSDL and XSDs