SWIM Standards Evolution Workshop

Transcription

1 SWIM Standards Evolution Workshop SWIM Service Description Specification Supporting Material Walter Van Hamme EUROCONTROL 26 June 2018

2 Go to Enter Passcode SUPPORTMAT

3 Objectives About Supporting Material (Need and Characteristics) Reminder on service description specification Emerging Supporting Material contextual for specification as a whole for an individual requirement complementing the specification Overview of key emerging Supporting Material Discussion

4 Objectives Overall Goal Support implementation of the service description specification Concrete Objective Develop supporting material to ensure that the SWIM Specification for Service Description is: Understood by users in a similar way; Supported by examples; Used effectively This workshop is expected to be the start point for the development present areas of work that have emerged (eg from Consultation) seek for contribution (in the form of Community of Interest) discuss (eg priorities) After the workshop, it is expected that the Community of Interest develops Supporting Material eventually, the developed Supporting Material is made available by ECTL

5 About Supporting Material Needs & Characteristics

6 Need for Supporting Material Consultation comments SOR, minutes and Annex B Lessons from implementation support What was learned already eg from EUROCAE, SWIM Governance IP, etc. Further re-use of SESAR 1 material Stakeholders feedback

7

8 Characteristics of supporting material Scope = part of the specification that is supported contextual Eg introduction to the spec the whole specification Eg a complete example; a template an individual requirement Eg SWIM-SERV-012 Service access and use conditions a complement to the specification Eg description of a non implemented service Other characteristics explanatory vs best practice level of difficulty level of maturity (how far we ve got input material) urgency (as indicated by implementers) priority (as to be defined by the CoI)

9 Reminder on the Service Description specification

10

11

12 Discover Consider using Implement consuming client Typical usage good use of the service service consumer running service service provider describes uses uses produces - covers the information needs of business experts, operational experts and technical experts follows service description specification enter your presentation title 12

13 Zoom on a requirement Which information is needed Requirement (excerpt from the Service Description spec) Resulting information (excerpt from a service description example) enter your presentation title 13

14 list of requirements (1/2) Identifier Title Level General Requirements SWIM-SERV-001 Service description coverage M SWIM-SERV-002 Service description language M SWIM-SERV-003 Define abbreviations and acronyms M SWIM-SERV-004 Use standard abbreviations and acronyms R SWIM-SERV-005 Service description identification M SWIM-SERV-006 Service identification M SWIM-SERV-007 Service abstract M SWIM-SERV-008 Service provider M SWIM-SERV-009 Service categories M SWIM-SERV-010 Service standard reference M SWIM-SERV-011 Operational needs M SWIM-SERV-012 Service functionality M SWIM-SERV-013 Service access and use conditions M SWIM-SERV-014 Quality of service M SWIM-SERV-015 Technical constraint R 14

15 list of requirements (2/2) Identifier Title Level Service Interface Requirements SWIM-SERV-016 Service interfaces M SWIM-SERV-017 Message exchange pattern M SWIM-SERV-018 Service profile and interface bindings M SWIM-SERV-019 Service interface protocols and data format M SWIM-SERV-020 Machine-readable service interface definition M Cond SWIM-SERV-021 Service operations M SWIM-SERV-022 Information definition M SWIM-SERV-023 AIRM conformance M SWIM-SERV-024 Filter capabilities M SWIM-SERV-025 Service behaviour M SWIM-SERV-026 Model view R Other Requirements SWIM-SERV-027 Service validation M SWIM-SERV-028 Service monitoring M Cond SWIM-SERV-029 Examples of Code R 15

16 Contextual Supporting Material

17 Contextual supporting material context & narrative Emerging supporting material Every time I introduce to the service description specification, I use the 2 animated slides just shown This material is not in the spec It could be helpful to people interested in implementing the spec These animated slides could be transformed as supporting material, and thus be made available widely can be augmented with Annex A on purpose and use of a Service Description

18 Supporting Material for the specification as a whole

19 For the specification as a whole example(s) and template Example(s) and template are obvious elements that would facilitate implementation of the specification Synergy can be gained by joint work between the 2 supporting material

20 For the specification as a whole XML Schema Need has been identified to have a service description in a structured notation such as XML or JSON, allowing the service description to be processed An XML Schema for service description is being developed in SWIM Governance IP, with the objectives automated compliance checking upload in SWIM Registry fully aligned and traced to the requirements of the Service Description specification Synergy can be gained by joint work between XML Schema and template

21 Supporting Material for an individual requirement

22 Proposed structure Next to the Requirement explanatory and/or example(s)

23 req SWIM-SERV-009 Service categories Need for an agreed service categorisation scheme was recognised early A service categorisation scheme is being developed in SWIM Governance IP for use in SWIM service description for use in SWIM Registry

24 req SWIM-SERV-013 Service access and use conditions Clear need recognised (in Drafting Group and in consultation comments) to be More concrete More detailed

25 req SWIM-SERV-026 Model view Consultation comments emphasised the usefulness of model views Reminder: Not mandatory as not want to exclude services for which no such model exists Re-use SESAR 1 ISRM work (Rulebook and Modelling Guidelines) Rework needed, in particular to align with the spec terminology

26 More supporting material for individual requirements More requirements would benefit from supporting material here some examples of such need req SWIM-SERV-017 Message exchange pattern need: clarification, eg on potential difference with MEP at technical level req SWIM-SERV-021 Service operations need: description of technical details and technology related information in particular when design style is not operation oriented, such as RESTful design or AMQP implementations req SWIM-SERV-022 Information definition need: clarification, eg on potential addition compared to the Information Definition spec req SWIM-SERV-011Operational needs Need: indication of relationship to PCP and/or SESAR Deployment Plan

27 Supporting Material complementing the specification

28 Supporting Material complementing the specification The scope of the specification is the description of implemented services. This specification considers which information needs to be provided to service consumers about implemented services. the requirements prescribe the minimum set of elements to be contained by a service description Stakeholders have pointed out additional needs, going beyond the prescribed description of implemented services beyond the prescribed minimum set of information beyond implemented services beyond description of services

29 complementing the specification additional optional information The specification defines the minimum set of information the requirements prescribe the minimum set of elements to be contained by a service description It includes shall and should requirements defining mandatory and recommended information It does not include may requirements not telling anything about optional information Additional information can be freely added, as the service provider sees fit, for the benefit of the service consumer So why should this be discussed? Some of this additional information seems to be recurring Opportunity to harmonise additional optional information Eg could be added to a template could be put on a checklist as a reminder

30 complementing the specification additional optional information (cont d) Examples of additional optional information concepts related to the service non-trivial services descriptions benefit from additional information that explain concepts related to the service (or additional context information) example: explaining Forecast Datasets, Simulation Datasets, or Proposal Flights geographical extent of the service often a service as a limited geographical applicability such an airport, a State, an airspace, or a series of those the on going work on service categories consider adding this as a series of values in a geographical extent category which makes sense as this can easily be used during service discovery list of consumed services see consultation comments.. TBD

31 complementing the specification non-implemented services (need)

32 complementing the specification non-implemented services (case 1) Case 1: Provider dependent service, not implemented yet A provider wants to describe a service that is not operational yet Description is very similar to an implemented service with some differences eg life-cycle information (status, timeline) eg possible missing info (technology details, endpoint, validation, ) The on-going work on service categories has identified an availability status with values Prospective, Operational, Retired use Prospective value within service categories clearly helps Case 2: Provider independent service

33 complementing the specification non-implemented services (case 2) Case 1: Provider dependent service, not implemented yet Case 2: Provider independent service A service described independently of any provider implementations Notion well known. Several names circulating: generic service, logical service, service type, service definition, provider independent service, SOA Best Practice to define such a service as a first step, before a service description supports interoperability (see SESAR 1 ISRM) early support requests have been for provider independent services SWIM Governance IP has started work on this subject under the name Service Definition one of the results is defining the content of such description as a subset of the specification requirements

34 complementing the specification non-implemented services (case 2) Identifier Title General Requirements Service Defintion Comment SWIM-SERV-001 Service description coverage yes Should focus on one specific "thing" SWIM-SERV-002 Service description language yes SWIM-SERV-003 Define abbreviations and acronyms yes SWIM-SERV-004 Use standard abbreviations and acronyms yes SWIM-SERV-005 Service description identification yes SWIM-SERV-006 Service identification SWIM-SERV-007 Service abstract yes SWIM-SERV-008 Service provider no SWIM-SERV-009 Service categories yes SWIM-SERV-010 Service standard reference yes SWIM-SERV-011 Operational needs yes SWIM-SERV-012 Service functionality yes SWIM-SERV-013 Service access and usage conditions yes If there are Provider independent ac SWIM-SERV-014 Quality of service yes If there are minimum requirements SWIM-SERV-015 Technical constraint yes If there are identified technical cons Service Interface Requirements SWIM-SERV-016 Service interfaces partial all but the FQNA SWIM-SERV-017 Message exchange pattern yes SWIM-SERV-018 Service profile and interface bindings yes Discussion need in Compliance Polic SWIM-SERV-019 Service interface protocols yes SWIM-SERV-020 Machine-readable service interface definition yes This one needs good examples to va SWIM-SERV-021 Service operations Needs to be discussed if the baselin SWIM-SERV-022 Information Definition yes May be incomplete in the definition SWIM-SERV-023 AIRM conformance statement yes Discussion need in Compliance Polic SWIM-SERV-024 Filter capabilities yes SWIM-SERV-025 Service behaviour yes if operations are defined (pending d SWIM-SERV-026 Model view yes Other Requirements SWIM-SERV-027 Service validation no SWIM-SERV-028 Service monitoring no SWIM-SERV-029 Examples of Code yes Case 2: Provider independent service Service definition mapping to the spec requirements (as from SWIM Governance IP)

35 complementing the specification beyond description service design clear need expressed for material going beyond the description of services Opportunity for additional reuse of SESAR 1 material, such as naming conventions

36 complementing the specification service design (cont d) Naming conventions eg for names of service, interfaces, and operations SESAR 1 material to be re-used Other elements requested during consultation acceptable limits of quality of service define the acceptable limits of quality of service based on service profile or security conditions service based mechanism to provide scheduled outages The service provider needs to describe the schedule of planned outages and a realtime service based mechanism to distribute that information to service consumers standardise or recommend service monitoring protocols etc

37 Overview of key emerging Supporting Material

38 Overview of key emerging supporting material Material origin req maturity urgency priority comment contextual Context and narrative S - Good 2 spec as a whole Complete example C All Medium 1 Template C All Good 1 XML Schema G All Medium 2 related to Registry individual req Service Categories C G 009 Good 2 related to Registry Access conditions 013 Low 4 Model view C 026 Medium 4 reuse SESAR 1 complementing additional optional information non-implemented service design (eg naming convention) S - Medium 4 Eg related to ICAO C G - Medium 2 service definition C - Good & Low 4 reuse SESAR 1

39 Community of Interest (CoI) Shared interest in Exchanging ideas on applying the specification Developing the spec s supporting material Maintaining the spec s supporting material

40 Discussion

41

42 Prepare strawman to kick-start the drafting? Establish the community Agree the overall plan

43