Docstoc

HMA Arch_TN_1.7

Document Sample
HMA Arch_TN_1.7 Powered By Docstoc
					           Title:           Architectural Design Technical Note
           Contract Ref.:   P-E190/DGIGSD-3556-05
           Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
           Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007




         GMES Heterogeneous Mission
                Accessibility




Title:        Architectural Design Technical Note




                                            Pag. 1/182
                    Title:           Architectural Design Technical Note
                    Contract Ref.:   P-E190/DGIGSD-3556-05
                    Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                    Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007



                                           Abstract
This document describes the Reference Model for GMES HMA Architecture focussing in particular
on the “Earth Observation Data Access Integration Layer”




                                                     Pag. 2/182
                                 Title:                  Architectural Design Technical Note
                                 Contract Ref.:          P-E190/DGIGSD-3556-05
                                 Int. Ref.:              P-E190/DGIGSD-0399-06                             Issue:       1    Rev.:       7
                                 Proj. Ref.:             HMA-DD-DAT-EN-001                                 Date:             14/09/2007




                                                   Table of Contents
1     Introduction ............................................................................................................................................ 18
    1.1       Purpose of the document ........................................................................................................... 18
    1.2       Background ................................................................................................................................... 18
    1.3       Acronyms and Definitions............................................................................................................ 19
    1.4       References..................................................................................................................................... 19
      1.4.1       Applicable documents ........................................................................................................... 19
      1.4.2       Reference documents ............................................................................................................ 20
      1.4.3       Bibliography .............................................................................................................................. 22
    1.5       Overview of the document ........................................................................................................ 23
2     Process of the GMES HMA Architectural Design............................................................................... 25
    2.1       Application of the Reference Model of Open Distributed Processing (RM-ODP) ............. 25
      2.1.1       RM-ODP Overview.................................................................................................................... 25
      2.1.2       Mapping of RM-ODP to the GMES-HMA Architectural Design Process........................... 26
      2.1.3       Service Taxonomy .................................................................................................................... 28
      2.1.4       Simple Service Architecture.................................................................................................... 29
3     Enterprise Viewpoint.............................................................................................................................. 30
    3.1       Overview ........................................................................................................................................ 30
    3.2       Business Perspective, Purpose and Scope................................................................................ 30
      3.2.1       Relationship with other projects ............................................................................................. 32
          3.2.1.1         INSPIRE [RD50] .................................................................................................................. 32
          3.2.1.2         ORCHESTRA ...................................................................................................................... 34
          3.2.1.3         SSE ...................................................................................................................................... 34
          3.2.1.4         FedEO................................................................................................................................ 35
          3.2.1.5         HMA Testbed: HMA-T ...................................................................................................... 36
    3.3       HMA High level architecture requirements .............................................................................. 36
    3.4       Evolution of the HMA Architecture ............................................................................................ 38
4     Information Viewpoint .......................................................................................................................... 39
    4.1       HMA Information Model .............................................................................................................. 39
      4.1.1       Service Metadata for Service Orchestration and Invocation........................................... 40
      4.1.2       Service Metadata for Human Readable Services Discovery............................................ 42
      4.1.3       Collection Metadata............................................................................................................... 43
      4.1.4       Product Metadata ................................................................................................................... 44
      4.1.5       Order .......................................................................................................................................... 46
          4.1.5.1         Order Options................................................................................................................... 47
          4.1.5.2         Product Order & Subscription........................................................................................ 47
      4.1.6       Programming ............................................................................................................................ 48
      4.1.7       User Management Data ......................................................................................................... 50
      4.1.8       Satellite / Sensor metadata .................................................................................................... 51
      4.1.9       Transaction Tracking Data ...................................................................................................... 51
5     Service Viewpoint .................................................................................................................................. 53
    5.1       Introduction ................................................................................................................................... 53


                                                                                 Pag. 3/182
                                Title:                   Architectural Design Technical Note
                                Contract Ref.:           P-E190/DGIGSD-3556-05
                                Int. Ref.:               P-E190/DGIGSD-0399-06                            Issue:       1     Rev.:       7
                                Proj. Ref.:              HMA-DD-DAT-EN-001                                Date:              14/09/2007

    5.2       Services Composition ................................................................................................................... 53
      5.2.1       User Defined Chaining Pattern .................................................................................................. 53
      5.2.2       Workflow-Managed Services Chaining...................................................................................... 54
      5.2.3       Aggregate Services Chaining..................................................................................................... 55
    5.3       Services Functional Classification............................................................................................... 56
    5.4       HMA Services ................................................................................................................................. 57
    5.5       Service Descriptions...................................................................................................................... 59
      5.5.1       Service Registration.................................................................................................................. 61
      5.5.2       Orchestration Service .............................................................................................................. 64
      5.5.3       Monitoring & Control Service ................................................................................................. 66
      5.5.4       Collection Discovery Service .................................................................................................. 68
      5.5.5       Service Discovery Service ....................................................................................................... 71
      5.5.6       Service Configuration Discovery Service.............................................................................. 74
      5.5.7       Catalogue Service ................................................................................................................... 79
      5.5.8       Programming Service .............................................................................................................. 81
      5.5.9       Order Service ............................................................................................................................ 87
      5.5.10          User Management Service................................................................................................. 91
      5.5.11          On-line Data Access Services ............................................................................................ 91
          5.5.11.1            Virtual FTP Service........................................................................................................ 92
          5.5.11.2            FTP.................................................................................................................................. 94
          5.5.11.3            WMS............................................................................................................................... 95
          5.5.11.4            WCS ............................................................................................................................... 97
      5.5.12          Help & Documentation Desk Service ............................................................................... 99
6     Engineering Viewpoint........................................................................................................................ 101
    6.1       HMA Service Instances Allocation ........................................................................................... 101
      6.1.1       Services Instances allocation trade-offs criteria................................................................ 104
    6.2       Services Architecture ................................................................................................................. 105
      6.2.1       Services Instance.................................................................................................................... 105
          6.2.1.1         HM Collection Discovery Service Instance................................................................ 106
          6.2.1.2         HM Service Discovery Service Instance ..................................................................... 106
          6.2.1.3         HM Service Configuration Discovery Service Instance ........................................... 107
          6.2.1.4         HM Catalogue Service Instance................................................................................. 107
          6.2.1.5         HM Programming Service Instance ............................................................................ 107
          6.2.1.6         HM Order Service Instance .......................................................................................... 108
          6.2.1.7         HM User Management Service Instance ................................................................... 109
          6.2.1.8         HM Service Registration Service Instance.................................................................. 109
          6.2.1.9         HM Orchestration Service Instance ............................................................................ 109
          6.2.1.10            HM Monitoring & Control Service Instance........................................................... 109
          6.2.1.11            HM Virtual FTP Service Instance .............................................................................. 109
      6.2.2       EO DAIL Components Description....................................................................................... 110
          6.2.2.1         Service Container.......................................................................................................... 112
          6.2.2.2         Database........................................................................................................................ 112
          6.2.2.3         Workflow Engine ............................................................................................................ 112
          6.2.2.4         User Profile Repository ................................................................................................... 115
          6.2.2.5         Collection Discovery Server ......................................................................................... 115
                                                                                Pag. 4/182
                            Title:                   Architectural Design Technical Note
                            Contract Ref.:           P-E190/DGIGSD-3556-05
                            Int. Ref.:               P-E190/DGIGSD-0399-06                            Issue:       1     Rev.:       7
                            Proj. Ref.:              HMA-DD-DAT-EN-001                                Date:              14/09/2007

      6.2.2.6        Service Discovery Server............................................................................................... 115
      6.2.2.7        Service Description Registry ......................................................................................... 115
      6.2.2.8        Catalogue Service ........................................................................................................ 116
      6.2.2.9        Order Service ................................................................................................................. 117
      6.2.2.10           Programming Service ............................................................................................... 118
      6.2.2.11           Virtual FTP Service...................................................................................................... 120
6.3       Services Implementation in partner Ground Segments ....................................................... 122
  6.3.1      GS Catalogue Service Instance........................................................................................... 122
  6.3.2      GS Programming Service Instance...................................................................................... 123
  6.3.3      GS Order Service Instance.................................................................................................... 123
  6.3.4      GS User Management Service Instance............................................................................. 124
  6.3.5      FTP ............................................................................................................................................. 124
  6.3.6      WMS & WCS............................................................................................................................. 124
  6.3.7      GS Service & Collections Registration ................................................................................. 124
  6.3.8      Virtual FTP Service Agents ..................................................................................................... 124
6.4       Dynamical Model ....................................................................................................................... 125
  6.4.1      Collections & Services............................................................................................................ 125
      6.4.1.1        Push approach .............................................................................................................. 125
      6.4.1.2        Pull approach................................................................................................................. 126
  6.4.2      Catalogue Search ................................................................................................................. 127
  6.4.3      Ordering................................................................................................................................... 128
      6.4.3.1        Get Options scenario.................................................................................................... 129
      6.4.3.2        Get Quotation scenario ............................................................................................... 130
      6.4.3.3        Submit scenario ............................................................................................................. 131
      6.4.3.4        Status notification scenario.......................................................................................... 132
      6.4.3.5        Get Status scenario ....................................................................................................... 133
      6.4.3.6        Cancel scenario ............................................................................................................ 133
      6.4.3.7        Retrieval of on-line available data scenario............................................................. 135
  6.4.4      Programming .......................................................................................................................... 135
      6.4.4.1        DescribeGetFeasibility scenario.................................................................................. 135
      6.4.4.2        Get Feasibility scenario................................................................................................. 136
          6.4.4.2.1       Light / estimate feasibility ....................................................................................... 136
          6.4.4.2.2       Full feasibility ............................................................................................................. 137
      6.4.4.3        Submit scenario ............................................................................................................. 138
      6.4.4.4        Get Status scenario ....................................................................................................... 139
      6.4.4.5        Cancel Programming scenario................................................................................... 140
      6.4.4.6        Status notification scenario.......................................................................................... 140
      6.4.4.7        DescribeResultAccess scenario................................................................................... 141
  6.4.5      On-line Data Access Scenarios............................................................................................ 141
      6.4.5.1        On-line Collection ......................................................................................................... 142
      6.4.5.2        On-line Access ............................................................................................................... 143
      6.4.5.3        On-line Consumption.................................................................................................... 144
      6.4.5.4        Virtual FTP Service .......................................................................................................... 146
6.5       User Identity Management ....................................................................................................... 146
  6.5.1      Policy Enforcement Point – PEP............................................................................................ 147
                                                                            Pag. 5/182
                                Title:                  Architectural Design Technical Note
                                Contract Ref.:          P-E190/DGIGSD-3556-05
                                Int. Ref.:              P-E190/DGIGSD-0399-06                          Issue:      1     Rev.:      7
                                Proj. Ref.:             HMA-DD-DAT-EN-001                              Date:             14/09/2007

      6.5.2       Identity Provider...................................................................................................................... 147
      6.5.3       User Registry............................................................................................................................. 148
      6.5.4       HM Services ............................................................................................................................. 148
7     Technology Viewpoint ........................................................................................................................ 149
    7.1       Main Design Drivers .................................................................................................................... 149
      7.1.1       Service Oriented Architecture (SOA).................................................................................. 149
      7.1.2       EO-DAIL Architecture Technologies Selection................................................................... 151
      7.1.3       Selection of Standards and Definition of New Protocols ................................................. 151
          7.1.3.1         Selection of Standards.................................................................................................. 151
          7.1.3.2         Definition of new protocols.......................................................................................... 154
      7.1.4       Can be implemented with COTS or Open-Source ........................................................... 156
8     Traceability Matrix................................................................................................................................ 158
    8.1       High level requirements traceability matrix ............................................................................ 158
    8.2       Functional Requirements and Scenarios traceability Matrix ............................................... 162
      8.2.1       Scenarios traceability Matrix ................................................................................................ 163
      8.2.2       Functional Requirements traceability Matrix ..................................................................... 167
    8.3       Scenarios vs. Protocol traceability Matrix ............................................................................... 180




                                                                              Pag. 6/182
                                Title:                 Architectural Design Technical Note
                                Contract Ref.:         P-E190/DGIGSD-3556-05
                                Int. Ref.:             P-E190/DGIGSD-0399-06                       Issue:      1    Rev.:      7
                                Proj. Ref.:            HMA-DD-DAT-EN-001                           Date:            14/09/2007



                                                Indexes of Figures
Figure 1: HMA Reference Model.................................................................................................................. 28
Figure 2: HMA Project context...................................................................................................................... 31
Figure 3: SSE as HMA Prototype [AD09]....................................................................................................... 35
Figure 4: HMA geographical context.......................................................................................................... 37
Figure 5: Relationship between SLA and DAA. .......................................................................................... 38
Figure 6: Service Metadata UDDI model .................................................................................................... 41
Figure 7: Mapping between WSDL sections and UDDI data model. ..................................................... 42
Figure 8: Service Metadata UML model (from [RD04])............................................................................. 43
Figure 9: ISO 19115 Basic Classes. ................................................................................................................ 44
Figure 10: EarthObservationProduct type hierarchy [AD11], [AD08]. .................................................... 45
Figure 11: Order Option structure................................................................................................................. 47
Figure 12: Product Order structure............................................................................................................... 48
Figure 13: Coverage Order structure........................................................................................................... 49
Figure 14: HMA transaction tracking information model (Courtesy of Spacebel)............................... 52
Figure 15: User Defined Services Composition ........................................................................................... 54
Figure 16: Workflow-Managed Services Composition. ............................................................................. 55
Figure 17: Aggregated Services Composition. .......................................................................................... 56
Figure 18: Services Classification. ................................................................................................................. 57
Figure 19: HM Service Instances vs. GSs Service Instances. ..................................................................... 59
Figure 20: Relationships between HM and GS service instances.......................................................... 103
Figure 21: Service Allocation....................................................................................................................... 105
Figure 22: EO DAIL level-1 decomposition................................................................................................ 110
Figure 23: Example BPEL process: Spot Image WCTS service chain Fig 1 ([RD40]). ........................... 113
Figure 24: Example BPEL process: Spot Image WCTS service chain Fig 2 ([RD40]). ........................... 114
Figure 25: Virtual FTP Service architecture. ............................................................................................... 121
Figure 26: Collections and services registration from remote GS operators. ...................................... 126
Figure 27: Harvesting of Collection & Service metadata....................................................................... 126
Figure 28: Catalogue search scenario...................................................................................................... 127
Figure 29: Order submission / subscription scenario................................................................................ 128
Figure 30: Get Options Scenario. ............................................................................................................... 129
Figure 31: Get Quotation Scenario............................................................................................................ 130
Figure 32: Submit Scenario. ......................................................................................................................... 131
Figure 33: Status notification scenario....................................................................................................... 132
Figure 34: Get Status Scenario.................................................................................................................... 133
Figure 35: Cancel Scenario......................................................................................................................... 134
Figure 36: Retrieval of on-line available data scenario.......................................................................... 135
Figure 37: DescribeGetFeasibility scenario. .............................................................................................. 136
Figure 38: GetFeasibility – light / estimate feasibility. .............................................................................. 137
Figure 39: Get Feasibility Scenario – Full feasibility................................................................................... 137
Figure 40: Submit Scenario. ......................................................................................................................... 138
Figure 41: Get Status Scenario.................................................................................................................... 139
Figure 42: Cancel Scenario......................................................................................................................... 140
Figure 43: Status notification scenario....................................................................................................... 140

                                                                            Pag. 7/182
                               Title:               Architectural Design Technical Note
                               Contract Ref.:       P-E190/DGIGSD-3556-05
                               Int. Ref.:           P-E190/DGIGSD-0399-06                     Issue:      1   Rev.:      7
                               Proj. Ref.:          HMA-DD-DAT-EN-001                         Date:           14/09/2007

Figure 44: DescribeResultAccess scenario................................................................................................ 141
Figure 45: On-line Collection scenario. ..................................................................................................... 142
Figure 46: On-line Access Scenario. .......................................................................................................... 143
Figure 47: On-line Consumption scenario................................................................................................. 144
Figure 48: Virtual FTP Service Scenario. ..................................................................................................... 146
Figure 49: Identity Management Architecture. ....................................................................................... 147
Figure 50: HMA Collection and Service Discovery Document Tree (Courtesy of Spacebel)........... 155
Figure 51: HMA Catalogue Document Tree (Courtesy of Spacebel). ................................................. 156




                                                                         Pag. 8/182
                                Title:               Architectural Design Technical Note
                                Contract Ref.:       P-E190/DGIGSD-3556-05
                                Int. Ref.:           P-E190/DGIGSD-0399-06                      Issue:      1    Rev.:     7
                                Proj. Ref.:          HMA-DD-DAT-EN-001                          Date:            14/09/2007



                                                Indexes of Tables
Table 1: Mapping of the RM-ODP Viewpoints to GMES HMA ................................................................. 27
Table 2: HMA Services High Level Description and Classification........................................................... 59
Table 3:           HM and GS service instances. ............................................................................................. 102
Table 4: Services allocation table. ............................................................................................................. 105
Table 5: HM Service Instances vs. Architectural Components. ............................................................. 112




                                                                          Pag. 9/182
                     Title:             Architectural Design Technical Note
                     Contract Ref.:     P-E190/DGIGSD-3556-05
                     Int. Ref.:         P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                     Proj. Ref.:        HMA-DD-DAT-EN-001                 Date:        14/09/2007


                                  Document Signature Table
                     Name                     Function                        Signature               Date

  Author         D. Marchionni                                                                      14/09/2007

Verification

 Approval




                                   Document Status Sheet
Issue            Date                                                 Comments

 1.0           31/05/2006           First Issue

1.0.1          16/06/2006

1.0.2          12/07/2006           Draft for Progress Meeting

 1.1           21/07/2006           Updated version after PDR

 1.2           28/08/2006           Updated version for CDR

 1.3           21/11/2006           Updated version for AR

 1.4           20/02/2007           Updated version for FP

 1.5           21/05/2007           Updated version after FP

 1.6           13/06/2007           Updated version for IMPR

 1.7           14/09/2007           Final version.




                                                        Pag. 10/182
                Title:           Architectural Design Technical Note
                Contract Ref.:   P-E190/DGIGSD-3556-05
                Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:      1   Rev.:   7
                Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:           14/09/2007


                         Document Change records
Issue      Reason for change               Involved                         Type of modification
                                          Paragraph

 1.0            First Issue                    All        First issue of the document

1.0.1        Issue after PDR                 §7, §8       Updated Technology View
                                                          Added section 8: Traceability Table

1.0.2   Issue for 12-13/7/2006 PM              All

 1.1            Action 1                       §5         Added row to each service description
                                                          referencing the corresponding INSPIRE
                                                          Network Service.

 1.1          Action 15, 16                   §1.5        Updated description of standing order and
                                                          coverage order.

 1.1           Action 17                       §5         Updated           description    of   Programming
                                                          Service.

 1.1           Action 18                       §5         Updated description of Order Service.

 1.1           Action 19                     §1.4.1       Added GSCB report in the list of applicable
                                                          documents;
                                              §6.5
                                                          Added SIEMENS contribution               on   User
                                                          Management in §6

 1.1           Action 20                    §5.5.10       Updated description of Mission Planning
                                                          using S.Vazzana PDR presentation slides

 1.1           Action 21                     §3.4.1       Added commercial or distributed entities in
                                                          the context diagrams at §3.4.1 and 6.1.1
                                             §6.1.1

 1.1           Action 22                      §6.3        Added sentence at §6.3

 1.1           Action 23                       §4         Enhanced all section of the Information
                                                          View

 1.1           Action 24                      §6.4        Added dynamical model.



 1.1           Action 25                       §8         Added traceability table.

 1.1           Action 26                      §3.4        Added functional analysis section with
                                                          context.
                                                          Improved EO DAIL description at §6.

 1.1           Action 27                      §5.3        Added Section 5.3 “Services Classification”;
                                             §5.4.x       updated section 5.5.x.

                                                 Pag. 11/182
                 Title:           Architectural Design Technical Note
                 Contract Ref.:   P-E190/DGIGSD-3556-05
                 Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:      1   Rev.:    7
                 Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:           14/09/2007


Issue      Reason for change                Involved                         Type of modification
                                           Paragraph

 1.1            Action 28                      §5.2        Added paragraph                  explaining       service
                                                           chaining.

 1.1            Action 29                  See action      See action 41
                                               41

 1.1            Action 31                     §4.1.1       Enhanced Information View.
                                              §4.1.2

 1.1            Action 35                     §1.4.1       Updated applicable documents

 1.1            Action 36                      §3.2        Updated relationship with other projects
                                                           section.

 1.1            Action 38                     §6.1.1       Updated services allocation criteria

 1.1            Action 39                       §4         Enhanced the information view.

 1.1            Action 40                       §6         Enhanced architecture description;
                                                           Added dynamical model.

 1.1            Action 41                      §7.1        Added section             for     listing   the     HMA
                                                           standards;
                                                           Added      reference                     to      CEN
                                                           recommendations    for                 selection   of
                                                           standards.

 1.1            Action 42                       §8         Added traceability table.

 1.2            Action 23                     §3.4         Removed
                                          §5.1, 5.4,6.1    Updated      removing                 references      to
                                                           Functional Analysis

 1.2    Update the Order Service             §5.5.9,       Updated operation                names;       updated
              operations                    §6.2.1.6,      sequence diagrams.
                                            §6.2.2.9,
                                             §6.3.3,
                                            §6.4.3.x

 1.2    Update the Programming           §4.1.6, §5.5.8, Updated operation                  names;       updated
           Service operations              §6.2.1.5,     sequence diagrams.
                                           §6.2.2.10,
                                            §6.3.2,
                                            §6.4.4.x

 1.2    Update the Catalogue and         §5.5.5, §5.5.4, Updated operation                  names;       updated
          Discovery operations to           §5.5.7,      sequence diagrams.
                uppercase                  §6.2.1.1,
                                           §6.2.1.2,
                                           §6.2.1.4,

                                                  Pag. 12/182
             Title:           Architectural Design Technical Note
             Contract Ref.:   P-E190/DGIGSD-3556-05
             Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:      1   Rev.:   7
             Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:           14/09/2007


Issue   Reason for change               Involved                         Type of modification
                                       Paragraph
                                       §6.2.2.5,
                                       §6.2.2.6,
                                       §6.2.2.8,
                                     §6.3.1, §6.4.1,
                                         §6.4.2



 1.2        Action 24                    §1.4.2,       Added reference document;                updated
                                         §6.2.2.3      BPEL workflow figure.

 1.2       Actions 25                 Traceability     Updated HL-GEN-510 comment
                                         Matrix

 1.2        Action 26                     §2.1.2       Updated table in section

 1.2        Action 28                 §2.1.3, §5.3,
                                      §5.4, §5.5.x

 1.2        Action 29                      §3.2        Repeated paragraphs removed

 1.2        Action 30                      §3.2        Removed paragraphs

 1.2        Action 37                      §5.2        Phrase removed

 1.2        Action 38                 §5.2.1, 5.5.2    Updated specifying that the functionality is
                                                       reserved to authorised users (e.g. Service
                                                       Providers)

 1.2        Action 39                  §5.4, 5.5.14    Help & Documentation Desk                Services
                                                       added even if not yet detailed

 1.2        Action 40                     §6.1.1       Dual role of Distributing & Commercial
                                                       entities explained

 1.2        Action 41                 §6.2.2, 7.1.2    Removed references to technology in this
                                                       section and moved to new section 7.1.2

 1.2        Action 42                     §6.2.2       Added links to section 7.1.2 for the relevant
                                                       selected technologies

 1.2        Action 43                    §1.4.1,       Added Applicable Document; Updated
                                        §3.2.1.3,      Fig. 3-2 caption; Updated Fig. 4-5 caption;
                                         §4.1.9,       Updated caption of Fig. 4-9; updated
                                        §7.1.3.2       caption of Fig. 6-24.

 1.2        Action 44                     §1.4.2       Ref doc table revised

 1.2        Action 47                   §1.3, 1.5      Updated section 1.3 referencing HMA
                                                       Acronyms and Definitions document.
                                                       Section 1.5 Definition removed.


                                              Pag. 13/182
             Title:           Architectural Design Technical Note
             Contract Ref.:   P-E190/DGIGSD-3556-05
             Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:      1   Rev.:   7
             Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:           14/09/2007


Issue   Reason for change               Involved                         Type of modification
                                       Paragraph

 1.2        Action 48                      §1.3        See previous comment

 1.2        Action 50                      §1.3        See previous comment

 1.2        Action 51                 §2.1.3, 5.5.x    Managed as per Action 48

 1.2        Action 52                     §2.1.4       updated

 1.2        Action 53                     §2.1.4       Sync/async     service     replaced      by
                                                       sync/async service operation

 1.2        Action 54                     §2.1.4       Updated paragraph.

 1.2        Action 58                    §6.2.1.1      Term replaced

 1.2        Action 64                     §4.1.x       Moved document references at the end of
                                                       the section.

 1.2        Action 65                      §4.1        Section updated

 1.2        Action 66                     §1.4.2       Table updated

 1.2        Action 67                     §1.4.2       Reference removed

 1.2        Action 68                  §5.2, 5.2.1,    Sections updated
                                          5.2.2

 1.2        Action 69                 §5.4, §5.5.13 Updated service description.

 1.3         CDR#8                         §3.3        Replaced “should” with “shall”

 1.3         CDR#9                         §3.3        Added relationships figure between DAA
                                                       and SLA

 1.3        CDR#10                      §4.1.5.2;      Add subscriptions
                                         §5.5.9;
                                        §6.2.1.6;
                                         §6.4.3

 1.3        CDR#13                        None         How the Service and Collection Discovery
                                                       Services are used is explained in §6.4.

 1.3        CDR#14                      §6.4.1.2;      Added error management to the dynamic
                                         §6.4.2;       model.
                                        §6.4.3.1;
                                        §6.4.3.2;
                                        §6.4.3.3;
                                        §6.4.3.5;
                                         6.4.3.6;
                                        §6.4.4.1



                                              Pag. 14/182
                   Title:           Architectural Design Technical Note
                   Contract Ref.:   P-E190/DGIGSD-3556-05
                   Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:      1   Rev.:        7
                   Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:           14/09/2007


Issue        Reason for change                Involved                         Type of modification
                                             Paragraph

 1.3               CDR#15                  §5.5.4; §5.5.5; Added Harvesting                   to       collection   and
                                             §6.2.1.1;     Service discovery.
                                             §6.2.1.2;
                                             §6.2.2.5;
                                             §6.2.2.6;
                                             §6.4.1.1;
                                              §6.4.1.2

 1.3               CDR#62                       §2.1.2       Updated bullet list introducing the table.

 1.3               CDR#63                        §3.2        Updated description.

 1.3               CDR#64                       §4.1.1       Updated

 1.3               CDR#65                  §4.1.4, §5.5.7 Added explanation on how the different
                                                          EO schemas can be required by clients.

 1.3    Align with updated Order ICD          §4.1.5.1;
                                              §4.1.5.2;
                                               §5.5.9

 1.3         Align with updated                §5.5.8;
             Programming ICD                  §6.2.2.10;
                                               §6.4.4.x

 1.4     Added traceability between              §8.3
           scenarios and protocols
        (provided by the Consortium).

 1.4    Astrium revisions for posting to          All
                     OGC

 1.4    Align with updated Order ICD              All

 1.4         Align with updated                   All
             Programming ICD

 1.5                FP#63                      §3.2.1.1      Updated INSPIRE description.
                                                             Added FedEO

 1.5                FP#64                  §4.1.7,           User Mgmgt updates:
                                           §5.5.11, Fig 6-
                                                             Updated user profile; Updated User
                                           2,    §6.2.1.7,
                                                             Management service description; Updated
                                           §6.3.4, §6.5,
                                                             User Management concept.
                                           §6.5.x,
                                           §6.2.24

 1.5                FP#65                  §4.1.8, §5.4, Mission Planning updates:
                                           §5.5.10,
                                                         Updated description of Mission Planning
                                           §5.5.8, Table
                                                         Data.
                                           3, Fig 6-1,

                                                    Pag. 15/182
             Title:           Architectural Design Technical Note
             Contract Ref.:   P-E190/DGIGSD-3556-05
             Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:      1   Rev.:   7
             Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:           14/09/2007


Issue   Reason for change               Involved                         Type of modification
                                       Paragraph
                                     §6.2.1.5,      Removed      Mission   Planning  Service
                                     §6.3.2, §6.4.4 (feasibility analysis is performed by
                                                    Programming Service).
                                                       Updated           definition     of    Programming
                                                       Service.


 1.5          FP#66                  §5.4,             On-line Data Access updates:
                                     §5.5.11.x,
                                                       Added Virtual FTP Service, FTP, WCS and
                                     Table 3, Fig
                                                       WMS in the list of services. Removed Data
                                     6-1, Fig 6-2,
                                                       Access Request Service.
                                     §6.2.1.11,
                                     Table        5,
                                     §6.3.5, §6.3.6,
                                     §6.3.8,

 1.5          FP#67                      §5.5.7,       Catalogue ICD update for taking into
                                         §7.1.3.1      account the new ebRIM based ICD.

 1.5          FP#68                                    Updated list of reference doc.

 1.5          FP#71                                    §8.2 split in §8.2.1 and §8.2.2

 1.5          FP#72                                    Added mapping of WFS on US5_1 at §8.3

 1.5          FP#73                   §8.2, §8.2.1,
                                         §8.2.2

 1.5                                 §5.4, §5.5.12, Removed Processing Services
                                        table 3

 1.6                                     §7.1.3.2      Updated ICDs document tree.

 1.6                                 §1.4.1, §5.5.4, Added OGC 07-038 as ICD for Collection
                                        §5.5.5,      and Service Discovery.
                                       §6.2.1.1,
                                       §6.2.1.2,
                                        6.2.2.5,
                                       §6.2.2.6,
                                         §6.4.1

 1.6                                      §6.5.x       Updated User Identity Management.

 1.6                                       §8.x        Updated Traceability Matrixes

 1.6                                    §6.2.2.11      To update Virtual FTP Service

 1.7        IMPR#41                  §1.4.1, §1.4.2 Updated    applicable                   and   reference
                                                    documents.

 1.7        IMPR#42                                    No changes


                                              Pag. 16/182
             Title:           Architectural Design Technical Note
             Contract Ref.:   P-E190/DGIGSD-3556-05
             Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:      1   Rev.:   7
             Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:           14/09/2007


Issue   Reason for change               Involved                         Type of modification
                                       Paragraph

 1.7        IMPR#43                  §1.4.2, §1.4.3 The list of reference documents has been
                                                    split into:
                                                            •   Reference documents (§1.4.2) for
                                                                the documents more close to HMA;
                                                            •   Bibliography (§1.4.3) for the more
                                                                general documents

 1.7        IMPR#44                                    No changes

 1.7        IMPR#45                      §3.2.1.5      Added paragraph for HMA-T

 1.7        IMPR#46                      §5.5.10       Added reference to the UM Architecture
                                                       and ICD.

 1.7        IMPR#47                                    No changes

 1.7        IMPR#48                      §7.1.3.2      Added history of HMA proposed ICDs

 1.7        IMPR#49                        §6.3        Updated §6.3

 1.7        IMPR#50                                    No changes are really needed.

 1.7        IMPR#51                       §5.5.8       Updated description of §5.5.8

 1.7        IMPR#52                                    No updates
                                                       No mention to ORACLE because the
                                                       architecture shall be COTS neutral.

 1.7        IMPR#53                       §8.2.2       Updated traceability matrix.

 1.7        IMPR#58                       §8.2.2       Mission Planning updated                 with   the
                                                       updated traceability matrix.

 1.7        IMPR#85                        §6.5        User Management architecture section
                                                       §6.5 has been drastically resized.




                                              Pag. 17/182
                     Title:           Architectural Design Technical Note
                     Contract Ref.:   P-E190/DGIGSD-3556-05
                     Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                     Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007



1         Introduction
1.1       Purpose of the document
This document describes the Reference Model for GMES HMA Architecture focusing in particular
on the “Earth Observation Data Access Integration Layer” that will be referred to by the acronym
EO DAIL in the rest of document.
The document contains the architecture approach, a description of the external interfaces and
references to their specification, the data model and a description of the HMA services.
The HMA Architecture is specified using an iterative analysis and design approach. This
architecture reflects the currently agreed set of requirements and operational scenarios. Further
analysis and design activities on the elements of the architecture will lead to a refined version of
the HMA Architecture.
The HMA Reference Model specification is structured according to the viewpoints of the
Reference Model for Open Distributed Processing (RM-ODP) as defined in ISO/IEC 10746-1:1998 (E)
[RD 15]


1.2       Background
The architecture of the GMES Space Component comprises the entire contribution from
spaceborne observations including a constellation of satellites together with its Ground Segment
and the necessary interfaces to the other components of GMES. The Ground Segment comprises
the Payload Data Handling including data acquisition, processing up to the appropriate level,
archiving, data communication networks and the associated data user services. The ground
segment also includes the “necessary interfaces for requesting and accessing data from national
and Eumetsat missions forming part of GMES” (RD01).


In the framework of the GMES EO Component preparatory activities, a number of studies have
been initiated ensuring the evolution of the earth observation component and services in support
to GMES. The “Heterogeneous Missions Accessibility (inter-operability)” HMA analyses the
requirements, evaluate the impact and propose an approach to allow the desired inter
accessibility across missions forming part of GMES.




                                                      Pag. 18/182
                      Title:           Architectural Design Technical Note
                      Contract Ref.:   P-E190/DGIGSD-3556-05
                      Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                      Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007



1.3      Acronyms and Definitions
Acronyms and Definitions applicable to HMA are reported in [RD39].
The following table lists the acronyms not included in the [RD-39] that are applicable to this
document.


        Acronym          Definition

ECP                      Enhanced Client or Proxy
IDP                      Identity Provider
OSP                      Orchestrated Service Provider
PDP                      Policy Decision Point
PEP                      Policy Enforcement Point
SP                       Service Provider



1.4      References

1.4.1    Applicable documents
Document Title                         Document Identifier             Issue      Date             Ref
Operation Scenarios Technical          HMA-TN-ASU-SY-0001              1.8                         AD01
Note
Requirement                Baseline    HMA-RS-ASU-SY-0001              1.6                         AD02
Document
Technical Meeting CNES (ESRIN          HMA-MOM-00XX-SPB                           03/03/2006       AD03
3/3/2006)
Ordering Services for          Earth   OGC 06-141r1                    0.9.2      27/09/2007       AD05
Observation Products
Heterogeneous             Mission      GMES-DFPR-EOPG-RP-06-           1.2        30/05/2006       AD07
Accessibility SRR Review Report        0004
GML Application Schema for             OGC 06-080r2                    0.1.4r5                     AD08
EO products
Heterogeneous             Mission      TP1650                          1.0        06/2005          AD09
Accessibility (Inter-Operability) –
Technical Proposal
Sensor Planning Service Profile        OGC 07-018r1                    0.9.4a                      AD10
for Earth Observation Sensors
OGC™ Catalogue Services                OGC 06-131                      0.1.3                       AD11
Specification 2.0 - EO Products
Extension Package for ebRIM
(ISO/TS 15000-3) Profile of CSW
2.0
HMA User Profiles                      HMA-UP-SIEM-UM-001              1.0.a                       AD12
HMA       User      Management         HMA-DD-SIE-UM-001               1.0e                        AD13

                                                       Pag. 19/182
                     Title:              Architectural Design Technical Note
                     Contract Ref.:      P-E190/DGIGSD-3556-05
                     Int. Ref.:          P-E190/DGIGSD-0399-06               Issue:   1   Rev.:   7
                     Proj. Ref.:         HMA-DD-DAT-EN-001                   Date:        14/09/2007


Document Title                           Document Identifier             Issue        Date             Ref
Concepts
User Management Architecture             HMA-DD-SPB-EN-001               1.1                           AD14
Document
HMA Mission Planning Services            HMA-RS-ASU-SY-002               1.3                           AD15
Specification
HMA On-line       Data        Access     HMA-TN-DAT-EN-001               1.2          13/06/2007       AD16
Technical Note
OGC™ Cataloguing of                ISO   OGC 07 038                      0.1.6        22/03/2007       AD17
Metadata (CIM) using               the
ebRIM profile of CS-W
OGC™       User    Management            OGC 07-118                                                    AD18
Interfaces For Earth Observation
Services



1.4.2   Reference documents
Document Title                           Document Identifier           Issue          Date             Ref
Reflection Paper: GMES Space             GAC(2004)7_Fin                               12/07/2004       RD01
Observation Component
Reference Model    for  the              OGC Ref: 05-107               1.10           14/10/2005       RD02
ORCHESTRA Architecture (RM-
OA)
Service Support Environment                                                           January          RD03
Architecture,  Model    and                                                           2006
Standards
White Paper
The      OpenGIS          Abstract       ISO/DIS 19119                 4.3            January          RD04
Specification                                                                         2002
Topic 12: OpenGIS             Service
Architecture
UDDI     Spec            Technical       uddi_v3                       3.0.2          19/10/2004       RD12
Committee Draft
Information technology – Open            ISO/IEC 10746-3:1998                                          RD15
Distributed    Processing     –
Reference model: Architecture
OGC      Catalogue        Services       OGC 04-021r3                  2.0.0          20/05/2005       RD23
Specification                                                          with
                                                                       Correge
                                                                       ndum
Web Services Security: SOAP              wss-v1.1-spec-os-             1.1            01/02/2006       RD26
Message Security (WS-Security            SOAPMessageSecurity
2004)
OASIS Standard Specification



                                                         Pag. 20/182
                       Title:           Architectural Design Technical Note
                       Contract Ref.:   P-E190/DGIGSD-3556-05
                       Int. Ref.:       P-E190/DGIGSD-0399-06               Issue:   1   Rev.:   7
                       Proj. Ref.:      HMA-DD-DAT-EN-001                   Date:        14/09/2007


Document Title                          Document Identifier           Issue          Date             Ref
OpenGIS® Geography Markup               OGC 03-105r1                  3.1.0          07/02/2004       RD28
Language (GML)
Implementation Specification
Open Geospatial Consortium              OGC 04-024                    1.3            02/08/2004       RD29
Inc.
Web Map Service
Open Geospatial Consortium              OGC 04-094                    1.1.0          03/05/2005       RD30
Inc.
Web      Feature       Service
Implementation Specification
Open Geospatial Consortium              OGC 03-065r6                  1.0.0          27/08/2003       RD31
Inc.
Web Coverage Service (WCS)
OpenGIS® Catalogue Services             OGC 04-038r4                  1.0            23/03/2006       RD32
Specification  2.0.1  (with
Corrigendum) -
ISO     Metadata      Application
Profile
Geographic       information    —       prCEN/TR 00287030 -1                         09/2005          RD36
Standards,          specifications,
technical        reports       and
guidelines,       required      to
implement        Spatial     Data
Infrastructure
Heterogeneous            Missions                                     1.2            25/07/2006       RD37
Accessibility – Tasks for the
already      identified   project
partners - Service Discovery TN
HMA Acronyms and Definitions            HMA-LI-ASU-EN-0001            1.4                             RD39
OpenGIS     Filter   Encoding           OGC 04-095                    1.1.0          2005-05-03       RD44
Implementation Specification
OpenGIS Catalogue Services -            05-025r3                      1.0.0                           RD47
ebRIM (ISO/TS 15000-3) profile of
CSW
INSPIRE Work Programme                  INSPIRE IR WP2007-2009-       1              16-5-2007        RD50
Transposition Phase 2007-2009           v1 0.doc

MPAS Preliminary Architectural          MPAS_ADD                      1-1            04/04/2006       RD51
Design Document

Earthnet Online XML Front-End           EOLI-XML-006-ICD              2.6.2          12/02/2007       RD52

Interface Control Document

Earthnet Online XML Front-End:          EOLI/Order-XML-ICD            3.1            11/05/2007       RD53
Order and On-line Access
Extension
Interface Control Document

                                                        Pag. 21/182
                        Title:           Architectural Design Technical Note
                        Contract Ref.:   P-E190/DGIGSD-3556-05
                        Int. Ref.:       P-E190/DGIGSD-0399-06               Issue:   1   Rev.:   7
                        Proj. Ref.:      HMA-DD-DAT-EN-001                   Date:        14/09/2007




1.4.3   Bibliography
Document Title                           Document Identifier           Issue          Date             Ref
OGC Reference Model                      OGC 03-040                    0.1.3          16/09/2003       RD05
Web Services Architecture                http://www.w3.org/TR/                        11/02/2004       RD06
W3C Working Group Note                   2004/NOTE-ws-arch-
                                         20040211/
SOAP: Primer                             http://www.w3.org/TR/         1.2            24/06/2003       RD07
W3C Recommendation                       2003/REC-soap12-
                                         part0-20030624/
Web    Services   Description            http://www.w3.org/TR/         2.0            27/03/2006       RD08
Language (WSDL): Primer W3C              2006/CR-wsdl20-primer-
Candidate Recommendation                 20060327
Uniform    Resource         Identifier   RFC 3986                                     January          RD10
(URI): Generic Syntax                                                                 2005
(http://www.gbiv.com/protocol
s/uri/rfc/rfc3986.html)
UDDI Features List                       http://uddi.org/pubs/u        3.0                             RD11
                                         ddi_v3_features.htm
Information technology – Open            ISO/IEC 10746-1:1998                                          RD13
Distributed    Processing   –
Reference model: Overview
Information technology – Open            ISO/IEC 10746-2:1998                                          RD14
Distributed    Processing    –
Reference model: Foundations
An overview of the Web Service           http://www-                                  06/2002          RD22
Inspection   Language,     IBM           128.ibm.com/develope
developerWorks                           rworks/library/ws-
                                         wsilover/
Web Services Glossary                    http://www.w3.org/TR/                        11/02/2004       RD20
W3C Working Group Note                   2004/NOTE-ws-gloss-
                                         20040211/
Business  Process   Execution            http://www-                   1.1            01/02/2005       RD24
Language for Web Services                128.ibm.com/develope
                                         rworks/library/specificat
                                         ion/ws-bpel/
Web Services Addressing - Core           http://www.w3.org/TR/         1.0            09/05/2006       RD25
                                         2006/REC-ws-addr-
                                         core-20060509
Web Services Policy Framework                                          1.2            March 2006       RD27
(WSPolicy)




                                                         Pag. 22/182
                         Title:            Architectural Design Technical Note
                         Contract Ref.:    P-E190/DGIGSD-3556-05
                         Int. Ref.:        P-E190/DGIGSD-0399-06               Issue:   1   Rev.:   7
                         Proj. Ref.:       HMA-DD-DAT-EN-001                   Date:        14/09/2007


Document Title                             Document Identifier           Issue          Date             Ref
WS-I Usage Scenarios                       http://www.ws-                1.01           09/12/2003       RD34
                                           i.org/SampleApplicatio
                                           ns/SupplyChainManag
                                           ement/2003-
                                           12/UsageScenarios-
                                           1.01.pdf
Reference Model for Service                wd-soa-rm-cd1                 1.0            10/02/2006       RD35
Oriented Architecture
Public Review Draft
OWS-3     Imagery           Workflow       OGC 05-140                    0.9            01/02/2006       RD40
Experiments:
Enhanced Service Infrastructure
Technology
Architecture and Standards in
the OWS-3 Testbed
OpenGIS®         Implementation            OGC 01-009                    1.0            12/01/2001       RD41
Specification:
Coordinate         Transformation
Services
HTTP Hypertext Transfer Protocol           W3C RFC 2616                  1.1            1999             RD42
– HTTP/1.1
File Transfer Protocol                     W3C RFC 959                                  1985             RD43
Simple Object Access Protocol                                            1.2            2003-06-24       RD45
(SOAP)   Version  1.2,   W3C
Recommendation
Security   Assertion Markup                                              1.1            2003-08          RD46
Language (SAML) v1.1, OASIS
standard set
Lightweight Directory             Access   IETF RFC 2251                 3                               RD49
Protocol (v3)
Information     technology    —            ISO/IEC 17799                 Second         2005-06-15       RD52
Security techniques — Code of                                            edition
practice for information security
management
Information   technology    —              ISO/IEC 27001                 First          2005-10-15       RD53
Security    techniques      —                                            edition
Information            security
management       systems    —
Requirements



1.5     Overview of the document
Chapter 1 of this document defines the information that can be found in the document and
references the list of Applicable and Reference documents.
Chapter 2 provides a summarization of the methodology followed for the Architecture Design of
the HMA.

                                                           Pag. 23/182
                     Title:           Architectural Design Technical Note
                     Contract Ref.:   P-E190/DGIGSD-3556-05
                     Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                     Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

Chapter 3 provides the Enterprise viewpoint of the HMA project.
Chapter 4 provides the Information viewpoint of the HMA project.
Chapter 5 provides the Service viewpoint of the HMA project.
Chapter 6 provides the Engineering viewpoint of the HMA project.
Chapter 7 provides the Technology viewpoint of the HMA project.
Chapter 8 provides the Services vs. Scenarios and Requirements traceability matrix.




                                                      Pag. 24/182
                       Title:           Architectural Design Technical Note
                       Contract Ref.:   P-E190/DGIGSD-3556-05
                       Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                       Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007



2         Process of the GMES HMA Architectural Design
2.1       Application of the Reference Model of Open Distributed Processing (RM-
          ODP)

2.1.1     RM-ODP Overview
The Reference Model of Open Distributed Processing (ISO/IEC 10746-1:1998) is an international
standard for architecting open, distributed processing systems. It provides an overall conceptual
framework for building distributed systems in an incremental manner. The RM-ODP standards have
been widely adopted: they constitute the conceptual basis for the ISO 19100 series of geomatics
standards (normative references in ISO 19119:2005), and they also have been employed in the
OMG object management architecture.
The RM-ODP approach has been used in the design of the OpenGIS Reference Model (OGC
2003) with respect to the following two aspects:
      •   It constitutes a way of thinking about architectural issues in terms of fundamental patterns
          or organizing principles, and
      •   It provides a set of guiding concepts and terminology.
Systems resulting from the RM-ODP approach (called Open Distributed Processing systems, i.e.
ODP systems) are composed of interacting objects (see section 7.1.1 of [RD-15]) whereby in RM-
ODP an object is a representation of an entity in the real world. It contains information and offers
services.
Based on this understanding of a system, ISO/IEC 10746 specifies an architectural framework for
structuring the specification of ODP systems in terms of the concepts of viewpoints and viewpoint
specifications, and distribution transparencies.
The viewpoints identify the top priorities for architectural specifications and provide a minimal set
of requirements—plus an object model—to ensure system integrity. They address different aspects
of the system and enable the ‘separation of concerns’.
Five standard viewpoints are defined:
      •   The enterprise viewpoint: A viewpoint on the system and its environment that focuses on
          the purpose, scope and policies for the system.
      •   The information viewpoint: A viewpoint on the system and its environment that focuses on
          the semantics of the information and information processing performed.
      •   The computational viewpoint: A viewpoint on the system and its environment that enables
          distribution through functional decomposition of the system into objects which interact at
          interfaces.
      •   The engineering viewpoint: A viewpoint on the system and its environment that focuses on
          the mechanisms and functions required to support distributed interaction between objects
          in the system.
      •   The technology viewpoint: A viewpoint on the system and its environment that focuses on
          the choice of technology in that system.
The aspect of a distributed ODP system is handled by the concept of distribution transparency.
Distribution transparency relates to the masking from applications of the details and the
differences in mechanisms used to overcome problems caused by distribution. According to the
RM-ODP, application designers simply select which distribution transparencies they wish to assume
and where in the design they are to apply. The RM-ODP distinguishes between eight distribution
transparency types. These distribution transparencies consider aspects of object access, failure of
objects, location of objects, as well as replication, migration, relocation, persistence and
transactional behaviour of objects.


                                                        Pag. 25/182
                                   Title:           Architectural Design Technical Note
                                   Contract Ref.:   P-E190/DGIGSD-3556-05
                                   Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:    7
                                   Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007


2.1.2                Mapping of RM-ODP to the GMES-HMA Architectural Design Process
An RM-ODP-based approach has been selected for the design of the GMES HMA Architecture as
the primary objectives of RM-ODP like:
                 •    support for aspects of distributed processing,
                 •    provision of interoperability across heterogeneous systems, and
                 •    hiding consequences of distribution to systems developers
are largely coherent with the GMES-HMA objectives. However, as GMES-HMA will have the
characteristic of a loosely-coupled network of systems and services instead of a “distributed
processing system based on interacting objects”, the RM-ODP concepts are not followed literally.
The usage of RM-ODP for the GMES-HMA Architectural design process focuses on the structuring
of ideas and the documentation of the GMES HMA Architecture. Thus, a mapping of the RM-ODP
viewpoints to the GMES HMA needs has been applied and summarised in Table 1:
             •       the first column of Table 1 provides the RM-ODP viewpoint.
             •       The second column of Table 1, provides the original definition according the ISO/IEC
                     10746.
             •       The third column of Table 1 provides the original definitions of the viewpoints as given in
                     the OpenGIS Reference Model using the terms of the OpenGIS glossary.
             •       The fourth column of Table 1 indicates the mapping of the viewpoints to the GMES HMA
                     needs using the terms as defined in the glossary (see [RD39]).
                     Note: In order to highlight the fact, that GMES HMA deployment will have the nature of a
                     loosely-coupled distributed system based on networked services rather than a distributed
                     application based on computational objects, the “computational viewpoint” is referred to
                     as “service viewpoint” in GMES HMA.
             •       The fifth column of Table 1 reports the intended readership interested in the respective
                     viewpoint.
                     In fact because each view is concerned with a specific aspect of the system, this column
                     specifies the kind of reader the view is targeted to.



Viewpoint                      Definition               Definition               Mapping to the                  Intended
  Name                        according to           according to the              GMES HMA                     readership
                             ISO/IEC 10746          OpenGIS Reference          architectural design
                                                         Model                       process
                          Concerned with the        Focuses on the             Concerned with the          End Users,
                          purpose, scope and        purpose, scope and         purpose, scope and          Stakeholders
Enterprise




                          policies governing the    policies for that          policies governing the
                          activities of the         system.                    activities of the
                          specified system                                     specified system
                          within the                                           within the
                          organization of which                                organization of which
                          it is a part.                                        it is a part.




                                                                    Pag. 26/182
                         Title:           Architectural Design Technical Note
                         Contract Ref.:   P-E190/DGIGSD-3556-05
                         Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:    7
                         Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007


Viewpoint            Definition               Definition               Mapping to the                  Intended
  Name              according to           according to the              GMES HMA                     readership
                   ISO/IEC 10746          OpenGIS Reference          architectural design
                                               Model                       process
                Concerned with the        Focuses on the             Specifies the               Analysts
                kinds of information      semantics of               modelling of all
Information




                handled by the            information and            categories of
                system and                information                information the GMES
                constraints on the use    processing.                HMA Architecture
                and interpretation of                                deals with including
                that information.                                    their thematic, spatial,
                                                                     temporal
                                                                     characteristics as well
                                                                     as their meta-data.
                Concerned with the        Captures component         Referred to as              Analysts
                functional                and interface details      “Service Viewpoint”.
Computational




                decomposition of the      without regard to          Specifies the GMES
                system into a set of      distribution.              HMA services that
                objects that interact                                support the
                at interfaces –                                      syntactical and
                enabling system                                      semantic
                distribution.                                        interoperability
                                                                     between GSs, clients,
                                                                     EO DAIL.
                Concerned with the        Focuses on the             Specifies the               Analysts &
Technology




                choice of technology      choice of technology.      technological               Developers
                to support system                                    choices of the service
                distribution.                                        infrastructure and the
                                                                     operational issues of
                                                                     the infrastructure.



                Concerned with the        Focuses on the             Specifies the               Analysts &
Engineering




                infrastructure required   mechanisms and             mapping of the GMES         Developers
                to support system         functions required to      HMA service
                distribution.             support distributed        specifications and
                                          interaction between        information models to
                                          objects in the system.     the chosen service
                                                                     and information
                                                                     infrastructure.
Table 1: Mapping of the RM-ODP Viewpoints to GMES HMA


These different views can be mapped on the HMA architectural design process and
implementation. This integrated view, and the relationships between the viewpoints and their
mapping to the HMA architectural design process, the implementation phase, provided in
following figure, is called the HMA Reference Model covering analysis, design and implementation
phase.




                                                          Pag. 27/182
                     Title:            Architectural Design Technical Note
                     Contract Ref.:    P-E190/DGIGSD-3556-05
                     Int. Ref.:        P-E190/DGIGSD-0399-06                   Issue:   1   Rev.:   7
                     Proj. Ref.:       HMA-DD-DAT-EN-001                       Date:        14/09/2007




                          Analysis
                                                        Enterprise
                                                        Viewpoint




                                                     HMA Architecture

                                       Information                      Services
                                        Viewpoint                       Viewpoint
                          Design




                                          HMA Implementation Specification

                                       Engineering                      Technology
                                        Viewpoint                        Viewpoint
                          Implemen
                            tation




                                              HMA Service Component(s)




                                      Figure 1: HMA Reference Model.


2.1.3   Service Taxonomy
The GMES HMA services can be classified according to different perspectives, one relevant
classification is the service taxonomy of ISO 19119:2005 [RD04], section 8.3:
   •    Human interaction services are services for management of user interfaces, graphics,
        multi-media, and for presentation of compound documents. HMA will deploy Human
        Interaction Services, only for testing purposes. However the architecture shall support the
        deployment of Human Interaction Services.
   •    Model/Information management services are services for management of the
        development, manipulation, and storage of meta-information (including ontology
        specifications), conceptual schemas, and datasets. Examples of HMA Information
        Management Services are Discovery Service, Catalogue Service, Order Service.
   •    Workflow/Task management services are services for support of specific tasks or work
        related activities conducted by humans or software components with a high degree of
        autonomy (agents). These services support use of resources and development of products
        involving a sequence of activities or steps that may be conducted by different persons.
        Example of this kind of service is the Orchestration Service
   •    Processing services are services that perform computations. These computations might
        range from the performance of mathematical equations up to large-scale computations
        involving substantial amounts of data. An example of this kind of service is the Processing
        Service (this service is currently still to be defined).
   •    Communication services are services for encoding and transfer of data across
        communications networks. No service of this type is currently present in HMA.
   •    System management services are services for the management of system components,
        applications, and networks. These services also include management of user accounts
        and user access privileges, in the following indicated as “User Management Services”.
        Other examples of this kind of service are Service Registration, Monitoring & Control
        Service.


                                                          Pag. 28/182
                      Title:           Architectural Design Technical Note
                      Contract Ref.:   P-E190/DGIGSD-3556-05
                      Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                      Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

Relationship between Services and their classification according to the presented taxonomy are
reported in sections 5.5.x.

2.1.4   Simple Service Architecture
The design of the HMA Architecture is driven also by the “Simple Service Architecture” concept
defined in the [RD04], section 7.6. A simple service architecture is a message-based architecture
that supports service chaining (see section 5.2) and considers the following simplifying
assumptions:
   •    Message-operations. The HMA Services operations are modelled as messages. A message
        operation shall consist of a request and response. Requests and responses contain
        parameters as the payload, which is transferred in uniform manner independent of
        content. Simple applications are characterized by message exchange patterns such as
        one-way (or event), and two-way (or synchronous) request response interactions. These
        concepts are mentioned also in [RD34]: “One-way” and “Synchronous Request/Response”
        usage scenarios.
        A service specification should make such simple exchange applications as easy as
        possible to create and to use.
   •    Separation of control and data. A client accessing a HMA service may not want the full
        results of the service. For example, the user may have no need for the potentially
        voluminous intermediate products in a service chain. Only the final result of a service chain
        may be needed by the client. Therefore, operations of an interface should separate the
        control of the service from the access to the data resulting from a service. A client should
        have the option of receiving just the status of an operation; the data would be accessible
        through a separate operation.
   •    Synchronous versus Asynchronous Service Operations. Depending on the expected
        response time, service operations are defined either synchronous (i.e. service operation
        response is real time -e.g. catalogue service GetRecords operation) or asynchronous (e.g.
        order Submit and Cancel operations)
   •    Known service type. HMA Service instances are of specific types and the clients know the
        type prior to run time (the HMA services interfaces are described in [AD11], [AD05], [AD10],
        [RD32]). Nevertheless some HMA services operations are optional and then some service
        operations discovery has to be performed (GetCapabilities operation is the one in charge
        of providing the operation metadata suitable for this purpose).
   •    Adequate hardware. HMA services are software implementations running on hardware
        hosts. This assumption means that the hardware assignment is transparent to user.




                                                       Pag. 29/182
                      Title:           Architectural Design Technical Note
                      Contract Ref.:   P-E190/DGIGSD-3556-05
                      Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                      Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007



3 Enterprise Viewpoint
3.1 Overview
The enterprise viewpoint of the GMES HMA Architecture gives an overview of its
         •   business perspective,
         •   purpose (the core mission of the GMES HMA Architecture),
         •   scope (e.g. intended users),
         •   policies (e.g. standardisation approach, openness)

3.2 Business Perspective, Purpose and Scope
The context of the HMA Project is the Phase 1 of the ESA GMES Space Component (GSC)
Programme.
HMA is defining the interoperability framework and architecture for the operational provision of
data access from the national and Eumetsat missions contributing during GMES Space
Component Phase 1 to provide the necessary data for the GMES Services. It is expected that
within the same time frame the GMES Fast Track Services will be activated and ready for
operational activity by 2008. Within the HMA contract the architecture of the overall interoperable
GS (comprising national and EUMETSAT missions) as well as the one of the Earth Observation Data
Access Integration Layer EO DAIL 1 are being defined.
Several ESA Member States, EUMETSAT and other Third Party operators have developed or are in
the process of developing EO satellite that can offer essential capacity to the GMES Space
Component to overcome the data gaps that might occur before the Sentinels to be developed
by ESA are operational. These missions, also called the “GMES contribution missions”, that together
with the ESA missions, will operationally provide Earth Observation data to the Fast Track Services
from 2008 on-wards.
The Agency will define with the “GMES contribution missions” the data access rules and conditions
for providing the data necessary to the provision of the GMES services. Access to data from these
missions can vary from data access agreements to a more comprehensive integration of satellite
missions into the overall GMES space segment architecture which may involve programming,
data acquisition and dissemination functions.
In the framework of the current HMA project, the Agency is defining in collaboration with the
“GMES contribution missions” the ground segment architecture and interoperability standards for
an across-missions harmonised data access, including data quality and product formats. The
GMES ground segment architecture will be conceived to integrate these missions from the
beginning, so that they can be used for GMES objectives within the limitations of their availability
outside their national/Eumetsat obligations.
The interoperability definition and standardisation is performed with the collaboration and/or
support of:
     •   JRC and Eurostat for alignment with the INSPIRE Implementing Rules in the areas of static
         geospatial data and on ortorectified images. Taking into account the parallel evolution of
         the INSPIRE initiative. This collaboration with JRC is formalised via the ESA-JRC
         Memorandum of Understanding.
     •   Standardisation and specialised recommendations bodies like OGC, CEN and ISO, CEOS
         and ECSS, for the EO ground segment interfaces standardisation.
HMA objective is to establish harmonised access to heterogeneous EO missions’ data from
multiple missions including national missions and ESA Sentinel missions.


1
    See PBEO GS Task Force Report ESA/PBEO(2004)53,rev.1
                                                       Pag. 30/182
                        Title:                  Architectural Design Technical Note
                        Contract Ref.:          P-E190/DGIGSD-3556-05
                        Int. Ref.:              P-E190/DGIGSD-0399-06                    Issue:    1   Rev.:     7
                        Proj. Ref.:             HMA-DD-DAT-EN-001                        Date:         14/09/2007

The already identified project partners who have a direct contractual relationship with ESA in the
framework of HMA are:
    •   ASI, the Italian Space Agency
    •   CNES, the French Space Agency
    •   CSA, the Canadian Space Agency
    •   DLR, the German Space Agency
    •   EUSC, the European Union Satellite Centre
Furthermore working relationships have been established with:
    •   EUMETSAT in order to ensure data access and interoperability with meteorological missions.
    •   FAO in order to ensure interoperability with the UN-SDI


Hereafter the context of the HMA project:




                                      SCI
    COM Science
          GMES                          COMMERCIAL



                                                      Service Access Layer




                                 EO Data Access integration layer                                                    Integration



                                                                                                               INSPIRE
 Non European         ESA             Other European         Other European
                                                                                  Meteorological                 Static        in
    Mission            MM                   Mission             Mission
                                                                                     Mission                   Geo-spatial    situ
 Ground Segment   Ground Segment      Ground Segment        Ground Segment




                                                Figure 2: HMA Project context.


The above figure identifies ESA, other European and national earth observation missions and their
respective GSs and interfaces, the EO Data Access Integration Layer (DAIL) and the static geo-
spatial data and in situ data not strictly derived by EO satellites.
At this stage, the architecture definition focuses on the interfaces involving:
    •   the ESA missions GS,
    •   other European Mission GS, and
    •   the static geo-spatial data.
        Geo-spatial data is data with a geographical reference providing information about a
        specific region, site or object. Objects are represented as points, lines, polygons or grids in
        databases. Maps (either digital or analogue) are a means of visualising a combined set of
        spatial data at a certain scale and in a certain layout.
Although interfaces to non-European agencies GS are part of the scheme, in particular in view of
Third Party Missions (TPM), they are not within the scope of this first phase of the scenario definition
work.
                                                                    Pag. 31/182
                        Title:           Architectural Design Technical Note
                        Contract Ref.:   P-E190/DGIGSD-3556-05
                        Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                        Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

The same applies to interfaces of in-situ non-space data. Their details are considered within the
framework of ESA cooperation within the EC Inspire initiative through a series of dedicated HMA
workshops. The first such workshop, focusing on the catalogue interfaces, was held the 27/28th
October 2005 consecutively to the Scenario workshop. The implementing rules to be provided by
INSPIRE initiative will describe the access to these data.
The interfaces with the Service Access Layer will be addressed when the GMES Service
interoperability requirements will become available.
In this schema, the DAIL serves two classes of 'users'
    •     the 'operators' of missions, enabling interoperation between the mission GS
    •     the 'users' of missions, providing a single entry point to interoperating mission GS

3.2.1     Relationship with other projects

3.2.1.1    INSPIRE [RD50]
Following 3 years of intensive collaboration with Member States experts and stakeholder
consultation, the Commission adopted on the 23 of July 2004 a proposal for a Directive of the
European Parliament and of the Council establishing an infrastructure for spatial information in the
Community (INSPIRE) [COM(2004) 516 final].
INSPIRE lays down general rules for the establishment of an infrastructure for spatial information in
Europe, for the purposes of environmental policies and policies or activities which may have a
direct or indirect impact on the environment.
On 21 November 2006, the European Parliament and the Council reached agreement in
conciliation on the final text of the Directive. The Directive has been formally approved by the
Council and by the European Parliament on 29 January and 12 February 2007, respectively.
INSPIRE was published as Directive 2007/2/EC of the European Parliament and of the Council of 14
March 2007 in the Official Journal of the European Union on 25 April 2007, and entered into force
on 15 May 2007.
The development and implementation of INSPIRE follows a programme of work consisting of three
phases. These are the Preparatory (2005-2006), the Transposition (2007-2009) and the
Implementation (2009-2019) phases.


Preparatory Phase (2005-2006)
INSPIRE requires the Member States to implement various measures. Some of these measures shall
be transposed by the Member States, while others require more detail, to be formulated in so-
called ‘Implementing Rules’. The Directive itself gives a timeline for the adoption of the
Implementing Rules. In order for the Implementing Rules to be ready in time, the process for their
development had to start early.
Hence, in parallel to the Co-Decision Procedure2, the Commission initiated actions to prepare
draft Implementing Rules, with the stakeholders playing a key role. This Preparatory Phase, which
started with the Commission’s proposal for INSPIRE, came to an end with the entry into force of the
INSPIRE Directive, although a number of activities including the drafting of the Implementing Rules
will continue into the Transposition Phase.


Transposition Phase (2007-2009)
Following adoption by the European Parliament and the Council the INSPIRE Directive entered
into force twenty days after its publication in the Official Journal of the European Union on 25 April
2007, which is 15 May 2007. Member States then have a period of two years to bring into force
laws, regulations and administrative provisions necessary to comply to the INSPIRE Directive.
At the beginning of this phase, the Commission will put in place the organisation necessary to
assure coordination at Community level and shall be assisted for that purpose by relevant
organisations, in particular by the European Environment Agency.


                                                         Pag. 32/182
                      Title:           Architectural Design Technical Note
                      Contract Ref.:   P-E190/DGIGSD-3556-05
                      Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                      Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

The development of the draft Implementing Rules will continue in the Transposition Phase. One of
the key activities in the Transposition Phase is the adoption of Implementing Rules following a
timetable set by INSPIRE. INSPIRE requires the formal adoption of those Implementing Rules by the
Commission following the “Comitology Procedure”. The regulatory nature of the Implementing
Rules requires the Commission to present them to a Regulatory Committee of Member States
representatives, referred to as the INSPIRE Committee, which will officially start its activities at the
beginning of the Transposition Phase. This INSPIRE Committee plays a central role in the regulatory
process.
The adopted Implementing Rules shall be implemented by the Member States.


Implementation Phase (2009-2019)
Once INSPIRE is transposed by the Member States into national legislation, its measures will be
implemented and monitored. Co-ordination at Community level by the Commission and at
Member State level will be operational and Member States shall report according to the roadmap
of INSPIRE.


Implementing rules will be defined for complying with the Metadata, Network Services and Data
Sharing Requirements based on the final text of the Directive summarized hereafter:
   •   Metadata.
       Member States shall create metadata and keep them up to date according the following
       requirements:
       •   Metadata shall include:
               o   conformity with IR on interoperability,
               o   conditions for access and use of data sets and services,
               o   quality and validity,
               o   the public authorities responsible,
               o   limitations on public access.
       •   An Implementing Rule for metadata shall be adopted within one year after the entry
           into force of the Directive.
       •   Once the Implementing Rule for metadata is adopted, metadata must be created:
               o   within 2 years for Annex I, II spatial data themes;
               o   within 5 years for Annex III spatial data themes.


   •   Network services
       Member States shall operate a network of the following services available to the public for
       data sets and services for which metadata has been created:
       •   Discovery services (No charge)
       •   View services (No charge (exceptions))
       •   Download services;
       •   Transformation services,
       •   Services allowing spatial data services to be invoked;
       Moreover,
       •   Member States shall ensure the technical possibility, for public authorities, to link their
           spatial data sets and services;
       •   Access to services may be restricted;
       •   Services shall be available on request to 3rd parties under conditions;
       •   An INSPIRE Geo-portal at Community level shall be established.


                                                       Pag. 33/182
                          Title:           Architectural Design Technical Note
                          Contract Ref.:   P-E190/DGIGSD-3556-05
                          Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                          Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

          An Implementing Rule shall be adopted for the different types of service according to the
          INSPIRE Roadmap.


    •     Data sharing Requirements
          Member States shall adopt measures for the sharing of data and services between public
          authorities for public tasks relating to the environment without restrictions occurring at the
          point of use.
          Public authorities may license and/or charge other public authorities and Community
          institutions provided that:
          •    It is compatible with the objective to facilitate sharing between public authorities.
          •    It is restricted to the minimum necessary to ensure sustained availability and quality of
               the data and services.
          When spatial data or services are provided to Community institutions for reporting
          obligations under Community law relating to the environment then this will not be subject
          to charging.
          Member States shall provide the institutions and bodies of the Community with access to
          spatial data sets and services in accordance with harmonised conditions. Implementing
          Rules governing those conditions shall be adopted according to the INSPIRE Roadmap.


The development of the Implementing Rules is the responsibility of the Commission. The
Implementing Rules will be adopted as Commission Decisions according to the INSPIRE Roadmap.


This initiative has been started at approximately the same time as HMA and will follow a similar
development: gathering of requirements and information, specification, implementation. It also
aims at standardising its ICDs.
The constraints coming from INSPIRE will be to ensure that the 2 projects share the same views on
standardisation of the online access to data and services and possibly on EO products and quality
certification.


3.2.1.2       ORCHESTRA
HMA and ORCHESTRA share a same goal: Interoperability.
Interoperability is an essential tool to increase usability and commercial viability of Earth
Observation (EO) mission data.
Interoperability is based on a large consensus for a common set of interfaces to each mission’s
ground segment and this consensus can be reached only if interfaces are based on de-facto and
de-iure standards.
Both ORCHESTRA and GMES HMA try to reach this goal via the design and development of a
reference model for an open architecture oriented to services. This process is iterative in order to
capture, in a mid term perspective, the technology progresses and dynamics of standardisation
processes
For these reasons the HMA architecture has been prepared following the same methodology
applied for ORCHESTRA: the Reference Model for Open Distributed Processing.


3.2.1.3       SSE
The SSE (Service Support Environment) is an open, interoperable system based on widely
accepted standards from W3C, OASIS, WSI and OGC. It implements a Service Oriented
Architecture (SOA) facilitating access to and deployment of services and combining services
using workflow technology. Services can be Ground Segment related modules such as


                                                           Pag. 34/182
                       Title:            Architectural Design Technical Note
                       Contract Ref.:    P-E190/DGIGSD-3556-05
                       Int. Ref.:        P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                       Proj. Ref.:       HMA-DD-DAT-EN-001                 Date:        14/09/2007

catalogues, ordering but also external services for oil spill monitoring, fire risk, algae bloom,
coordinate transformation, classification etc.
The SSE is currently the target of several projects aiming to demonstrate interoperability and
generally Services orchestration.
The SSE will be used in HMA as the starting point for the prototype implementation exploiting its
functionality as Services container, support for Services orchestration, etc…
Figure 3-2 shows an implementation view of Figure 3-1. The colours show the correspondence
between the two pictures. The ground segment modules expose a Web service interface via an
“access layer” (i.e. adapter) in the same way as other services (e.g. MASS-SER, GMES etc.). They
can thus be integrated in a similar way.
An advantage of the chosen approach is that mission specific applications can be built by
reusing components in process flows (i.e. workflows).




                                     Figure 3: SSE as HMA Prototype [AD09]


3.2.1.4    FedEO
The Federated Earth Observation Missions (FedEO) Pilot will provide a broad international venue
for operational prototyping and demonstration of Earth Observation (EO) requirements as defined
by the European Space Agency (ESA) and by other OGC members. The FedEO Pilot will apply
and refine OGC specifications relevant to EO.
An OGC Pilot is a collaborative effort that applies the OGC Standards Baseline and other relevant
non-OGC standards to Sponsor interoperability scenarios. In a Pilot initiative, OpenGIS
specifications can be stress tested and perfected based on real-world application and
experience. Specification development in Pilots is focused on improving existing specifications
rather than in creating new specifications. Results of a Pilot initiative migrate to the persistent
infrastructure provided by OGC Network.
The FedEO Pilot will test and validate OGC specifications in a business context, and will provide
feedback to the OGC process regarding their ability to improve access to and application of
earth observation data and services. The FEDEO Pilot will focus on refining the following
Implementation Specifications and other OGC documents:
    •     Catalogue Service for the Web (CSW) for EO Collection and Service Discovery (defined in
          HMA)

                                                         Pag. 35/182
                       Title:           Architectural Design Technical Note
                       Contract Ref.:   P-E190/DGIGSD-3556-05
                       Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                       Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

      •   Standard template user guide for an CSW ebRIM extension package
      •   Web Map Services - Application Profile for EO Products
      •   Sensor Planning Service for EO Sensors (defined in HMA)
      •   GML 3.1.1 Application schema for Earth Observation products (defined in HMA)
      •   Improvements to Ordering Services for Earth Observation Products (defined in HMA)


3.2.1.5    HMA Testbed: HMA-T
The HMA Testbed – HMA-T ESA project has been established in order to:
      •   Permit consolidation/evolution of HMA standards in parallel with DAIL implementation.
      •   Permit conformance testing of HMA standards.
      •   Support take-up of standards by European users and software developers.
      •   Permanent testbed based on SOA architecture, located at ESRIN.


Regarding the evolution of HMA standards, HMA-T has the objective of using the ebRIM
Application Profile of OGC CSW for EO Product Metadata Catalogue, for Collection and Service
Discovery. In this context the following specifications have been already prepared / updated:
      •   OGC 07-038, OGC™ Cataloguing of ISO Metadata (CIM) using the ebRIM profile of CS-W,
          which covers Collection and Service Discovery and it is already incorporated within HMA
          specifications;
      •   Update of OGC 06-131, OGC™ Catalogue Services Specification 2.0 - EO Products
          Extension Package for ebRIM (ISO/TS 15000-3) Profile of CSW 2.0, to align with GML
          Application Schemas OGC 06-080. Part of HMA specifications as well.


Regarding conformance testing, HMA-T project:
      •   is establishing a permanent test environment at ESRIN based on the Service Support
          Environment;
      •   is preparing CITE (OGC Compliance & Interoperability Testing & Evaluation) scripts for:
             o   CSW ebRIM Application Profile (Galdos, OWS-4): OGC 07-049
             o   ebRIM extension package for EO: OGC 06-131


Development activities are also in progress:
      •   Support for ebRIM extension package for EO in Ionic catalogue – proxy approach
      •   Support for ebRIM extension package for EO in Indicio catalogue (Galdos)


Possible activities planned for the next phases of the project:
      •   CITE scripts for Programming (OGC 07-018)
      •   CITE scripts for Ordering (OGC 06-141)
      •   CITE scripts ebRIM extension package ISO (07-038)
      •   Processing (WCTS etc)


3.3       HMA High level architecture requirements
HMA project has to allow geographically distributed users to smoothly access the ESA / other
European / Canadian Mission Ground Segments, geo spatial data and other in-situ resources.




                                                        Pag. 36/182
                     Title:             Architectural Design Technical Note
                     Contract Ref.:     P-E190/DGIGSD-3556-05
                     Int. Ref.:         P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                     Proj. Ref.:        HMA-DD-DAT-EN-001                 Date:        14/09/2007




                                      Figure 4: HMA geographical context.


The architecture of HMA is driven by the following high level architectural requirements [AD02]:
   •   HL_GEN_505: The overall HMA architecture, including the DAIL one, shall be driven to
       minimise the cost and impact on partners’ ground segments for both existing and future
       missions.
       The SOA approach pursued in the architecture design is in line with this requirement.
   •   HL_GEN_506: The DAIL architecture shall be independent of a particular partner’s ground
       segment.
       The access to the partner’s ground segment is realised through Web Services interfaces
       specified by ICDs to be agreed in the frame of the project.
   •   HL_GEN_507: The HMA architecture shall permit integration and reuse by additional
       partners in the future.
       The architecture does not make any assumption about where the system is installed and
       the number of installations; hence there are not limitations for its re-use from the partners.
       Furthermore, the ICD specifications will ensure maximum applicability across the range of
       providers of EO data acquired from space.
   •   HL_GEN_509: It shall be possible to add missions without changing the HMA architecture.
       The SOA architecture is specifically targeted at expanding systems, and services, in this
       case mission GS provided services, can be added seamlessly. The supported missions will
       not be hard coded in the system and this information is managed dynamically within the
       repositories of services and collection metadata. To include a new mission, and hence
       new mission GS services and/or data collection, it is sufficient to update these repositories.
   •   HL_GEN_510: The HMA shall permit the support of INSPIRE implementing rules.
   •   HL_GEN_511: The HMA architecture shall allow the use of partners’ proprietary GUI clients
       that are compliant to HMA interface specifications for the user access to HMA provided
       functionality/ services.
       HMA does not provide a GUI client, but specifies only the ICD’s for accessing its services,
       hence any client compliant with those ICD’s will be able to access the HMA services.
   •   HL_GEN_512: The HMA shall allow the traceability of all allowed and denied transactions
       which are handled through the DAIL.



                                                        Pag. 37/182
                          Title:               Architectural Design Technical Note
                          Contract Ref.:       P-E190/DGIGSD-3556-05
                          Int. Ref.:           P-E190/DGIGSD-0399-06                 Issue:   1    Rev.:     7
                          Proj. Ref.:          HMA-DD-DAT-EN-001                     Date:         14/09/2007

      •   HL_GEN_513: The HMA architecture shall permit the partner to choose whether the user
          registration and the management of user privileges and or policies are managed either on
          the DAIL or at the partners’ ground segment or both.
          Then the HMA has to implement both approaches.
      •   HL_GEN_500: The Access to the data and services from the missions participating in GMES
          will be ruled by Data Access Agreements to be signed between ESA and the mission
          owner.
      •   HL_GEN_501: The Data Access Agreements will define the Service Level Agreements to be
          supported for the specific mission/data access.


The relationship between the Data Access Agreement & Service Level Agreement of the partner
Ground Segments and the HMA project documents is highlighted in the picture below.



                 G/Sx
                                                                                                   HMA
                 Data                                                                         Requirement
                                                    G/Sx
                Access                         Implementation                                     Baseline
                                                                      traceability
              Agreement                           Technical
                                                  Document

              Includes                                                                              HMA
                                                                                                     ICDs
                          G/Sx
                         Service
                                                                                 HMA
                         Level                                                Architecture
                     Agreement                                                 Technical
                                                                                 Note

                                        Figure 5: Relationship between SLA and DAA.


3.4       Evolution of the HMA Architecture
The HMA project will be run in several development phases and the HMA architecture is likely to
evolve during these phases. Changes to the GMES programme may also influence the HMA
architecture.
The changes to the HMA architecture shall be submitted to the HMA Architecture Advisory Board.




                                                                Pag. 38/182
                        Title:           Architectural Design Technical Note
                        Contract Ref.:   P-E190/DGIGSD-3556-05
                        Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                        Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007



4 Information Viewpoint
The information view describes the information that flows in a system and is processed by a system
([RD04], [RD15]). It focuses on the structuring of semantic information, typically the information
that is stored in a database and communicated between the components of a system. Hence
this chapter deals with the modelling of the data the HMA has to manage, namely:
      •   Service & collection metadata (for Discovery services);
      •   Product metadata (for Catalogue service);
      •   Order, programming and subscription (for Order & Programming services);
      •   Satellite / sensor characteristic (for Programming service);
      •   User Profile and authorization metadata (for User Management service);
      •   Transaction Tracking data (for Monitoring & Control service);


These data items are described in the following sub-sections.


4.1       HMA Information Model
The EN ISO 19100 series of standards provide a model-driven approach: the information is
described by a formal, implementation-independent schema. Implementations for various
techniques (e.g. XML file transfer, web services, relational database) and implementation
environments (e.g. J2EE, .Net) can be derived from the schema in a more or less automatic way.
Changes in information requirements are applied to the schema; never directly to the
implementation.
Formal schemas are in EN ISO 19100 named application schemas. They contain semantics for
data interpretation as well as data structures for generation of, for example, XML-schemas.
According to prEN ISO 19109, the development of an application schema for a specific domain
has to follow certain rules. For example, spatial aspects have to be expressed according to a
standard (EN ISO 19107:2005).
Application schemas are documented by using a conceptual schema language. Such a
language may have a well defined graphical notation (such as UML for class diagrams) but also a
machine-readable format (such as XMI). The ISO/TS 19103 specifies the requirements for
conceptual schema languages. In practice ISO/TC 211 has adopted the Unified Modelling
Language (UML) as the conceptual schema language to be used.
Extensible Markup Language (XML) is selected as the basis for an implementation-neutral
exchange format (encoding). The transition from UML to a common XML format should be well
defined, and should preferably be done by automatic code generation. ISO 19118 describes rules
and transitions for how to generate XML schema.
Geography Markup Language (GML) was developed to provide a common XML encoding for
spatial data. GML is jointly developed by ISO/TC 211 and OGC for publication as ISO 19136.
As reported in [RD36] ISO 19136 (GML) is promoted as the encoding method when transferring
geographic data.
ISO 19139 was developed to provide a common XML encoding for EN ISO 19115 conceptual
schemas and the part of the ISO/TC 211 conceptual schemas used in EN ISO 19115.
As reported in [RD36] ISO 19139 is promoted as the encoding method when transferring
information related to geographic data such as metadata, feature catalogues and data
dictionaries.
According above principles, the product metadata has been described defining an application
schema of GML, the collection metadata has been modelled through an application profile of
ISO19115 and services have been modelled through an application profile of the ISO 19119.



                                                         Pag. 39/182
                      Title:           Architectural Design Technical Note
                      Contract Ref.:   P-E190/DGIGSD-3556-05
                      Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                      Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

The following sub-sections give additional details on services, collection and product metadata
and on the other information items HMA has to deal with.


4.1.1   Service Metadata for Service Orchestration and Invocation
The service metadata describes the services provided by the DAIL and the mission Ground
Segments. The level of description is such that an application should be able to discover and then
use the services (e.g. supported operations). For the management of this data the usage of a
UDDI registry is envisaged.
The Universal Description, Discovery, and Integration (UDDI) specification (see [RD11]) describes
an online electronic registry that serves as electronic Yellow Pages, providing an information
structure where various business entities register themselves and the services they offer through
their definitions (e.g. using WSDL).
The UDDI specification defines a 4-tier hierarchical XML schema that provides a model for
publishing, validating, and invoking information about Web Services. XML was chosen because it
offers a platform-neutral view of data and allows hierarchical relationships to be described in a
natural way. UDDI uses standards-based technologies, such as common Internet protocols (TCP/IP
and HTTP), XML, and SOAP (a specification for using XML in simple message-based exchanges).
UDDI is a standard Web Service description format and Web Service discovery protocol; a UDDI
registry can contain metadata for any type of service, with best practices already defined for
those described by Web Service Description Language (WSDL).
A UDDI registry consists of the following data structure types:
   •    businessEntity - The top-level XML element in a business UDDI entry, it captures the data
        partners require to find information about a business service, including its name, industry or
        product category, geographic location, and optional categorization and contact
        information. It includes support for "yellow pages" taxonomies to search for businesses by
        industry, product, or geography.
   •    businessService - The logical child of a businessEntity data structure as well as the logical
        parent of a bindingTemplate structure, it contains descriptive business service information
        about a group of related technical services including the group name, a brief description,
        technical service description information, and category information. By organizing Web
        Services into groups assoociated with categories or business processes, UDDI allows more
        efficient search and discovery of Web Services.
   •    bindingTemplate - The logical child of a businessService data structure, it contains data
        that is relevant for applications that need to invoke or bind to a specific Web Service. This
        information includes the Web Service URL and other information describing hosted
        services, routing and load balancing facilities, and references to interface specifications.
   •    tModel - Descriptions of specifications for Web Services or taxonomies that form the basis
        for technical fingerprints; its role is to represent the technical specification of the Web
        Service, making it easier for Web Service consumers to find Web Services that are
        compatible with a particular technical specification. That is, based on the descriptions of
        the specifications for Web Services in the tModel structure, Web Service consumers can
        easily identify other compatible Web Services. For instance, to send a business partner's
        Web Service a purchase order, the invoking service must know not only the location/URL of
        the service, but what format the purchase order should be sent in, what protocols are
        appropriate, what security is required, an what form of a response will result after sending
        the purchase order.
The information hierarchy and the key XML element names that are used to describe and
discover information about Web Services are shown in the figure below and in the following
example.




                                                       Pag. 40/182
                        Title:                 Architectural Design Technical Note
                        Contract Ref.:         P-E190/DGIGSD-3556-05
                        Int. Ref.:             P-E190/DGIGSD-0399-06              Issue:     1     Rev.:   7
                        Proj. Ref.:            HMA-DD-DAT-EN-001                  Date:            14/09/2007



                                 BusinessEntity
                                  name
                                  contacts
                                  description
                                  identifiers
                                  catagories
                                  geographic location




                                 +implements
                                            1..n
                                 BusinessService
                                  name
                                  description
                                  service description
                                  category information




                                  +implements
                                            1..n
                                 BindingTemplate                                 tModel
                                                                              name
                                  Web Service URL
                                                                              overViewURL
                                  services                           +binds   WSDL Specification
                                  routing
                                                                         1    protocol
                                  accessPoint
                                                                              transport
                                  portType
                                                                              security




                                         Figure 6: Service Metadata UDDI model


A generic sample is provided in the following.

<businessService>
   (...)
   <bindingTemplates>

      <bindingTemplate>
         (...)
         <accessPoint urlType="http"> http://www.etc.com/</accessPoint>
         <tModelnstanceDetails>
            <tModelnstanceInfo tModelKey="...">

            </tModelnstanceInfo>
            (...)
         </tModelnstanceDetails>
      </bindingTemplate>
      (...)

   </bindingTemplates>
</businessService>


Generic services are described via Web Services Description Language (WSDL) providing Service
Interface Specification and Service Implementation information. A WSDL service description
contains an abstract definition for a set of operations and messages, a concrete protocol binding
for these operations and messages, and a network endpoint specification for the binding. This
represents a reusable definition of a service.
In order to publish and find Services by means of their WSDL description using UDDI the following
applies: the Service interface is published in a UDDI registry as a tModel. The service

                                                               Pag. 41/182
                      Title:           Architectural Design Technical Note
                      Contract Ref.:   P-E190/DGIGSD-3556-05
                      Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                      Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

implementation describes instances of a service. Each instance is defined using a WSDL service
element. Each service element in a service implementation document is used to publish a UDDI
businessService.




                     Figure 7: Mapping between WSDL sections and UDDI data model.
The full specification of UDDI is provided in [RD11].

4.1.2   Service Metadata for Human Readable Services Discovery
This is Human readable service metadata about available Earth Observation related services. It
provides users sufficient information to assess and to access these services.
Whereas the metadata stored in the UDDI registry provides standard web-service discovery
metadata used for example for service orchestration, this service discovery metadata is more
tailored to the Earth Observation needs, e.g. it is in charge of answering questions like: finding an
order service allowing ordering products of a specified collection; finding a Web Coverage
Service returning products of a specific collection; etc.
This metadata is defined by identifying the minimum set of elements of the ISO 19119 Service
Metadata which are sufficient for discovering the HMA services.
The following concepts have to be represented in this Service Metadata:
   o    Services are defined by:
           o   Identification info (e.g. contact information, usage restrictions, region/time period
               of applicability, etc.);
           o   Operations and related parameters
           o   Dependencies (i.e. how operations depend on results of other operations);
   o    Data metadata may be subject to restrictions and therefore
           o   not visible for each user of the catalogue service
           o   Access control not handled by the catalogue service natively
In the following figure, the UML model including the minimum set of elements for HMA service
discovery derived by ISO 19119 Service Metadata model is summarized:




                                                       Pag. 42/182
                     Title:           Architectural Design Technical Note
                     Contract Ref.:   P-E190/DGIGSD-3556-05
                     Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                     Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007



                                             <<Abstract>>
                                         MD_Identification




               SV_ServiceIdentification
                                                                      +operatesOn

                                                                      MD_DataIdentification


                  +containsOperations
                    SV_OperationMetadata


                                                            SV_CoupledResource


                          Figure 8: Service Metadata UML model (from [RD04]).


The SV_ServiceIdentification element specifies: the identifier of the service, the type (e.g. WFS,
WMS, ..), restriction, the data on which each operation of the service works, the list of operations.
The SV_OperationMetadata describe one operation of the service including: the operation name,
the protocol binding, the URI (see [RD10]) to access the operation.
The full description of the Human Services Metadata is provided in the [RD37].


4.1.3   Collection Metadata
A catalogue collection is a set of catalogue entries having a common set of characteristics. For
the EO products, collections are generally associated to mission sensors and operation mode, e.g.
a collection of all the TerraSAR-X spotlight mode data. The collection metadata describes these
sets by providing the identifier, the description, the possible geographical and temporal extent,
the common attributes, etc.
Collection Metadata, according to [RD32] (OpenGIS Catalogue Services Specification 2.0.1 – ISO
Metadata Application Profile), which has been selected as the protocol for accessing the HMA
Discovery (for collections) Service, has been modelled following the ISO 19115 standard.
The following figure reports the high level overview of the basic classes of the ISO 19115
information model.




                                                      Pag. 43/182
                       Title:            Architectural Design Technical Note
                       Contract Ref.:    P-E190/DGIGSD-3556-05
                       Int. Ref.:        P-E190/DGIGSD-0399-06              Issue:   1    Rev.:   7
                       Proj. Ref.:       HMA-DD-DAT-EN-001                  Date:         14/09/2007



                                           MD_Identification                             MD_Metadata
                                                                1..n




               MD_DataIdentification +operatesOn                       SV_ServiceIdentification


                                        Figure 9: ISO 19115 Basic Classes.


   o    MD_Metadata: Contains Metadata entity set information. The MD_Metadata entity is an
        aggregate of MD_Identification and further classes that are suppressed due to clarity, but
        explained in detail in ISO19115:2003. [ISO19115:2003 A.2.1]
   o    MD_Identification: This abstract class contains information to uniquely identify the
        information resource that has to be described. MD_Identification is mandatory. It may be
        implemented as MD_DataIdentification or SV_ServiceIdentification. [ISO19115:2003 A.2.2]
   o    MD_DataIdentification: Subclass and concretion of the abstract class MD_Identification.
        According to the application profile, MD_DataIdentification describes either data or
        applications. [ISO19115:2003 A.2.2]
   o    SV_ServiceIdentification: Subclass and concretion of the abstract class MD_Identification.
        SV_ServiceIdentification gives a high level description of services according to
        ISO19119:2005. A service might be 'loosely coupled' (with no associated data), 'tightly
        coupled' (with associated data) or 'mixed coupled'. This distinction is done by setting the
        couplingType attribute of the CSW_ServiceIdentification class [see also ISO19119:2005
        7.4.2]
The full description of Collection Metadata is provided in [RD32].


4.1.4   Product Metadata
This is the metadata used for describing the products derived by earth observation satellites that
are managed by the Catalogue service of the HMA architecture.
Earth observation satellite products are mainly characterised by the following attributes:
   •    satellite and sensor acquiring the data;
   •    the time when the data has been acquired;
   •    the geographical coverage of the acquired data;
   •    the ground station receiving the satellite downlink;
   •    other attributes depending on the type of sensor:
           o     for radar sensors possible relevant attributes are: polarization, Doppler frequency,
                 swath identifier;
           o     for optical sensors possible relevant attributes are: cloud coverage, the illumination
                 angles;
           o     for atmospheric sensors possible specific attributes are: vertical coverage, specy;


From user point of view the main characteristic of Earth Observation products is their geographical
coverage and then, because GML provides a rich set of definitions for representing geographic

                                                         Pag. 44/182
                      Title:            Architectural Design Technical Note
                      Contract Ref.:    P-E190/DGIGSD-3556-05
                      Int. Ref.:        P-E190/DGIGSD-0399-06             Issue:     1   Rev.:   7
                      Proj. Ref.:       HMA-DD-DAT-EN-001                 Date:          14/09/2007

objects, the representation of Earth Observation products is performed through GML application
schemas.
Earth observation products are modelled with the EarthObservationProductType type which is an
extension of GML AbstractFeatureType type. Because different product types derived by different
type of sensors have different set of specific attributes, then the following approach has been
followed:
   •   a namespace including definitions common to all sensors has been defined: hma
   •   a separated namespace for each class of sensor has been defined:
          o    sar for radar sensors
          o    ohr for optical sensors
          o    atm for atmospheric sensors
          o    other namespaces can be defined for other classes of sensors
   •   additional specific namespaces can be defined on top of previous ones.
The EarthObservationProductType is defined in each namespace by extending the definition in
the parent namespace leading to this hierarchy:



                                              gml:AbstractFeature




                                         hma:EarthObservationProduct




          sar:EarthObservationProduct     ohr:EarthObservationProduct         atm:EarthObservationProduct


                   Figure 10: EarthObservationProduct type hierarchy [AD11], [AD08].


Because a Catalogue compliant with this definition can return different EarthObservationProduct
element format depending on the supported schema, then the catalogue allows the clients to
get first the list of supported schemas (either hma, ohr, sar, or other ones defined on them) and
then to specify the schema that best fit their needs when the data is retrieved.


Stated the rationale for the modelling of earth observation products, in the following the
description of the different EarthObservationProductType types is briefly summarized:
   o   hma:EarthObservationProductType
           o   identifier: Identifier for metadata item, includes ground segment namespace to
               guarantee uniqueness within HMA
           o   productType: describes product type in case that mixed types are available within
               a single collection, this is ground segment specific definition
           o   status: status of the product (archived, acquired, planned, potential)
           o   startDate & completionDate: acquisition start and stop times
           o   extentOf: footprint of the product
                                                        Pag. 45/182
                      Title:           Architectural Design Technical Note
                      Contract Ref.:   P-E190/DGIGSD-3556-05
                      Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                      Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

           o    centerOf: centre coordinate of the product
           o    acquiredBy: satellite, instrument, sensor type, sensor mode;
           o    acquisitionStation
           o    archivedIn/ArchivingInformation:        archiving      centre,    archiving       date,   archive
                identifier;
           o    acquisitionParameters/Acquisition: orbit number, last orbit number, direction
                (ascending / descending), pointing angle;
           o    browse/BrowseInformation: type, sub-type, reference system, file name;
           o    product/ProductInformation: size, version, reference system, file name;
           o    histograms information;
           o    hasScene: Xlink to scene metadata;
           o    hasMask: Xlink to mask;
           o    coupledWith: Xlink to the coupled datastrip with coupling information (stereo, tri-
                stereo, mosaic);
           o    localAttribute & localValue: list of attributes used for representing missions specific
                attributes not represented in the schema.
   o    ohr:EarthObservationProductType: it extends the hma:EarthObservationProductType for
        including the optical sensors specificities:
           o    acquisitionParameters/Acquisition: added illumination azimuth and illumination
                elevation;
           o    cloudCoveragePercentage
           o    snowCoveragePercentage
   o    sar:EarthObservationProductType: it extends the hma:EarthObservationProductType for
        including the radar sensors specificities:
           o    polarisationMode
           o    polarisationChannels
           o    antennaLookDirection
           o    minimumIncidenceAngle
           o    maximumIncidenceAngle
           o    dopplerFrequency
           o    acquiredBy/Sensor/swathIdentifier
           o    beamModeMnemonic
   o    atm:EarthObservationProductType: it extends the hma:EarthObservationProductType for
        including the atmospheric sensors specificities:
           o    dataLayers/DataLayer/specy
           o    dataLayers/DataLayer/unit
           o    dataLayers/DataLayer/highestLocation
           o    dataLayers/DataLayer/bottomLocation
           o    dataLayers/DataLayer/algorithmName
           o    dataLayers/DataLayer/algorithmVersion
The full description of Product Metadata is provided in [AD08].


4.1.5   Order
This metadata covers the needs of EO products ordering and subscriptions.
The main information items related to product ordering are:
   •    Order Options

                                                       Pag. 46/182
                                Title:                 Architectural Design Technical Note
                                Contract Ref.:         P-E190/DGIGSD-3556-05
                                Int. Ref.:             P-E190/DGIGSD-0399-06                 Issue:       1   Rev.:     7
                                Proj. Ref.:            HMA-DD-DAT-EN-001                     Date:            14/09/2007

    •      Product Order
    •      Subscriptions
The structure of above items is outlined in the UML models reported hereafter.
The detailed definition of Order information model can be found in the HMA Ordering ICD [AD05].

4.1.5.1      Order Options

                                                            OrderOptions




                                                          ProductServiceOptions




                                                          -productOrderOptions

                                                                    1..n
                                                          P roductOrderO ption
                                    -option                                                -productDeliveryOptions
                                                   productOrderOptionsId : Strings
                                                   <<Vector>> qualityOfService : Strings




                                                                -sceneSelectionOption


                             0..*
                                                                                                                        1..n
                            OptionType                                      0..n
          optionName : Strings                                                                             P roductDeliveryOptionType
                                                                SceneSelectionOptionType
          <<Vector>> optionValueDefinition : Strings                                                  deliveryMethod : Strings
                                                                 sc eneType : Strings
          optionType                                                                                  <<Vector>> packageMedium : Strings
          identifier : String




                                                   Figure 11: Order Option structure.


Order options specify all possible valid combinations of options for ordering products of a
specified collection and for adhering to a subscription.
A single order option instance includes the following attributes:
    •      Identifier of the order options group;
    •      scene selection options (e.g. possible options for ordering a scene on the product). These
           are not applicable to subscriptions.
    •      the list of possible product delivery options (e.g. CD, DVD, electronic, etc.);
    •      the list of other options (e.g. for product orders: product level, product format, etc; for
           subscriptions: expiration date, geographical area, etc.).


4.1.5.2      Product Order & Subscription
The order is the data structure sent by the user / operator to order products and to adhere to
subscriptions.




                                                                           Pag. 47/182
                                Title:                      Architectural Design Technical Note
                                Contract Ref.:              P-E190/DGIGSD-3556-05
                                Int. Ref.:                  P-E190/DGIGSD-0399-06                                      Issue:      1     Rev.:             7
                                Proj. Ref.:                 HMA-DD-DAT-EN-001                                          Date:             14/09/2007



                                                                                                                           -userInformation
                                                                                                                                              1..1
                                                                                                               Order                                 UserInf ormation



                                                                                                      -orderSpecification

                                                                                                              1..1
                                                                                                 ProductOrderSpecif ication     -deliveryInformation
                                                                       -ord erItem                                                                        DeliveryInf omationType
                                                                                                  orderA ccount : Strings
                                                                                                                                                1..1       f tp_push
                                                                                                  orderRef erence : Strings
                                                 1..n                                                                                                      f tp_pull
                                                                                                  orderRemark : Strings


                                          ProductOrderIte mType
                                         deliveryMethod : Strings
                                         packageMedium : Strings
                                         qualityOf Service : Strings                                                                                            +mail 1
                                         orderItemRemark : Strings
                                                                                                                                                          DeliveryA ddressType
                                                                                                                                                           recipient : Strings
                                                                                                                                                           companyRef : Strings
                                                                                                                                                           telNumber : Strings
                                                  -sceneSelection




                                                            0..1                                                                                                         0..1

                                               SceneSelectionType                                 1
                                                                                                                                                               PostalA ddress
               Option                        sceneType : Strings                           ProductId                                                        streetNumber : int
                                             sceneCentre : coordinates                                                                                      city : Str in gs
        optionName                                                                    identif ier : Strings
                                             scenePosition : Strings                                                                                        state : S trings
        optionSelectedV alues                                                         collectionId : Strings
                                             sceneSize : Strings                                                                                            postalCod e : St rings
                                             scenePolygon : coordinates                                                                                     countr y : Strings
                                                                                                                                                            postBox : Strings



                                                          0..1
                                                 TemporalSelection
                                              star tDateTime : DateTim e
                                              endDateTime : DateTime




                                                        Figure 12: Product Order structure.


An order contains the following information:
   •      userInformation, identifying the user who submitted the order;
   •      orderSpecification, which regroups the following attributes:
                  o      orderAccount, Account under which the user is authorised to order from the
                         specific provider;
                  o      orderReference, user defined name of the order;
                  o      orderRemark, textual remark;
                  o      deliveryInformation, which include FTP / mail (with related deliver address);
                  o      list of orderItem, which include:
                                 productId, which identifies the item to order;
                                 option: list of user selected options. Several type of options can be
                                 specified: strings, numbers, enumerated strings, polygon, times.
                                 sceneSelection: in case of scene order it identifies the scene on the parent
                                 product;
                                 deliveryMethod, package, quality of service.
This structure is used for the 2 purposes: product ordering / subscription. The distinction is
performed by the productId element: if the specified collection reference to a collection then the
order implies the adhesion to the subscription; if it reference an EO product, then it is a product
order.

4.1.6     Programming
This section deals with the data exchanged for ordering future products.


                                                                                     Pag. 48/182
                                   Title:                         Architectural Design Technical Note
                                   Contract Ref.:                 P-E190/DGIGSD-3556-05
                                   Int. Ref.:                     P-E190/DGIGSD-0399-06                              Issue:        1       Rev.:      7
                                   Proj. Ref.:                    HMA-DD-DAT-EN-001                                  Date:                 14/09/2007

The reported description provides a conceptual description of the information items managed by
the Programming interface. The actual data structures used for handling this information can be
found in the HMA Programming ICD [AD10].
The main information items related to the programming services are:
   •   Acquisition Orders
   •   Coverage Orders
Acquisition Orders are conceptually identical to the order items described in 4.1.5.2, apart from
being related to the future, and then are not described in this section.
The figure reported below presents the conceptual model of a Coverage Order.


                                                                                  CoverageOrder




                                                                                            1..1
                                                                              CoverageOrderSpecification
                 1..1                                                                                                                                ObservationRepetition
                                                                               orderAc count : Strings          -observationRepe ti ti on
                                                                               orderReference : Strin gs                                           num berOfObservations : byte
             UserI nform a ti on                                                                                                           0..1    observationGap : int
                                                                               orderRem ark : S tring s
                                                                               pl afShNm : Strings
                                                                               pl atfSer : St ri ngs
                                                                               i nst ShNm : Strin gs
                                            -geoTemporalCon dition
                                                                               i nst Mode : St rings                -deliveryInformation
                                                                                                                                                            1..1


                                                            1..1
                                            GeoT em pora lCondi ti onT ype
                                                                                                                                                    DeliveryInfom ationT ype
          -programming              m axNum OfProductsPerObservation : byte
                                                                                                                                                      ftp_push
                                    priority : int                                            -coverageRequired
                                                                                                                                                      ftp_pull



                                                                                                             1..1
                   0..1                                           -dataExt
                                                                                                   <<Enum eration>>
           Pro gram m ingT y pe                                                                    CoverageRequired                                         +m ail
       swathId : Strings                                                                          any cov erage                                                    1
       xPntAngle : Strings                                                                        any reference cov erage                             DeliveryAddressT ype
                                                                       1..1
       aPntAngle : Strings                                                                        full c overage                                      recipient : Strings
       <<Vector>> pol : Strings                              DataExt                                                                                  com panyRef : Strings
       <<Vector>> stration : Strings                                                                                                                  telNum ber : Strings

                                                       -tempEle      -geoEle
                                                                                                                                                                   0..1
                                                 1..1                           1..1

                                       T em pExtentT ype                 GeoExtentT ype
                                                                                                                                                          PostalAddress
                                                                                                                                                     streetNum ber : int
                                             -exTemp                                                                                                 city : Strings
                                                                                                                                                     state : Strings
                                                   1..1                                                                                              postalCode : Strings
                                   T im eDurati onT yp e                      Pol ygonT ype                                                          country : Strings
                                                                                                                                                     postBox : Strings
                                                                         coordinates : Strings

                                        -beginEnd

                                                1..1
                                   StartEndT im eT ype
                                     begi n : DateT i me
                                     end : DateT im e




                                                           Figure 13: Coverage Order structure.


The coverage order is set by the user / operator to order products for covering a certain area in a
specified time period.
A coverage order contains the following information:
   •   userInformation, identifying the user who submitted the order;
   •   coverageOrderSpecification, which regroups the following information items:

                                                                                         Pag. 49/182
                       Title:             Architectural Design Technical Note
                       Contract Ref.:     P-E190/DGIGSD-3556-05
                       Int. Ref.:         P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                       Proj. Ref.:        HMA-DD-DAT-EN-001                 Date:        14/09/2007

            o   deliveryInformation, which include FTP / mail (with related deliver address);
            o   satellite / sensor identifiers;
            o   geoTemporalCondition, which include:
                           programming: includes the swathId, the pointing angle, polarization and
                           acquisition station;
                           dataExt/tempEle: temporal extension of the reference observation;
                           dataExt/geoEle: geographical extension of the reference observation;
                           coverageRequired: it specifies how the area has to be covered (all
                           products overlapping the area, only an optimized sub-set not overlapped);
                           maxNumOfProductsPerObservation;
                           priority: priority of the request;
            o   observationRepetition: specifies the periodicity of the observation (number of
                observation, temporal distance between 2 adjacent observations);
The full description of Programming information model can be found in the HMA Programming
ICD [AD10].

4.1.7   User Management Data
This section deals with the HMA information items needed for user authentication.
HMA user profile is a set of user attributes that describes an HMA user, whether a human or a
service entity. The user profile is composed of several attributes, each associated with an identity,
a source and an authority. The identity is the entity (or principal) which is described by the profile.
The source is the entity that provides the information for the profile item and the authority is the
entity that verifies and/or maintains the value.
Because the large support of COTS and because the usage from many user and organizations,
the LDAP V3 has been selected as the mean for modelling and managing HMA user profiles.
LDAP foresees a hierarchical representation of the stored objects and items and then HMA user
profile are represented by sub-trees of LDAP hierarchy.
HMA user profile defines three types of users:
   •    Scientific users
   •    GMES users
   •    Commercial users
these types are modelled with the following LDAP objects:
   •    hmaUser, which regroups the attributes common to all types of HMA users:
            o   country of origin
            o   common name
            o   organization name
            o   organizationalUnitName
            o   mail
            o   telephoneNumber
            o   userCertificate
            o   hmaId
            o   nationality
            o   facsimileTelephoneNumber
            o   postalAddress
            o   postalCode
            o   preferredLanguage
   •    hmaScientificUser, which regroups the specific attributes for scientific users:

                                                          Pag. 50/182
                       Title:           Architectural Design Technical Note
                       Contract Ref.:   P-E190/DGIGSD-3556-05
                       Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                       Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

            o   hmaProjectName
    •   hmaGMESUser, which regroups the specific attributes for GMES users:
            o   hmaServiceName
    •   hmaCommercialUser, which regroups the specific attributes for commercial users.
            o   hmaOperatorName
            o   hmaContactPerson
            o   shippingAddress
            o   shippingAddressComment
            o   shippingAddress2
            o   shippingAddressComment2
            o   shippingAddress3
            o   shippingAddressComment3
            o   currency


The full description of User Profile is provided in [AD12].


4.1.8   Satellite / Sensor metadata
Within HMA no mission planning functionality is actually implemented: the actual tasking of
satellite activity and solving of resource conflicts is performed within the Ground Segments without
any interference from the EO DAIL. At HMA level is considered instead the feasibility of mission
planning requests i.e. it is verified the possibility of fulfilling the request considering the satellite orbit
parameters, the sensor characteristic and, for optical sensor, the meteorological conditions.
To accomplish the feasibility analysis the following information items are received / harvested from
/ to the ground segments:
    •   reference orbit
    •   instrument swaths
    •   instrument parameters
    •   acquisition stations parameters
    •   manoeuvre plans
    •   instrument unavailability information (including unavailability due to already planned
        activity)
    •   system service disruption
    •   duty cycle limitations


The identification of these parameters is not finalised yet, but in the [AD10] some examples
parameters are provided (DescribeSensorResponse message).


4.1.9   Transaction Tracking Data
Transaction tracking is needed for different reasons:
    •   for monitor & control purposes, e.g. for understanding the workload of the system
    •   in case an operation goes wrong, it allows to understand the status of the system e.g.: in
        case a user has not received an ordered product, the system is able to understand
        whether the product has been sent or not or whether some errors occurred during the
        processing, etc.
Based on the experience of SSE system [RD03], a model of data for tracking execution of services
operations is reported in the figure below:

                                                        Pag. 51/182
                                  Title:                    Architectural Design Technical Note
                                  Contract Ref.:            P-E190/DGIGSD-3556-05
                                  Int. Ref.:                P-E190/DGIGSD-0399-06                    Issue:     1     Rev.:     7
                                  Proj. Ref.:               HMA-DD-DAT-EN-001                        Date:            14/09/2007



                                                             Or    saton
                                                               gani i
                                Ser ceCat
                                  vi    egor
                                           y                 nam e
                                                                  i i
                                                             descrpton
                                                             UR L




                                                                       der
                                                                     Or ed sequence of
                                                0.n
                                                  .                     vi     aton
                                                                     ser ce oper i
                                                              .
                                                            0.n
                                                   vi
                                                Ser ce                                              vi f
                                                                                                 Ser ceLieCycl e
                                           nam e                                                     atonN
                                                                                                 oper i am e
                                                 ii
                                           descrpton                                                 atonN
                                                                                                 oper i um ber
                                           echnol
                                           t      ogy                                            synchronousFlag
                                           i       i yTi
                                           fxedD elver m e                                     .
                                                                                             0.n wor l
                                                                                                    kfowN am e
                                           i      i
                                           fxedPrce
                                             at
                                           st us
                                              vi d
                                           ser ceI
               U ser                                                    nputf each
                                                                    One i   or                                                     nput t s he
                                                                                                                              XM L I :i i t
       (r
        fom U serM anagem ent
                            )                                           aton he    vi
                                                                    oper i oft ser ce                                                  I rng
                                                                                                                              XM L ASCI sti
         userdI                                                                                                                 ovi
                                                                                                                              pr ded as i nput
         passw or  d                                                                                    atonI
                                                                                                    O per i nput                 am er o he
                                                                                                                              par et t t
         fr N am e
          ist                                           .
                                                      0.n                                               aton
                                                                                                    oper i                        aton he
                                                                                                                              oper i oft
         l N am e
          ast                                  vi
                                           Ser ceR equest                                           XM LInput                    vi
                                                                                                                              ser ce
         organi izaton                     r      I
                                            equestd                                             .
                                                                                              0.n
         em ai l                             at
                                           st us
                                    0.n
                                      .          at
                                           subSt us
                                             i
                                           prce
                                             ari    m
                                           st tngTi e                                                    atonR
                                                                                                     O per i esul t
                                            ast
                                           l U pdat    m
                                                    edTi e                                                                              t t s he
                                                                                                                               XM LResul:i i t
                                                                                                         aton
                                                                                                     oper i                             I rng
                                                                                                                               XM L ASCI sti
                                                                                                     XM LResult                 et ned as r t
                                                                                                                               r ur       esul
                                                                                               .
                                                                                              0.n
                                                                                                      at
                                                                                                     st us                     r    he     aton
                                                                                                                               fom t oper i of
                    kfow nst
               A wor l i ance i s                                                                    ast
                                                                                                     l U pdat   m
                                                                                                             edTi e
               cr ed f each
                 eat or                                                                                                        he    vi
                                                                                                                               t ser ce
                                                                               e esuls or
                                                                     One orm or r t f
               i           aton
                nvoked oper i                                                 aton he
                                                                     each oper i oft
                                                                       vi
                                                                     ser ce
                                                        .
                                                      0.n
                                              kfowI ance
                                           W or l nst




                       Figure 14: HMA transaction tracking information model (Courtesy of Spacebel).
The main class in this diagram is the Service Request: it represents the execution of a request
invoked by a client. Because a request in our service oriented architecture may be only the
activation of an operation of a service, then the service request is the “instantiation” of a service
operation. Then this instantiation is tracked recording the following information:
   •       the activated service;
   •       the input and output parameters of each invoked operation (the full XML messages are
           stored in the system);
   •       the status of the operation and the activation date & time and the last updated time;
   •       for each invoked service and operation a corresponding unique identifier is generated in
           order to allow a later retrieval of the data.




                                                                               Pag. 52/182
                        Title:           Architectural Design Technical Note
                        Contract Ref.:   P-E190/DGIGSD-3556-05
                        Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                        Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007



5 Service Viewpoint
5.1       Introduction
This section maps the Computation Viewpoint of the RM-ODP Reference Model (see section
2.1.2).
This section describes the services to be provided through the HMA. In combination with the
Information Viewpoint, these service specifications provide the HMA Service Architecture.
According to [RD02] principles, the Services described hereafter include all properties of services
that may be specified in a platform-neutral way. Their mapping to infrastructure platforms (like
e.g. a W3C Web Services environment) is specified in the Engineering view.



5.2       Services Composition
One of the main concepts behind service oriented architecture is that services can be composed
in many ways obtaining value added services or chaining multiple services to combine data and
services in ways that are not pre-defined by the data or service providers. This service chaining
defines compound services [RD39].
Based on the ODP definition of Chain, a Service Chain is defined as a sequence of services where,
for each adjacent pair of services, occurrence of the first action is necessary for the occurrence
of the second action.
The action of making the input of one service dependent upon another service leads to treating
service chains as directed graphs, where each service is a node in the graph and references to
service interactions form the edges.
A node in the directed graph is a representation of the service. A service node contains two types
of information: parameters and sources. Parameters in a service node provide the configurations
of the service for the particular chain in which the service class is being used. Sources in a service
node indicate the sources of input data to the node.
Additional elements characterizing a service chain:
      •   Parallel vs. serial chains: the Service chain can have parallel paths based on branches;
          potential branch types include: if/else, merge, switch, and trigger
      •   Iteration: the Service chain can operate as an iteration, e.g., while and count loops
Services can be chained composing compound services according to the patterns presented in
the following sections (ref. to [RD04]):
      •   User defined (transparent) chaining: the Human user manages the workflow.
      •   Workflow-managed (translucent) chaining: the Human user invokes a Workflow
          Management service that controls the chain and the user is aware of the individual
          services.
      •   Aggregate service (opaque): the user invokes a service that carries out the chain, with the
          user having no awareness of the individual services.
In addition to the difference in visibility of the services to the user, a key distinction between these
patterns is the difference in control. In transparent chaining the control is exclusively with the user.
In translucent, a workflow service is present which controls the chain execution, perhaps with
oversight by the human. In the aggregate pattern, the aggregate service exclusively performs the
control function with no visibility by the user.



5.2.1     User Defined Chaining Pattern
The user defines and controls the order of execution of the individual services.
The user knows of a service catalogue in order to discover services of interest. A specific chain
does not exist before the user begins. The user has the ability to define a valid chain.
                                                         Pag. 53/182
                         Title:                      Architectural Design Technical Note
                         Contract Ref.:              P-E190/DGIGSD-3556-05
                         Int. Ref.:                  P-E190/DGIGSD-0399-06                                 Issue:   1   Rev.:   7
                         Proj. Ref.:                 HMA-DD-DAT-EN-001                                     Date:        14/09/2007

This implies that the user must be able to design an efficient chain that will execute. The inputs and
outputs of the individual services must be compatible, or an intervening service must be added,
e.g., format translation.
In this pattern the user is knowledgeable of how services can be combined. The user discovers
and evaluates the available services, determines their fitness to the need, determines a valid
sequence of services, and controls the chaining. The user is provided information sufficient to
make the control decisions.




                                                                         1 – Search Request
                                  Client                                                                            Catalogue
                                                                          2 – Search Results                         Service




                                                                                 5a - Service invocation



                                            4a - Service invocation
                   3 - Service invocation




                                             4b - Request for input         Srv 2        5b - Request for input


                                   Srv 1
                                                              5c - Request for input                        Srv 3

                                       Figure 15: User Defined Services Composition
1.          A human uses a client to send a search request (or series of searches) to a catalogue
service. The catalogue service provides queries on service metadata.
2.        Catalogue Service returns metadata about services of interest to the user. For this
example the user has found three services which will be chained.
3.           User invokes a service using the client, causing a result to be available for a subsequent
service
4a/b.       User invokes a second service using the client. The request includes a reference to the
results from the previous step. The service creates a result that is available for the next service.
5a/b/c.    User invokes a third service using the client. The request includes references to the two
previous services. This third service returns a result to the client.



5.2.2     Workflow-Managed Services Chaining
The Services execution is under the supervision and control of the Orchestration Service; it handles
details of the distributed computing aspects of executing the chain.
The Orchestration Service provides means of activating, monitoring and controlling services
execution according to the following specification: the client application selects the workflow of
interest and activates it providing needed parameters.




                                                                             Pag. 54/182
                     Title:                         Architectural Design Technical Note
                     Contract Ref.:                 P-E190/DGIGSD-3556-05
                     Int. Ref.:                     P-E190/DGIGSD-0399-06                                 Issue:        1     Rev.:   7
                     Proj. Ref.:                    HMA-DD-DAT-EN-001                                     Date:              14/09/2007


                                                                         1 - chain invocation
                                   Client
                                                                    5 - Chain results




                                                                                          Orchestration
                                                                                            Service
                                                             3c - Service Status



                        2b - Service Status
                                                                                                        4a - Service invocation
                                                    2a - Service invocation

                                                                                    3a - Service invocation



                                              3b - Request for input           Srv 2          4b - Request for input


                                    Srv 1
                                                                 4c - Request for input                         Srv 3

                              4d - Service Status

                              Figure 16: Workflow-Managed Services Composition.


The previous figure depicts the Orchestration Service in charge of activating various chained
services in the right order; a brief description is provided in the following:
1.       A human uses a client to request that a workflow service execute a chain;
2a/b.     The Orchestration service determines the services in the chain and invokes the first
service. The service informs the Orchestration service of the completion of the task. Status of the
service may be provided directly to the client. The client may stop the workflow.
3a/b/c. Upon notification of completion of the first service, the workflow service determines the
next service in the chain and invokes it. The second service requests results from the first service.
The service informs the workflow service of the completion of the task. Status of the service may
be provided directly to the client. The client may stop the workflow.
4a/b/c/d. Upon notification of completion of the second service, the workflow service determines
the next service in the chain and invokes it. The third service requests results from the first and
second services. The service informs the workflow service of the completion of the task. Status of
the service may be provided directly to the client. The client may stop the workflow.
5.       Upon notification of completion of the last service, the workflow service informs the client
of the completion of the chain.



5.2.3   Aggregate Services Chaining
As the name implies, in this pattern the services appear as a single service which handles all
coordination of the individual services behind the aggregate service. The user has no awareness
that there is a set of services behind the aggregate.




                                                                              Pag. 55/182
                     Title:                    Architectural Design Technical Note
                     Contract Ref.:            P-E190/DGIGSD-3556-05
                     Int. Ref.:                P-E190/DGIGSD-0399-06                                  Issue:         1   Rev.:   7
                     Proj. Ref.:               HMA-DD-DAT-EN-001                                       Date:             14/09/2007



                                                                         Client



                                                            1 – Invoke Service
                                                                          5 - Service Result




                                                                    Catalogue
                                                                     Service



                                   2 - Service invocation                                      4a - Service invocation
                                                                3a - Service invocation




                                       3b - Request for input           Srv 2
                                                                                      4b - Request for input

                              Srv 1
                                                            4c - Request for input                              Srv 3

                                   Figure 17: Aggregated Services Composition.


1.     A human uses a client to request that an aggregate service execute a chain. The user
may have no knowledge that the service is implemented using a chain of services.
2a.       The aggregate service determines the services in the chain and invokes the first service.
The service informs the aggregate service of the completion of the task.
3a/b.     Upon notification of completion of the first service, the aggregate service determines the
next service in the chain and invokes it. The second service requests results from the first service.
The service informs the aggregate service of the completion of the task.
4a/b/c. Upon notification of completion of the second service, the aggregate service determines
the next service in the chain and invokes it. The third service requests results from the first and
second services. The service informs the aggregate service of the completion of the task.
5.         Upon notification of completion of the last service, the aggregate service informs the
client of the completion of the chain.



5.3    Services Functional Classification
An additional services classification according to a different perspective with respect to ISO 19119
Service Taxonomy (see section 2.1.3) is presented in the following.
Services are functionally classified in service categories. Following the taxonomy used in RD02, the
main service categories are Architecture Services (AR Services) and Application Services (AP
Services):
        • An AR Service provides a generic, platform-neutral and application-domain
          independent functionality.
        • An AP Service provides an application domain-specific functionality built on top and
          by usage of AR Services and/or other AP services.
Note that AR Services may themselves use other AR Services. Furthermore, AP Services may use AR
Services in order to fulfil a given functionality.
This functional classification and relationships between ARchitecture and APplication services are
illustrated in the following figure.


                                                                          Pag. 56/182
                      Title:            Architectural Design Technical Note
                      Contract Ref.:    P-E190/DGIGSD-3556-05
                      Int. Ref.:        P-E190/DGIGSD-0399-06                 Issue:   1    Rev.:   7
                      Proj. Ref.:       HMA-DD-DAT-EN-001                     Date:         14/09/2007




                                          AP Srv 1
                                                       Use
                                                                        AP Srv 2

                                                       AP Srv 3



                                                Application Services


                                               Use                          Use



                                          AR Srv 1
                                                             Use

                                                                        AR Srv 2

                                         Use
                                                Architecture Services

                                       Figure 18: Services Classification.



5.4     HMA Services
The table provides a brief description of the services to be provided through HMA and classify
them according to the two taxonomies proposed in sections 2.1.3 and 5.3.
 Service           Description                                                             ISO 19119     Service
                                                                                           Taxonomy      Category
 Service           It is used to add new services beyond the built-in set to           System            AR
 Registration      the HMA.                                                            Management
 Service                                                                               Services
 Orchestration     The ability to execute and control compound services.               Workflow/ Task    AR
 Service                                                                               Management
                                                                                       Services
 Monitoring &      The Monitoring & Control service provide a set of                   System            AR
 Control Service   functionalities for logging and monitoring the                      Management
                   transaction traffic across the HMA. It shall also allow a           Services
                   user to monitor and control their requests and return
                   the status of on-going activities.
 Collection        This service provides the capability to the user/operator           Model/Informati   AP
 Discovery         or applications to discover and get details about the               on management
 Service           dataset collections available in the HMA infrastructure.            Services
 Service           The Discovery service provides a set of functionalities             Model/Informati   AP
 Discovery         for the user/operator or for applications to search and             on management
 Service           retrieve structured information on the “Human                       Services
                   Readable” services available e.g. it is able to find the
                   Ground Segments allowing to order a specific type of
                   products, to find the ground segments having a
                   catalogue for a specified type of products, etc.




                                                         Pag. 57/182
                    Title:              Architectural Design Technical Note
                    Contract Ref.:      P-E190/DGIGSD-3556-05
                    Int. Ref.:          P-E190/DGIGSD-0399-06               Issue:   1    Rev.:   7
                    Proj. Ref.:         HMA-DD-DAT-EN-001                   Date:         14/09/2007


Service         Description                                                              ISO 19119     Service
                                                                                         Taxonomy      Category
Service         This service is for lower level service discovery e.g.: it is        Model/Informati   AR
Configuration   in charge of managing the WSDLs of HMA services,                     on management
Discovery       etc.                                                                 Services
Service
Catalogue       The Catalogue service provides a set of functionalities              Model/Informati   AP
Service         for the user/operator to search and retrieve metadata                on management
                and browse images for the catalogued EO products                     Services
                from the missions being part of the HMA infrastructure
Programming     The programming            service    provides    a   set     of     Model/Informati   AP
Service         functionalities for:                                                 on management
                    •        performing feasibility analysis of future EO            Services
                             products i.e. to check whether the request of
                             future products can be fulfilled considering the
                             satellite  &    sensor   characteristics,    the
                             meteorological conditions and possibly the
                             mission work load.
                    •        placing requests for future EO products from
                             the mission(s) being part of HMA infrastructure.


Order Service   The Order service provides a set of functionalities to the           Model/Informati   AP
                user/operator for:                                                   on management
                    •        Placing orders for the catalogued EO products           Services
                             from the mission(s) being part of the HMA
                             infrastructure.
                    •        Subscribing to EO products.
                The services should verify any constraints that may be
                imposed on users, and report status and relevant
                information back to the user.
User            The User Management service provides a set of                        System            AR
Management      functionalities to manage all information related to a               Management
Service         user and access to the services. This includes                       Services
                management of an account and related quotas for
                access to specific services, the registration, the
                authentication, the GS and HMA policies enforcement
                and the authorisation.
Virtual FTP     This service allows searching and downloading on-line                Model/Informati   AP
Service         available data.                                                      on management
                                                                                     Services
FTP             This service allows downloading on-line available data.              Model/Informati   AP
                                                                                     on management
                                                                                     Services
WMS             Web Map Service allows clients to retrieve the map                   Model/Informati   AP
                layer covering the specified area, at the specified time             on management
                (optional), at the specified height (optional). The                  Services
                returned map layer is an image with standard format.
WCS             Web Coverage Service allows clients to retrieve a grid               Model/Informati   AP
                of data covering the specified area, at the specified                on management
                time (optional), at the specified height (optional).                 Services
                The difference with respect the WMS is the format of
                the output: in the WMS case it is an image, in the WCS
                case it is a grid of data, which can be also further
                processed for getting images.

                                                        Pag. 58/182
                             Title:           Architectural Design Technical Note
                             Contract Ref.:   P-E190/DGIGSD-3556-05
                             Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:      1     Rev.:     7
                             Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:             14/09/2007


 Service               Description                                                              ISO 19119       Service
                                                                                                Taxonomy        Category
 Help &                 This service provide support to users providing access            Model/Informati       AP
 Documentation          to system relevant documentation, including missions'             on management
 Desk Service           documentation, Answering user enquiries, complaints               Services
                        and investigation on services, tools, orders.
                        The service will be further detailed in future release of
                        the document.
Table 2: HMA Services High Level Description and Classification.


Different instances of these services are present in the HMA infrastructure. In fact according to
[AD01] and [AD02], in the HMA infrastructure there are three main entities:
    •    The Users / Operators, submitting requests to the system. This entity includes anyone
         needing earth observation and geospatial data: generic users, scientific users, commercial
         or distributing entities, GMES service segment, etc.
    •    GSs Service Instances, are those services instances hosted by the Ground Segments that
         provide the specific service functionality exploited by the HMA infrastructure.
    •    HM Service Instances, are those services instances hosted by the EO-DAIL that manage
         complex client requests for access to multiple GS service instances, split them into simpler
         requests activating the GS services instances for being actually executed. They are
         intermediary between the users / operators and the GSs service instances. They are in
         charge of orchestrating the access to the GSs native services providing added value to
         the users / operators.


               User / Operator                       GS 1
                                                       GS Instance
                                                 HM Service1

                                                                                                GS 1
                                                                                                GS 1
                                                                                         GSs Service Instance
                                                     Same ICDs




                                 Figure 19: HM Service Instances vs. GSs Service Instances.
For example, to perform a distributed catalogue search (scenario US_2_3 of [AD01]) the HM
Catalogue service Instance receives the search request from the client, and the GS Catalogue
service Instances receive the split requests from the HM Catalogue Instance.
The description and the relationships between the different service instances is the topic of the §6
Engineering Viewpoint.
The above figure clarifies also that:
    •    The GS native Services can be accessed directly without passing through the HM Services
    •    The same specifications are used to implement the interfaces between the Users /
         Operators and the HM Services, and the interfaces between the HM Services and the GSs
         Services.



5.5 Service Descriptions
On the model of [RD02], the description of the services is provided in table format according to
the template below.
        Name                 Name of the Service
                             Convention: All individual words in the service name are capitalized.

                                                                 Pag. 59/182
                  Title:           Architectural Design Technical Note
                  Contract Ref.:   P-E190/DGIGSD-3556-05
                  Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                  Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007


Taxonomy          Specify the taxonomy the service is related to (refer to section 2.1.3)
Category          Specify if the service is Architecture / Application Service (refer to section
                  5.3)
Standard          Reference to an abstract or a concrete service specification according to a
Specifications    standardisation organisation (e.g. ISO, W3C, OASIS, CEN, OGC,…) or to
                  important reference material that is relevant for the service or contained
                  service operations
                  In case of no adequate reference the field is set to “no corresponding
                  standard known”
INSPIRE           Put a reference to the corresponding INSPIRE network service, if a
                  corresponding service exists.
Extension of      Reference to the name of the GMES HMA service(s) in the service interface
                  model from which operations are directly inherited.


Description       Human understandable description of the service
Service
Operations
   servOper1      Description              Human understandable description of the service
                                           operation 1.
                                           Convention: All words in the service operation name
                                           are written together in italics without a blank in
                                           between. The first letter of the first word is lower case, all
                                           other words upper case.
                  Input                    Parameters provided by the requestor
                  Output                   Return parameters
              …
   servOperN      Description              Human understandable description of the service
                                           operation n
                  Input                    Parameters provided by the requestor
                  Output                   Return parameters
Example
usage
Comments




                                                   Pag. 60/182
                         Title:              Architectural Design Technical Note
                         Contract Ref.:      P-E190/DGIGSD-3556-05
                         Int. Ref.:          P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                         Proj. Ref.:         HMA-DD-DAT-EN-001                 Date:        14/09/2007


5.5.1    Service Registration
        Name                      Service Registration
        Taxonomy                  System management services
        Category                  Architecture Service
        Standard                       •   OGC Web Services Common Specification
        Specifications                 •   OASIS UDDI
                                       •   Web Notification Service
        INSPIRE                   Invoke Spatial Data Services
        Extension of              None
        Description               This service provide the operators the capability to deploy new
                                  compound services On the HMA infrastructure.
        Service
        Operations
          RegisterService         Description            It allows a Service Provider to register a new service
                                                         on HMA. After a successful registration, a
                                                         confirmation and a link to the service details page
                                                         are provided.
                                  Input                  •   Service Name": allows entering name of the
                                                             service.
                                                         •   "Publish State": allows setting the status of the
                                                             service. The following values are defined for the
                                                             service publish state:
                                                             • "disabled": the service is not available
                                                             • "enabled": the service is available for all users
                                                             • "testing": the service is visible for all users but
                                                                  can only be activated by the corresponding
                                                                  Service Provider.
                                                         •    "Service category" and "Service subcategory":
                                                              allow to select the category and subcategory
                                                              the service belongs to.
                                                         •    “Price & Price Value": valid values are "Free",
                                                              "RFQ", "Fixed" and a value applicable if the price
                                                              is Fixed.
                                                         •    "Currency": allows the service provider to specify
                                                              a currency for the price.
                                                         •    “Delivery Time": valid values are "RFQ", "Fixed"
                                                              and a value applicable in case Fixed delivery is
                                                              provided
                                                         •    "Service Access": allows to restrict the service
                                                              access. The following values are valid for the
                                                              service access:
                                                             • "no restriction": the service is available for all
                                                                  users.
                                                             • "restricted": the service is not available for all
                                                                  users.
                                                             • "restricted with authorisation workflow ": the
                                                                  service is not available for all users, you need
                                                                  an authorisation.
                                                         •   "Service Description" edit field: allows entering a
                                                             textual description of the service. The text should
                                                             Pag. 61/182
              Title:            Architectural Design Technical Note
              Contract Ref.:    P-E190/DGIGSD-3556-05
              Int. Ref.:        P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
              Proj. Ref.:       HMA-DD-DAT-EN-001                 Date:        14/09/2007


                                               be valid HTML. This means that some characters
                                               may have to be entered as entities. See
                                               http://www.htmlhelp.com/reference/html40/enti
                                               ties/ for a list of HTML entities.
                                           "Description file" upload field : allows to upload a "txt"
                                           or "html" file containing the service description. Only
                                           one of the two fields "Service Description" and
                                           "Description file" must be provided.
                                           • "Keywords": allows to enter some key words
                                               which correspond to some characteristics of the
                                               service.
                                           • "Technology": allows to provide some more
                                               technical information on the service.
                                           • "Quality of Service": allows to describe the quality
                                               of service. Hyper-Link to an external PDF
                                               document explaining QoS is allowed.
                                           • The last fields concern the specifications of the
                                               technical details needed to communicate with a
                                               service provider. These details are specified
                                               within Service interface, Service description and
                                               Service presentation files that will be uploaded
                                               from the Service Provider system to the HMA.
                                               three files are required:
                                               • WSDL file : must contain the WSDL definition
                                                   of the service. Its expected filetype is ".wsdl".
                                               • XSL stylesheet : must contain the style sheet
                                                   to apply on the instance file in order to
                                                   present the forms used to enter, display the
                                                   service specific parameters. Its expected
                                                   filetype is ".xsl".
                                               • Schema file : must contain the schema
                                                   definition of the service. Its expected file type
                                                   is ".xsd".
                                           • "Use AOI": allows to enable the Area Of Interest
                                               functionality for this Service.
                                           • “AOI”: provide the AOI to apply as restriction to
                                               the Service
                       Output              •    Registration Result
                                           •    Service details page link
          SetAOI       Description         Allows defining a geographic restriction in term of
                                           Area Of Interest accessible for the Service.
                       Input               • AOI Label: Name of the AOI
                                           • Code: Area Code
                                           • Extent: minimum and maximum extent of the
                                               area
                                           • Co-ordinates: detailed specification of the geo-
                                               region
                                           • Region: alternative selection method specifying
                                               an already defined Region to be used as AOI
                       Output              AOI Specification according to OGC’s Geographic
                                           Markup Language
Example
usage


                                                Pag. 62/182
           Title:              Architectural Design Technical Note
           Contract Ref.:     P-E190/DGIGSD-3556-05
           Int. Ref.:         P-E190/DGIGSD-0399-06              Issue:   1   Rev.:   7
           Proj. Ref.:         HMA-DD-DAT-EN-001                 Date:        14/09/2007


Comments            Creating a complex service, i.e. a service which invokes two or more
                    basic services, comprises the following steps:
                         1. Create a new workflow with the workflow editor
                         2. Deploy workflow with the workflow console
                         3. Register service




                                               Pag. 63/182
                         Title:               Architectural Design Technical Note
                         Contract Ref.:       P-E190/DGIGSD-3556-05
                         Int. Ref.:           P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                         Proj. Ref.:          HMA-DD-DAT-EN-001                 Date:        14/09/2007


5.5.2    Orchestration Service
        Name                           Orchestration Service
        Taxonomy                       Workflow/ Task Management Service
        Category                       Architecture Service
        Standard                       OASIS BPEL
        Specifications                 XLANG, WSFL, WSDL
                                       W3C ws-addressing
                                       W3C ws-choreography
        INSPIRE                        Invoke Spatial Data Services
        Extension of                   None
        Description                    This service allows designing and executing compound services.
                                       A compound service is defined by a workflow describing it in term of
                                       interactions among simple and / or compound services already
                                       defined. This is similar to defining a normal service. It means that you
                                       need to define the interface and to provide the definitions to
                                       implement that interface. The workflow is implemented based on the
                                       BPEL (Business Process Execution Language) technology.
        Service
        Operations
             CreateWorkflow            Desription             A workflow can be defined by an authorised user
                                                              using a workflow (BPEL) editor.
                                                              Supported workflows can be synchronous or
                                                              asynchronous.
                                                              The HM will execute the workflows by using
                                                              specific system APIs. Therefore, to make the
                                                              workflow executable via the APIs, the workflow's
                                                              definition must match the following constraints:
                                                              For asynchronous interaction workflow:
                                                              •   The workflow interface (the wsdl file) must be
                                                                  compliant to the HM ICD.
                                                              •   The workflow interface must have a start-up
                                                                  operation (be invoked to provide the workflow
                                                                  input) and an end operation (be invoked to
                                                                  return the workflow output).
                                                              •   The xml messages assigned to the two
                                                                  operations    must have  part  named
                                                                  "parameters".
                                                              •   The start-up operation, which is implemented
                                                                  by using the BPEL receive function, must be
                                                                  named "initiate".
                                                              •   In   the   workflow    bpel.xml      file,   the
                                                                  callbackBindings must be set to "jms". This is to
                                                                  direct the workflow engine to deliver the
                                                                  workflow output into a JMS queue, in which
                                                                  the HMA portal application is listening for the
                                                                  workflow output.
                                                              For synchronous interaction workflow:

                                                              Pag. 64/182
             Title:                Architectural Design Technical Note
             Contract Ref.:        P-E190/DGIGSD-3556-05
             Int. Ref.:            P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
             Proj. Ref.:           HMA-DD-DAT-EN-001                 Date:        14/09/2007


                                                   •   The workflow interface (the wsdl file) must be
                                                       compliant to the HM ICD.
                                                   •   The workflow interface must have one and
                                                       only one operation, named "main". The main
                                                       operation is similar to an RPC style operation.
                                                       The workflow input is stored in the operation's
                                                       argument message and the workflow output is
                                                       stored in the operation's return message.
                                                   •   The xml messages (containing the workflow
                                                       input and output), which are assigned to the
                                                       operation "main", must have the part named
                                                       "parameters".
                           Input
                           Output                  BPEL description of the Workflow ready to for
                                                   packaging (.jar file)
  PackageWorkflow          Description             Validate the workflow and package it ready for
                                                   deployment
                           Input                   BPEL description of the Workflow ready to be
                                                   deployed
                           Output                  Pockaged Workflow
    DeployWorkflow         Description             Deploy a Packaged workflow within HM.
                                                   Once the workflow has been validated and
                                                   packaged as a .jar file, you have to deploy it
                                                   using the workflow console.
                           Input                   Workflow Package (.jar),
                                                   Domain (Service Provider name)
                           Output
Example
usage
Comments                   New Workflow definition is an activity restricted only to authorised
                           users, e.g. Service Providers.




                                                   Pag. 65/182
                       Title:            Architectural Design Technical Note
                       Contract Ref.:    P-E190/DGIGSD-3556-05
                       Int. Ref.:        P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                       Proj. Ref.:       HMA-DD-DAT-EN-001                 Date:        14/09/2007


5.5.3    Monitoring & Control Service
        Name                         Monitoring & Control Service
        Taxonomy                     System management services
        Category                     Architecture Service
        Standard Specifications      No standard specification available
        INSPIRE                      No corresponding service found.
        Extension of                 None
        Description                  This service provides a set of functionalities for logging and
                                     monitoring the transactions traffic across the DAIL. It shall also allow
                                     a user to monitor and control their requests and return the status of
                                     on-going activities.
                                     This service provides two main categories of operations:
                                        •     the operations for logging transaction activities;
                                        •     the operations for querying the repository of transactions;
                                        •     operations for checking the status of activated workflows.


        Service
        Operations
               GenerateReports       Description     This operation allows clients to retrieves information
                                                     about completed transactions in a certain time
                                                     period
                                     Input           Start / stop of the period of interest;
                                                     Transaction type for which provide report (e.g.
                                                     orders);
                                                     Output format (pdf, excel, pie chart, bar chart)
                                     output          Report containing the current status of submitted
                                                     transactions of the given type in the specified period
        MonitoringViewSelector       Description     This operation returns different views of the active
                                                     Workflows
                                     Input           ViewType: is the type of view the client would like to
                                                     have:
                                                     •    Dashboard view: provide a view of the active
                                                          Workflows (i.e. the active processes running in the
                                                          DAIL);
                                                     •    Flow view: provide a visual representation of the
                                                          trail a workflow instance has followed. A specific
                                                          workflow shall be provided as input.
                                                     •    Audit view: provide a textual representation of
                                                          the trail a workflow instance has followed. A
                                                          specific workflow shall be provided as input.
                                                     •    Debug view: provides a textual representation of
                                                          the trail a workflow instance and allows to view
                                                          values of intermediate results.
                                                     •    Processes view: provides the list of deployed
                                                          processes, and indicates how many are open

                                                         Pag. 66/182
                Title:           Architectural Design Technical Note
                Contract Ref.:   P-E190/DGIGSD-3556-05
                Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1     Rev.:   7
                Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:          14/09/2007


                                                  and how many are completed and number of
                                                  instances active for any of them.
                                             •    Instances view: provides the list of workflow
                                                  instances
                                             Selected Workflow: optional input related to a
                                             specific workflow to be monitored;
                                             Time Period: optional input related to a time period
                                             applicable to filtering information returned.
                              output         Requested view            filtered     according   to   input
                                             parameters
    GenerateStatistics        Description    This operation allows clients to retrieves information
                                             about a series of statistics e.g. average duration of
                                             workflow instances, detailed breakdown of time
                                             consumption within the workflows.
                              Input          Specific workflow: optional parameter needed to
                                             retrieve detailed statistics for a given workflow
                              output         Statistics report according to input parameters
          ClearStatistics     Description    This operation allows clients to reset all data used to
                                             generate statistics
                              Input          None
                              output         None
Example
usage
Comments




                                                 Pag. 67/182
                         Title:            Architectural Design Technical Note
                         Contract Ref.:    P-E190/DGIGSD-3556-05
                         Int. Ref.:        P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                         Proj. Ref.:       HMA-DD-DAT-EN-001                 Date:        14/09/2007


5.5.4    Collection Discovery Service
        Name                      Collection Discovery Service
        Taxonomy                  Model/Information management services
        Category                  Application Service
        Standard                  OGC™ Cataloguing of ISO Metadata (CIM) using the ebRIM profile of
        Specifications            CS-W
        INSPIRE                   Discovery Services
        Extension of
        Description               This service provides a set of functionalities for the user/operator or for
                                  applications to insert, search and retrieve structured information on the
                                  collections offered as part of the HMA architecture.
                                  This service is used for storing metadata of data set collections and
                                  subscriptions.
        Service
        Operations
           GetCapabilities        Description           The mandatory GetCapabilities operation allows a
                                                        client to retrieve collection metadata from a server.
                                                        The response to a GetCapabilities request is an XML
                                                        document containing service metadata about the
                                                        server.
                                  Input
                                  Output                Service metadata.
               GetRecords         Description           This mandatory operation allows querying the list of
                                                        available collections.
                                  Input                 Required results format, sorting criteria, filtering
                                                        criteria.
                                  Output                Metadata of the collections matching the input
                                                        parameters.
           GetRecordById          Description           The GetRecordById operation provides a simple
                                                        means of retrieving one or more records by identifier;
                                                        the identifier may be that of some registry object
                                                        (rim:RegistryObject/@id) or an external identifier
                                                        (rim:ExternalIdentifier/@value) assigned to a registry
                                                        object.
                                  Input                 Identifier of the item to retrieve
                                  Output                The record having the required identifier.
          DescribeRecord          Description           The DescribeRecord operation allows a client to
                                                        discover the information model(s) supported by the
                                                        service and to retrieve record type definitions.
                                  Input                 List of type names that are to be described by the
                                                        catalogue.
                                  Output                Description of the requested types.




                                                           Pag. 68/182
              Title:            Architectural Design Technical Note
              Contract Ref.:    P-E190/DGIGSD-3556-05
              Int. Ref.:        P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
              Proj. Ref.:       HMA-DD-DAT-EN-001                 Date:        14/09/2007


      GetDomain        Description           The optional GetDomain operation produces a
                                             description of the value domain of a given data
                                             element or request parameter, where the value
                                             domain is the set of actual or permissible values. The
                                             value domain may be enumerated or non-
                                             enumerated. One use of this operation is to discover
                                             ‘active’ terms in taxonomy that are currently used to
                                             classify registry objects.
                       Input                 Name of property or interface parameter for which
                                             value domain information is desired
                       Output                Allowed values
GetRepositoryItem      Description           The GetRepositoryItem operation is used to retrieve
                                             the repository item corresponding to some extrinsic
                                             object. If available, the item is included in the body
                                             of the response; it must be an instance of a MIME
                                             media type, as indicated by the value of the
                                             Content-Type header field.
                                             An extrinsic object may also be used to catalogue
                                             an external repository item that is managed by
                                             another party. In this case, the ExtrinsicObject must
                                             be associated (using the “RepositoryItemFor”
                                             association) with an ExternalLink that specifies an
                                             absolute URL for retrieving the item.
                       Input                 Absolute URI that refers to some extrinsic object.
                       Output                If the request is processed successfully and a
                                             repository item is accessible, the body of the
                                             response message shall include the repository item
                                             as a MIME entity. If any additional encodings have
                                             been applied to the resource (e.g., compression
                                             using gzip), these must be specified by the Content-
                                             Encoding header field.
      Transaction      Description           This operation allows inserting / deleting / updating
                                             registry records already loaded in the server.
                       Input                 Collection metadata to be inserted / updated /
                                             deleted
                       Output                The transaction response message conveys two
                                             pieces of information. First of all, it reports a summary
                                             of the transaction by indicating the number of
                                             records created, updated or deleted by the
                                             transaction. Secondly, the transaction response
                                             message indicates the results of each insert
                                             operation found in the transaction.




                                                Pag. 69/182
               Title:            Architectural Design Technical Note
               Contract Ref.:    P-E190/DGIGSD-3556-05
               Int. Ref.:        P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
               Proj. Ref.:       HMA-DD-DAT-EN-001                 Date:        14/09/2007


           Harvest      Description           The Harvest operation allows a user to request that
                                              the catalogue attempt to harvest a repository item
                                              from a specified network location, thereby realizing
                                              a 'pull' model for publishing registry content. If the
                                              catalogue successfully retrieves the resource and
                                              successfully processes it, then one or more
                                              corresponding registry objects are created or
                                              updated. Brief representations of all modified
                                              records are returned to the client when processing is
                                              complete.
                                              The Harvest operation has two modes of operation,
                                              controlled by a flag in the request. The first mode of
                                              operation is a synchronous mode in which the
                                              service receives a Harvest request from the client,
                                              processes it immediately, and sends the results to the
                                              client while the client waits. The second mode is
                                              asynchronous in that the server receives a Harvest
                                              request from the client, and sends the client an
                                              immediate acknowledgement that the request has
                                              been successfully received.
                        Input                 URI of the remote catalogue to be harvested; the
                                              type and the format of data to harvest; the sync /
                                              async flag.
                        Output                In sync mode it returns the summary of the data
                                              retrieved by the remote catalogue; in async mode it
                                              returns immediately an acknowledge and later, at
                                              the address specified in the request, it returns the
                                              summary of harvested data.
Example
usage
Comments




                                                 Pag. 70/182
                         Title:            Architectural Design Technical Note
                         Contract Ref.:    P-E190/DGIGSD-3556-05
                         Int. Ref.:        P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                         Proj. Ref.:       HMA-DD-DAT-EN-001                 Date:        14/09/2007


5.5.5    Service Discovery Service
        Name                      Service Discovery Service
        Taxonomy                  Model/Information management services
        Category                  Application Service
        Standard                  OGC™ Cataloguing of ISO Metadata (CIM) using the ebRIM profile of
        Specifications            CS-W
        INSPIRE                   Discovery Services
        Extension of
        Description               This service provides a set of functionalities for the user/operator or for
                                  applications to search and retrieve structured information on the
                                  “Human Readable Services” offered as part of the HMA architecture.
        Service
        Operations
           GetCapabilities        Description           The mandatory GetCapabilities operation allows a
                                                        client to retrieve service metadata from a server.
                                                        The response to a GetCapabilities request is an
                                                        XML document containing service metadata
                                                        about the server.
                                  Input
                                  Output                Service metadata.
               GetRecords         Description           This mandatory operation allows querying the list of
                                                        available services.
                                  Input                 Required results format, sorting criteria, filtering
                                                        criteria.
                                  Output                Metadata of the service matching the input
                                                        parameters.
           GetRecordById          Description           The GetRecordById operation provides a simple
                                                        means of retrieving one or more records by
                                                        identifier; the identifier may be that of some
                                                        registry object (rim:RegistryObject/@id) or an
                                                        external identifier (rim:ExternalIdentifier/@value)
                                                        assigned to a registry object.
                                  Input                 Identifier of the item to retrieve
                                  Output                The record having the required identifier.
          DescribeRecord          Description           The DescribeRecord operation allows a client to
                                                        discover the information model(s) supported by
                                                        the service and to retrieve record type definitions.
                                  Input                 List of type names that are to be described by the
                                                        catalogue.
                                  Output                Description of the requested types.




                                                           Pag. 71/182
              Title:            Architectural Design Technical Note
              Contract Ref.:    P-E190/DGIGSD-3556-05
              Int. Ref.:        P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
              Proj. Ref.:       HMA-DD-DAT-EN-001                 Date:        14/09/2007


      GetDomain        Description           The optional GetDomain operation produces a
                                             description of the value domain of a given data
                                             element or request parameter, where the value
                                             domain is the set of actual or permissible values.
                                             The value domain may be enumerated or non-
                                             enumerated. One use of this operation is to
                                             discover ‘active’ terms in taxonomy that are
                                             currently used to classify registry objects.
                       Input                 Name of property or interface parameter for
                                             which
                                             value domain information is desired
                       Output                Allowed values
GetRepositoryItem      Description           The GetRepositoryItem operation is used to retrieve
                                             the repository item corresponding to some extrinsic
                                             object. If available, the item is included in the
                                             body of the response; it must be an instance of a
                                             MIME media type, as indicated by the value of the
                                             Content-Type header field.
                                             An extrinsic object may also be used to catalogue
                                             an external repository item that is managed by
                                             another party. In this case, the ExtrinsicObject must
                                             be associated (using the “RepositoryItemFor”
                                             association) with an ExternalLink that specifies an
                                             absolute URL for retrieving the item.
                       Input                 Absolute URI that refers to some extrinsic object.
                       Output                If the request is processed successfully and a
                                             repository item is accessible, the body of the
                                             response message shall include the repository item
                                             as a MIME entity. If any additional encodings have
                                             been applied to the resource (e.g., compression
                                             using gzip), these must be specified by the
                                             Content-Encoding header field.
      Transaction      Description           This operation allows inserting / deleting / updating
                                             single service metadata records already loaded in
                                             the server.
                       Input                 Service metadata to be inserted / updated /
                                             deleted
                       Output                The transaction response message conveys two
                                             pieces of information. First of all, it reports a
                                             summary of the transaction by indicating the
                                             number of records created, updated or deleted
                                             by the transaction. Secondly, the transaction
                                             response message indicates the results of each
                                             insert operation found in the transaction.




                                                Pag. 72/182
               Title:            Architectural Design Technical Note
               Contract Ref.:    P-E190/DGIGSD-3556-05
               Int. Ref.:        P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
               Proj. Ref.:       HMA-DD-DAT-EN-001                 Date:        14/09/2007


           Harvest      Description           The Harvest operation allows a user to request that
                                              the catalogue attempt to harvest a repository item
                                              from a specified network location, thereby
                                              realizing a 'pull' model for publishing registry
                                              content. If the catalogue successfully retrieves the
                                              resource and successfully processes it, then one or
                                              more corresponding registry objects are created or
                                              updated. Brief representations of all modified
                                              records are returned to the client when processing
                                              is complete.
                                              The Harvest operation has two modes of
                                              operation, controlled by a flag in the request. The
                                              first mode of operation is a synchronous mode in
                                              which the service receives a Harvest request from
                                              the client, processes it immediately, and sends the
                                              results to the client while the client waits. The
                                              second mode is asynchronous in that the server
                                              receives a Harvest request from the client, and
                                              sends the client an immediate acknowledgement
                                              that the request has been successfully received.
                        Input                 URI of the remote catalogue of services to be
                                              harvested; the type and the format of data to
                                              harvest; the sync / async flag.
                        Output                In sync mode it returns the summary of the data
                                              retrieved by the remote catalogue; in async mode
                                              it returns immediately an acknowledge and later,
                                              at the address specified in the request, it returns
                                              the summary of harvested data.
Example
usage
Comments




                                                 Pag. 73/182
                         Title:            Architectural Design Technical Note
                         Contract Ref.:    P-E190/DGIGSD-3556-05
                         Int. Ref.:        P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                         Proj. Ref.:       HMA-DD-DAT-EN-001                 Date:        14/09/2007


5.5.6    Service Configuration Discovery Service
        Name                      Service Configuration Discovery Service
        Taxonomy                  Model/Information management services
        Category                  Architecture Service
        Standard                  OASIS UDDI v3
        Specifications

        INSPIRE                   Discovery Services
        Extension of
        Description               This service provides the operation to publish and inquire structured
                                  information of the services available in the HMA infrastructure.
                                  The level of description is such that an application should be able to
                                  discover and then use the services (e.g. supported operations).
                                  This service adheres to the UDDI standard (see [RD11]).

                                  For the sake of simplicity, in this section are provided only a summary of
                                  the UDDI operations; the full definition can be found in [RD12]
        Service
        Operations
            Inquire API set       Description          The inquiry API set allows locating and obtaining
                                                       details on entries in a UDDI registry.
                                                       The Inquiry API provides three forms of query that
                                                       follow broadly used conventions which match the
                                                       needs of software traditionally used with registries.
                                                       Three distinct patterns of inquiry are supported:
                                                                The browse pattern characteristically involves
                                                                starting with some broad information,
                                                                performing a search, finding general result
                                                                sets and then selecting more specific
                                                                information for drill-down.
                                                                The drill-down pattern: Each instance of the
                                                                core data structures – businessEntity,
                                                                businessService,    bindingTemplate      and
                                                                tModel – has a key which is one of the items
                                                                in the summary information retrieved by
                                                                find_xx APIs. Given such a key, it is easy to
                                                                retrieve the full registered details for the
                                                                corresponding instance by passing the key
                                                                to the relevant get_xx API.
                                                                The invocation pattern: To have an
                                                                application take advantage of a Web
                                                                service that is registered within a UDDI
                                                                registry, that application must be prepared
                                                                to use the information found in the registry
                                                                for the specific Web service being invoked.
                                                                By using this pattern with Web services,
                                                                applications can interact with partners
                                                                without    undue      communication       and
                                                                coordination costs. For example, if a business
                                                                has activated a disaster recovery site, most

                                                           Pag. 74/182
            Title:            Architectural Design Technical Note
            Contract Ref.:    P-E190/DGIGSD-3556-05
            Int. Ref.:        P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
            Proj. Ref.:       HMA-DD-DAT-EN-001                 Date:        14/09/2007


                                                   of the calls from partners will fail when they
                                                   try to invoke Web services at the failed site.
                                                   By updating the UDDI information with the
                                                   new address for the Web service, partners
                                                   who use the invocation pattern will
                                                   automatically locate the new Web service
                                                   information and recover without further
                                                   administrative action.
                                          In the following some of the operations of this API:
                                                   find_binding: Used to locate bindings within
                                                   or   across    one   or   more    registered
                                                   businessServices.
                                                   find_business: Used to locate information
                                                   about one or more businesses. Returns a
                                                   businessList structure.
                                                   find_relatedBusinesses: Used to locate
                                                   information about businessEntity registrations
                                                   that are related to a specific business entity
                                                   whose key is passed in the inquiry.
                                                   find_service: Used to locate specific services
                                                   within registered business entities. Returns a
                                                   serviceList structure.
                                                   Etc.


                     Input
                     Output
Publication API      Description          The API calls in this section are used to publish and
            Set                           update information contained in a UDDI registry.
                                          According to the policy of the UDDI registry, a
                                          publisher selects a UDDI node where it will publish
                                          the information.
                                          API calls in this section MUST all be implemented as
                                          synchronous and "atomic" from the point of view of
                                          the caller. That is, each call MUST either succeed
                                          completely or fail completely.
                                          In the following some of the operations of this API:
                                                   add_publisherAssertions:    Used     to   add
                                                   relationship assertions to the existing set of
                                                   assertions.
                                                   delete_binding: Used to remove an existing
                                                   bindingTemplate from the registry.
                                                   delete_business: Used to delete existing
                                                   businessEntity information from the registry.
                                                   delete_service: Used to delete an existing
                                                   businessService from the registry.
                                                   get_assertionStatusReport: Used to get a
                                                   status report containing publisher assertions
                                                   and status information. This report is useful to
                                                   help an administrator manage publisher
                                                   assertions. Returns an assertionStatusReport

                                              Pag. 75/182
                Title:            Architectural Design Technical Note
                Contract Ref.:    P-E190/DGIGSD-3556-05
                Int. Ref.:        P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                Proj. Ref.:       HMA-DD-DAT-EN-001                 Date:        14/09/2007


                                                       that includes the status of all assertions made
                                                       involving any businessEntity controlled by the
                                                       requesting publisher.
                                                       save_binding:     Used   to  register new
                                                       bindingTemplate information or to update
                                                       existing bindingTemplate information. Use
                                                       this to control information about technical
                                                       capabilities exposed by a registered
                                                       business.
                                                       save_service: Used to register or update
                                                       complete       information    about    a
                                                       businessService.
                                                       save_tModel: Used to register or update
                                                       information about a tModel.
                                                       Etc.


                         Input
                         Output
Security Policy API      Description          The security API includes the following API calls:
                Set                                    discard_authToken: Used to inform a node
                                                       that a previously obtained authentication
                                                       token is no longer required and should be
                                                       considered invalid if used after this message
                                                       is received.
                                                       get_authToken:     Used     to   request    an
                                                       authentication token in the form of an
                                                       authInfo element from a UDDI node. An
                                                       authInfo element MAY be required when
                                                       using the Inquiry API Set, Publication API Set,
                                                       Custody and Ownership Transfer API Set,
                                                       Subscription API Set.
                         Input
                         Output
     Custody and         Description          The Custody and Ownership Transfer API Set enables
       Ownership                              any nodes of a registry to cooperatively transfer
   Transfer API Set                           custody of one or more businessEntity or tModel
                                              structures from one node to another, as well as
                                              allowing the transfer of ownership of these structures
                                              from one publisher to another.
                                              Associated entities of a businessEntity such as its
                                              businessService,        bindingTemplate,         and
                                              publisherAssertion structures are transferred as part
                                              of the custody transfer of the business entity.
                                                       discard_transferToken
                                                       get_transferToken
                                                       transfer_entities
                                                       transfer_custody
                         Input


                                                  Pag. 76/182
              Title:            Architectural Design Technical Note
              Contract Ref.:    P-E190/DGIGSD-3556-05
              Int. Ref.:        P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
              Proj. Ref.:       HMA-DD-DAT-EN-001                 Date:        14/09/2007


                       Output
 Subscription API      Description          Subscription provides clients, known as subscribers,
              Set                           with the ability to register their interest in receiving
                                            information concerning changes made in a UDDI
                                            registry. These changes can be scoped based on
                                            preferences provided with the request. The APIs
                                            described below support this capability. Each of the
                                            subscription APIs described here are OPTIONAL for
                                            UDDI implementations and MAY be implemented
                                            entirely at the discretion of a Node.


                                            The subscription APIs are:
                                                     delete_subscription: Cancels one or more
                                                     specified subscriptions.
                                                     get_subscriptionResults:         Synchronously
                                                     returns registry data pertaining to a
                                                     particular subscription within a specified time
                                                     period.
                                                     get_subscriptions: Returns a list of existing
                                                     subscriptions previously saved by the
                                                     subscriber.
                                                     save_subscription:    Establishes    a   new
                                                     subscription or changes an existing one. Also
                                                     used to renew existing subscriptions.
                                                     notify_subscriptionListener: A node invoked
                                                     API which the client implements as a
                                                     subscription listener service to accept
                                                     notifications containing the data that
                                                     changed since notify_subscriptionListener
                                                     was last invoked for a particular subscription.
                       Input
                       Output
Value Set API Set      Description          The Application Programming Interfaces in this
                                            section represent capabilities that a UDDI registry
                                            MAY use to enable validation of references to value
                                            sets.
                                            Registry policy determines which external value sets
                                            are supported and how.
                                            These SOAP messages all behave synchronously.
                                            The publicly accessible APIs that are used to support
                                            external value set validation are:
                                                     validate_values: Used by nodes to allow
                                                     external providers of value set validation
                                                     Web      services   to   assess  whether
                                                     keyedReferences or keyedReferenceGroups
                                                     are valid. Returns a dispositionReport
                                                     structure.
                                                     get_allValidValues: Used by nodes that
                                                     support caching of valid values from
                                                     cacheable checked value sets to obtain the

                                                Pag. 77/182
           Title:            Architectural Design Technical Note
           Contract Ref.:    P-E190/DGIGSD-3556-05
           Int. Ref.:        P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
           Proj. Ref.:       HMA-DD-DAT-EN-001                 Date:        14/09/2007


                                                  set of valid values. Returns an empty
                                                  message or a dispositionReport structure.
                    Input
                    Output
Example
usage
Comments




                                             Pag. 78/182
                       Title:           Architectural Design Technical Note
                       Contract Ref.:   P-E190/DGIGSD-3556-05
                       Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                       Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007


5.5.7    Catalogue Service
        Name                               Catalogue Service
        Taxonomy                           Model/Information management services
        Category                           Application Services
        Standard Specifications            EO Products Extension Package for ebRIM (ISO/TS 15000-3)
                                           Profile of CSW 2.0 [AD11]
        INSPIRE                            Discovery Services
        Extension of
        Description                        The Catalogue service provides a set of functionalities for
                                           the user/operator to search and retrieve metadata and
                                           browse images for the catalogued EO products from the
                                           missions being part of the HMA infrastructure.
                                           This service allows user/operator to find the EO products
                                           matching their needs. Catalogue searches can specify:
                                               •    The collection (e.g. Envisat_ASAR, ERS_SAR, etc)
                                               •    The ROI (e.g. one or more rectangles / circles /
                                                    polygons)
                                               •    The time windows of interest
                                               •    Mission specific parameters e.g. orbit, pass
                                                    direction, swath, track number, frame number, etc.
                                           Note that some EO catalogues contain entries for future
                                           planned and potential (i.e. products predictable through
                                           orbit swath propagation) products.
                                           The access to a catalogue service is subject to user
                                           authorization.
        Service
        Operations
                       GetCapabilities     Description            The      mandatory     GetCapabilities
                                                                  operation allows clients to retrieve
                                                                  service metadata from a server.
                                                                  The response to a GetCapabilities
                                                                  request is an XML document containing
                                                                  service metadata about the server. In
                                                                  particular it returns also the list of
                                                                  supported schemas (e.g. hma, ohr, sar,
                                                                  ..), the queryable attributes and the
                                                                  supported type names.
                                           Input
                                           Output                 Service metadata.
                           GetRecords      Description            This operation allows querying    the
                                                                  catalogued EO product records.




                                                        Pag. 79/182
            Title:           Architectural Design Technical Note
            Contract Ref.:   P-E190/DGIGSD-3556-05
            Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:       1   Rev.:   7
            Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:            14/09/2007


                                Input                  Filtering criteria:
                                                           •       Region of interest
                                                           •       Time window
                                                           •       Sensor
                                                           •       Specific attributes       e.g.   orbit,
                                                                   track, pass, etc.
                                                           •       Desired results format (e.g. hits,
                                                                   records with brief format, record
                                                                   identifier, etc.)
                                Output                 Depending on specified results format:
                                                           •       Number of hits or
                                                           •       Product metadata records
           GetRecordById        Description            This operation allows retrieving               the
                                                       details of product metadata items.
                                                       In order to support the ordering, the
                                                       returned items have to be provided with
                                                       sufficient information to order them.
                                                       Several types of record composition are
                                                       supported (summary, full).
                                Input                  The identifiers of the products to get
                                                       detailed information.
                                Output                 Metadata for each identified record
                                                       containing the attributes corresponding
                                                       to the required level of presentation
                                                       (Brief, Full, Browse, Summary)
           DescribeRecord       Description            The      mandatory    DescribeRecord
                                                       operation allows a client to discover
                                                       elements of the information model
                                                       supported by the target catalogue
                                                       service.
                                Input                  List of type names that are to be
                                                       described by the catalogue.
                                Output                 Description of the requested types.
Example
usage
Comments




                                             Pag. 80/182
                       Title:           Architectural Design Technical Note
                       Contract Ref.:   P-E190/DGIGSD-3556-05
                       Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                       Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007


5.5.8    Programming Service
        Name                                 Programming Service
        Taxonomy                             Model/Information management services
        Category                             Application Services
        Standard Specifications              HMA programming ICD [AD10]
        INSPIRE                              No corresponding service found.
        Extension of                         None
        Description                          The programming service provides a set of functionalities
                                             for the user/operator to:
                                                  •   Perform feasibility analysis of EO future products
                                                      i.e. to check whether the request can be fulfilled
                                                      considering      the     satellite  and     sensor
                                                      characteristic, meteorological conditions and
                                                      mission workload. The analysis can be performed
                                                      at different level of accuracy:
                                                           o    light, the check takes into account
                                                                physical characteristic of the satellite /
                                                                sensor;
                                                           o    estimate, with respect the previous one it
                                                                adds also possible meteorological data
                                                                and the estimated workload of the
                                                                satellite;
                                                           o    full, with respect the previous it takes into
                                                                account the work load of the satellite.
                                                  •   The lower levels are performed at HMA level, the
                                                      highest level is performed at ground segment
                                                      level (the mission workload is not normally made
                                                      available at HMA level).
                                                  •   Issue future EO products requests


                                             The programming service supports the following 3 types
                                             of requests:
                                                  •   Order of precisely identified future products. This
                                                      type of orders are referenced as Acquisition
                                                      Orders;
                                                  •   Order asking the coverage of specified area in a
                                                      specified time window. This type of orders are
                                                      referenced as Coverage Orders;
                                                  •   Same as the previous one, but the coverage is
                                                      repeated several times with a defined periodicity.


                                             A request to the Programming Service is generally
                                             referred to “Programming Request”.
                                             An order for future products is referred to “task”.


                                             This service allows the clients to perform the following
                                             activities:

                                                        Pag. 81/182
             Title:           Architectural Design Technical Note
             Contract Ref.:   P-E190/DGIGSD-3556-05
             Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:     1   Rev.:   7
             Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:          14/09/2007


                                        •   Retrieval of the programming parameters related
                                            to the specified product / sensor;
                                        •   Definition of the programming request and
                                            checking the feasibility;
                                        •   Submission of the programming request;
                                        •   Programming request status monitoring;
                                        •   Possible cancellation of the submitted request;
                                        •   Issuing of status notification.
                                        •   Retrieval of acquired data.


                                   In order to autonomously accomplish the feasibility
                                   analysis, the service has to receive / harvest
                                   satellite/sensor characteristics. The parameters are
                                   received via files (ROP files [RD51]) or are harvested by
                                   calling DescribeSensor operation implemented by GS
                                   Programming Services.
                                   The full specification of operations and input and output
                                   parameters are provided in [AD10]. In the following the
                                   operations, input and output parameters are briefly
                                   summarized.
Service
Operations
              GetCapabilities      Description        The mandatory GetCapabilities operation
                                                      allows clients to retrieve service metadata
                                                      from a server. The response to a
                                                      GetCapabilities request shall be an XML
                                                      document containing service metadata
                                                      about the server, including specific
                                                      information about the Programming
                                                      Service.
                                   Input
                                   Output             Service and operation metadata.
               DescribeSensor      Description        This    operation    provides    detailed
                                                      information about the specified sensor
                                                      e.g.:    average   orbit   period,  orbit
                                                      inclination, WRS information, incidence
                                                      angle, reference swaths, etc.
                                   Input              sensor identifier.
                                   Output             Satellite and sensor parameters.
       EstimateSensorWorkload      Description        The EstimateSensorWorkload provides
                                                      information     about    the    estimated
                                                      workload of the requested sensor. This
                                                      information is under the responsibility of
                                                      each mission and must be accessible on
                                                      demand by the SPS server. The SPS service
                                                      has to maintain up to date information of
                                                      such workload by harvesting the
                                                      information to the mission on regular basis
                                                      (weekly, or monthly)

                                              Pag. 82/182
     Title:           Architectural Design Technical Note
     Contract Ref.:   P-E190/DGIGSD-3556-05
     Int. Ref.:       P-E190/DGIGSD-0399-06              Issue:   1   Rev.:   7
     Proj. Ref.:      HMA-DD-DAT-EN-001                  Date:        14/09/2007


                                              The minimal information provided by the
                                              mission is as follows:
                                                    •   Temporal domain: begin date,
                                                        end date,
                                                    •   Temporal resolution: number of
                                                        days (i.e. how many days
                                                        between two consecutive values
                                                        in a mesh),
                                                    •   Spatial domain: lat min, lat max,
                                                        long min, long max (somewhat
                                                        similar to "Area of service"),
                                                    •   Spatial resolution: size of the
                                                        meshes, expressed in degrees,
                                                        minutes or in km


                                              Further on, the following information has
                                              to be provided for each mesh:
                                                    •   mesh       location:      lat-long
                                                        coordinates of the mesh centre,
                                                    •   mesh date or range of dates
                                                    •   workload value: percentage of
                                                        the resource already booked on
                                                        this mesh at this date
                           Input              sensorId
                           Output             TBD
DescribeGetFeasibility     Description        This operation describes the list of input
                                              and output parameters of GetFeasibility
                                              operation.
                           Input              sensor identifier
                           Output             Array of input parameters required for the
                                              feasibility analysis of the specified sensor
                                              Array of parameters returned by the
                                              feasibility analysis of the specified sensor.
       DescribeSubmit      Description        This operation describes the list of input
                                              and output parameters of Submit
                                              operation.
                           Input              sensor identifier
                           Output             Array of input parameters required for
                                              issuing a tasking request for the specified
                                              sensor.
                                              Array of parameters returned by the
                                              Submit operation.
          GetFeasibility   Description        This operation allows asking the system to
                                              verify the feasibility of the specified
                                              programming requests.
                                              This operation is asynchronous: it returns
                                              only an acknowledgement on the request


                                      Pag. 83/182
Title:           Architectural Design Technical Note
Contract Ref.:   P-E190/DGIGSD-3556-05
Int. Ref.:       P-E190/DGIGSD-0399-06              Issue:    1   Rev.:   7
Proj. Ref.:      HMA-DD-DAT-EN-001                  Date:         14/09/2007


                                         including the feasibilityID.
                                         The actual result is sent to the client by
                                         calling the GetFeasibilityResponse client’s
                                         operation.
                       Input                   •   Notification: the method for
                                                   notifying the         caller of this
                                                   operation about the result of the
                                                   feasibility analysis.
                                               •   List of sensor parameters: one
                                                   sensor task can be specified within
                                                   the GetFeasibility specifying the
                                                   parameters       described      by
                                                   DescribeGetFeasibility.


                       Output            Completion result specifying the feasibility
                                         of the programming request with the
                                         feasibilityID, which identifies the analysed
                                         request.
              Submit   Description       This operation allows                submitting   a
                                         programming request.
                                         It allows to submit a previously analysed
                                         request (i.e. checked by GetFeasibility
                                         operation), in this case the request can
                                         be submitted specifying only the
                                         feasibilityID returned by the GetFeasibility;
                                         it allows also to submit a new request not
                                         previously checked, in this case all
                                         parameters have to be provided.
                                         This operation is asynchronous: it returns
                                         only an acknowledgement on the request
                                         including the taskID.
                                         The actual result is sent to the client by
                                         calling the SubmitResponse client’s
                                         operation.
                       Input                   •   Notification: the method for
                                                   notifying the client about the result
                                                   of this operation.
                                               •   One task can be specified within
                                                   the Submit operation providing
                                                   either:
                                                       o     feasibilityID: in case of
                                                             sensor       task    already
                                                             checked it is sufficient to
                                                             send the identifier returned
                                                             by GetFeasibility
                                                       o     In case of non checked
                                                             sensor task, the full set of
                                                             sensor parameters have to
                                                             be provided.
                                               •   Delivery information: method for
                                                   disseminating products to the user

                                 Pag. 84/182
    Title:             Architectural Design Technical Note
    Contract Ref.:     P-E190/DGIGSD-3556-05
    Int. Ref.:         P-E190/DGIGSD-0399-06              Issue:    1   Rev.:    7
    Proj. Ref.:        HMA-DD-DAT-EN-001                  Date:         14/09/2007


                                                         (FTP push, FTP pull, mail)


                             Output                  •   The taskID
                                                     •   The status of the submitted task
                                                     •   Possible alternatives in case the
                                                         requested task in not feasible.
                                               The operation is asynchronous: it returns
                                               quickly the result of the submission without
                                               waiting for the completion of the
                                               programming activity.
                 GetStatus   Description       This operation allows retrieving the status
                                               of submitted programming requests.
                             Input                   •   taskID: it is the identifier of the
                                                         programming request task to
                                                         retrieve the status.
                             Output            Status of the specified task. It can include
                                               also the list of acquired scenes.
                  Update     Description       This operation allows a client to update a
                                               previously submitted task.
                             Input                   •   taskID: it is the identifier of the
                                                         programming request task to
                                                         retrieve the status.
                                                     •   Tasking parameters
                             Output            Completion          result   of       the   update
                                               operation.
                   Cancel    Description       The Cancel operation                   cancels    a
                                               previously requested task.
                             Input                   •   taskID: it is the identifier of the
                                                         sensor task to cancel.
                             Output            This operation returns:
                                                     •   The completion result             of   the
                                                         cancellation request;
                                               The operation is asynchronous: it returns
                                               quickly the result of the cancellation
                                               request    without   waiting    for   the
                                               completion of the cancellation. The
                                               progress of the cancellation of the order
                                               can be monitored with GetStatus
                                               operation.
DescribeResultAccess         Description       This operation, in case no delivery
                                               information has been specified in the
                                               Submit operation, allows Programming
                                               Service clients to retrieve information
                                               about where the observed data can be
                                               accessed from. This access source may
                                               be a SOS, WMS, WFS or any other OGC
                                               Web Service that provides data.


                                       Pag. 85/182
                Title:           Architectural Design Technical Note
                Contract Ref.:   P-E190/DGIGSD-3556-05
                Int. Ref.:       P-E190/DGIGSD-0399-06              Issue:   1   Rev.:   7
                Proj. Ref.:      HMA-DD-DAT-EN-001                  Date:        14/09/2007


                                      Input                    •   taskID: it is the identifier of the
                                                                   sensor task to retrieve the data.
                                      Output                   •   URL of the service to get the
                                                                   observed data.
                                                               •   The identifier of the products
                                                                   resulting from the tasking request.
Example usage
Comments




                                                 Pag. 86/182
                         Title:             Architectural Design Technical Note
                         Contract Ref.:     P-E190/DGIGSD-3556-05
                         Int. Ref.:         P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                         Proj. Ref.:        HMA-DD-DAT-EN-001                 Date:        14/09/2007


5.5.9    Order Service
        Name                              Order Service
        Taxonomy                          Model/Information management services
        Category                          Application Services
        Standard Specifications           HMA Ordering ICD [AD05]
        INSPIRE                           No corresponding service found.
        Extension of                      OpenGIS Catalogue Services – Best Practices for EO Products
                                          OGC-05-057r4
        Description                       This service provides a set of functionalities for the user/operator to
                                          place orders for the catalogued EO products and for adhere to
                                          subscriptions from the missions being part of the HMA
                                          infrastructure.
                                          This service allows the clients to perform the following activities:
                                              •    Get the service capabilities: retrieval of the supported
                                                   version, the supported operations, etc.
                                              •    Order options retrieval (scene selection options, processing
                                                   options, media definition, subscription sub-setting, etc.).
                                              •    Order Quotation: for getting a quotation of the order
                                                   going to be submitted.
                                              •    Order submission
                                              •    Order monitor: to check the status of submitted orders.
                                              •    Order Cancellation: to cancel an on-going order.
                                              •    Retrieval of on-line available products.
                                          During the order execution the user can query the status of his /
                                          her orders or also cancel the orders.
                                          The services should verify any constraints that may be imposed on
                                          users, and report status and relevant information back to the user


                                          The full specification of operations and input and output
                                          parameters are provided in [AD05]. In the following the
                                          operations, input and output parameters are briefly summarized.
        Service
        Operations
                  GetCapabilities         Description     The mandatory GetCapabilities operation allows
                                                          clients to retrieve service metadata from a server.
                                                          The response to a GetCapabilities request shall be
                                                          an XML document containing service metadata
                                                          about the server, including specific information
                                                          about a Order Service.
                                          Input
                                          Output           Service and operation metadata.
                       GetOptions         Description     This operation allows the retrieval of the options for
                                                          ordering products of a specific collection or for
                                                          customizing the parameters of a subscription.
                                          Input           CollectionId: it is the identifier of the collection to
                                                          issue requests.
                                                            Pag. 87/182
    Title:             Architectural Design Technical Note
    Contract Ref.:     P-E190/DGIGSD-3556-05
    Int. Ref.:         P-E190/DGIGSD-0399-06              Issue:   1   Rev.:   7
    Proj. Ref.:        HMA-DD-DAT-EN-001                  Date:        14/09/2007


                                     Optional identifier of the product to order (for
                                     getting product specific options).
                                      userInformation: identification information about
                                      the user who issues the request.
                     Output           Array of all possible combinations of ordering
                                      options.
GetQuotation         Description     This operation allows the client to get a quotation
                                     of the order that is going to be submitted.
                                     This operation has to be supported by HM and GS
                                     Services instances.
                                     This operation can be used in synchronous and
                                     asynchronous mode: it depends on the client and
                                     server capabilities.
                                     If the server is able to provide a quotation in real
                                     time, the quotation can be included in the output
                                     message of GetQuotation; otherwise the quotation
                                     is   sent       to the   client  by   calling    the
                                     GetQuotationResponse operation provided by the
                                     client it self.
                     Input                •    userInformation: identification information
                                               about the user who issues the request.
                                          •    Order specification: it is the order going to
                                               be submitted (see Submit operation).
                     Output               •    Completion result of the quotation request.
                                          •    Either the quotationId,              in   case    of
                                               asynchronous usage;
                                          •    Or the quotation itself in case asynchronous
                                               usage.


        Submit       Description     This operation allows submitting an order of
                                     precisely identified non-future products or for
                                     subscribing to EO products.
                                     This operation is asynchronous: it returns only an
                                     acknowledgement on the request including the
                                     orderId and the completion result of the submission.
                                     Depending on the required status notification, the
                                     progress of the order can be notified to the client
                                     by calling its SubmitResponse operation.
                     Input           userInformation: identification information about
                                     the user who issues the request.
                                     Order specification:
                                          •    Delivery     information: method    for
                                               disseminating products to the user (FTP
                                               push, FTP pull, mail)
                                          •    Invoice address;
                                          •    List of order items:
                                                     o   Product identifier: it is the identifier of
                                                         the item to order. In case of product
                                                         orders it has to specify a pair of
                                       Pag. 88/182
Title:             Architectural Design Technical Note
Contract Ref.:     P-E190/DGIGSD-3556-05
Int. Ref.:         P-E190/DGIGSD-0399-06              Issue:    1   Rev.:    7
Proj. Ref.:        HMA-DD-DAT-EN-001                  Date:         14/09/2007


                                                     strings: the first identifies the product,
                                                     the second, optional, identifies the
                                                     collection the product is related to.
                                                     In case of subscription only the
                                                     collection id has to be specified.
                                                 o   options: list of selected processing
                                                     options (e.g. NRT / OFFLINE, level of
                                                     processing, etc.) or subscription
                                                     parameters (e.g. expiration date,
                                                     sub-area of interest, etc.)
                                                 o   Scene        selection       options:
                                                     specification of the scene to be
                                                     extracted from the parent product.
                                                     The scene can be defined either
                                                     providing    the     scene    centre
                                                     coordinates, or the start and stop
                                                     time or some provider specific
                                                     parameters (e.g. frame number).
                                                     Not applicable to subscriptions.
                                                 o   Delivery method and medium of the
                                                     single item.
                                                 o   Additional user added item info
                                                     (orderITemRemark).
                                                 o   Payment information:
                                                               Either    Order      account:
                                                               Account under which the
                                                               user is authorised to order
                                                               from the specific provider.
                                                               Or credit card info.
                                 Alternatively the order can be specified providing
                                 the identifier of the quotation, in case the
                                 quotation has been provided and accepted by
                                 the client.
                 Output          This operation returns:
                                      •    The completion           result       of   the   order
                                           submission;
                                      •    The identifier of the submitted order.
                                 The operation is asynchronous: it returns quickly the
                                 result of the order submission without waiting for the
                                 completion of the order.
GetStatus        Description     This operation allows retrieving the status of
                                 submitted product orders.
                                 This operation allows two different type of requests:
                                      1. Retrieval of the status of an order providing
                                         its identifier.
                                      2. Retrieval the status of all orders which have
                                         been updated (i.e. which have done some
                                         progress) after a specified date.


                 Input           userInformation: identification information about

                                   Pag. 89/182
             Title:             Architectural Design Technical Note
             Contract Ref.:     P-E190/DGIGSD-3556-05
             Int. Ref.:         P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
             Proj. Ref.:        HMA-DD-DAT-EN-001                 Date:        14/09/2007


                                              the user who issues the request.
                                              lastUpdate: it is alternative to the next one. It is
                                              used for issuing the second of type of requests
                                              described above.
                                               OrderId: it is the identifier of the order to retrieve
                                               the status (first type of requests described above).
                              Output           List of product order status. For each item the
                                               following information is returned:
                                                   o    The whole submitted product order
                                                        including also the status for each ordered
                                                        item.
                                                   o    The product order identifier.
                                                   o    The status at order level: order state (e.g.
                                                        BeingProcessed, Completed, Cancelled)
                                                        and a textual description.
                Cancel        Description     This operation allows asking the cancellation of an
                                              already submitted order.
                              Input           userInformation: identification information about
                                              the user who issues the request.
                                              orderId: it is the identifier of the product order to be
                                              cancelled.
                              Output          This operation returns:
                                                   •    The completion result of the cancellation
                                                        request;
                                              The operation is asynchronous: it returns quickly the
                                              result of the cancellation request without waiting
                                              for the completion of the cancellation. The
                                              progress of the cancellation of the order can be
                                              monitored with GetStatus operation.
  DescribeResultAccess        Description     This operation is in charge of returning the URLs of
                                              products ordered specifying on-line delivery.
                              Input                •    userInformation
                                                   •    orderId
                                                   •    flag specifying whether the URLs of all ready
                                                        products have to be delivered or only the
                                                        new one with respect the previous call.
                              Output               •    URLs of the products ready for being
                                                        accessed.
Example
usage
Comments




                                                Pag. 90/182
                      Title:               Architectural Design Technical Note
                      Contract Ref.:       P-E190/DGIGSD-3556-05
                      Int. Ref.:           P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                      Proj. Ref.:          HMA-DD-DAT-EN-001                 Date:        14/09/2007


5.5.10 User Management Service
     Name                           User Management Service
     Taxonomy                       System management services
     Category                       Architecture Service
     Standard                       LDAP, Ws-security, ws-policy, SAML
     Specifications
     INSPIRE                        No corresponding service found.
     Extension of                   None
     Description                    User Management is actually a middleware layer rather than a
                                    service.
                                    In fact it is not called directly from users for getting some concrete
                                    outputs, but it is a set of functionalities used by the other services for
                                    managing the following aspects:
                                        o Storage of user profile
                                        o user authentication
                                        o user authorization

                                    User Management is composed of the following functions:
                                       o IDP, Identity Provider, it is the owner of the user profiles. It is in
                                           charge of verifying user credentials and returning a security
                                           context; it is in charge also of managing user registration.
                                       o PEP, Policy Enforcement Point, is a kind of firewall in front of the
                                           service to be protected, which is in charge of checking
                                           whether the received user request has already a security
                                           context, if not it redirects the request to the IDP for
                                           authentication check. If the request has already a security
                                           context, then the request itself is forwarded to the PDP for
                                           checking whether the authenticated user is also authorized to
                                           issue that request. If all checks are successful, then the request
                                           is finally forwarded to the service originally required by the
                                           user.
                                       o PDP, Policy Decision Point, is the entity in charge of checking
                                           the message content against the policy rules for verifying
                                           whether the message can be accepted by the PEP or not.

                                    Details about User Management architecture can be found in [AD14]
                                    while details about interfaces conveying Identity Management
                                    information can be found in [AD18].

     Service
     Operations
     Example
     usage
     Comments



5.5.11 On-line Data Access Services
On-line Data Access is provided by the following services, which are described in the following
sub-sections:


                                                           Pag. 91/182
                        Title:                   Architectural Design Technical Note
                        Contract Ref.:           P-E190/DGIGSD-3556-05
                        Int. Ref.:               P-E190/DGIGSD-0399-06             Issue:   1    Rev.:   7
                        Proj. Ref.:              HMA-DD-DAT-EN-001                 Date:         14/09/2007

   •    Virtual FTP Service
   •    FTP
   •    WMS (OGC Web Map Service)
   •    WCS (OGC Web Coverage Service)


5.5.11.1 Virtual FTP Service
       Name                           Virtual FTP Service [AD16]
       Taxonomy                       Model/Information management services
       Category                       Application Service
       Standard                       FTP,
       Specifications                 OGC™ Catalogue Services Specification 2.0 - EO Products Extension
                                      Package for ebRIM (ISO/TS 15000-3) Profile of CSW 2.0 [AD11]
                                      OpenGIS® Catalogue Services Specification 2.0.1 (with Corrigendum)
                                      - ISO Metadata Application Profile [RD32]
       INSPIRE                        Download Services
       Extension of                   None
       Description                    The Virtual FTP Service is an all in-one solution allowing:
                                             o    Indexing product files available on remote hosts;
                                             o    Publishing the indexed products in a public catalogue;
                                             o    Managing       products      download         including     authentication
                                                  checks.
                                      The Virtual FTP Service foresees:
                                             o    a centralized service allowing users browsing, searching and
                                                  downloading products of interest;
                                             o    distributed agent components in charge of:
                                                       o   publishing to the centralized service the products
                                                           locally available;
                                                       o   allowing download of products to the users.

                                      The catalogue of product data is accessible for searching and
                                      retrieving via the “OGC™ Catalogue Services Specification 2.0 - EO
                                      Products Extension Package for ebRIM (ISO/TS 15000-3) Profile of CSW
                                      2.0” [AD11].
                                      Additionally the catalogue data can be browsed and downloaded
                                      via the FTP protocol.
                                      Identified products can be downloaded from the remote hosts via
                                      the FTP protocol.

       Service
       Operations
              GetCapabilities         Description                The GetCapabilities operation allows clients to
                                                                 retrieve service metadata from the server. The
                                                                 response to a GetCapabilities request contains
                                                                 service metadata about the server (ISO 19119
                                                                 document).
                                      Input

                                                                 Pag. 92/182
        Title:                Architectural Design Technical Note
        Contract Ref.:        P-E190/DGIGSD-3556-05
        Int. Ref.:            P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
        Proj. Ref.:           HMA-DD-DAT-EN-001                 Date:        14/09/2007


                      Output                  The following sections are             included   in   the
                                              GetCapabilities response:
                                                  •    ServiceIdentification: General information
                                                       about the service (type, version, etc.).
                                                  •    ServiceProvider: Information about            the
                                                       organization providing the service.
                                                  •    OperationsMetadata:      Summarizes      the
                                                       operational characteristics of the service.
                                                  •    Filter_Capabilities: Describes       supported
                                                       OGC filter operations.
                                                  •    ServiceFeatures:   Information            about
                                                       implemented features.
                                                  •    ServiceProperties:   Information          about
                                                       general service properties.


  GetRecords          Description             The GetRecords operation is the main operation
                                              used to search the catalogue content. Some or all
                                              the registry objects in the result set that satisfy the
                                              search criteria may be piggy-backed in the
                                              response message.
                      Input                   The main request parameters are:
                                                  •    ResultType     &    ElementSetName        or
                                                       ElementName: specifies whether the
                                                       response shall return only the number of
                                                       hits of the search or whether the record
                                                       with brief, summary or full format shall be
                                                       returned.
                                                  •    ConstraintLanguage & Constraint: specify
                                                       the   filtering   language     (OGC     filter
                                                       encoding 1.1.0) and the filtering expression
                                                       to apply in the search.
                                                  •    SortBy: list of product metadata attributes
                                                       to use as sorting criterion.


                      Output                  The response contains either the number of hits or
                                              a list of metadata records matching the filtering
                                              expression.
GetRecordById         Description             The GetRecordById operation provides a simple
                                              mean for retrieving one or more records by
                                              identifier; the identifier may be that of some
                                              object stored in the catalogue or an external
                                              identifier (see [AD11]).
                      Input                   Identifiers of records to retrieve
                      Output                  Records metadata
   Transaction        Description             This operation allows inserting / deleting /
                                              updating single metadata record already loaded
                                              in the service.
                                              The Transaction request specifies one or more

                                              Pag. 93/182
                       Title:                Architectural Design Technical Note
                       Contract Ref.:        P-E190/DGIGSD-3556-05
                       Int. Ref.:            P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                       Proj. Ref.:           HMA-DD-DAT-EN-001                 Date:        14/09/2007


                                                             transaction elements each of them defines an
                                                             atomic unit of work and is a container for one or
                                                             more insert, update and/or delete actions. Each
                                                             action includes the product metadata record
                                                             which has to be inserted, updated or deleted.
                                     Input                   Metadata records to insert
                                     Output                  Result of the operation
               FTP operations        Description             This is a place holder for all operations supported
                                                             by FTP protocol:
                                                                 •    USER (user name)
                                                                 •    PASS (password)
                                                                 •    CWD (changing working directory)
                                                                 •    QUIT (logout)
                                                                 •    PORT (data port)
                                                                 •    PASV (passive mode)
                                                                 •    MODE (transfer mode)
                                                                 •    RETR (retrieve)
                                                                 •    STOR (store)
                                                                 •    Etc.


                                                             FTP protocol is used by the Virtual FTP Server for
                                                             browsing files and directories not locally stored
                                                             (virtual indeed), but that are stored in remote FTP
                                                             servers connected to the Virtual FTP Service
                                                             “network”.
                                     Input
                                     Output
     Example
     usage
     Comments



5.5.11.2 FTP
     Name                            File Transfer Protocol, FTP
     Taxonomy                        Model/Information management services
     Category                        Application Service
     Standard                        FTP (RFC-959)
     Specifications
     INSPIRE                         Download Services
     Extension of                    None
     Description                     FTP or File Transfer Protocol is used to transfer data from one computer
                                     to another over the Internet, or through a network.
                                     Specifically, FTP is a commonly used protocol for exchanging files
                                     over any network that supports the TCP/IP protocol (such as the
                                     Internet or an intranet).

                                                             Pag. 94/182
                      Title:                Architectural Design Technical Note
                      Contract Ref.:        P-E190/DGIGSD-3556-05
                      Int. Ref.:            P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                      Proj. Ref.:           HMA-DD-DAT-EN-001                 Date:        14/09/2007


    Service
    Operations
              FTP operations        Description             This is a place holder for all operations supported
                                                            by FTP protocol:
                                                                •    USER (user name)
                                                                •    PASS (password)
                                                                •    CWD (changing working directory)
                                                                •    QUIT (logout)
                                                                •    PORT (data port)
                                                                •    PASV (passive mode)
                                                                •    MODE (transfer mode)
                                                                •    RETR (retrieve)
                                                                •    STOR (store)
                                                                •    Etc.


                                    Input
                                    Output
    Example
    usage
    Comments


5.5.11.3 WMS
    Name                            Web Map Service
    Taxonomy                        Model/Information management services
    Category                        Application Service
    Standard                        OGC WMS [RD29]
    Specifications
    INSPIRE                         Download Services
    Extension of                    None
    Description                     An OGC Web Map Service (WMS) produces maps of spatially
                                    referenced data dynamically from geographic information. This
                                    international standard defines a "map" to be a portrayal of
                                    geographic information as a digital image file suitable for display on a
                                    computer screen.
                                    A map is not the data itself. WMS-produced maps are generally
                                    rendered in a pictorial format such as PNG, GIF or JPEG, or
                                    occasionally as vector-based graphical elements in Scalable Vector
                                    Graphics (SVG) or Web Computer Graphics Metafile (WebCGM)
                                    formats. This is in contrast to a Web Coverage Service (WCS), which
                                    returns actual raster data.

                                    WMS support HTTP GET and optionally HTTP POST: in this case the
                                    request is encoded in XML format.

                                    WMS defines three operations:

                                                            Pag. 95/182
              Title:                Architectural Design Technical Note
              Contract Ref.:        P-E190/DGIGSD-3556-05
              Int. Ref.:            P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
              Proj. Ref.:           HMA-DD-DAT-EN-001                 Date:        14/09/2007


                               •     GetCapabilities, which returns service-level metadata.
                               •     GetMap, which returns a map whose geographic and
                                     dimensional parameters are well-defined.
                               •     GetFeatureInfo, which returns information about particular
                                     features shown on a map (optional).

Service
Operations
     GetCapabilities        Description             The purpose of the mandatory GetCapabilities
                                                    operation is to obtain service metadata, which is
                                                    a machine-readable (and human-readable)
                                                    description of the server's information content and
                                                    acceptable request parameter values.
                            Input
                            Output                  o   Service Metadata
                                                    o   Capabilities
                                                            o Layers
                                                                  The geographic information content
                                                                  offered for portrayal by a WMS server is
                                                                  organized into "layers": metadata
                                                                  about the content is subdivided into
                                                                  descriptions of each layer, and a
                                                                  request for a map names one or more
                                                                  layers. The relationship between “map”
                                                                  and “layer” is that a map is the result of
                                                                  a request to portray information
                                                                  represented by a layer.
                                                             o    Style
                                                             o    Format specifiers


             GetMap         Description             The GetMap operation returns a map. Upon
                                                    receiving a GetMap request, a WMS shall either
                                                    satisfy the request or issue a service exception.
                            Input                       •    LAYER: specifies what has to be rendered.
                                                             Available layers are specified by the
                                                             capabilities document.
                                                        •    STYLE: describes how the layer has to be
                                                             rendered. The possible styles are returned
                                                             by the Capabilities document.
                                                        •    CRS, BBOX: coordinates of the map to be
                                                             rendered.
                                                        •    FORMAT, WIDTH, HEIGH: image format and
                                                             size in pixel.
                                                        •    TRANSPARENT, BGCOLOR: whether the
                                                             map is transparent or not and the
                                                             background colour.
                                                        •    EXCEPTION INIMAGE: the error message is
                                                             rendered within an image with the
                                                             specified format.
                                                        •    TIME: the same layer can be available for
                                                             different times and then this parameter
                                                             select which is the one to return.

                                                    Pag. 96/182
                     Title:                Architectural Design Technical Note
                     Contract Ref.:        P-E190/DGIGSD-3556-05
                     Int. Ref.:            P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                     Proj. Ref.:           HMA-DD-DAT-EN-001                 Date:        14/09/2007


                                                               •    ELEVATION: the same layer can be
                                                                    available at different height, and then this
                                                                    parameter selects which one to return.


                                   Output                  The response to a valid GetMap request shall be a
                                                           map of the spatially referenced information layer
                                                           requested, in the desired style, and having the
                                                           specified coordinate reference system, bounding
                                                           box, size, format and transparency.
          GetFeatureInfo           Description             It returns additional info related to a specific pixel
                                                           of a map. Then the request has to include almost
                                                           all parameters used for getting the map plus the
                                                           parameters specifying the point where getting
                                                           information.
                                   Input                       •    QUERY_LAYERS parameter states the map
                                                                    layer(s) from which feature information is
                                                                    desired to be retrieved.
                                                               •    INFO_FORMAT parameter indicates what
                                                                    format to use when returning the feature
                                                                    information. Supported values for a
                                                                    GetFeatureInfo request on a WMS server
                                                                    are listed as MIME types in one or more
                                                                    <Request><FeatureInfo><Format>
                                                                    elements of its service metadata.
                                                               •    FEATURE_COUNT parameter states the
                                                                    maximum number of features per layer for
                                                                    which feature information shall be
                                                                    returned.
                                                               •    I and J request parameters are integers
                                                                    that indicate a point of interest on the
                                                                    map that was produced by the
                                                                    embedded GetMap request
                                   Output                  The server shall return a response according to the
                                                           requested INFO_FORMAT if the request is valid, or
                                                           issue a service exception otherwise. The nature of
                                                           the response is at the discretion of the service
                                                           provider, but it shall pertain to the feature(s)
                                                           nearest to (I,J).
    Example
    usage
    Comments


5.5.11.4 WCS
    Name                           Web Coverage Service, WCS
    Taxonomy                       Model/Information management services
    Category                       Application Service
    Standard                       OGC WCS [RD31]
    Specifications

                                                           Pag. 97/182
               Title:                Architectural Design Technical Note
               Contract Ref.:        P-E190/DGIGSD-3556-05
               Int. Ref.:            P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
               Proj. Ref.:           HMA-DD-DAT-EN-001                 Date:        14/09/2007


INSPIRE                      Download Services
Extension of                 None
Description                  The Web Coverage Service is an Open Geospatial Consortium
                             standard web service for exchanging geospatial data.
                             WCS provides available data together with their detailed
                             descriptions; allows complex queries against these data; and returns
                             data with its original semantics (instead of pictures) which can be
                             interpreted, extrapolated, etc. -- and not just portrayed. This is in
                             contrast to a Web Map Service (WMS) which produces a digital
                             image file.
                             WCS provides three operations:

                             •   GetCapabilities, which returns XML document describing the data
                                 collections available via WCS.
                             •   DescribeCoverage, which returns details about a specified data
                                 collection.
                             •   GetCoverage, which returns the data in a well known format.

Service
Operations
     GetCapabilities         Description             This operation returns general service information
                                                     and the list of available data collections from
                                                     which coverage may be required.
                             Input
                             Output                  o   Service Metadata: description of supported
                                                         operations
                                                     o   ContentMetadata:
                                                             o List of CoverageOfferingBrief elements.
                                                                Each element contains description of
                                                                one data collection available via the
                                                                WCS.
                                                                   The “name” element included in
                                                                   CoverageOfferingBrief is the identifier
                                                                   of the data collection and that one
                                                                   can be used in DescribeCoverage and
                                                                   GetCoverage operations.


  DescribeCoverage           Description             This operation returns full description of coverages
                                                     managed by the WCS server.
                             Input                   COVERAGE: this parameter specifies one or more
                                                     coverages by their identifier. These identifiers must
                                                     be among those listed in the name element of
                                                     CoverageOfferingBrief element(s).
                             Output                  •   List of CoverageOffering elements. Each
                                                         contains:
                                                              o domainSet: temporal and spatial
                                                                  coverage of the data collection
                                                              o rangeSet: it defines the properties
                                                                  (categories, measures, or values)
                                                                  assigned to each location in the
                                                                  domain.

                                                     Pag. 98/182
                   Title:                Architectural Design Technical Note
                   Contract Ref.:        P-E190/DGIGSD-3556-05
                   Int. Ref.:            P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                   Proj. Ref.:           HMA-DD-DAT-EN-001                 Date:        14/09/2007


                                                                  o    supportedCRSs: For each coverage
                                                                       offering, the supportedCRSs element
                                                                       lists the CRSs (coordinates reference
                                                                       system) in which the server understands
                                                                       incoming GetCoverage requests; and
                                                                       those in which it can respond to
                                                                       GetCoverage requests.
                                                                  o    supportedFormats: This element
                                                                       advertises the output format(s) in
                                                                       which coverages may be requested
                                                                       from this server.
                                                                       Mandatory formats (i.e. at least one of
                                                                       them shall be supported):
                                                                              GeoTIFF
                                                                              HDF-EOS
                                                                              DTED
                                                                              NITF
                                                                              GML
                                                                  o    supportedInterpolations


            GetCoverage          Description             The GetCoverage operation allows retrieval of
                                                         coverages from a coverage offering.
                                 Input                   •   The COVERAGE parameter requests a single
                                                             coverage, identified by a name under a
                                                             CoverageOfferingBrief        in        the
                                                             ContentMetadata section of the Capabilities
                                                             XML document.
                                                         •   CRS, RESPONSE_CRS: coordinates reference
                                                             system of request and response
                                                         •   BBOX, TIME: spatio-temporal extent of request
                                                             data.
                                                         •   PARAMETER: for selecting the sub-values in
                                                             case of data collections of compound values.
                                                         •   WIDTH, HEIGHT, DEPTH; RESX, RESY, RESZ: size
                                                             and resolution of returned grid.
                                                         •   FORMAT: format of returned grid of data.
                                 Output                  Coverage extracted from the coverages
                                                         requested, with the specified spatial reference
                                                         system, bounding box, size and format.
     Example
     usage
     Comments



5.5.12 Help & Documentation Desk Service
     Name                        Help & Documentation Desk Service
     Taxonomy                    Model/Information management services
     Category                    Application Service


                                                         Pag. 99/182
                 Title:               Architectural Design Technical Note
                 Contract Ref.:       P-E190/DGIGSD-3556-05
                 Int. Ref.:           P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                 Proj. Ref.:          HMA-DD-DAT-EN-001                 Date:        14/09/2007


Standard                       No standard applicable
Specifications
INSPIRE                        No corresponding service found.
Extension of                   None
Description                    This service provide support users providing access to system relevant
                               documentation, including missions' documentation, Answering user
                               enquiries, complaints and investigation on services, tools, orders.

                               This service will be defined in future issue of the document.
Service
Operations
Example
usage
Comments




                                                     Pag. 100/182
                        Title:              Architectural Design Technical Note
                        Contract Ref.:      P-E190/DGIGSD-3556-05
                        Int. Ref.:          P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                        Proj. Ref.:         HMA-DD-DAT-EN-001                 Date:        14/09/2007



6         Engineering Viewpoint
This section explains how and where the services are instantiated in the HMA infrastructure and
the related implementation.


6.1       HMA Service Instances Allocation
As anticipated in the Service Viewpoint section, each service is instantiated at HM and / or GS
level to provide different functionalities:
      •   GSs Service Instances, are those services instances hosted by the Ground Segments that
          provide the specific service functionality exploited by the HMA infrastructure.
      •   HM Service Instances, are those services instances hosted by the EO-DAIL that manage
          complex client requests for access to multiple GS service instances, split them into simpler
          requests activating the GS services instances for being actually executed. They are
          intermediary between the users / operators and the GSs service instances. They are in
          charge of orchestrating the access to the GSs native services providing added value to
          the users / operators.


From the service definition performed in §5.4, the following instances have been envisaged:


Service                              HM Instance    GS Instance       Comment
Service Registration Service         Yes            No
Orchestration Service                Yes            No
Monitoring & Control Service         Yes            No                GSs may implement their own Monitoring &
                                                                      control services, but these are decoupled
                                                                      from HMA.
Collection Discovery Service         Yes            Yes               The core approach is to have a centralized
                                                                      repository of discovery information at HM
Service Discovery Service            Yes            N/A               level, however it is anticipated that some
Service Configuration                Yes            Yes               GS’s may also have their collection discovery
Discovery Service                                                     service.
                                                                      The HMA architecture is designed to support
                                                                      UDDI’s both at DAIL and at GS levels
Catalogue Service                    Yes            Yes               The HM instance will support distributed
                                                                      catalogue search requests
Programming Service                  Yes            Yes               The HM instance supports distributed
                                                                      programming   requests  and   performs
                                                                      autonomously lower levels of feasibility
                                                                      analysis.
                                                                      The GS instance is in charge of performing
                                                                      the higher level of feasibility analysis and of
                                                                      actually tasking the satellite.
Order Service                        Yes            Yes               The HM instance will support distributed
                                                                      ordering requests
User Management Service              Yes            Yes               The authentication and authorization checks
                                                                      can be performed on both HM and GS side.
Virtual FTP Service                  Yes            No*               HM Instance: the centralized server hosting
                                                                      metadata of on-line available products is
                                                                      held at HM level.


                                                           Pag. 101/182
                      Title:             Architectural Design Technical Note
                      Contract Ref.:     P-E190/DGIGSD-3556-05
                      Int. Ref.:         P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                      Proj. Ref.:        HMA-DD-DAT-EN-001                 Date:        14/09/2007

                                                                   On GS side the client that extracts metadata
                                                                   from locally available products and ingests
                                                                   them into the Virtual FTP Service central
                                                                   server has to be deployed.
FTP                                No            Yes               At HM level no data is stored and then no FTP
                                                                   server is necessary.
WMS                                No            Yes               At HM level no maps are managed, then no
                                                                   WMS instance.
WCS                                No            Yes               At HM level no coverage is managed, then
                                                                   no WCS instance.
Help & Documentation Desk          Yes           Yes               This service is still under definition but both HM
Service                                                            and GS instances are expected
Table 3: HM and GS service instances.




                                                        Pag. 102/182
                                                                                      Title:                                      Architectural Design Technical Note
                                                                                      Contract Ref.:                              P-E190/DGIGSD-3556-05
                                                                                      Int. Ref.:                                  P-E190/DGIGSD-0399-06                                                Issue:                 1        Rev.:   7
                                                                                      Proj. Ref.:                                 HMA-DD-DAT-EN-001                                                    Date:                           14/09/2007




The following figure outlines the relationships between the different service instances.


                                                                                                                      uses




                                                                                              HM Catalogue Service Instance
                                                       forw to
                                                           ard                                       (from Catalogue Scenarios)


                                                                                                                                                                       uses
                                                                                                                                                                                         S
                                                                                                                                                                                        G Catalogue Service Instance
                                                                                        HM Collection Discovery Service Instance
                                                                                                                                                                                           (from Catalogue Scenarios)
                                                            forw to
                                                                ard                                   rom Discovery Scenarios)
                                                                                                     (f
                                               uses


                 Web Service Client                                                                                                     uses
                                                                                               HM Order Service Instance
                                                                            ard
                                                                        forw to                  (from Ordering Scenarios)                                                                                    S
                                                                                                                                                                                                             G Order Service Instance
                                                                                                                                                         uses
                                                                                                                                                                notifies         forw to
                                                                                                                                                                                     ard                        rom Ordering Scenarios)
                                                                                                                                                                                                               (f
    User Management Layer is                                                                                  uses
    in charge of filtering access     HM User Management Service Instance
    to services.                                                                ard
                                                                            forw to
                                                                                       HM Service Discovery Service Instance                                                                 ard
                                                                                                                                                                                         forw to
                                                                                                (f
                                                                                                 rom Discovery Scenarios)                                                                                                     S
                                                                                                                                                                                                                             G FTP
                                                                                                                                                                                                                         rom ODA Scenarios)
                                                                                                                                                                                                                        (f
                                                                                                                                                                                                         ard
                                                                                                                                                                                                     forw to
                                                                                                                                                      S
                                                                                                                                                     G User Management Service Instance
                                        uses                                                                  uses
                                                                                                                                                                                                      ard
                                                                                                                                                                                                  forw to                    S
                                                                                                                                                                                                                            G WCS
                       Operator                                                                                                                                                                                     rom ODA Scenarios)
                                                                                                                                                                                                                   (f
                                                                                            HM Programming Service Instance                           uses                     ard
                                                                                                                                                                           forw to              ard
                                                                                                                                                                                            forw to
                                                                    ard
                                                                forw to                          rom Programming Scenarios)
                                                                                                (f                                        satellite / sensor data

                                                            forw to
                                                                ard                                                                       notifies                   S
                                                                                                                                                                    G Programming Service Instance                           S
                                                                                                                                                                                                                            G WMS
                                                                                                                                                                        rom Programming Scenarios)
                                                                                                                                                                       (f                                           (from ODA Scenarios)
                                                                                  HM Service Configuration Discovery Service Instance
                                                                                                     (from Discovery Scenarios)
                                                            ard
                                                        forw to
                                                                                      publishing()
                                                          ard
                                                      forw to
                                                                                        HM Monitoring & Control Service Instance
                                                      ard
                                                  forw to


                                                                                         HM Service Registration Service Instance               Used by all other HM instances for
                                                                                                                                                logging the activity
                                              ard
                                          forw to
                                                                                       HM Service Orchestration Service Instance



                                                                                                 HM Virtual FTP Service
                                                                                                      (from ODA Scenarios)




                                               Figure 20: Relationships between HM and GS service instances.




                                                                                                                                                             Pag. 103/182
                          Title:                 Architectural Design Technical Note
                          Contract Ref.:         P-E190/DGIGSD-3556-05
                          Int. Ref.:             P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                          Proj. Ref.:            HMA-DD-DAT-EN-001                 Date:        14/09/2007


6.1.1 Services Instances allocation trade-offs criteria
The different Service Instances identified in the previous sections may be allocated to the
following entities:
     • EO DAIL
     • Partners GS
     • Future ESA MM Ground Segment
     • Commercial or Distributing Entities

The envisaged criteria for the Services allocation either to the EO DAIL or to the partners’ GS (and
to the ESA MM GS) have been identified as follows:
    1. When the responsibility for follow-on actions is with the GS Owner, then the service shall be
        provided by the GS owner
    2. The splitting of complex service request, the combination of results, the tracking of the
        transaction is allocated to EO DAIL;
    3. Complex coordination functions are allocated to ESA MM Ground Segment (either current
        or future);
    4. If a mission GS needs support then a decision on the service localization shall be taken at
        GSCB level.
    5. The level of performance and/or reliability provided by the different components (e.g. EO
        DAIL, GS Owner, ESA MM GS) may be used as criterion to allocate service execution
        responsibility.


Regarding the GS service instances, no trade-offs needed: they are provided by the GS side.
Regarding the HM service instances, the trade-offs have to be done. The following table
summarizes the allocation trade-offs:


Service Instance                       Allocation        Comment
HM Service Registration                EO DAIL           This functionality is related to the service orchestration
Service                                                  engine, which is the basic building block of the EO DAIL
                                                         (criterion 2). Then it is allocated to EO DAIL.
HM Orchestration Service               EO DAIL           This is the basic build block of the EO DAIL, and then it is
                                                         allocated to EO DAIL.
HM Monitoring & Control                EO DAIL           This service is explicitly specified in the criterion 2 and then it
Service                                                  is allocated to EO DAIL.
HM Collection Discovery                EO DAIL           This service does not fall in any trade-off criteria, but being
Service                                                  essential to split and recombine user requests and ground
                                                         segments answers, it is allocated to EO DAIL.
HM Service Discovery                   EO DAIL
Service
HM Service Configuration               EO DAIL
Discovery Service
HM Catalogue Service                   EO DAIL           The HM Catalogue Service Instance follows exactly the
                                                         pattern identified in the criterion 2 and then it is allocated to
                                                         EO DAIL.
HM Order Service                       EO DAIL           In this case the decision is controversial: in fact it complies
                                                         with criteria 2 and 3:
                                                              •     Several operations are performed following exactly
                                                                    the pattern of criterion 2: split of the request and
                                                                    delegation to the GS for the execution of the actual
                                                                    work;
                                                              •     But it is also in charge of non-trivial coordination
                                                                    activities: it keeps updated the order status

                                                                  Pag. 104/182
                         Title:                 Architectural Design Technical Note
                         Contract Ref.:         P-E190/DGIGSD-3556-05
                         Int. Ref.:             P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                         Proj. Ref.:            HMA-DD-DAT-EN-001                 Date:        14/09/2007

                                                                 receiving notifications form the GSs and it is able to
                                                                 undertake countermeasures when some problems
                                                                 occur during the execution of the order request.
                                                        For the time being the functionality is allocated to the EO
                                                        DAIL, but if in the next phase of the project it is charged with
                                                        additional responsibilities, then it will be allocated to the ESA
                                                        MM GS.
HM Programming Service                EO DAIL           Same as previous one.
HM User Management                    EO DAIL           The currently envisaged approach foresees the user identity
Service                                                 check on both HM and GS sides, then the EO DAIL will be
                                                        provided with a User Management Service instance.
HM Virtual FTP Service                EO DAIL
Table 4: Services allocation table.


The following figure summarizes the services allocation:




                                                Figure 21: Service Allocation.
From the previous figure it can be seen that Commercial and Distributing Entities have a double
role in the HMA context: they are users exploiting the GSs services via HM ones, at the same time
they also act as Service Provider having their own users to which they provide services. In the
figure is presented the minimal set of services that Commercial and Distributing Entities shall
support when acting as Service Provider, i.e. the User Management Service. This does not prevent
them to offer additional value added services exploited via HMA (currently not presented in
figure).

6.2      Services Architecture
6.2.1   Services Instance
In the following sub-sections the functionality to be provided by the services instantiated on the
EO DAIL is described.




                                                               Pag. 105/182
                        Title:           Architectural Design Technical Note
                        Contract Ref.:   P-E190/DGIGSD-3556-05
                        Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                        Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

6.2.1.1    HM Collection Discovery Service Instance
This service instance is in charge of managing the list of all dataset collections available in the
HMA infrastructure.
It is the centralised repository for this kind of data.
It provides operations allowing the clients to search the collections matching their needs and
allowing the providers of the products collections (e.g. the other GSs) to register their collections in
this registry.
The HM Collection Discovery Service Instance has to implement the following operations specified
in the [AD17]:
    •     GetCapabilities: returns general information about the server implementing the service;
    •     GetRecords: this operation allows to query the repository of collection metadata looking
          for the dataset collections matching the query parameters.
    •     GetRecordById: this operation extracts a single record from the collections repository
          corresponding to the input identifier.
    •     DescribeRecord: this operation returns an XML document providing the definition of the
          input element / type.
    •     GetDomain: it returns runtime information about the range of values of a metadata record
          element or request parameter.
    •     GetRepositoryItem.
    •     Transaction: this operation allows inserting / updating / deleting single entry in the
          collections repository.
    •     Harvest: this operation accesses the remote catalogue for extracting data to store locally.


To note that this service does not make any filtering against the user privileges. It is a responsibility
of the User Management service instances at HM and GS level.


6.2.1.2    HM Service Discovery Service Instance
This service instance is in charge of managing the list of Human Readable Services available in the
HMA infrastructure.
It is the centralised repository for this kind of data.
It provides operations allowing the clients to search the Human Readable Services matching their
needs and allowing the service providers (e.g. the other GSs) to register their services.
This service follows the same protocol specified for the collection discovery ([AD17]), but with
customization for managing only the Human Readable Services. Then the operations to be
implemented are the same, but dealing with different content:
    •     GetCapabilities: returns general information about the server implementing the service;
    •     GetRecords: this operation allows querying the repository of service metadata looking for
          the services matching the query parameters.
    •     GetRecordById: this operation extracts a single record from the repository corresponding
          to the input service identifier.
    •     DescribeRecord: this operation returns an XML document providing the definition of the
          input element / type.
    •     GetDomain: it returns runtime information about the range of values of a metadata record
          element or request parameter.
    •     GetRepositoryItem
    •     Transaction: this operation allows inserting / updating / deleting single entry in the services
          repository.
    •     Harvest: this operation accesses the remote catalogue for extracting data to store locally.

                                                        Pag. 106/182
                          Title:           Architectural Design Technical Note
                          Contract Ref.:   P-E190/DGIGSD-3556-05
                          Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                          Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007



To note that this service does not make any filtering against the user privileges. It is a responsibility
of the User Management service instances at HM and GS level.


6.2.1.3       HM Service Configuration Discovery Service Instance
This service instance is in charge of managing the WSDL files of the service instances making part
of the HMA infrastructure. It is effectively implemented via a UDDI server.
This service is mainly needed to support the Service Registration and Orchestration services rather
than the catalogue, order and programming services, which uses the Collection and Service
Discovery Services instead.


6.2.1.4       HM Catalogue Service Instance
This service instance is the entry point for a seamless access to all Catalogue service instances
available in the HMA infrastructure.
It does not actually store any product metadata records, but it is in charge of orchestrating the
access to the other catalogues in answer to heterogeneous catalogue searches issued by the
clients.
This catalogue implements the protocol defined in [AD11] “OGC™ Catalogue Services
Specification 2.0 - EO Products Extension Package for ebRIM (ISO/TS 15000-3) Profile of CSW 2.0”
and then provides the following operations:
    •     GetCapabilities: returns general information about the server implementing the service;
    •     GetRecords: this operation allows querying the products catalogues looking for the
          products matching the query parameters. This operation is performed in this way:
                o   the catalogue gets the description of the collections specified in the request;
                o   the search is split in single collection searches and then sent to the GS Catalogue
                    Service instances natively managing them;
                o   at the end the results are put together and sent back to the client.
    •     GetRecordById: this operation extracts a single record from the repository corresponding
          to the input service identifier. This operation is performed in this way:
                o   from the identifier of the product, the collection id has to be retrieved;
                o   then the right catalogue is identified and the request is sent to it. At the end the
                    received response is sent back to the client.
    •     DescribeRecord: this operation returns an XML document providing the definition of the
          input element / type.


The interactions between this service instance and the other ones of the HMA infrastructure are
described in the §6.4.


6.2.1.5       HM Programming Service Instance
This service instance allows the users / operators to submit heterogeneous multi-mission future
products orders on the HMA infrastructure.
This service instance is in charge of performing the following tasks:
    •     Feasibility analysis: the HMA Programming ICD [AD10] defines 3 levels of feasibility analysis
          accuracy:
          •     light, the check takes into account physical characteristic of the satellite / sensor;
          •     estimate, with respect the previous one it adds also possible meteorological data and
                the estimated workload of the satellite;

                                                          Pag. 107/182
                          Title:           Architectural Design Technical Note
                          Contract Ref.:   P-E190/DGIGSD-3556-05
                          Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                          Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

          •     full, with respect the previous it takes into account the work load of the satellite.
          Because the workload is not known outside the ground segment, then the full feasibility
          check is performed only by the Programming Service instance running on the ground
          segment itself.
          The HM instance of the Programming service has to perform light and estimate feasibility
          check.
    •     Orchestration of ground segment programming services: the light and estimate feasibility
          analysis are the only activities completely performed by the service: all others (full
          feasibility, task submission, task monitoring) are performed by calling the corresponding
          Programming service instance.


It implements the operations described in the [AD10] (HMA Programming ICD), which are
summarized hereafter:

    •     GetCapabilities, which returns information about the server and the supported operations.

    •     DescribeSensor, which returns detailed description of sensors.

    •     DescribeGetFeasibility, which allows the retrieval of the parameters for getting the
          feasibility analysis of a specific satellite / sensor.

    •     GetFeasibility, which allows asking the system to verify the feasibility of the specified
          programming request.

    •     DescribeSubmit, which allows the retrieval of the parameters for submitting a tasking
          request for the specific satellite / sensor.

    •     Submit, which allows submitting a programming request (both checked and not
          checked).

    •     GetStatus, which allows to retrieve the status of submitted programming requests.

    •     Cancel, which allows asking the cancellation of an already submitted programming
          request.
    •     DescribeResultAccess, which, in case delivery information has not been specified in the
          submission, returns the URL of the service where the acquired data can be accessed.


Because it is an asynchronous client for GSs services, it has to implement also the following
operations:
    •     GetFeasibilityResponse (for receiving the answer to a Full GetFeasibility issued to a GS)
    •     SubmitResponse


The interactions between this service instance and the other ones of the HMA infrastructure are
described in the §6.4.


6.2.1.6       HM Order Service Instance
This service instance allows the users / operators to submit heterogeneous multi-mission past
products orders on the HMA infrastructure and to adhere subscriptions.
This service instance orchestrates the access to the GSs Order Service instances, which are the
ones providing effectively the ordering functionality.
It implements the operations described in the [AD05] (HMA Ordering ICD), which are summarized
hereafter:

    •     GetCapabilities, which returns information about the server and the supported operations.

                                                          Pag. 108/182
                        Title:           Architectural Design Technical Note
                        Contract Ref.:   P-E190/DGIGSD-3556-05
                        Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                        Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

    •     GetOptions, which allows the retrieval of the options for ordering a specific type of
          products or for subscriptions.

    •     GetQuotation, which allows the client to get a quotation of the order that is going to be
          submitted.

    •     Submit, which allows submitting an order of precisely identified non-future products or to
          subscribe a subscription.

    •     GetStatus, which allows to retrieve the status of submitted orders.

    •     Cancel, which allows asking the cancellation of an already submitted order or to
          unsubscribe a subscription.

    •     DescribeResultAccess, which allows getting URLs of on-line available products.


Because it is an asynchronous client for GSs services, it has to implement also the following
operations:
    •     GetQuotationResponse
    •     SubmitResponse
    •     CancelResponse


The interactions between this service instance and the other ones of the HMA infrastructure are
described in the §6.4.


6.2.1.7    HM User Management Service Instance
The User Management architecture is not finalised yet (the on-going prototype activity is
addressing the open points). However the main concepts and mechanisms are summarized in
section 6.5.


6.2.1.8    HM Service Registration Service Instance
This is the instantiation of the Service Registration described in the §5.5.1.


6.2.1.9    HM Orchestration Service Instance
This is the instantiation of the Orchestration Service described in the §5.5.2.


6.2.1.10 HM Monitoring & Control Service Instance
This is the instantiation of the Monitor & Control Service described in the §5.5.3.
The monitor & control has been instantiated at HM level because it has to track the requests
managed by HMA infrastructure.


6.2.1.11 HM Virtual FTP Service Instance
This server [AD16] is in charge of storing metadata of all products available for on-line download. It
is populated by the Virtual FTP Agent deployed on ground segments, which are in charge of
extracting metadata from available products and sending to the Virtual FTP Service.
The Virtual FTP Service allows searching and retrieving product metadata via the HMA Catalogue
ICD [AD11] and also browsing and downloading data via the usual FTP protocol.



                                                        Pag. 109/182
                      Title:             Architectural Design Technical Note
                      Contract Ref.:     P-E190/DGIGSD-3556-05
                      Int. Ref.:         P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                      Proj. Ref.:        HMA-DD-DAT-EN-001                 Date:        14/09/2007


6.2.2   EO DAIL Components Description
The following figure reports the first level decomposition of the EO DAIL component:




                                    Figure 22: EO DAIL level-1 decomposition.


The EO DAIL has been decomposed in the following sub-components:
   •    Service Container: It is the run-time environment for executing other EO DAIL components.
        It provides main functionality for service storage, activation and management and their
        interactions with other EO DAIL elements e.g. other services, Database and Workflow
        Engine.
   •    Database: it is the database management system used to store the data needed by the
        EO DAIL. Database is used by HMA Services (e.g. Monitoring & Control Service) and also by
        the Workflow Engine to maintain the status of running workflows.
   •    Workflow Engine: this is the core component of the EO DAIL architecture. It is in charge of
        executing the EO DAIL’s services. The same component provides also the functionality to
        deploy new services and for monitoring & control the status of running work-flows. It
        represents the HM instance of the Orchestration Service, Service Registration Service, and
        Monitoring & Control Service.
   •    User Profile Repository: it is the repository in charge of storing HMA user’s profiles of the EO-
        DAIL. User profile information includes only authentication information.
   •    Collection Discovery Server: it is the catalogue server storing the list of collections available
        in the HMA infrastructure. It is the HM instance of the Collection Discovery Service.
   •    Service Discovery Server: it is the catalogue server storing the list of “Human Readable
        Services” provided by the HMA infrastructure. It is the HM instance of Service Discovery
        Service.



                                                        Pag. 110/182
                          Title:                  Architectural Design Technical Note
                          Contract Ref.:          P-E190/DGIGSD-3556-05
                          Int. Ref.:              P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                          Proj. Ref.:             HMA-DD-DAT-EN-001                 Date:        14/09/2007

    •   Service Description Registry: it is the component in charge of maintaining specification of
        the services available in the HMA infrastructure. It is the HM instance of the Service
        Configuration Discovery Service.
    •   Catalogue Service, Order Service and Programming Service: these are the HM instances of
        the Catalogue, Order and Programming services. They are implemented through BPEL
        scripts and then are run by the Work-flow engine.
    •   Virtual FTP service: component implementing the Virtual FTP Service interface ([AD16]).
    •   User Management: package of infrastructure components in charge of providing to the
        EO DAIL the following functionalities:
            o   IDP, Identity Provider, for EO DAIL users;
            o      PEP, Policy Enforcement Point, for accessing EO DAIL resources;
            o      PDP, Policy Decision Point, for evaluating EO DAIL policies.
    •   Feasibility Server: component in charge of performing light and estimate feasibility analysis
        without calling the corresponding ground segment. It includes propagation algorithms for
        predicting satellite sensor earth track and functionalities for taking into account
        meteorological conditions.


The following table reports the mapping of HM service Instances on the Architectural components
of the EO DAIL:


Service Instance                       Architectural               Comment
                                       Component
HM Service Registration                Workflow Engine             The management console of the Workflow Engine
Service                                                            allows the deployment / registration of new services.
HM Orchestration Service               Workflow Engine             The Workflow Engine is the technological solution for
                                                                   orchestrating Web Services.
HM Monitoring & Control                Workflow Engine             The management console of the Workflow Engine
Service                                                            allows the activation / stop / resume of deployed
                                                                   and running workflow processes.
HM Collection Discovery                Collection Discovery
Service                                Server
HM Service Discovery                   Service       Discovery
Service                                Server
HM Service Configuration               Service      Description
Discovery Service                      Registry
HM Catalogue Service                   Catalogue Service           The catalogue service instance running on the EO
                                                                   DAIL performs split & recombination, then it is
                                                                   implemented using the workflow engine technology.
                                       Workflow Engine


HM Programming Service                 Workflow Engine             The programming service instance running on the EO
                                                                   DAIL performs the following activities:
                                                                       •    split & recombination, and then it is
                                       Programming                          implemented using the workflow engine
                                       Service                              technology.
                                       Feasibility Server              •    Feasibility analysis, then an orbit swath
                                                                            propagation module is necessary.
HM Order Service                       Order Service               The order service instance running on the EO DAIL
                                                                   performs mainly split & recombination, and then it is



                                                                  Pag. 111/182
                          Title:               Architectural Design Technical Note
                          Contract Ref.:       P-E190/DGIGSD-3556-05
                          Int. Ref.:           P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                          Proj. Ref.:          HMA-DD-DAT-EN-001                 Date:        14/09/2007


                                       Workflow Engine            implemented using the workflow engine technology.

HM User Management                     User Management:
Service                                IDP, PEP, PDP
                                       User            Profile
                                       Repository
Virtual FTP Service                    Virtual FTP Service

Table 5: HM Service Instances vs. Architectural Components.


The EO DAIL components are detailed in the following sub-sections.


6.2.2.1    Service Container
The Service Container provides the runtime environment for hosting services implementing various
application / business logic (see section 7.1.2 for further information).
It provides as main functionality:
    •     Services deployment,
    •     activation and execution of the service (even in multiple instances) granting any service
          instance the possibility of running in a dedicated environment,
    •     services lifecycle management (activation and disposition),
    •     messages dispatching: it allows message dispatching to relevant service instance and
          return of outgoing messages to the caller,
    •     Support for logging and Error handling.


6.2.2.2    Database
This architectural component is used for several purposes. It is used by services to store their data,
e.g. the Monitoring & Control service uses the Database storing transaction tracking data flowing
through the EO DAIL layer. Each time a service is invoked, a service implementing an interface to
the DB is activated to log service invocation in the repository. The repository is accessed by the
Monitoring & Control component to produce reports on performed activities containing the
current status of submitted transactions, to monitor the status of ongoing activities, produce
statistics about performed transactions. Database hosts a schema compliant to information
model for transaction data described in §4.1.9.
The Database is also used by the Workflow Engine to maintain status information of running
workflows.


6.2.2.3    Workflow Engine
This component is in charge of executing the BPEL scripts used whenever possible for
implementing EO DAIL services.
BPEL is a programming language that allows developers to compose multiple discrete Web
Services into collaborative and transactional end-to-end process flow (see section 7.1.2 for further
information).
It has built-in support for:
    •     Invocation of web services (sequential or parallel);
    •     asynchronous interactions;
    •     flow control;
    •     compensating business transactions;
    •     copy and manipulate XML documents with XPath, XSLT and Xquery;
                                                                 Pag. 112/182
                     Title:           Architectural Design Technical Note
                     Contract Ref.:   P-E190/DGIGSD-3556-05
                     Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                     Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

   •   bind to SOAP services;
   •   coordinate process flow (parallel, switch, while);
   •   manage events and exceptions (throw, catch, faultHandlers, etc.);
   •   activate external modules through the WSIF (Web Service Inspection Language) method;
   •   expose a process flow as a new service;
   •   monitoring functionalities.
Then a BPEL business process (application) is a service that is a composite of existing services
(compound service).
The interface of a BPEL compound service uses a set of port types through which it provides
operations like any other service. The invocation of a BPEL business process is performed by
invocating the resulting compound service. The next figure shows a schematic view of an
example BPEL process.




            Figure 23: Example BPEL process: Spot Image WCTS service chain Fig 1 ([RD40]).




                                                     Pag. 113/182
                     Title:           Architectural Design Technical Note
                     Contract Ref.:   P-E190/DGIGSD-3556-05
                     Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                     Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007




            Figure 24: Example BPEL process: Spot Image WCTS service chain Fig 2 ([RD40]).


These main functionalities allow the Workflow engine to orchestrate basic services providing value
added services that are perceived by the client, as new services to be invoked.
Considering that the services deployed on the EO DAIL have to mainly call the other services
provided by the ground segments, then this component and BPEL processes will have an
extensive usage in the EO DAIL development.
BPEL work flow engines are supplied with a management console that allows the operators to:
       deploy new work flows and then new Services
       monitor the status of started BPEL process instances
       stop / resume already started work-flows


Then this component provides the following services:
       Monitor & Control
       Registration Service
       Orchestration Service


                                                     Pag. 114/182
                        Title:           Architectural Design Technical Note
                        Contract Ref.:   P-E190/DGIGSD-3556-05
                        Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                        Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

6.2.2.4    User Profile Repository
This is the repository where HMA users’ profiles and other user relevant information are stored, e.g.
user name, address, etc. (4.1.7). This repository is used by the User Management Service in order to
perform user authentication (IDP) (see section 6.5 and 7.1.2 for further information).


6.2.2.5    Collection Discovery Server
The Collection Discovery Server (CDS) is the component in charge of storing, publishing and
making accessible to the HM applications, users and operators the EO catalogues information
described by [AD17].
The collection metadata is made available to remote clients through a Web Service interface.
A Collections repository where collection metadata are stored and retrieved is part of the CDS.
This repository is internally managed by CDS.
Both the Discovery and Publication interfaces are implemented by the CDS.
Publication interface defines operations for creating, modifying and deleting catalogue records. It
is needed to fill the metadata of collections available into the HMA context.
For populating the service with the collections managed by the GSs, the two approaches defined
in [AD17] have been considered and then all operations of Publication Interface have to be
supported:
    •     Transaction: the GSs can call this operation providing the collections metadata to upload
          in the server;
    •     Harvest: the operation is locally triggered to start the retrieval of data form the remote GSs
          collection catalogues.


Discovery interface implements the actual discovery services used by applications, operators and
users to retrieve and access collection information. Collections registered are made available by
means of standard operations defined in the [AD17].


6.2.2.6    Service Discovery Server
The Service Discovery Server (SDS) is the component in charge of storing, discovering and making
accessible to the HM applications, users and operators the Earth Observation related services.
The server is implemented as a Web Service providing the interfaces specified in the [AD17].
A Service repository where services metadata are stored and retrieved is part of the SDS. This
repository is internally managed by SDS.
Similarly to the previous one, for populating this server with the services metadata hosted on GSs,
both operations of the Publication Interface have to be supported: Transaction & Harvest.


Discovery interface implements the actual discovery services used by applications, operators and
users to retrieve and access service information. Users are interested in knowing available services
for their needs (e.g. discovering services available for a given collection; search for an HMA Order
Service offering a Product search using the Collection identifier of the products which user wants
to order).


6.2.2.7    Service Description Registry
It allows storing information about available services description.
Services are published, by Service Providers, by means of this registry; this allows other applications
to query and retrieve service specification i.e. the interface exposed by the service, connection
information to activate the service (port and supported protocol) and then activate the service
(see section 7.1.2 for further information).

                                                        Pag. 115/182
                        Title:           Architectural Design Technical Note
                        Contract Ref.:   P-E190/DGIGSD-3556-05
                        Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1    Rev.:   7
                        Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:         14/09/2007




6.2.2.8    Catalogue Service
This section describes the implementation of the Catalogue Service in EO DAIL.
Because this service has to split received requests and forward them to the suitable remote GS
catalogues, it is suitable for a work-flow manager based implementation based on the BPEL
language.
The operations provided by this service are:
    •     GetCapabilities. This operation returns an XML document describing the server. It includes
          information like: server version, provider metadata, supported filter operation, etc.
          This operation can be implemented with a simple BPEL process instantiating a variable to
          store the response message, setting it with the metadata of the server and then returning
          the variable as result of the script.
    •     GetRecords. This operation is in charge of searching the catalogues.
          The main parameters that can be specified are:
             o   output format
             o   filtering conditions:
                         circle / polygon / rectangle
                         collection id
                         acquisition start & stop times
                         satellite & sensor identifiers
                         etc.
          The operation returns an array of records matching the filtering conditions.
          The operation is implemented in this way:
             o   for each collection id specified in the filtering condition:
                         call the GetRecords operation of the Collection Discovery Server specifying
                         the collection Id as filter;
                         the received information are used for finding the catalogue server
                         managing that collection;
                         the found catalogue is queried using the original query but with only one
                         collection id.
             o   In case the collection is not specified:
                         The filtering parameters supported at collection level are used for querying
                         the Collection Discovery Server;
                         The returned collections are the ones to                       be   queried, then the
                         corresponding catalogue servers are look for;
                         The found catalogues are queried and results put together.
          The described steps suit very well the BPEL model and then this operation is implemented
          via a BPEL process.
    •     GetRecordById. This operation returns the summary or full information related to the
          identified record.
          The retrieval can be done as in the previous operation. The difference is that only one
          catalogue has to be queried.
    •     DescribeRecord. This operation returns the XSD file corresponding to the specified input
          element (dataset, sar-dataset, etc..).
          This operation is implemented with a simple BPEL process that returns the different schemas
          (which are static information) depending on the input parameter.



                                                        Pag. 116/182
                        Title:           Architectural Design Technical Note
                        Contract Ref.:   P-E190/DGIGSD-3556-05
                        Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                        Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

6.2.2.9    Order Service
This section describes the implementation of the Order Service in EO DAIL.
Because this service has to split received requests and forward them to the suitable remote GS
order services, it is suitable for a work-flow manager based implementation using the BPEL
language.
The operations provided by this service are:
    •     GetCapabilities. This operation returns an XML document describing the server. It includes
          information like: server version, provider metadata, supported operations, etc.
          This operation can be implemented with a simple BPEL process instantiating a variable to
          store the response message, setting it with the metadata of the server and then returning
          the variable as result of the script.
          GetOptions. This operation is in charge of returning the order options related to the
          specified collection and product.
          The current approach foresees a distributed management of order options i.e. each order
          services stores locally the order options. Then the approach is similar to the one for
          distributed catalogue searches:
             o   call the GetRecordById operation of Service Discovery Server specifying the
                 provided collectionId
             o   the returned service metadata specifies the address of the order service managing
                 that collection
             o   invoke the found order service calling the GetOptions operation
             o   return the found order options
          GetQuotation.
          This operation can return the quotation either in synchronous or asynchronous mode
          depending on client and server capabilities.
          A product order contains a list of order items, each belonging to possibly different
          collections and services. Then the first step is to regroup in separated sub-orders all items
          that can be managed by the same order service. Then the quotation of each sub-order is
          asked to each remote order service. If supported by the remote service, the quotation is
          asked in synchronous mode. When all quotations are received, the quotation for the whole
          order is provided to the client.
          For understanding the order service managing a specific product / collection the Service
          Discovery Server is called.
          The split of the order seems a quite complex process that cannot be simply achieved by a
          pure BPEL process, and then could be necessary to implement this procedure with external
          modules connected to the BPEL process.
          Submit. This operation performs the submission of a product order to the remote GS order
          services.
          In case the order is submitted specifying the whole set of parameters, the problem is similar
          to the previous one: the order has to be reorganized and split in different sub-order each
          containing order items managed by the same order service. If the order is submitted
          specifying the quotation id, the quotation id of suborders have to be retrieved from the
          transaction tracking database and the sub-orders can be sent specifying these identifiers.
          The input order is stored in the database of transaction tracking data via a dedicated
          external module; each sub-order is submitted to corresponding order service and the
          received order identifier, together the sub-order, is stored in the transaction tracking data
          as well.
          The described tasks have to be likely implemented using BPEL process helped by several
          external modules: one for split the order, another for inserting data in the database.
          GetStatus. This operation returns the status of a previously submitted order.

                                                        Pag. 117/182
                     Title:           Architectural Design Technical Note
                     Contract Ref.:   P-E190/DGIGSD-3556-05
                     Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                     Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

       The sub-orders linked to the user order to get status are retrieved by the transaction
       tracking data via a dedicated external module. Then a GetStatus request is sent for each
       sub-order to the related order service instance.
       Cancel. This operation asks the cancellation of a previously submitted order.
       The sub-orders linked to the user order to cancel are retrieved by the transaction tracking
       data via a dedicated external module. Then a cancellation request is sent for each sub-
       order to the related order service instances.
       DescribeResultAccess.
       Similarly to the previous cases, the request is split and forwarded to the remote services
       and then all returned URLs are returned back to the client.


Additionally, because the Order Service instance in the DAIL is an asynchronous client for remote
GSs services, it has to implement also the following operations:
       GetQuotationResponse.
       This operation is called by remote GS Ordering Services supporting asynchronous
       quotation. Because the quotation is provided to the client when all quotations have been
       received and the quotation can be re-used for submitting the order, then this information
       has to be stored in the database.
       SubmitResponse & CancelResponse. These operations are called for updating the status of
       sub-orders.
       This operation is activated by the remote order services for notifying the progress of the
       orders in charge to them.
       As far as the sub-orders and related status are stored in the database, then the BPEL
       process implementing this operation has to activate an external module able to update
       the status of sub-orders.


6.2.2.10 Programming Service
This section describes the implementation of the Programming Service in EO DAIL.
Apart from light and estimate feasibility analysis, the other operations are performed by
forwarding the request to the suitable remote GS programming services then it is suitable for a
work-flow manager based implementation using the BPEL language.
The operations provided by this service are:
   •   GetCapabilities. This operation returns an XML document describing the server. It includes
       information like: server version, provider metadata, supported operations, available
       sensors.
       DescribeSensor.
       Depending on the kind of sensor different algorithms are followed:
           o   In case of sensor natively supported by a remote Programming service, the request
               is forwarded to it;
           o   In case the sensor is “virtual” i.e.: defined by the EO DAIL by assembling several
               native sensors (e.g.: “SPOT_image” regroups all SPOT satellites and sensors); then
               the description of the sensor is pre-configured and then it is returned by retrieving
               data from a local store.
       DescribeGetFeasibility. This operation returns the list of parameters to be set for issuing
       feasibility analysis requests towards specified satellite sensors.
       The current approach foresees a distributed management of programming parameters i.e.
       each programming service instance stores locally the list of programming parameters
       available for the sensors it manages. This is the same approach followed for GetOptions of
       the Order Service.

                                                     Pag. 118/182
                 Title:           Architectural Design Technical Note
                 Contract Ref.:   P-E190/DGIGSD-3556-05
                 Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                 Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

Then the operation is executed following these steps:
    o     call the GetRecords operation of Service Discovery specifying the provided
          satellites and sensors;
    o     the returned service metadata specifies the address of the programming services
          managing those satellites / sensors.
    o     invoke the found services calling the DescribeGetFeasibility operation
    o     return the found parameters.
In case of “virtual” sensors, the list of parameters is pre-configured and then it is returned by
retrieving data from a local store.
DescribeSubmit.
Same as previous one.
GetFeasibility. This operation returns the feasibility of the tasks specified within the
programming request.
Depending on the required feasibility level the operation is performed in different ways:
    o     Light / estimate feasibility analysis: the analysis is performed locally using a
          dedicated function.
    o     Full feasibility analysis: the request has to be forwarded to the remote GS which
          manages natively the sensor.
                  retrieve the address of Programming service in charge of natively manage
                  the satellite / sensor specified in the task (by querying the Service
                  Discovery).
                  call the GetFeasibility operation on the identified Programming service.
                  This task can be implemented by a BPEL process possibly helped by an
                  external module for regrouping the tasks and for storing the feasibilityID &
                  tasks in a local database.
The feasibilityID returned by the Programming service together the list of programming
parameters related to it are locally stored for being re-used later-on during Submit
operation.
In case of virtual sensor, a preliminary step for getting the native sensors behind the virtual
one is needed.
Submit.
The steps performed by this operation are:
    o     If the feasibilityID is specified:
                  Retrieve from the local storage the programming parameters and the
                  Programming service address related to that feasibilityID;
                  Update the task replacing the retrieved parameters to the feasibilityID
    o     Submit the task to the identified programming service.
    o     Store in a local database the tasks specified in the user request and the taskID
          returned by the remote Programming services.
    The remote programming services will receive always Submit requests specifying the
    parameters for tasking the sensor and not only the identifier. In this way the remote
    Programming services are not obliged to manage a database of feasibility requests.
In case of virtual sensors, a preliminary step for retrieving the list of native sensors behind
the virtual one is needed.
Similarly to the other operations, the Submit can be implemented using a BPEL workflow for
the execution of the main steps, and using some external module to regroup the tasks and
for accessing the feasibility database.
GetStatus. This operation returns the status of a previously submitted tasking request.


                                                 Pag. 119/182
                      Title:           Architectural Design Technical Note
                      Contract Ref.:   P-E190/DGIGSD-3556-05
                      Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                      Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

       It is implemented following the same approach followed for GetStatus of the Order
       Service.
   •   Cancel
       It is implemented following the same approach followed for Cancel of the Order Service.
   •   Update
       Because the tasking requests are handled by the remote Programming services, then the
       Update operation is forwarded to them.
   •   DescribeResultAccess
       The steps performed by this operation are:
           o   Get the Programming service managing the specified programming request by
               querying the local database by taskID;
           o   Forward the DescribeResultAccess operation to the retrieved Programming service.


Additionally, because the Programming Service instance in the DAIL is an asynchronous client for
remote GSs services, it has to implement also the following operations:
       GetFeasibilityResponse.
       This operation is called for sending the feasibility result to the DAIL.
       It is implemented following the same approach followed for GetQuotation of the Order
       Service.
       SubmitResponse. This operation is called for updating the status of a sub-order.
       It is implemented following the same approach followed for SubmitResponse of the Order
       Service.


6.2.2.11 Virtual FTP Service
The Virtual FTP Service component stores the product metadata sent by the remote Virtual FTP
Agents / harvested from remote servers hosted on partner ground segments; allows users to
search on this data and supports also the usual FTP commands for browsing directories.
The following figure shows the architectural decomposition of the Virtual FTP Service component.




                                                      Pag. 120/182
                      Title:              Architectural Design Technical Note
                      Contract Ref.:      P-E190/DGIGSD-3556-05
                      Int. Ref.:          P-E190/DGIGSD-0399-06                Issue:       1   Rev.:   7
                      Proj. Ref.:         HMA-DD-DAT-EN-001                    Date:            14/09/2007



                                                 User Management: IDP, PEP, PDP




                                                                     Authentication check

                                                                                   Authentication Check (via
                   Authentication Check (via                                             redirection)
                         redirection)

                                               Virtual FTP Service

                                                                                                               Virtual FTP
                       GetRecords /                          Virtual                    Transaction
  Virtual FTP         GetRecordById
                                                                                                               Agent (from
                                                            Catalogue                                            Ground
     Client
                                                             Service                    File Transfer          Segments)

                                                                                Product
                                                                               Metadata
                       FTP commands
                                                        Virtual File           Database
                                                         Service



                                                            Harvesting
                                                             Module




                                               Search & Retrieve
                                                                         FTP commands



                                                Catalogue                     FTP Server

                                    Figure 25: Virtual FTP Service architecture.


The Virtual FTP Service includes the following sub-components:
   •   Virtual Catalogue Service:
           1. it is the service allowing clients to issue catalogue searches via the [AD11] ICDs
              (GetRecords, GetRecordById operations);
           2. it allows remote Agents ingesting their product metadata via the [RD-32] ICDs
              (Transaction operation);
           3. supports the authentication mechanisms defined in the HMA UM architecture (§6.5,
              AD16).
   •   Product Metadata Database:
       It is the RDBMS in charge of storing product metadata and in charge of providing spatial
       indexing mechanisms to perform geographical searches on the data.
   •   Virtual File Service:
       Server implementing the FTP protocol for “emulating” browsing of directories without
       actually accessing the file system, but querying the product metadata database.
       This component, as the other services of this infrastructure, shall support authentication via
       Identity Provider.



                                                            Pag. 121/182
                        Title:           Architectural Design Technical Note
                        Contract Ref.:   P-E190/DGIGSD-3556-05
                        Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                        Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

          Product files are not locally stored, but are held by the remote Virtual FTP Agents, and then
          when a user asks to download a file, the Virtual File Service has to access the remote
          Agent where the file is held, get the file and at the same time send the data to the client.
      •   The Harvesting module is in charge of gathering metadata of on-line available products
          hosted by sites on which the Virtual FTP Agent is not installed.
          Two types of harvesting are supported:
          •   Harvesting from EO catalogues compliant with HMA Catalogue ICD.
              The Catalogue harvest component has to be deployed as a plug-in module in order to
              allow the support of additional catalogues beyond the predefined one.
          •   Harvesting from FTP sites: FTP directories are searches looking for files having names
              compliant with a configured rule. Then these names are stored in the database
              together the product metadata that can be extracted from them.
              This functionality is suitable when the file name of the product includes a sufficient
              amount of information (e.g. as in the Envisat case).




6.3       Services Implementation in partner Ground Segments
According the service instances definition performed in §6.1, the following services have to be
instantiated on the Ground Segments making part of the HMA infrastructure:
      •   Catalogue Service
      •   Programming Service;
      •   Order Service;
      •   User Management Service;
      •   On-line Data Access: FTP, WCS, WMS;


Additionally:
      •   some manual / automatic procedures for uploading on the EO DAIL the GSs supported
          collections & services have to be included.
      •   The Agent for GS making part of the Virtual FTP Service shall be deployed on the GS.


This document does not make any assumption and recommendation on how the services have to
be implemented on the GSs, but requires only that the GSs provide the listed services with the
defined functionalities (see next sub-sections) and complying with the defined interfaces ([AD11],
[AD05], [AD10] and user management ICD that will be defined in the next phase of the project).
From HMA perspective, the GSs are “black boxes”.


6.3.1     GS Catalogue Service Instance
This service instance provides catalogue functionalities for the owning GS:
      •   Storing of product metadata;
      •   Search and retrieval of product metadata;
From the HMA perspective it is an opaque building block managing the product metadata
catalogue of the owner GS.
It is called by the HM Catalogue Service Instance to serve the sub-catalogue searches derived by
the user catalogue search.
It implements the same protocol implemented by the HM Catalogue Service Instance ([AD11]),
then it has to provide the following operations:
      •   GetCapabilities

                                                        Pag. 122/182
                     Title:           Architectural Design Technical Note
                     Contract Ref.:   P-E190/DGIGSD-3556-05
                     Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                     Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

   •    GetRecords
   •    GetRecordById
   •    DescribeRecord


The interactions between this service instance and the other ones of the HMA infrastructure are
described in the §6.4.


6.3.2   GS Programming Service Instance
This service instance provides the functionalities for future products ordering of the owning GS:
   •    Management of programming options;
   •    Management of coverage and acquisition orders;
   •    Preparation of Technical and Financial proposal;
   •    Product delivery;
   •    Request monitoring.
From the HMA perspective it is an opaque building block providing above functions.
It is called by the HM Programming Service Instance to serve the sub-programming requests
derived by the user request.
It implements the same protocol implemented by the HM Programming Service Instance ([AD10]),
then it has to provide the following operations:

   •    GetCapabilities

   •    DescribeGetFeasibility

   •    DescribeSubmit

   •    GetFeasibility: the full feasibility analysis has to be implemented (light and estimate are
        managed by the HM Programming service instance.)

   •    Submit

   •    GetStatus

   •    Cancel

   •    Update

   •    DescribeResultAccess
The interactions between this service instance and the other ones of the HMA infrastructure are
described in the §6.4.


6.3.3   GS Order Service Instance
This service instance provides the functionalities for products ordering of the owning GS:
   •    Management of order options;
   •    Management of products orders;
   •    Preparation of Technical and Financial proposal;
   •    Product delivery;
   •    Order monitoring.
From the HMA perspective it is an opaque building block providing above functions.
It is called by the HM Service Instance to serve the sub-orders derived by the user order.


                                                     Pag. 123/182
                       Title:           Architectural Design Technical Note
                       Contract Ref.:   P-E190/DGIGSD-3556-05
                       Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                       Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

It implements the same protocol implemented by the HM Order Service Instance ([AD05]), then it
has to provide the following operations:

   •    GetCapabilities

   •    GetOptions

   •    GetQuotation

   •    Submit

   •    GetStatus

   •    Cancel

   •    DescribeResultAccess


The interactions between this service instance and the other ones of the HMA infrastructure are
described in the §6.4.


6.3.4   GS User Management Service Instance
The User Management architecture, including EO DAIL and GS side, is not finalized yet.
The main concepts and mechanisms are summarized in section 6.5.


6.3.5   FTP
In order to allow the following ODA scenarios ([AD16]):
   •    On-line collections
   •    On-line access
the ground segments shall provide a FTP server.
For the first scenario, a server without any authentication check is sufficient. For the other a server
checking against user credential, following the User Management architecture defined in HMA,
has to be provided instead.


6.3.6   WMS & WCS
In order to support the On-line Consumption scenario the ground segment shall provide either a
WCS or WMS service.


6.3.7   GS Service & Collections Registration
The GSs have to be provided with automatic / manual procedures for uploading or to allow the
harvesting of their collections and services on the UDDI Registry, Collection Discovery Server and
Service Discovery Server of the EO DAIL.


6.3.8   Virtual FTP Service Agents
For populating the Virtual FTP Service catalogue hosted at the EO DAIL the ground segment shall
host the Virtual FTP Agent component.
In detail, the functions provided by the Virtual FTP Agent component are [AD16]:
   •    Product Metadata extractor:



                                                       Pag. 124/182
                        Title:           Architectural Design Technical Note
                        Contract Ref.:   P-E190/DGIGSD-3556-05
                        Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                        Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

          The Agent parses the product files for extracting the most important metadata attributes to
          send to the Virtual FTP Service. Due to the number of different product file formats this
          function is the most complex.
      •   FTP server:
          The Agent allows the users to download products. It is accomplished via FTP protocol.


During the component start-up the following steps are performed:
      •   checking whether new files are present in the shared directories (configuration
          parameter); whenever a new file is found:
              o   the file is parsed for getting the relevant metadata (see next paragraph);
              o   file name, size and last modification date, and all extracted metadata are stored
                  in a local table;
      •   authentication for accessing the Virtual FTP Service via the corresponding Identity Provider;
      •   sending metadata of all shared files to the Virtual FTP Service via calling the Transaction
          operation.


After the Agent start-up has been completed, its files become public and then the users can find
them querying the Virtual FTP Service.
When a client requires downloading a file, the following steps are performed:
      •   the client has to send its authentication information for checking the identity.
      •   upon successful verification of user identity and user authorizations, the download can be
          started.



6.4       Dynamical Model
This section describes the interactions occurring between the services instances at both HM and
GS level to perform the main activities of HMA:
      •   Collection & Service Registration
      •   Catalogue Search
      •   Product Ordering
      •   Programming Requests
      •   On-line Data Access
Because the HM instances have been all allocated to the EO DAIL (§6.1.1), then whenever an HM
instance is involved in the following diagrams, it means that the EO DAIL is involved in the
interaction.


6.4.1     Collections & Services

6.4.1.1    Push approach
The following sequence diagram outlines the steps followed by a remote operator to publish the
collections, human readable services, web services provided by the ground segment.




                                                        Pag. 125/182
                                Title:               Architectural Design Technical Note
                                Contract Ref.:       P-E190/DGIGSD-3556-05
                                Int. Ref.:           P-E190/DGIGSD-0399-06                            Issue:       1     Rev.:     7
                                Proj. Ref.:          HMA-DD-DAT-EN-001                                Date:              14/09/2007




          : HM Collection Discovery           : HM Service Discovery            : HM Service Configuration
              Service Instance                   Service Instance               Discovery Service Instance
                                                                                                                                       : GS O perator

                                                                                                                1: publishing( )


                                                                                            2: Transaction( )




                                                                       3: Transaction( )




                        Figure 26: Collections and services registration from remote GS operators.


Collection and Service Discovery service instances are compliant with the [AD17] and then the
new metadata records can be uploaded via the Transaction operation.
The Transaction operation allows also updating and deleting previously loaded metadata
records.
In case of the Service Configuration Discovery instance the registration of new services is
performed by the publishing operation.


6.4.1.2      Pull approach
Alternative approach for populating the HM Collection and Service Discovery services.

                       : HM Collection Discovery            : HM Service Discovery                               GS Collection /
                           Service Instance                    Service Instance                                 Service Catalogue
                                      1: Harvest

                                                                   2: data retrieval




                                                                          3: Harvest

                                                                                           4: data retrieval




                                      Figure 27: Harvesting of Collection & Service metadata.


The activation of Harvest operation starts the retrieval of data form GSs. The retrieval of data can
be accomplished in different ways depending on the GSs. In fact in case the data is held in a
[AD17] catalogue, then it can be retrieved by calling GetRecords and GetRecordById operation.
To avoid that the whole data is extracted from the remote GSs at each activation, the following
approach can be followed:
    •      On HM side the last successful harvest date is stored for each GSs to be harvested;




                                                                          Pag. 126/182
                                  Title:                   Architectural Design Technical Note
                                  Contract Ref.:           P-E190/DGIGSD-3556-05
                                  Int. Ref.:               P-E190/DGIGSD-0399-06                                Issue:     1    Rev.:         7
                                  Proj. Ref.:              HMA-DD-DAT-EN-001                                    Date:           14/09/2007

   •      On GS side, for each Collection / Service metadata the last update date has to be stored
          and it has to be made available as query able property. The items cancelled do not have
          to be actually cancelled but flagged as deleted.
   •      When the Harvest operation is activated, all collection / services that have been updated
          after the last harvesting date are retrieved;
   •      The received data is stored in the Collection / Service Discovery server.


In case a GS collection / service catalogue is off-line it implies a possible mis-alignment only for the
time between two successive Harvesting activations. In fact at the next activation all the data
that has been updated after the last successful harvest is extracted.


6.4.2     Catalogue Search
In this section the whole scenario for performing a catalogue search is performed: from the
discovery of the collections to the issue of the catalogue searches.


                            : HM Co llection Dis covery      : HM Catalogue             : HM Service Dis covery          GS1 : GS Catalogue       GSn : GS Catalogue
                                Service Ins tance            Service Instance              Service Ins tance              Service Instance         Service Ins tance
        : W eb Service
            Client


                    1: GetRecords ( )



                   2: GetRecordById( )

                     optionally

                                                                       T o unde rs tand the c at alogue s e rve r
                                   3: GetRec ords ( )                  ma naging the s pe cified c olle ction

                                                                           4: GetRecords ( )


                                                                                            5: Ge tRecords( )


                                                                                                            6: GetRecords( )



                                  7: GetRecordById( )

                                                                           8: GetRecords ( )


                                                                                          9: GetRecordById( )


                                                                                The record is retrieved by one
                                                                                catalogue only




                                                        Figure 28: Catalogue search scenario.


   •      The client gets the list of available collections performing a search on the HM Collection
          Discovery instance (step 1). Optionally the full details of the collection are retrieved (step
          2).
   •      Once selected the collection(s) of interest, a catalogue search is performed against the
          HM Catalogue instance (step 3).
   •      The HM Service Discovery is queried to understand the catalogue servers in charge of
          managing the specified collections (step 4).
          Once understood the catalogue servers to query, the search is split in several sub-searches
          natively supported by the identified catalogue servers. Then the sub-searches are sent in
          parallel to the identified catalogues and then the results are sent back to the client (steps

                                                                                Pag. 127/182
                             Title:              Architectural Design Technical Note
                             Contract Ref.:      P-E190/DGIGSD-3556-05
                             Int. Ref.:          P-E190/DGIGSD-0399-06              Issue:    1     Rev.:     7
                             Proj. Ref.:         HMA-DD-DAT-EN-001                  Date:           14/09/2007

          5 & 6). Because the complete result can be built when all responses are received, then the
          search time is limited by the slower catalogue. To avoid waiting too long, a configurable
          time out for waiting for results is specified. If some catalogues do not provide responses
          within the time out, the overall response is flagged as “partial”.
   •      For some of the found records the client requires the details (step 7). The split process is
          performed again (steps 8 and 9). Because the GetRecordById retrieves only one record,
          then only one GS is queried.


6.4.3     Ordering
The ordering service is in charge of allowing the user to submit product orders and to subscribe
subscriptions. For both activities the same operations are used, the distinction is performed at
order item level: in the first case the identifier of the product and also the collection owning the
product have to be specified; in the second case only the collection (that represents the
subscription) has to be specified.
Because dataset collections and subscriptions are modelled with the same metadata and are
held in the same service (Collection Discovery Service).
The following figure summarizes the differences either for submitting a product order o for
subscribing a subscription.




                                      : HM Collection Discovery                  : HM Catalogue               : HM Order
        : Web Service                     Service Instance                       Service Instance           Service Instance
            Client
                        1: GetRecords( )
                                                            Mandatory for
                                                            sub scriptions                          only fo r product
                    2: GetRecordById( )                                                             ordering


                                              3: GetRecords( )

                                            4: GetRecordById( )


                                                          5: GetOptions( )


                                                         6: GetQuotation( )

                                                            7: Submit( )


                                                           8: GetStatus( )


                                                            9: Cancel( )




                                      Figure 29: Order submission / subscription scenario.



                                                                  Pag. 128/182
                         Title:                Architectural Design Technical Note
                         Contract Ref.:        P-E190/DGIGSD-3556-05
                         Int. Ref.:            P-E190/DGIGSD-0399-06             Issue:   1   Rev.:     7
                         Proj. Ref.:           HMA-DD-DAT-EN-001                 Date:        14/09/2007

The first 2 steps are common: the collection discovery has to be queried for finding either the
dataset collections / subscriptions of interest.
The access to the catalogue is necessary only for product ordering because the items to order
have to be identified.
Once the collections to subscribe / products to order have been selected, the ordering options
are retrieved. For product orders they allow to specify the processing level, the format, etc.; in
case of subscriptions they allow e.g. to specify a sub-area, the expiration date, how the area has
to be covered, etc.
The Submit allows ordering products / adhering the subscription.
The GetStatus allows to get the status of ordered products / to check whether the subscription is
still active.
The Cancel can be called for cancelling a products order / to unsubscribe.
In the following sub-sections the different operations are explained more in depth.

6.4.3.1     Get Options scenario
The following scenario describes the steps followed for providing the client the order options for
the required product.



                                          : HM Order                : HM Service Discovery              : GS Order
        : Web Service                   Service Instance               Service Instance               Service Instance
           Client
                    1: GetOptions( )

                                                         2: GetRecords( )

                              3: understand the Order Service to call
             One ProductType
             a time
                                                                      4: GetOptions( )




                                      No local storage
                                      of order options

                                              Figure 30: Get Options Scenario.


The design decision behind this scenario is that the order options are not centralised in the HM
Order Service instance, but are distributed between the different provider Ground Segments.

    •     The client asks order options for one specific collection specifying also optionally the
          product identifier;

    •     The HM Order Service instance retrieves from the HM Service Discovery Service Instance
          the information about the service allowing to order that specific product / collection;

    •     The order options are asked to the right provider and then returned back to the client.
          Because in this scenario the HM instance works as a “router” of requests, then no counter
          measures can be undertaken in case the remote order services is off-line.




                                                               Pag. 129/182
                                Title:                  Architectural Design Technical Note
                                Contract Ref.:          P-E190/DGIGSD-3556-05
                                Int. Ref.:              P-E190/DGIGSD-0399-06                            Issue:     1    Rev.:   7
                                Proj. Ref.:             HMA-DD-DAT-EN-001                                Date:           14/09/2007

6.4.3.2     Get Quotation scenario
This scenario explains the steps performed by the different service instances to quote the order
specified by the client.


                                                 : HM Order                : HM Service Discovery           GS 1 : GS Order      GS N : GS Order
                                               Service Instance               Service Instance              Service Instance     Service Instance
        : Web Service
           Client
                         1: GetQuotation( )

                  A global quotation                           2: GetRecords( )
                  identifier is returned back
                                          3: understand the Order Service to call

                                                                             4: GetQuotation( )

                                                               A quotation identifier is
                                                               returned back

                                                                                           5: GetQuotation( )

                                                                             A quotation identifier is
                                                                             returned back
                                                                        6: GetQuotationResponse( )



                                                                                     7: GetQuotationResponse( )


                         8: GetQuotation( )

                    GetQuotation by
                    monitoring




                                                     Figure 31: Get Quotation Scenario.



    •     The client has prepared an order for precisely identified items / subscription. Before
          submitting the order, it asks the quotation;

    •     The HM Order Service instance retrieves from the HM Service Discovery Service Instance
          the information about the order services allowing to order all the items specified in the
          order;

    •     The input order is split into different sub-orders each regrouping all items that can be
          managed by a single provider GS;

    •     The different identified GSs are asked for the quotation of the different sub-orders.

    •     Each GS returns back an identifier of the received quotation request. All quotation
          identifiers are put together and sent to the client.

          Because the quotation identifiers can be re-used for order submission, then the transaction
          tracking data shall store the user order, the different sub-orders and the quotation identifier
          linked to each of them.

          In case of failure / off-line of some GSs, the response is flagged as partial and the error
          message specifies the items the quotation have been failed.

    •     The different GSs send back the quotations to the HM Order Service instance calling the
          asynchronous call-back operation.

                                                                             Pag. 130/182
                                Title:                 Architectural Design Technical Note
                                Contract Ref.:         P-E190/DGIGSD-3556-05
                                Int. Ref.:             P-E190/DGIGSD-0399-06                            Issue:    1   Rev.:    7
                                Proj. Ref.:            HMA-DD-DAT-EN-001                                Date:         14/09/2007

    •      When all quotations have been received, several options are possible:

                o       If the client specified asynchronous quotation, the client is notified by calling the
                        call-back operation;

                o       If the client specified no notification, then the client has to monitor the status of the
                        quotation by calling again GetQuotation operation specifying the quotationId
                        received by the first call.



6.4.3.3      Submit scenario
This scenario explains the steps performed by the different service instances when an order is
submitted by the client.

                                           : HM Order             : HM Service Discovery                GS 1 : GS Order       GS N : GS Order
                                         Service Instance            Service Instance                   Service Instance      Service Instance
        : Web Service
           Client
                         1: Submit( )

                                                       2: GetRecords( )

                                3: understand the Order Service to call



                                                                          4: Submit( )


                                                                                         5: Submit( )




                                                            Figure 32: Submit Scenario.

    •      The client has prepared an order for precisely identified items / subscription. Before
           submitting the order, it has also asked the quotation; the quotation has been accepted
           and then the order is submitted.

    •      The order can be submitted either sending again all information or sending the quotation
           identifiers received by GetQuotation. GetQuotation returns the quotation identifiers of all
           sub-orders sent to the GSs. When the order is submitted the client can specify all quotation
           identifiers or a sub-set of them (the ones whose quotation is accepted).

    •      In case the order is submitted specifying all parameters then:

                o       The HM Order Service instance retrieves from the HM Service Discovery Service
                        Instance the information about the order services allowing to order all the items
                        specified in the order.

                o       The input order is split into different sub-orders each regrouping all items that can
                        be managed by a single provider;

                o       The split sub-orders are sent to different GSs identified in the second step.

    •      In case the order is submitted specifying a list of quotation identifiers:

                o       The transaction tracking data is accessed for retrieving the already split sob-orders;

                o       The sub-orders are submitted to the GSs.


                                                                            Pag. 131/182
                         Title:              Architectural Design Technical Note
                         Contract Ref.:      P-E190/DGIGSD-3556-05
                         Int. Ref.:          P-E190/DGIGSD-0399-06             Issue:      1   Rev.:       7
                         Proj. Ref.:         HMA-DD-DAT-EN-001                 Date:           14/09/2007

    •     Each provider GS creates and returns back the identifier of the sub-order that has been
          submitted to it. These identifiers are included in the order information stored in the
          transaction tracking data.

    •     The HM Order Service instance creates and returns back to the client the identifier of the
          whole order. Internally it has to manage the link between the “Client Order” and the
          different “Sub Orders”.

In case the submission towards some GSs fails because the service is off-line, then this event is set
in the order information stored in the transaction tracking data.

A dedicated process / thread within the order service periodically checks these items for trying a
re-submission of the sub-order. If after a configurable number of retries the problem still occurs the
sub-order is flagged as failed.

If during the retry phase the GetStatus is activated, the related GS is not called and the initial
order status is returned (BeingQuoted) status is returned. When the order is flagged as failed, it is
returned as failed by the GetStatus as well.


6.4.3.4    Status notification scenario
This scenario describes the update of the status of the order managed by the HM Order Service
Instance.



              GS 1 : GS Order                     GS N : GS Order                         : HM Order
              Service Instance                    Service Instance                      Service Instance

                                                                 1: SubmitResponse( )

                                                                                          2: update order status




                                                 3: SubmitResponse( )

                                                                                          4: update order status




                                          Figure 33: Status notification scenario.

    •     Whenever a sub-order processed by a GS order service instance changes its status and
          depending also on the value specified for status notification during order submission, the
          HM Order Service Instance is notified through the SubmitResponse operation.

    •     The SubmitResponse is called specifying the identifier of the sub-order, and then the HM
          Order Service Instance has to retrieve the original order submitted by the client and then
          has to update the status of items specified in the notification.
In case the HM Order service is off-line, the GSs have to retry the activation of this operation.




                                                            Pag. 132/182
                            Title:               Architectural Design Technical Note
                            Contract Ref.:       P-E190/DGIGSD-3556-05
                            Int. Ref.:           P-E190/DGIGSD-0399-06                Issue:   1   Rev.:      7
                            Proj. Ref.:          HMA-DD-DAT-EN-001                    Date:        14/09/2007

6.4.3.5     Get Status scenario
This scenario explains the steps performed by the different service instances when the client asks
the status of previously submitted orders.



                                            : HM Order                 GS 1 : GS Order                     GS N : GS Order
        : Web Service                     Service Instance             Service Instance                    Service Instance
           Client

                        1: GetStatus( )


             2: retrieve the order (and sub-orders); understand the order services to call


                                                         3: GetStatus( )




                                                                           4: GetStatus( )




                                                Figure 34: Get Status Scenario.


Because in the order submission the amount of status notifications can be specified (None, All,
notification at order completion), then the HM instance does not always know the status of the
user order. Then the status of the order is built by asking the remote GS order service instances.
Then the steps are the following:

    •     The HM Order Service instance retrieves the identifiers of the sub-orders linked to the order
          to get the status.

    •     For each sub-order a GetStatus request is sent to the corresponding GS. The received
          statuses are put together and sent back to the client.
In case some GSs are off-line, the status of the corresponding items is set as unknown.


6.4.3.6     Cancel scenario
This scenario explains the steps performed by the different service instances when the client asks
the cancellation of a previously submitted order.




                                                                Pag. 133/182
                      Title:             Architectural Design Technical Note
                      Contract Ref.:     P-E190/DGIGSD-3556-05
                      Int. Ref.:         P-E190/DGIGSD-0399-06             Issue:    1   Rev.:   7
                      Proj. Ref.:        HMA-DD-DAT-EN-001                 Date:         14/09/2007




                                      : HM Order               GS 1 : GS Order               GS N : GS Order
    : Web Service                   Service Instance           Service Instance              Service Instance
       Client

                    1: Cancel( )



            2: retrieve order (with sub-orders); understand order services to call


                                                   3: Cancel( )


                                                                  4: Cancel( )




                                           Figure 35: Cancel Scenario.

•     The client requires the cancellation of a specific order.

•     The HM Order Service instance retrieves the identifiers of the sub-orders linked to the order
      to be cancelled.

•     For each sub-order a cancellation request is sent to the corresponding provider.

      If the GSs reply with success to the cancellation of the sub-orders, then the whole
      cancellation is set successful.

      If some GSs reply with failure / partial then the whole cancellation is partial.

      If all GSs reply with failure then the whole cancellation is failure.

      If some GSs are off-line, then this event is flagged in the order information within transaction
      tracking data. A dedicated process / thread within the order service periodically checks
      these items for re-trying the cancellation of the sub-order.




                                                        Pag. 134/182
                            Title:                       Architectural Design Technical Note
                            Contract Ref.:               P-E190/DGIGSD-3556-05
                            Int. Ref.:                   P-E190/DGIGSD-0399-06                            Issue:       1   Rev.:      7
                            Proj. Ref.:                  HMA-DD-DAT-EN-001                                Date:            14/09/2007

6.4.3.7 Retrieval of on-line available data scenario


                                                                : HM Order                          : GS Order                : GS Order
                                                              Service Ins tance                  Service Ins tance         Service Ins tance
               : W eb Service
                   Client
                                         1: Submit( )

                                                                                  2: Submit( )

                                                                                                 3: Submit( )


                                                                           4: SubmitRes pons e( )

                                                                                           5: SubmitRes pons e( )

                                   6: Submit Res pons e ( )



                                7: Des cribeRes ultAcc es s ( )

                                                                        8: Des cribeRes ultA cces s ( )

                                                                                        9: DescribeRes ultAcces s( )



                                                        10: FTP download


                                                                     11: W CS acces s




                                     Figure 36: Retrieval of on-line available data scenario.

    •     The initial steps for preparing the order are not considered in this scenario.

    •     An order with on-line delivery is prepared and submitted by the client asking final
          asynchronous notification.

    •     When all providers had made available the data the SubmitResponse of the HM Order
          Service Instance is called.

    •     The HM Order Service Instance notifies the client by calling the SubmitResponse operation
          of it.

    •     The client can access the data by calling the DescribeResultAccess operation.

    •     Depending on the selected delivery method, the client can download the data via FTP or
          can interact with it by using the WCS protocol, etc.




6.4.4     Programming

6.4.4.1    DescribeGetFeasibility scenario
The following scenario describes the steps followed for providing the client the programming
parameters for the required sensors.




                                                                             Pag. 135/182
                                Title:                 Architectural Design Technical Note
                                Contract Ref.:         P-E190/DGIGSD-3556-05
                                Int. Ref.:             P-E190/DGIGSD-0399-06                           Issue:   1      Rev.:   7
                                Proj. Ref.:            HMA-DD-DAT-EN-001                               Date:           14/09/2007




                                 : HM Programming              : HM Service Discovery          GS 1 : GS Programming      GS N : GS Programming
        : Web Service
                                   Service Instance               Service Instance                Service Instance           Service Instance
           Client

               1: DescribeGetFeasibility( )

                                                 2: GetRecords( )

                                    3: understand GS to call


                                                               4: DescribeGetFeasibility( )


                                                                              5: DescribeGetFeasibility( )




                                              Figure 37: DescribeGetFeasibility scenario.
The scenario highlights that programming parameters are not centralized in the HM Programming
Service instance, but are distributed between the different providers.

    •     The client asks programming parameters for one sensor;

    •     The HM Programming Service instance retrieves the information about the programming
          service able to manage the required sensor;

    •     The programming parameters are asked to the right providers and then returned back to
          the client.
In case some of the remote Programming services are off-line the parameters of the
corresponding sensors are not included in the answer.

6.4.4.2     Get Feasibility scenario
This scenario explains the steps performed by the different service instances to verify the feasibility
of the programming request.
Two options are possible depending on the required level of feasibility analysis:
    •     light and estimate feasibility analysis are performed by the HM Programming service itself;
    •     full feasibility analysis is performed calling the remote GS.

6.4.4.2.1 Light / estimate feasibility




                                                                              Pag. 136/182
                          Title:               Architectural Design Technical Note
                          Contract Ref.:       P-E190/DGIGSD-3556-05
                          Int. Ref.:           P-E190/DGIGSD-0399-06                    Issue:     1       Rev.:   7
                          Proj. Ref.:          HMA-DD-DAT-EN-001                        Date:              14/09/2007




                                                              : HM Programming
                                   : Web Service                Service Instance
                                       Client

                                              1: GetFeasibility( )




                                                   2: GetFeasibility() by calling the feasibility server




                                   Figure 38: GetFeasibility – light / estimate feasibility.

    •    The client prepares a programming request which includes only one task.

    •    The client issues a feasibility analysis request (GetFeasibility) asking light / estimate feasibility
         level.

    •    The HM Programming Service instance performs the analysis without calling the GS, but
         using the feasibility server deployed at HM level.



6.4.4.2.2 Full feasibility



                                     : HM Programming                : HM Service Discovery            GS 1 : GS Programming
        : Web Service                  Service Instance                 Service Instance                  Service Instance
           Client

                   1: GetFeasibility( )

                                                     2: GetRecords( )



                          3: understand the Programming Service to call

                                                                       4: GetFeasibility( )


                                                                 5: GetFeasibilityResponse( )

               6: GetFeasibilityResponse( )




                                    Figure 39: Get Feasibility Scenario – Full feasibility.

                                                                 Pag. 137/182
                            Title:                Architectural Design Technical Note
                            Contract Ref.:        P-E190/DGIGSD-3556-05
                            Int. Ref.:            P-E190/DGIGSD-0399-06                       Issue:   1   Rev.:   7
                            Proj. Ref.:           HMA-DD-DAT-EN-001                           Date:        14/09/2007

    •      The client prepares a programming request which includes only one task, but can be
           accomplished using one between many sensors.

    •      The client issues a feasibility analysis request (GetFeasibility) asking Full feasibility level.

    •      The HM Programming Service instance retrieves the information about the programming
           service able to manage the specified sensors; the best candidate is selected.

    •      The GetFeasibility is sent to programming service discovered at the previous step.

    •      The acknowledgement provided by the GS programming service is gathered and sent
           back to the client.

    •      The feasibility analysis is sent back to the HM instance by calling the GetFeasibilityResponse
           operation.

    •      The feasibilityID returned by the programming service together the list of programming
           parameters related to it are locally stored for being re-used later-on during Submit
           operation.

    •      The feasibility analysis is sent to the client via calling the GetFeasibilityResponse call-back
           operation.




6.4.4.3      Submit scenario
This scenario explains the steps performed by the different service instances when a programming
request is submitted by the client.


                                          : HM Programming            : HM Service Discovery               GS 1 : GS Programming
                                            Service Instance             Service Instance                     Service Instance
          : Web Service
              Client

                          1: Submit( )

                                     2: access cached feasibility responses

                                                          3: GetRe cords ( )

                               4: understand Programming Services to call

                                                                               5: Submit( )




                                                    Figure 40: Submit Scenario.

    •      The client has prepared a programming request including either a task that has been
           analysed, and then it is provided by specifying only the feasibilityID, or including a new
           task that will be submitted specifying all parameters.

    •      In case the task is specified by the feasibilityID, the HM Programming Service instance
           retrieves the parameters that have been previously locally stored in the transaction
           tracking data by the GetFeasibility operation.


                                                                   Pag. 138/182
                        Title:                Architectural Design Technical Note
                        Contract Ref.:        P-E190/DGIGSD-3556-05
                        Int. Ref.:            P-E190/DGIGSD-0399-06              Issue:   1   Rev.:   7
                        Proj. Ref.:           HMA-DD-DAT-EN-001                  Date:        14/09/2007

    •     In case the task is specified by parameters, the HM Programming Service instance retrieves
          the GS Programming Service which matches the input parameters and the task is
          submitted to it.

    •     The GS Programming service returns back the taskID related to the submitted request and
          the HM returns it back to the client.

    •     The HM instance stores the taskID with the related programming parameters in the local
          database.




6.4.4.4    Get Status scenario
This scenario explains the steps performed by the different service instances when the client asks
the status of previously submitted programming requests.



                                                    : HM Programming          GS 1 : GS Programming
                   : Web Service                      Service Instance           Service Instance
                      Client

                                      1: GetStatus( )


                      2: retrieve the programming request; understand the programming service to call


                                                                    3: GetStatus( )




                                              Figure 41: Get Status Scenario.


Then the steps are the following:

    •     The HM Programming Service instance retrieves the address of the Programming service
          who received the task specified in the input parameter.

    •     the GetStatus request is sent to the corresponding GS. The received status is sent back to
          the client.




                                                              Pag. 139/182
                        Title:                  Architectural Design Technical Note
                        Contract Ref.:          P-E190/DGIGSD-3556-05
                        Int. Ref.:              P-E190/DGIGSD-0399-06                Issue:        1   Rev.:   7
                        Proj. Ref.:             HMA-DD-DAT-EN-001                    Date:             14/09/2007

6.4.4.5    Cancel Programming scenario
This scenario explains the steps performed by the different service instances when the client asks
the cancellation of a previously submitted programming request.




                                          : HM Programming                            GS : GS Programming
                 : Web Service
                    Client                  Service Instance                            Service Instance


                                 1: Cancel( )


                                                  2: retrieve information about the input taskID

                                                                     3: Cancel( )




                                                 Figure 42: Cancel Scenario.

    •     The client asks the cancellation of a specified task providing the taskID;

    •     The HM instance retrieves the data related to that task by accessing the local database. In
          this way it is possible to find the Programming service that is actually managing the task.

    •     The found Programming service is asked for cancelling that task.


6.4.4.6    Status notification scenario
This scenario describes the update of the programming requests handled by the HM Programming
Service Instance upon notification form the GSs.

                         GS 1 : GS Programming
                            Service Instance                                    : HM Programming
                                                                                  Service Instance


                                                      1: SubmitResponse( )




                                         Figure 43: Status notification scenario.

    •     Whenever a status update occurs on the GS Programming instance for a previously
          submitted task, the HM instance is notified by the activation of the SubmitResponse
          operation. In the activation the taskID and the new status are specified.

    •     The HM instance updates the local database updating the status of the task within the
          programming request.




                                                                Pag. 140/182
                        Title:             Architectural Design Technical Note
                        Contract Ref.:     P-E190/DGIGSD-3556-05
                        Int. Ref.:         P-E190/DGIGSD-0399-06               Issue:    1   Rev.:   7
                        Proj. Ref.:        HMA-DD-DAT-EN-001                   Date:         14/09/2007

6.4.4.7    DescribeResultAccess scenario
This scenario explains the interactions occurring between the different service instances when the
client calls the DescribeResultAccess operation.




                 : Web Service               : HM Programming                  GS : GS Programming
                    Client                     Service Instance                  Service Instance


                         1: DescribeResultAccess( )


                                                  2: retrieve information about the input taskID


                                                          3: DescribeResultAccess( )




                                      Figure 44: DescribeResultAccess scenario.

    •     In case the delivery has not been specified during the submission, the client has to call the
          DescribeAccessResult operation to find the address of the service allowing accessing the
          data acquired by the programming request.

    •     The HM instance retrieves the data related to the taskID specified in the input parameter
          and then forwards the request to the delegated instance that managed the programming
          request.


6.4.5     On-line Data Access Scenarios
This section describes the on-line data access scenario analysed in [AD16].




                                                          Pag. 141/182
                            Title:                Architectural Design Technical Note
                            Contract Ref.:        P-E190/DGIGSD-3556-05
                            Int. Ref.:            P-E190/DGIGSD-0399-06                 Issue:    1   Rev.:   7
                            Proj. Ref.:           HMA-DD-DAT-EN-001                     Date:         14/09/2007

6.4.5.1     On-line Collection



                             : HM Collection Discovery         : HM Catalogue           GS : GS Catalogue         GS : GS FTP
                                 Service Instance              Service Instance          Service Instance
        : Web Service
           Client
                    1: GetRecords( )


                                     2: GetRecords( )

                                                                             3: GetRecords( )



                                4: GetRecordById( )

                                                                            5: GetRecordById( )


                                                              6: get file

                                                             7: download




                                              Figure 45: On-line Collection scenario.


    •     The client gets the list of available collections performing a search on the HM Collection
          Discovery instance (step 1). Optionally the full details of the collection are retrieved (not
          shown).
    •     Once selected the collection(s) of interest, a catalogue search is performed against the
          HM Catalogue instance (step 2).
    •     HM Catalogue Service forwards the search to the right GS Catalogue Server (step 3).
    •     For getting the URL, the details of the products are required (GetRecordById, steps 4 & 5).
    •     Once the product URL is available, then the download can be started via a FTP client
          (steps 6 & 7).




                                                                  Pag. 142/182
                           Title:               Architectural Design Technical Note
                           Contract Ref.:       P-E190/DGIGSD-3556-05
                           Int. Ref.:           P-E190/DGIGSD-0399-06                  Issue:   1   Rev.:    7
                           Proj. Ref.:          HMA-DD-DAT-EN-001                      Date:        14/09/2007

6.4.5.2     On-line Access



                             : HM Collection Discovery              : HM Catalogue          : HM Order           GS : GS FTP
                                 Service Instance                   Service Instance      Service Instance
        : Web Service
           Client
                    1: GetRecords( )


                                     2: GetRecords( )




                                    3: GetRecordById( )


                                                4: GetOptions( )


                                               5: GetQuotation( )

                                                  6: Submit( )

                                             7: SubmitResponse( )

                                          8: DescribeResultAccess( )


                                                             9: get file

                                                           10: download




                                              Figure 46: On-line Access Scenario.


    •     The client gets the list of available collections performing a search on the HM Collection
          Discovery instance (step 1). Optionally the full details of the collection are retrieved (not
          shown).
    •     Once selected the collection(s) of interest, a catalogue search is performed against the
          HM Catalogue instance (step 2). The redirection towards the GS is not shown.
    •     Get optionally details of the product (step 3). The redirection towards the GS is not shown.
    •     In this scenario the products cannot be accessed directly from the catalogue, but an
          order with on-line delivery has to be issued, then:
               o   Get order options for the selected product (step 4).
               o   Prepare the order selecting the needed processing and delivery options. Note that
                   this scenario is applicable for on-line deliveryMethod (i.e. FTP).
               o   If supported by the GS then ask order quotation (step 5).
               o   Submit the order possibly referencing the quotation identifier got at previous step
                   (step 6). In this scenario the order completion is notified by the activation of
                   SubmitResponse operation.

                                                                   Pag. 143/182
                           Title:               Architectural Design Technical Note
                           Contract Ref.:       P-E190/DGIGSD-3556-05
                           Int. Ref.:           P-E190/DGIGSD-0399-06                  Issue:   1   Rev.:   7
                           Proj. Ref.:          HMA-DD-DAT-EN-001                      Date:        14/09/2007

               o   When the order has been completed by the GS (the ordered products have been
                   put on the FTP server), the SubmitResponse operation of the client is called (step 7).
               o   When the order has been completed the client gets the URL of products by calling
                   the DescribeResultAccess operation (step 8).
               o   Step 9 & 10 the ordered products are downloaded by the client using the URLs
                   returned by the previous call.


Interactions with User Management infrastructure components are not showed in the diagram
(the access to ordering service and the product download are commonly restricted.)


6.4.5.3     On-line Consumption
Same as the previous one, but the product is not downloaded locally but it is used from remote
via the WMS or WCS protocol.




                             : HM Collection Discovery              : HM Catalogue         : HM Order            : GS WCS
                                 Service Instance                   Service Instance     Service Instance
        : Web Service
           Client
                    1: GetRecords( )


                                     2: GetRecords( )




                                    3: GetRecordById( )


                                                4: GetOptions( )


                                               5: GetQuotation( )

                                                  6: Submit( )

                                             7: SubmitResponse( )

                                          8: DescribeResultAccess( )


                                                          9: GetCoverage( )




                                          Figure 47: On-line Consumption scenario.


    •     The client gets the list of available collections performing a search on the HM Collection
          Discovery instance (step 1). Optionally the full details of the collection are retrieved (not
          shown).

                                                                   Pag. 144/182
                     Title:           Architectural Design Technical Note
                     Contract Ref.:   P-E190/DGIGSD-3556-05
                     Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                     Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

   •   Once selected the collection(s) of interest, a catalogue search is performed against the
       HM Catalogue instance (step 2). The redirection towards the GS is not shown.
   •   Get optionally details of the product (step 3). The redirection towards the GS is not shown.
   •   In this scenario the products cannot be accessed directly from the catalogue, but an
       order with on-line delivery has to be issued, then:
          o   Get order options for the selected product (step 4).
          o   Prepare the order selecting the needed processing and delivery options. Note that
              this scenario is applicable for on-line consumption deliveryMethod (i.e. WCS, WMS).
          o   If supported by the GS ask order quotation (step 5).
          o   Submit the order possibly referencing the quotation identifier got at previous step
              (step 6). In this scenario the order completion is notified by the activation of
              SubmitResponse operation.
          o   When the order has been completed by the GS (the ordered products have been
              put on the WCS / WMS server), the SubmitResponse operation of the client is called
              (step 7).
          o   When the order has been completed the client gets the URL of products by calling
              the DescribeResultAccess operation (step 8).
          o   Once the URL for using the product is available, then the client can use the
              product via the WCS / WMS protocol.


Interactions with User Management infrastructure components are not showed in the diagram
(the access to ordering service, WCS / WMS are commonly restricted.)




                                                     Pag. 145/182
                              Title:             Architectural Design Technical Note
                              Contract Ref.:     P-E190/DGIGSD-3556-05
                              Int. Ref.:         P-E190/DGIGSD-0399-06              Issue:       1   Rev.:     7
                              Proj. Ref.:        HMA-DD-DAT-EN-001                  Date:            14/09/2007

6.4.5.4       Virtual FTP Service


                                                : Virtual FTP                GS1 : Virtual                   GS N : Virtual
                                                   Service                    FTP Agent                       FTP Agent

          : Web Service
             Client                                                                 1: Startup

                                                             2: Transaction( )

                                               3: Update local Catalogue

                                                                                                                    4: Startup

                                                                           5: Transaction( )

                                               6: Update local Catalogue


                           7: GetRecords( )


                          8: GetRecordById( )


                                                            9: FTP( )

                                                      10: product download




                                            Figure 48: Virtual FTP Service Scenario.


      •     At start-up each Virtual FTP Agents extract product metadata from locally stored products
            (step 1, 4).
      •     Then the agents send the data to the Virtual FTP Service catalogue calling the Transaction
            operation (steps 2, 5).
      •     The Virtual FTP Service updates its catalogue storing the received metadata (steps 3, 6).
      •     The data is now available for being searched by clients (step 7);
      •     For getting product URL, product details have to be extracted (step 8);
      •     The product can be retrieved form the appropriate remote agent, which store a
            customized FTP server (see [AD16]) (step 9 & 10).


Interactions with User Management infrastructure components are not showed in the diagram
(the access to the Virtual FTP Service and to the agents for downloading products is restricted).


6.5         User Identity Management
HMA user management is not a replacement for the existing GS user management; rather it builds
on their capabilities to enable interoperability. Users will be capable of logging in at the respective
GS’s with their existing account, and will also be able to log in at the DAIL. User requests will be


                                                                 Pag. 146/182
                      Title:               Architectural Design Technical Note
                      Contract Ref.:       P-E190/DGIGSD-3556-05
                      Int. Ref.:           P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                      Proj. Ref.:          HMA-DD-DAT-EN-001                 Date:        14/09/2007

enveloped in a security context which carries proofs of authentication and authorization made
prior to their issue.
The supported authentication scenarios and relevant interfaces are described in [AD14] & [AD18].
In this section the UM Architecture described in [AD14] is briefly summarized.




                                    Figure 49: Identity Management Architecture.


Web Service 1 & 2 are place holder for representing the Web Services to be protected from
unauthorized accesses.
The following paragraphs describe the identified architectural components.


6.5.1   Policy Enforcement Point – PEP
PEP enforces access policy to web services. SOAP over HTTP requests for web resources are
intercepted by the PEP where the policy is invoked and if permitted the request is routed to the
web service. It enforces access policies on SOAP resources providing dynamic policy evaluation,
authorization, and auditing services.
It decrypt the SAML token received in the user request, extracts the embedded profile information
and then checks whether the client is authorized for that request or not.


6.5.2   Identity Provider
This component allows authentication of a user either from the local user registry or if the DAIL is
not the identity provider for the requesting party then it passes the request to the appropriate GS
Identity Provider for authentication.
It provides an authentication service interface allowing SOAP clients to log in to the system. Upon
successful authentication check it returns a SAML token to embed in all subsequent services calls.

                                                          Pag. 147/182
                        Title:           Architectural Design Technical Note
                        Contract Ref.:   P-E190/DGIGSD-3556-05
                        Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                        Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007




6.5.3   User Registry
It is a stand-alone server that manages identity information about users, groups and organisation.
It performs the following tasks:
   •    Read and write user profile information from / to the database;
   •    Provide LDAP V3 compliant interface.


6.5.4   HM Services
It is a place holder representing the EO DAIL services based on orchestration of GS provided
services.




                                                        Pag. 148/182
                       Title:           Architectural Design Technical Note
                       Contract Ref.:   P-E190/DGIGSD-3556-05
                       Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                       Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007



7         Technology Viewpoint
In this section the drivers for the selection of technologies and protocols for the implementation of
HMA services are described. Additionally a preliminary selection, to be further analysed in the next
phase of the project for taking into account the HMA Services still to be finalized (e.g. user
management, data access request, and programming) is provided.


7.1       Main Design Drivers
The main design drivers for the DAIL architecture are:
      •   Service oriented architecture
      •   Based on open-standards
      •   Can be implemented with COTS or open-source components
These design drivers are explained in more detail in the following subsections.


7.1.1     Service Oriented Architecture (SOA)
SOA architecture is popular and widespread because it allows exploitation and reusing of existing
systems functionality by means of services and it provides interoperability among functionality
provided by heterogeneous systems and technologies (refer to [RD35]).
It's an architectural style of building software applications that promotes loose coupling between
components so that they can be re-used in an easy and cost effective way. Thus, it's a new way
of building applications with the following characteristics:
      •   Services are software components that have published contracts/interfaces; these
          contracts are platform-, language-, and operating-system-independent. XML and the
          Simple Object Access Protocol (SOAP) are the enabling technologies for SOA, since
          they're platform-independent standards.
      •   Consumers can dynamically discover services.
      •   Services are interoperable.
SOA promotes application assembly because services can be reused by numerous consumers. It
allows automating of business-process management. Business processes may consume and
orchestrate these services to achieve the desired functionality. Thus, new business processes can
be constructed by using existing services.
SOA Architecture style offers several advantages:
      •   Adapt applications to changing technologies.
      •   Easily integrate applications with other systems.
      •   Leverage existing investments in legacy applications.
      •   Quickly and easily create new business processes from existing services.
What makes SOA so powerful is that it encompasses Web services. These modular, self-contained
components are built on open standards, so they work together without custom coding. Since the
services share a common protocol, they can communicate with each other even though they
don’t share the same language or application platform. Web services make individual services
available to other systems via a network.
To make services available to a wider audience, SOA uses the find-bind-execute paradigm.
Service providers (e.g. any of the existing PGS) register their services in a public registry, the Service
Directory. This registry is used by service consumers to find services matching certain criteria. The
registry provides the service consumer with a contract (an interface) and an endpoint address for
that service.




                                                       Pag. 149/182
                     Title:           Architectural Design Technical Note
                     Contract Ref.:   P-E190/DGIGSD-3556-05
                     Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                     Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007




Each component (Web Service) provides a service through a clear and well known interface. The
WSDL (Web Services Description Language) is the de facto standard for XML-based service
description. WSDL defines the interface and mechanics of service interaction. The WSDL
document can be complemented by other service description documents to describe these
higher level aspects of the Web service. For example, business context is described using UDDI
data structures in addition to the WSDL document. UDDI provides a mechanism for holding
descriptions of Web Services. Although UDDI is often thought of as a directory mechanism, it also
defines a data structure standard for representing service description information in XML. WSDL-
UDDI are the contracts to be respected by integrated service providers to join a Service Oriented
architecture. Each component exposes offered services and is able to discover and exploit
services provided by other infrastructures. These concepts are the basis to achieve an integrated,
interoperable and extensible architecture.
Another advantage of using SOA architecture is the evolution of problematic regarding Security,
Reliability and Authentication. The distributed nature of this architecture makes addressing security
concerns a critical factor. New standards have been introduced to ensure reliable and secure
communications over the network conceived to protect the environment based on the SOA
architecture.
Each component is then an independent and de-coupled resource giving its contribution to
reach the final result. Basic services will be composed in a work flow describing the sequence of
actions to be taken contacting a number of service providers. Compound services are so
characterized by a working flow composing basic services into an interoperability chain. A “Work-
Flow Manager” agent is introduced to handle the basic services cooperation. Each “super-
service” is related to a work flow describing the succession of invoked basic services in order to
furnish the final result to the end user.




                                                     Pag. 150/182
                        Title:           Architectural Design Technical Note
                        Contract Ref.:   P-E190/DGIGSD-3556-05
                        Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                        Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007


7.1.2     EO-DAIL Architecture Technologies Selection
The present section reports the technologies selected for the implementation of the EO-DAIL
components presented in section 6.2.2. These selections are mainly driven by the service oriented
approach using Web Services selected for HMA implementation.
    •     Services Container: JAVA J2EE Server is selected as Web Services and EJB container.
          Web Container manages the execution of JSP page and Servlet components for Java EE
          applications.
          EJB Container manages the execution of enterprise beans for Java EE applications.
          It is used as general mean for the deployment of web services, and as run-time
          environment of the Work-flow engine with which it is tightly integrated.
          The J2EE platform offers a multi-tiered distributed application model, reusable
          components, a unified security model, flexible transaction control, and web services
          support through integrated data interchange on Extensible Markup Language (XML)-
          based open standards and protocols. Moreover access to a wide variety of RDBMS is
          allowed via JDBC interface.
    •     User Information Repository: to store and manage User information LDAP (Lightweight
          Directory Access Protocol) Server is selected for HMA.
          LDAP allows to share Users account information among EO-DAIL and partner GSs in a
          transparent and secured way (using https) allowing users to use the same account
          information both when logging directly on the partner GS and when accessing it from the
          EO-DAIL.
    •     Service Description Registry: this registry is implemented via an UDDI Registry. This registry is
          populated and accessed using UDDI Protocol. It is used for storing the WSDL of the Web
          services part of the HMA. This registry has to support the Work-flow engine and the
          operators for deploying new compound services on the EO DAIL.
    •     Workflow Engine: BPEL is the selected language for implementing HM services workflows.


7.1.3     Selection of Standards and Definition of New Protocols

7.1.3.1    Selection of Standards
In the HMA architecture a large set of open standards have been used:
    •     Service Oriented Design. Due to the SOA approach, the following standards have been
          adopted:
             •   XML Schemas express shared vocabularies and allow machines to carry out rules
                 made by people. They provide a means for defining the structure, content and
                 semantics of XML documents in more detail. XML Schema is used together WSDL for
                 defining the interfaces of HMA Services.
             •   Message-based SOAP (Simple Object Access Protocol) over HTTP or HTTPS for
                 secure communication is used as protocol between the EO DAIL, clients and
                 remote GS services (see [RD07]).
             •   WSDL (Web Services Description Language) is used to define the operations (see
                 [RD08]), the SOAP messages, the protocol bindings of the HMA services in a formal
                 way. It is equivalent to a CORBA IDL.
             •   The Business Process Execution Language (BPEL) [RD24] from OASIS provides a
                 vendor-independent XML-based format to model service workflows. The EO DAIL
                 workflow engine uses this open standard. Software (i.e. workflows) developed
                 using this language is thus reusable and the workflow engine or workflow editing
                 tool would be replaced.
             •   Universal Description, Discovery and Integration (UDDI) [RD12]. This standard allows
                 for service discovery and is an essential part of a SOA. It defines the external

                                                        Pag. 151/182
                    Title:           Architectural Design Technical Note
                    Contract Ref.:   P-E190/DGIGSD-3556-05
                    Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                    Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

            interfaces of a Web service registry. Competing standards (with less vendor
            support) are WS-inspection [RD22] (IBM) and OGC Catalogue specification 2.0
            [RD23]. HMA Services configuration metadata is managed by EO DAIL using a UDDI
            registry.
        •   Ws-addressing [RD25] is used to correlate asynchronous message exchanges in a
            standard way instead of an ad-hoc content-based mechanism. Ws-addressing is
            being standardized by the W3C Consortium.


•   Geospatial, Inspire related and recommended by CEN [RD36]:
    for the analysis of the spatial data model the following standards have been considered
        •   ISO 19109, which contains the general feature model for ISO/TC 211. It guides the
            use of classes, relationships, interfaces, and properties in designing feature
            schemas for data transfers or transactions.
        •   ISO/TS 19103 provides rules and guidelines for the use of a conceptual schema
            language within the ISO geographic information standards. It also provides a
            profile of UML (Unified Modelling Language) for use with geographic information.
            UML is the chosen conceptual schema language within ISO/TC 211.
    The definition of spatial data encoding has been done following the:
        •   ISO 19136 Geography Markup Language (GML)[RD28]. It is an XML grammar
            written in XML Schema for the modelling, transport, and storage of geographic
            information. The key concepts used by GML to model the world are drawn from the
            OpenGIS® Abstract Specification and the ISO 19100 series. GML provides a variety
            of kinds of objects for describing geography including features, coordinate
            reference systems, geometry, topology, time, units of measure and generalized
            values.
            The HMA product metadata schema is an application schema of GML.
    For the definition of features spatial data services:
        •   The Web Feature Service (WFS) [RD30] allows a client to retrieve and update
            geospatial data encoded in Geography Markup Language (GML) from multiple
            Web Feature Services. The requirements for a Web Feature Service are:
                •    The interfaces must be defined in XML.
                •    GML must be used to express features within the interface.
                •    At a minimum a WFS must be able to present features using GML.
                •    The predicate or filter language will be defined in XML and be derived from
                     CQL as defined in the OpenGIS Catalogue Interface Implementation
                     Specification.
                •    The datastore used to store geographic features should be opaque to
                     client applications and their only view of the data should be through the
                     WFS interface.
                •    The use of a subset of XPath expressions for referencing properties.
            This standard is relevant for the on-line data access interface.
    For the definition of raster spatial data services:
        •   Web Map Service (WMS) [RD29] standard specifies the behaviour of a service that
            produces spatially referenced maps dynamically from geographic information. It
            specifies operations to retrieve a description of the maps offered by a server, to
            retrieve a map, and to query a server about features displayed on a map. This
            International Standard is applicable to pictorial renderings of maps in a graphical
            format; it is not applicable to retrieval of actual feature data or coverage data
            values.
            This standard is relevant for the on-line data access interface.

                                                    Pag. 152/182
                  Title:           Architectural Design Technical Note
                  Contract Ref.:   P-E190/DGIGSD-3556-05
                  Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                  Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

       •   The Web Coverage Service (WCS) [RD31] supports electronic interchange of
           geospatial data as "coverages" – that is, digital geospatial information representing
           space-varying phenomena. A WCS provides access to potentially detailed and
           rich sets of geospatial information, in forms that are useful for client-side rendering,
           multi-valued coverages, and input into scientific models and other clients. The WCS
           may be compared to the OGC Web Map Ser-vice (WMS) and the Web Feature
           Service (WFS); like them it allows clients to choose portions of a server's information
           holdings based on spatial constraints and other criteria.
           Unlike WMS, which filters and portrays spatial data to return static maps (rendered
           as pictures by the server), the Web Coverage Service provides available data
           together with their detailed descriptions; allows complex queries against these
           data; and returns data with its original semantics (instead of pictures) which can be
           interpreted, extrapolated, etc. -- and not just portrayed.
           Unlike WFS, which returns discrete geospatial features, the Web Coverage Service
           returns representations of space-varying phenomena that relate a spatio-temporal
           domain to a (possibly multidimensional) range of properties.
           This standard is relevant for the on-line data access interface.
    For the definition of spatial data catalogue services:
       •   ISO 19119 Services identifies and defines the architecture patterns for service
           interfaces used for geographic information and defines its relationship to the Open
           Systems Environment model. It also presents a geographic services taxonomy and
           a list of example geographic services placed in the services taxonomy.
       •   OGC CSW2.0 Application Profile ISO19115/19119 [RD32]
           This application profile specifies the interfaces, bindings, and encodings required to
           publish and access digital catalogues of metadata for geospatial data, services,
           and applications that comply with the given profile. Metadata act as generalised
           properties that can be queried and returned through catalogue services for
           resource evaluation and, in many cases, invocation or retrieval of the referenced
           resources.
           This application profile has been selected as base for the collections discovery
           specification.


•   Security/Identity management: for the management of user identity, user profile, to have
    secure exchange of information between the EO DAIL and the GSs, the following protocols
    have been considered:
       •   Security Assertion Markup Language (SAML), developed by the Security Services
           Technical Committee of OASIS, is an XML-based framework for communicating
           user authentication, entitlement, and attribute information. As its name suggests,
           SAML allows business entities to make assertions regarding the identity, attributes,
           and entitlements of a subject (an entity that is often a human user) to other entities,
           such as a partner company or another enterprise application.
       •   Lightweight Directory Access Protocol (LDAP) is a set of protocols for accessing
           information directories. LDAP is based on the standards contained within the X.500
           standard, but is significantly simpler. And unlike X.500, LDAP supports TCP/IP, which
           is necessary for any type of Internet access. Because it's a simpler version of X.500,
           LDAP is sometimes called X.500-lite. It has been selected as the protocol for the
           management of user identities across the HMA and GS services.
       •   WS-Security [RD26] describes enhancements to SOAP messaging to provide quality
           of protection through message integrity, message confidentiality, and single
           message authentication. These mechanisms can be used to accommodate a
           wide variety of security models and encryption technologies.


                                                  Pag. 153/182
                       Title:            Architectural Design Technical Note
                       Contract Ref.:    P-E190/DGIGSD-3556-05
                       Int. Ref.:        P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                       Proj. Ref.:       HMA-DD-DAT-EN-001                 Date:        14/09/2007

                 WS-Security also provides a general-purpose mechanism for associating security
                 tokens with messages. However, no specific type of security token is required by
                 WS-Security. It is designed to be extensible (e.g. support multiple security token
                 formats) to accommodate a variety of authentication and authorization
                 mechanisms. For example, a requestor might provide proof of identity and a signed
                 claim that they have a particular business certification. A Web service, receiving
                 such a message could then determine what kind of trust they place in the claim.
                 Additionally, WS-Security describes how to encode binary security tokens and
                 attach them to SOAP messages. Specifically, the WS-Security profile specifications
                 describes how to encode Username Tokens, X.509 Tokens, SAML Tokens , REL Tokens
                 and Kerberos Tokens as well as how to include opaque encrypted keys as a sample
                 of different binary token types. With WS-Security, the domain of these mechanisms
                 can be extended by carrying authentication information in Web services requests.
             •   WS-Policy [RD27] provides a flexible and extensible grammar for expressing the
                 capabilities, requirements, and general characteristics of entities in an XML Web
                 services-based system. WS-Policy defines a framework and a model for the
                 expression of these properties as policies. WS-Policy defines a policy to be a
                 collection of policy alternatives, where each policy alternative is a collection of
                 policy assertions. Some policy assertions specify traditional requirements and
                 capabilities that will ultimately manifest on the wire (e.g., authentication scheme,
                 transport protocol selection). Other policy assertions have no wire manifestation yet
                 are critical to proper service selection and usage (e.g., privacy policy, QoS
                 characteristics). WS-Policy provides a single policy grammar to allow both kinds of
                 assertions to be reasoned about in a consistent manner. WS-Policy does not specify
                 how policies are discovered or attached to a Web service.


7.1.3.2    Definition of new protocols
In the frame of HMA project several new protocols have been proposed for standardization
covering the following areas:
    •     Collection & Service Discovery
    •     EO Product Catalogues
    •     EO Product Ordering
    •     EO Programming
    •     Identity Management


For Collection & Service Discovery, several protocols have been proposed during the life of the
project:
    •     OpenGIS® Catalogue Services Specification 2.0.1 (with Corrigendum) - ISO Metadata
          Application Profile OGC 04-038, which is going to be replaced by OGC 07-045.
          Deprecated.
    •     OGC 07-025 – Collection and Service Discovery, which is an OGC "Pending document".
          Deprecated.
    •     OGC™ Cataloguing of ISO Metadata (CIM) using the ebRIM profile of CS-W OGC 07-038,
          which is the final protocol for HMA Collection and Service Discovery.
          This document complements the ebRIM application profile of CS-W for the cataloguing of
          ISO 19115 and ISO 19119 compliant metadata record. It defines for this purpose a Core ISO
          Metadata extension package of ebRIM.



For EO Products Catalogue several protocols have been proposed as well:

                                                        Pag. 154/182
                       Title:             Architectural Design Technical Note
                       Contract Ref.:     P-E190/DGIGSD-3556-05
                       Int. Ref.:         P-E190/DGIGSD-0399-06             Issue:   1     Rev.:     7
                       Proj. Ref.:        HMA-DD-DAT-EN-001                 Date:          14/09/2007

   •   OGC 05-057 – Best Practices for EO
       Derived from EOLI XML ICDs ([RD52], [RD53]), which are currently used in ESA User Services
       Infrastructure. It was starting point for HMA Catalogue and Ordering Services. Deprecated.
   •   OGC 04-094 – Web Feature Service
       It has been taken into account during the definition of the Catalogue protocol.
   •   OGC™Catalogue Services Specification 2.0.1 (with Corrigendum) – EO Application Profile
       for CSW 2.0 - OGC 06-079
       This protocol was originally candidate for standardization, it was subject to prototype
       activities, but it has been deprecated in favour of the next one.
   •   OGC™ Catalogue Services Specification 2.0 - EO Products Extension Package for ebRIM
       (ISO/TS 15000-3) Profile of CSW 2.0 - OGC 06-131.
       This document describes the mapping of Earth Observation Products (see next) to an
       ebRIM structure within an OGC™ Catalogue 2.0.0 (with Corrigendum) [OGC 04-021r3]
       implementing the OGC™ ebRIM (ISO/TS 15000-3) Profile [OGC 05-025r3].
       This is the final protocol for accessing EO Product Catalogues.
   •   GML Application Schema for EO products – OGC 06-080
       It is not a Catalogue Service specification, but it is referenced by the previous ones for
       modeling the EO Product metadata. In fact it defines an application schema of the
       Geography Markup Language (GML) version 3.1.1 for describing Earth Observation
       products (EO products) within the OGC 06-131 (and also 06-079).


The following figures show the relationships between these documents (in blue) and the already
existing OGC standards (yellow boxes):


                           Catalogue 2.0.1
                            OGC 04-021




           CSW ISO AP                   CSW ebRIM AP
           OGC 04-038                    OGC 05-025



            Collection &                                                      RIM
              Service                    OASIS RIM        Instantiates extension package
             Discovery                                                      for ISO
                                        ISO/TS 15000-3
           OGC 07-025                                                   (OGC 07-038)

                                                                     Refers to               Refers to

           Replaced by 07-038                                            Metadata                  Metadata
                                                                         Datasets                  Services
                                                                         ISO 19115             ISO 19119

         Figure 50: HMA Collection and Service Discovery Document Tree (Courtesy of Spacebel).




                                                         Pag. 155/182
                         Title:              Architectural Design Technical Note
                         Contract Ref.:      P-E190/DGIGSD-3556-05
                         Int. Ref.:          P-E190/DGIGSD-0399-06               Issue:     1   Rev.:    7
                         Proj. Ref.:         HMA-DD-DAT-EN-001                   Date:          14/09/2007


                                          Catalogue 2.0.1
                                           OGC 04-021




           CSW ISO AP                                                   CSW ebRIM AP                         WFS

            OGC 04-038                                                     OGC 05-025                   OGC 04-094
                                            OGC Filter                                                   ISO 19142
                                             Encoding
                                            OGC 04-095                               Uses
                                             ISO 19143
          CSW Appl. Profile                                                   OASIS RIM
               for EO1
                                                                        ISO/TS 15000-3
            OGC 06-079                       GML 3.2
                                          OGC XX-XXX                               Instantiates
                                           ISO 19136                           RIM
           Replaced by 06-131
                                                                        extension package
                                                                             for EO2
                                                                           OGC 06-131
         Refers to                     GML Appl. Schema
                                        for EO Products
                                                                  Refers to
                                           OGC 06-080
        (1) Aligned with ISO AP
        (2) Aligned with ebRIM AP
                      Figure 51: HMA Catalogue Document Tree (Courtesy of Spacebel).


For EO Product Ordering, the following 2 specifications have been proposed:
   •    OGC 05-057 – Best Practices for EO
        Deprecated in favour of the next one.
   •    Ordering Services for Earth Observation Products (OGC-06-141)
        It has been derived from the previous one and integrated with SWE Common elements.


For EO Programming, the following specification has been proposed:
   •    Sensor Planning Service Profile for Earth Observation Sensors (OGC-07-018)
        Derived from OpenGIS® Sensor Planning Service Implementation Specification - OGC-05-
        089r3


Regarding the Identity Management an initial draft document has been proposed to OGC:
   •    User Management Interfaces for Earth Observation Services – OGC 07-118


7.1.4   Can be implemented with COTS or Open-Source
The adoptions of standards whenever possible and the adoption of the SOA approach leads to
the possibility to use a large set of commercial / freeware COTS that allows to greatly reducing the
development effort. Moreover, the adoption of standard protocols and technologies avoid the
locking of the architecture to specific COTS.
COTS are available either as commercial or freeware / open-source products. Both solutions have
their pro & cons that are summarized in the table below.
To be noted that reported pro & cons are generic and can not be considered as “absolutely”
valid for all the proposed products, e.g. Open Source software like Apache Application Server
can not be considered as a “not stable product” (it is also used by ORACLE) even if one of the

                                                            Pag. 156/182
                      Title:           Architectural Design Technical Note
                      Contract Ref.:   P-E190/DGIGSD-3556-05
                      Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                      Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

main disadvantages of Open-Source products is often they lack of stability being not mature and
not derived by an industrial project.


Open-Source Tools Advantages                          Open-Source Tools Disadvantages
Less dependence on vendors: there are                 Stability: often these initiatives need long time
many contributors to Open-Source and,                 before being eligible to be used in operational
even if they are vendors (like IBM , ORACLE,          environment
etc…) when they participate to Open-
Source initiatives their presence is mitigated
and almost never create dependency
Cost savings: cost of acquisition is zero but if      Lack of Support Service: they do not provide direct
we consider the total cost of ownership, lack         support services but you need to look for the
of documentation, support, etc…. could turn           solution within the network.
this to a disadvantage especially if operated
by not specialist resources.
Reduced cost to innovate: they are a real             No warranty for future support or evolution
chance to introduce and verify innovations
without significant investment in new
infrastructures
Participation to improvements: Open-Source            Quality level of the proposed solution is often not
is really Open, whoever has a good idea, a            sufficient  for    their usage    in   operational
good contribution can participate to the              environment.
game
Wide consensus: being developed by many
contributors, they already have a wide
consensus




Commercial Tools Advantages                           Commercial Tools Disadvantages
Stability: commercial tools are the result of         Cost: this cost is referred to the tool purchase cost
long process and have a stability granted             but, if we consider the total cost of ownership, this
                                                      could turn to an advantage for the customer.
Support Service: the service support             is   Dependency: a mutual dependency is created
granted by a service level agreement                  between customer and supplier.
Provide a reference solution for a given field        Impossibility of interacting in the Tool evolution
of applicability (e.g. ORACLE for RDBMS)              process
Reliability often related only to the brand.
Standard de-facto: widespread commercial
solutions often become standard de-facto.
Consultancy service Official documentation
and third party books




                                                      Pag. 157/182
                    Title:           Architectural Design Technical Note
                    Contract Ref.:   P-E190/DGIGSD-3556-05
                    Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                    Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007



8      Traceability Matrix
8.1    High level requirements traceability matrix
In the following table the traceability of high level requirements [AD02] with respect the HMA
architecture is reported.


 Requirement                 Description                Parent             Compliance            Comment
   Number                                             Scenario(s)
HL_GEN_499      HMA shall be able to support                           C                    Policy yet to be
                the GMES Data Policy,                                                       published
HL_GEN_500      The Access to the data and                             N/A
                services from the missions
                participating in GMES will be
                ruled by Data Access
                Agreements to be signed
                between ESA and the mission
                owner
HL_GEN_501      The Data Access Agreements                             N/A
                will define the Service Level
                Agreements to be supported
                for the specific mission/data
                access
HL_GEN_502      Each partner shall document                            N/A
                the mapping of the SLA
                implementation vis a vis the
                DAIL or his own ground
                segment
HL_GEN_503      HMA shall publish a Technical                          N/A
                Document defining the
                relationship between the
                Service Level Agreement and
                the HMA services/functions
                supporting the agreement
                itself.
HL_GEN_517      Performance requirements                               C
                towards the mission GS shall
                be established in the SLA
HL_GEN_521      Reliability, Availability,                             C
                Maintainability (RAM)
                requirements towards the
                mission GS shall be agreed in
                the SLA
HL_GEN_510      The HMA shall permit the                               TBD                  Draft rules under
                support of INSPIRE                                                          review. Worked
                implementing rules.                                                         closely with
                                                                                            INSPIRE team for
                                                                                            the specification
                                                                                            of the services.
HL_GEN_504      The HMA architecture shall                             C                    Pricing issues
                support the definition and                                                  have not been
                management of a variety of                                                  studied in details
                user groups with different user                                             in this phase of
                privileges and pricing                                                      the project

                                                    Pag. 158/182
                 Title:           Architectural Design Technical Note
                 Contract Ref.:   P-E190/DGIGSD-3556-05
                 Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                 Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007


             schemas.
HL_GEN_627   The HMA shall make use of a                            C
             common priority scheme,
             covering both routine and
             emergency situations, that
             can map onto the schemes
             used by the partner missions.
HL_GEN_628   The HMA architecture shall                             C
             support quota management
             for both data and service use
HL_GEN_505   The overall HMA architecture,                          C                    Web service
             including the DAIL one, shall                                               based SOA
             be driven to minimise the cost
             and impact on partners’
             ground segments for both
             existing and future missions.
HL_GEN_629   The definition of the Interface                        C                    Consensus
             Control Documents and the                                                   based definition
             selection of the underlying                                                 of ICDs
             standards shall be driven by
             the minimisation of the cost
             impact on the partner ground
             segments.
HL_GEN_631   The HMA architecture shall                             C
             offer support tools for the easy
             integration of new services in
             the system, e.g web service
             skeleton.
HL_GEN_506   The DAIL architecture shall be                         C
             independent of a particular
             partner’s ground segment.
HL_GEN_507   The HMA architecture shall                             C                    SSE based
             permit integration and reuse                                                technology that
             by additional partners in the                                               has already a
             future.                                                                     proven
                                                                                         portability.
HL_GEN_508   The HMA architecture shall                             C                    FeDEO is best
             permit its integration and                                                  example
             reuse in other architecture in
             the future (e.g. GEOSS).
HL_GEN_509   It shall be possible to add                            C
             missions without changing the
             HMA architecture.
HL_GEN_633   It shall be possible to increase                       C
             the HMA service portfolio with
             new service types without
             changing the HMA
             architecture.
HL_GEN_511   The HMA architecture shall                             C                    Already
             allow the use of partners’                                                  demonstrated
             proprietary GUI clients that are                                            with WIN project
             compliant to HMA interface
             specifications for the user
             access to HMA provided
             functionality/ services

                                                 Pag. 159/182
                 Title:           Architectural Design Technical Note
                 Contract Ref.:   P-E190/DGIGSD-3556-05
                 Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                 Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007


HL_GEN_648   The HMA Architecture shall                             C
             include a GUI client, or a set
             of GUI clients, for user access
             to the HMA services, operator
             access and test:
             The user access GUI shall
             provide an intuitive interface
             for a user to activate all
             operations of all the proposed
             services.
             The operator access GUI shall
             provide an intuitive interface
             for an operator, or a user with
             administator privileges, to
             monitor the system and
             register and update service
             details
             The test GUI shall provide an
             intuitive interface for an
             operator, or a user with
             administator privileges, to test
             newly added or upgraded
             service operations
HL_GEN_608   The HMA architecture shall                             C
             allow the use of Mission
             Furnished Items to access the
             services of a mission ground
             segment
HL_GEN_512   The HMA shall allow the                                C
             traceability of all allowed and
             denied transactions which are
             handled through the DAIL
HL_GEN_617   The HMA architecture shall                             C                    Help &
             keep an up-to-date record of                                                Documentation
             all future interruptions at GS or                                           Desk
             MM level and make this
             record visible to all the HMA
             partners
HL_GEN_513   The HMA architecture shall                             C
             permit the partner to choose
             whether the user registration
             and the management of user
             privileges and or policies are
             managed either on the DAIL
             or at the partners’ ground
             segment or both.
HL_GEN_556   The HMA architecture shall                             C
             support storage of the user
             management policy in HMA
             standard format in the DAIL
HL_GEN_557   The HMA architecture shall                             C
             support Mission GS storage of
             the user management policy
             in HMA standard format
HL_GEN_558   The HMA architecture shall                             C

                                                 Pag. 160/182
                 Title:           Architectural Design Technical Note
                 Contract Ref.:   P-E190/DGIGSD-3556-05
                 Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                 Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007


             support policy enforcement
             points in the DAIL
HL_GEN_559   The HMA architecture shall                             C
             support Mission GS policy
             enforcement points
HL_GEN_560   The HMA architecture shall                             C
             support user identification
             information to be managed in
             the DAIL
HL_GEN_561   The HMA architecture shall                             C
             support user identification
             information to be managed
             at the Mission GS.
HL_GEN_652   The policy enforcement of the                          C
             HMA architecture shall allow a
             mission GS to track and limit
             requests on a certain
             geographical area
HL_GEN_653   The policy enforcement of the                          C
             HMA architecture shall allow a
             mission GS to track and limit
             requests from users located in
             a certain geographical area
HL_GEN_514   The HMA architecture shall                             C                    Web service
             permit to choose whether an                                                 based SOA
             HMA function is implemented
             either on the DAIL or at a
             partner ground segment or
             both.
HL_GEN_515   When providing access to                               C                    Not verified in
             mission GS services the DAIL                                                this phase of the
             and HM functions shall not                                                  project
             noticeably degrade the
             availability of the service (e.g.
             the DAIL and HM functions
             shall support concurrent
             access to the mission GS
             services, the DAIL shall not limit
             the number of concurrent
             users below the level
             available from the mission GS,
             the DAIL shall be nominally
             available 24*7). The DAIL shall
             have an overall availability of
             98%(TBC) measured per
             month.
HL_GEN_516   When providing direct access                           C                    Not verified in
             to mission GS services the                                                  this phase of the
             HMA architecture shall not                                                  project
             noticeably degrade the
             performance of the native
             service (e.g. the response time
             via DAIL and any HM function
             shall not be greater than 110%
             of the native service, including

                                                  Pag. 161/182
                    Title:           Architectural Design Technical Note
                    Contract Ref.:   P-E190/DGIGSD-3556-05
                    Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:    7
                    Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007


                authorisation, transaction
                logging etc.)
HL_GEN_518      The HMA architecture shall                             PC                   Requirement to
                ensure that data are not lost                                               be flown down
                in case of communication                                                    to
                problems, e.g. it shall be                                                  implementation
                ensured that data (such as                                                  phase
                orders) are preserved at
                sender side such that the
                transfer can be repeated until
                it is confirmed that the
                receiver has correctly
                received them.
HL_GEN_519      Failure or management of                               PC                   Defensive
                erroneous data in one HMA                                                   programming
                service shall be detected and                                               may not be
                handled as much as possible                                                 possible for all
                within the DAIL and HM                                                      services
                functions, handling such errors
                "gracefully" and without
                affecting other functions.
                Implying e.g.:
                continuation of nominal
                function operations for further
                requests (i.e. robustness);
                possibility to correct the
                problem locally by specific
                operator/administrator
                intervention without
                necessarily relying on
                resubmission of corrected
                data;
                usage of "defensive
                programming" (i.e. not
                assuming that the interface
                partner produces syntactically
                and semantically correct
                information;
                appropriate logging of such
                events to allow investigation.
HL_GEN_645      HMA shall publish a Technical                          C                    ISMS
                Document defining the
                procedures to manage the IT
                requirements
HL_GEN_522      The HMA architecture should                            C
                be based on open standards.




8.2    Functional Requirements and Scenarios traceability Matrix
Not all scenarios and requirements presented in [AD1] and [AD2] have been addressed by the
present document. This mainly because some of these scenarios are not yet supported by partner
GS or are not in the current scope of HMA activities.



                                                    Pag. 162/182
                       Title:           Architectural Design Technical Note
                       Contract Ref.:   P-E190/DGIGSD-3556-05
                       Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                       Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007

In the following sub-sections the traceability of services instances (see §5 and §6) with respect the
operational scenarios and functional requirements described in the [AD1] [AD2] are reported.
The services instances will be referred in the next tables with the following acronyms:


Service Instances                                        Acronym
HM Orchestration Service                                 HM CS
HM Monitoring & Control Service                          HM MCS
HM Service Registration Service                          HM SRS
HM Collection Discovery Service                          HM CDS
HM Service Discovery Service                             HM SDS
HM Service Configuration Discovery Service               HM SCDS
HM Catalogue Service                                     HM CAS
HM Programming Service                                   HM PS
HM Order Service                                         HM OS
HM User Management Service                               HM UMS
HM Virtual FTP Service                                   HM VFS
HM Help & Documentation Desk Service                     HM HDS


GS Collection Discovery Service                          GS CDS
GS Service Discovery Service                             GS SDS
GS Service Configuration Discovery Service               GS SCDS
GS Catalogue Service                                     GS CAS
GS Programming Service                                   GS PS
GS Order Service                                         GS OS
GS User Management Service                               GS UMS
GS Virtual FTP Agent                                     GS VFTP
GS WCS                                                   GS WCS
GS WMS                                                   GS WMS
HM Help & Documentation Desk Service                     GS HDS


The additional abbreviations are also used:
   o    All: all services instances
   o    All GS: all GS service instances
   o    All HM: all HM service instances


8.2.1   Scenarios traceability Matrix
The following table reports the mapping of operational scenarios on previously identified service
instances.


                                                       Pag. 163/182
                     Title:            Architectural Design Technical Note
                     Contract Ref.:    P-E190/DGIGSD-3556-05
                     Int. Ref.:        P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                     Proj. Ref.:       HMA-DD-DAT-EN-001                 Date:        14/09/2007


Scenario                                  Service         Discrepancies
                                          Instance
                                          Acronym
US1_1 - Standardised GS service           GS DS, GS
                                          CAS,    GS
                                          PS, GS OS,
                                          GS UMS,
                                          GS FTP, GS
                                          WMS, GS
                                          WCS
US1_2 - Compound services                 HM    CS,       This scenario mainly describes the approach
                                          HM SOS          for creating higher level services from the
                                                          services already available in the HMA
                                                          infrastructure: it may be considered as a
                                                          suggestion for the services (e.g. the
                                                          Catalogue, Ordering, etc.) implementation
                                                          The definition of service orchestration service
                                                          in the present document instead focuses on
                                                          the possibility for some special users (e.g. the
                                                          operators of the Ground Segments) to install
                                                          and activate their own workflows on the
                                                          Service Orchestration Service for exploiting
                                                          the workflow engine. Whilst not shown in the
                                                          scenario, it is implied and referenced in the
                                                          text.


US1_3 - Access to the GS services         N/A             The applicability of this scenario depends on
through the use of Mission Furnished                      the availability of Mission Furnished items for
Items                                                     specific services.
US2_1 - Replicated catalogue              None            Not retain for HM Catalogue service
US2_2 - Delegated catalogue               HM VFS          The Virtual FTP Service can be used for
                                                          delegating catalogues of on-line available
                                                          products.
US2_3 - Interoperable catalogue           HM    DS,       The collection and service discovery parts of
interfaces                                HM CAS,         the scenario are handled through an ISO
                                          GS    DS,       profile compliant catalogue, however the
                                          GS_CAS          harvesting approach could be preferred to
                                                          the transaction approach described in the
                                                          scenario.
US3_1 - HM ordering function              HM     OS,
                                          HM PS, GS
                                          OS, GS PS
US3_1_1 - HM order options retrieval      HM OS, GS       Only the option 2 is covered.
                                          OS
US3_1_2 - HM order assessment             HM PS, GS
                                          PS
US3_1_3 - HM product delivery             HM,   OS,       Option 2 only has been retained.
                                          GS OS


                                                      Pag. 164/182
                     Title:             Architectural Design Technical Note
                     Contract Ref.:     P-E190/DGIGSD-3556-05
                     Int. Ref.:         P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                     Proj. Ref.:        HMA-DD-DAT-EN-001                 Date:        14/09/2007


Scenario                                    Service        Discrepancies
                                            Instance
                                            Acronym
US4_1 -      Spatio-temporal       order    HM PS, GS
definition                                  PS
US4_2 - Mission-independent spatio-         HM PS, GS      The mission independent element of the
temporal order definition                   PS             scenario can be handled through the use of
                                                           virtual sensor ID’s either at HM and/or at GS
                                                           level. Higher-level services described in the
                                                           HMA Mission Planning specifications are more
                                                           likely to handle the full complexity of this
                                                           scenario however
US5_1 - Advertising pre-planned             GS    CAS,     The agreements on pre-planned acquisitions
acquisitions                                GS PS          are likely to be made through separate
                                                           negotiations, e.g. DAA’s, rather through a
                                                           DAIL interface. No means of advertising this
                                                           information has been specifically identified
                                                           but the architecture provides several options
                                                           on this aspect, e.g. through the Help &
                                                           Documentation      service,   through     the
                                                           Catalogue service.
                                                           No interface for hot-spots registrations in the
                                                           DAIL yet however.
US5_2   -     Advertising    sensing        HM PS          The Feasibility Server of the HM PS will collect
opportunities and constraints                              that information to be used to provide coarse
                                                           feasibility analyses. Higher-level services
                                                           described in the HMA Mission Planning
                                                           specifications are more likely to handle the
                                                           planning element of this scenario however.
US5_3 - Cooperative planning of             HM PS, GS      This application of this scenario depends on
the acquisition schedule                    PS             agreements made with the mission GS’s,
                                                           outside the DAIL interfaces. Once these
                                                           agreements in place, this information can be
                                                           used by a high-level service, e.g. CoMu, to
                                                           implement this scenario, as described in the
                                                           Mission Planning specification.
US5_4 - Delegation of planning for          HM PS, GS      Same as above
sections of users                           PS
US6_1 - GS level policy enforcement         HM UMS,        US6_1_1 does not correspond to current
                                            GS UMS         design however as identity management will
                                                           be federated.
US6_2   -   Delegated              policy   HM UMS,        The UM architecture proposed allows this
enforcement                                 GS UMS         scenario, however it is not expected that
                                                           mission specific policies will be applied at HM
                                                           level.
US6_3   -   Cooperative            policy   GS UMS         General idea behind scenario is in line with
enforcement                                                the trust concept of the UM concept for HMA.




                                                       Pag. 165/182
                      Title:             Architectural Design Technical Note
                      Contract Ref.:     P-E190/DGIGSD-3556-05
                      Int. Ref.:         P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                      Proj. Ref.:        HMA-DD-DAT-EN-001                 Date:        14/09/2007


Scenario                                     Service        Discrepancies
                                             Instance
                                             Acronym
US7_1    -   Peer-to-peer           ground   None           This scenario is not yet covered by the
stations                                                    architecture and will be part of a second
                                                            phase of HMA services development
US7_2 - HM stations management               None           This scenario is not yet covered by the
                                                            architecture and will be part of a second
                                                            phase of HMA services development
US8_1 - Mission details provided at          HM   SDS,
service registration                         HM CDS
US8_2 - Dynamic service discovery            GS SDS
US9_1 - Standard electronic and/or           HM OS, GS      The delivery is implicit in the ordering service.
hard-copy dissemination                      OS, GS FTP     Only option 1 of the delivery is covered by the
                                                            architecture however


US9_2 - Online Data Access via               HM WMS,
OGC Web Services(ODA)                        HM OS, GS
                                             WCS
US9_3 - HM Subscription service              HM OS
US9_4 - Satellite multicast service          None           This scenario is not yet covered by the
                                                            architecture and will be part of a second
                                                            phase of HMA services development
US10_1 - Mission-in-the-loop service         HM PS, GS      The cross-order dependency element of this
                                             PS             scenario is not covered the current HMA
                                                            Programming ICD so this scenario can only be
                                                            implemented by high-level services as
                                                            described in the HMA Mission Planning
                                                            specifications. Specific tasking options for this
                                                            dependency will have to be agreed in future
                                                            releases of the ICD for this scenario to be fully
                                                            covered through DAIL provided services
US10_2 - Orders dependencies                 HM PS, GS      Same as above
                                             PS
US10_3 - Inter-linked Orders                 HM PS, GS      Higher-level services described in the HMA
                                             PS             Mission Planning specifications should handle
                                                            the planning element of this synchronisation
                                                            element of this scenario however.
US11_1 - High-priority orders                GS PS, HM      Ordering & Programming ICD have an
                                             PS, GS OS,     identified emergency priority level to be used
                                             HM OS          by accredited users.
US11_2 - International Charter:              HM PS, GS      HMA will facilitate this scenario rather than
Space and Major Disasters                    PS             providing the full service




                                                        Pag. 166/182
                     Title:              Architectural Design Technical Note
                     Contract Ref.:      P-E190/DGIGSD-3556-05
                     Int. Ref.:          P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                     Proj. Ref.:         HMA-DD-DAT-EN-001                 Date:        14/09/2007


Scenario                                     Service        Discrepancies
                                             Instance
                                             Acronym
US12_1 - Confidential orders                 HM UMS,        Access to request and order information will
                                             GS UMS         be restricted through user rights and policies.
                                                            The level of confidentiality to apply to certain
                                                            orders must be negotiated with the mission
                                                            GS’s as part of the SLA’s
US13_1 - Order monitoring                    HM OS, GS
                                             OS
US13_2 - Order cancellation                  HM OS, GS
                                             OS
US13_3     -    Central           requests   HM MCS         The logging mechanism may not be exactly
monitoring                                                  as described in the scenario however
US13_4 – HM Help & Documentation             HM HDS
Desk
US14_1 - Pricing and billing in the          HM OS, GS      Option 1 is the current baseline for GMES
HM environment                               OS             acquisitions
US14_2 - Pricing and billing via a           None           This scenario has not been further analysed in
Financial Accounting System                                 this phase of the project as focus was put on
                                                            the GMES context.
US14_3 - HM Announcement of                  None           This scenario has not been further analysed in
Opportunities Management                                    this phase of the project as focus was put on
                                                            the GMES context.
US15_1 - Notification of product             HM OS
availability
US16_1 - Sharing of archives                 None           This scenario has not been further analysed in
                                                            this phase of the project
US17_1 - Processing On Demand                None           This scenario has not been further analysed in
                                                            this phase of the project



8.2.2   Functional Requirements traceability Matrix
The following table reports the mapping of functional requirements on previously identified service
instances.


Requirement            Parent                 Service       Compliance                    Comment
Number               Scenario(s)             Instance
                                                     General
GS_GEN_1           US1_1, US1_2, All GS                     C
                   US15_1
GS_GEN_3           US1_1, US1_2          All GS             C
GS_GEN_411         US1_1, US1_2          All GS             PC                 No warning message
GS_GEN_412         ALL                   All GS             C
GS_GEN_9           US1_1, US1_2          GS PS, GS OS       C

                                                        Pag. 167/182
               Title:           Architectural Design Technical Note
               Contract Ref.:   P-E190/DGIGSD-3556-05
               Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
               Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007


GS_GEN_26     US1_3             All GS             C
GS_GEN_28     US1_3             All GS             C
GS_GEN_266    US12_1            All GS             C
HM_GEN_10     US1_1             All HMA ICDs       PC                 No HMA identifier rules officially
                                                                      produced
HM_GEN_413    US1_1             All HMA ICDs       C
HM_GEN_29     US1_3             All GS             C
HM_GEN_30     US1_3             All HM             C
HM_GEN_630    ALL               All HM             C
                                Service Orchestration (SO)
HM_SO_19      US1_2             All HM             C                  pre-authorisation     sequences
                                                                      possible
HM_SO_562     US1_2             All HM             C
HM_SO_20      US1_2             HM CS              C
HM_SO_21      US1_2             HM CS              C
HM_SO_22      US1_2             HM CS              PC                 Cancellation is supported via
                                                                      dedicated operations of the
                                                                      service itself.
HM_SO_24      US1_2                                NC                 To be flown down to             the
                                                                      implementation phase
HM_SO_23      US1_2             HM CS              C
HM_SO_25      US1_2                                NC
                                          Web (WEB)
GS_WEB_74     US3_1                                NC                 Not part of SPS specification
GS_WEB_133    US5_3             HM PS              C                  One of the Mission Feasibility
                                                                      server's purpose is to centralise
                                                                      information       on       HMA
                                                                      acquisitions.
HM_WEB_247    US9_3             HM CDS             C                  Help & Documentation Desk
HM_WEB_694                      HM HDS             C
                                      Discovery (DISC)
GS_DISC_227   US8_2             GS CDS,            PC                 DAIl service registry will be the
                                GS SDS,                               operational service registry,
                                                                      however this registry can be
                                GS SCDS
                                                                      built upon distributed registries
                                                                      at the GS's through harvesting if
                                                                      available
GS_DISC_221   US8_1             GS CDS,            C                  DAIL service catalogue
                                GS SDS,
                                GS SCDS,
                                HM CDS,


                                               Pag. 168/182
               Title:             Architectural Design Technical Note
               Contract Ref.:     P-E190/DGIGSD-3556-05
               Int. Ref.:         P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
               Proj. Ref.:        HMA-DD-DAT-EN-001                 Date:        14/09/2007


                                  HM SDS,
                                  HM SCDS
GS_DISC_223   US8_1               GS CDS,            C
                                  GS SDS,
                                  GS SCDS,
                                  HM CDS,
                                  HM SDS,
                                  HM SCDS
GS_DISC_224   US8_1               GS CDS,            PC                 Harvesting and transaction
                                  GS SDS,                               mechanisms for the filling of the
                                                                        DAIL service registry are both
                                  GS SCDS,
                                                                        possible.
                                  HM CDS,
                                  HM SDS,
                                  HM SCDS
HM_DISC_225   US8_1               HM CDS,            C
                                  HM SDS,
                                  HM SCDS
HM_DISC_226   US8_1               HM CDS,            PC                 Local user profiles may be used
                                  HM SDS,                               for authorisation.
                                  HM SCDS
                                        Catalogue (CAT)
GS_CAT_31     US2_1                                  NC                 Scenario not covered
GS_CAT_33     US2_1,              GS CAT             C
              US2_1_3(optio       HM CAT
              n 4)
GS_CAT_45     US2_2               GS VFTP            PC                 Partly covered by Virtual FTP
                                                                        Server service
GS_CAT_56     US2_3               GS CAT             C
GS_CAT_57     US2_3               GS CDS,            C
                                  GS SDS,
                                  GS SCDS,
                                  HM CDS,
                                  HM SDS,
                                  HM SCDS
GS_CAT_59     US2_3               GS CDS             PC                 Subset has       not   yet   been
                                                                        defined
GS_CAT_58     US2_3               GS CAT             C
GS_CAT_61     US2_3               GS CAT             C
GS_CAT_62     US2_3               GS CAT             PC                 Warning       element          of
                                                                        requirement not covered
HM_CAT_38     US2_1,        US2_2, HM CDS,           C                  Authorisation is not performed
              US2_3               HM UMS                                by the service, but from PEP.

                                                 Pag. 169/182
              Title:                Architectural Design Technical Note
              Contract Ref.:        P-E190/DGIGSD-3556-05
              Int. Ref.:            P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
              Proj. Ref.:           HMA-DD-DAT-EN-001                 Date:        14/09/2007


HM_CAT_39    US2_1,        US2_2, HM CAT               C
             US2_3
HM_CAT_40    US2_1,        US2_2, HM CDS               C
             US2_3
HM_CAT_624   US2_1,        US2_2, HM CDS,              C
             US2_3                  HM CAT
HM_CAT_42    US2_1,        US2_2, HM CAT,              C
             US2_3                  GS CAT
HM_CAT_41    US2_1,        US2_2, HM CAT,              C
             US2_3                  GS CAT
HM_CAT_43    US2_1,        US2_2,                      NC
             US2_3
HM_CAT_44    US2_1,        US2_2, HM CAT               C
             US2_3
HM_CAT_34    US2_1                                     NC
HM_CAT_35    US2_1                                     NC
HM_CAT_47    US2_2                  HM VFS             PC                 Partly covered by Virtual FTP
                                                                          Server service
HM_CAT_48    US2_2                  HM VFS             PC                 Partly covered by Virtual FTP
                                                                          Server service
HM_CAT_49    US2_2                  HM VFS             PC                 Partly covered by Virtual FTP
                                                                          Server service
HM_CAT_63    US2_3                                     C
HM_CAT_67    US2_1,        US2_2, HM CAT               PC                 Feasible using query language
             US2_3                                                        but not specifically addressed
                                                                          in this phase
HM_CAT_312   US15_1                 HM OS              PC                 Notification service can be
                                                                          implemented        using    the
                                                                          ordering service as an option of
                                                                          the subscription service.
                                       Online Ordering (OO)
GS_OO_72     US3_1, US4_X, GS OS                       C
             US11_2        GS PS
GS_OO_68     US3_1                  GS OS              C
                                    HM OS
GS_OO_70     US3_1                  GS OS              C
                                    GS PS
GS_OO_71     US3_1                  GS OS              C
                                    GS PS
GS_OO_90     US4_1                  GS OS              C
                                    GS PS
GS_OO_146    US5_4                  GS OS              C

                                                   Pag. 170/182
               Title:             Architectural Design Technical Note
               Contract Ref.:     P-E190/DGIGSD-3556-05
               Int. Ref.:         P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
               Proj. Ref.:        HMA-DD-DAT-EN-001                 Date:        14/09/2007


                                  GS PS
GS_OO_255     US10_2                                 NC                 No order update supported;
GS_OO_261     US11_2              GS OS              PC                 Emergency priority included in
                                  GS PS                                 the priority scheme

GS_OO_262     US11_2              GS OS              C
                                  GS PS
GS_OO_269     US13_1              GS OS              C
                                  GS PS
GS_OO_270     US13_1              GS OS              C
                                  GS PS
GS_OO_271     US13_1              GS OS              PC
                                  GS PS
GS_OO_279     US13_2              GS OS              C
                                  GS PS
GS_OO_280     US13_2              GS OS              C
                                  GS PS
                                  Online Data Provision (ODP)
GS_ODP_236    US9_2               GS WMS             C
                                  GS WCS
GS_ODP_676    US9_2               GS OS              C
                                  GS PS
GS_ODP_684    US9_2               GS VFTP            C
                                          User Profile (UP)
GS_UP_162     US6_1               GS UMS             C
GS_UP_163     US6_1               GS UMS             PC                 A common set of profile data
                                                                        has been defined in the GMES
                                                                        Minimum Profile
GS_UP_164     US6_1               GS UMS             PC                 HMA entity allows mission GS's
                                                                        to map the user to a local
                                                                        account
                              Help & Documentation Desk (H&DD)
GS_H&DD_656   US13_4              GS HDS             C
GS_H&DD_658   US13_4              GS HDS             C
GS_H&DD_659   US13_4              GS HDS             C
HM_H&DD_661   US13_4              HM HDS             C
HM_H&DD_662   US13_4              HM HDS             C
HM_H&DD_663   US13_4              HM HDS             C
HM_H&DD_664   US13_4              HM HDS             C
                        Mission Planning (MP) - General Mission Planning


                                                 Pag. 171/182
             Title:           Architectural Design Technical Note
             Contract Ref.:   P-E190/DGIGSD-3556-05
             Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:    1   Rev.:   7
             Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:         14/09/2007


GS_MP_89    US4_1             GS PS              C
GS_MP_104   US4_2             GS PS              PC                 No percentage update but
                                                                    status changes
GS_MP_250   US10_1            GS PS              C
GS_MP_258   US11_1            GS PS              C
GS_MP_118   US5_1                                NC                 out    of   scope      of    HMA
                                                                    architecture
GS_MP_564   US5_3, US5_4                         NC                 No mission planning function
                                                                    identified      in       current
                                                                    architecture, only a feasibility
                                                                    server. It is assumed that such
                                                                    capability would be provided
                                                                    by an external service (e.g.
                                                                    Capacity           Management
                                                                    function)
GS_MP_132   US5_3, US5_4                         NC                 out    of   scope      of    HMA
                                                                    architecture
GS_MP_202   US7_1, US7_2                         NC                 Sharing of groung stations
                                                                    scenarios not covered in this
                                                                    phase of the project
GS_MP_205   US7_1                                NC                 See above
GS_MP_651   US5_1_1           GS PS              PC                 Scenario not directly covered
                                                                    but the    hot spots concept
                                                                    could be used as part of the
                                                                    DAA with the missions
HM_MP_424   ALL               HM PS              PC                 Feasibility  Server     to      be
                                                                    accessible to all users
HM_MP_425   ALL               HM PS              C                  Covered by Feasibility server
                                                                    and HM programming service
HM_MP_137   US5_3, US5_4      HM PS,       HM PC                    Authorisation is not the direct
                              UMS                                   responsibility of the services, but
                                                                    is a responsibility of HM UMS
HM_MP_138   US5_3                                NC                 See comment on GS_MP_564
HM_MP_152   US5_4                                NC                 See comment on GS_MP_564
HM_MP_142   US5_3                                NC                 See comment on GS_MP_564
HM_MP_144   US5_3(Option                         NC                 See comment on GS_MP_564
            2), US5_4
HM_MP_140   US5_3(Option HM PS                   C
            1),     US3_1,
            US3_1_1(Optio
            n 2)
HM_MP_113   US4_X             HM PS              C
HM_MP_632   US4_X             HM PS              C
HM_MP_565   US4_2             HM PS              C

                                             Pag. 172/182
             Title:              Architectural Design Technical Note
             Contract Ref.:      P-E190/DGIGSD-3556-05
             Int. Ref.:          P-E190/DGIGSD-0399-06             Issue:    1   Rev.:     7
             Proj. Ref.:         HMA-DD-DAT-EN-001                 Date:         14/09/2007


HM_MP_253   US10_1                                  PC                 Not specifically addressed but
                                                                       can be covered        by higher
                                                                       level services provided through
                                                                       the DAIL.
HM_MP_161   US5_4                HM PS              C
HM_MP_568   US13_2               HM PS              C
HM_MP_116   US4_2                HM PS              PC                 Alternatives investigation part
                                                                       of    the     requirement   not
                                                                       specifically addressed but can
                                                                       be covered by higher level
                                                                       services provided through the
                                                                       DAIL.
HM_MP_122   US5_1                HM PS              C                  DAA setups
HM_MP_649   US5_1_1                                 NC
HM_MP_650   US5_1_1                                 NC
                          Mission Planning (MP) - Feasibility Analyses
GS_MP_431   US3_1,        US4_X, GS PS              C
            US5_X
GS_MP_117   US5_1                GS PS              C                  Capability       included        but
                                                                       pratically difficult to use (mission
                                                                       GS's are reluctant to provide
                                                                       the information)
GS_MP_124   US5_2                GS PS              PC
HM_MP_130   US3_1,        US5_2, GS PS              PC                 Feasibility Server will only cover
            US5_1,        US5_3,                                       the light and estimate feasibility
            US5_4                                                      requests. Full feasibility request
                                                                       will be handled by the mission
                                                                       GS's directly
HM_MP_423   US5_2, US5_1, HM PS                     C
            US5_3, US5_4
HM_MP_143   US5_3,        US5_4, HM PS              C
            US5_2
HM_MP_131   US5_2, US5_1, HM PS                     C
            US5_3, US5_4
HM_MP_157   US5_4 (option HM PS                     C
            1)
                                     Order Handling (OH)
GS_OH_73    US3_1                GS OS              C
                                 GS PS
GS_OH_87    US4_1                GS PS              C
                                 GS OS
GS_OH_88    US4_1                GS PS              C
                                 GS OS
GS_OH_145   US5_4                GS OS              PC                 Technically       feasible   but   the

                                                Pag. 173/182
             Title:             Architectural Design Technical Note
             Contract Ref.:     P-E190/DGIGSD-3556-05
             Int. Ref.:         P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
             Proj. Ref.:        HMA-DD-DAT-EN-001                 Date:        14/09/2007


                                                                      scenario is not envisaged for
                                                                      any of the current mission GSs
GS_OH_147   US5_4               GS OS              C
                                GS PS
GS_OH_245   US9_3               GS OS              PC                 The type of subscription to
                                                                      provide is left to the mission GS
                                                                      to decide
GS_OH_589                                          NC
                                         HM Function
HM_OH_76    US3_1,        US5_X, HM OS             PC                 Authorisation is not the direct
            US4_X               HM PS                                 responsibility of the services but
                                                                      from PEP
HM_OH_427   US3_1, US5_X        HM OS              C
                                HM PS
HM_OH_77    US3_1, US4_X, HM OS                    C
            US3_1_1       HM PS
HM_OH_79    US3_1, US3_1_1 HM OS                   C
                                HM PS
HM_OH_637   US3, US4_X          HM OS              PC                 Not     mentionned   in   this
                                HM PS                                 document      but  technically
                                                                      feasible
HM_OH_691                       HM OS              PC
HM_OH_566   US3_1, US3_1_1 HM OS                   C
                                HM PS
HM_OH_110   US4_2               HM PS              C
HM_OH_81    US3_1               HM OS              C
                                HM PS
HM_OH_675   US5_2_1             HM PS              C
HM_OH_428   US3_1, US4_X                           NC                 There is no top-level ordering
                                                                      service covering both past and
                                                                      future products. This needs to
                                                                      be handled by higher level
                                                                      services (MMOH, COMU, etc)
HM_OH_429   US3_1                                  NC                 There is no top-level ordering
                                                                      service covering both past and
                                                                      future products. This needs to
                                                                      be handled by higher level
                                                                      services (MMOH, COMU, etc)
HM_OH_82    US3_1                                  NC                 There is no top-level ordering
                                                                      service covering both past and
                                                                      future products. This needs to
                                                                      be handled by higher level
                                                                      services (MMOH, COMU, etc)
HM_OH_567   US3_1, US4_X        HM PS,             C

                                               Pag. 174/182
             Title:           Architectural Design Technical Note
             Contract Ref.:   P-E190/DGIGSD-3556-05
             Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
             Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007


                              HM OS
HM_OH_80    US3_1, US4_X                         NC                 There is no top-level ordering
                                                                    service covering both past and
                                                                    future products. This needs to
                                                                    be handled by higher level
                                                                    services (MMOH, COMU, etc)
HM_OH_84    US3_1             HM OS              C
                              HM PS
HM_OH_626   GEN               HM OS              C
HM_OH_85    US3_1             HM OS              C
HM_OH_86    US3_1             HM OS              C
                              HM PS
HM_OH_111   US4_2             HM OS              C                  Through the      use   of    virtual
                              HM PS                                 sensor_ids

HM_OH_248   US9_3             HM OS              PC                 The delegated subscription
                                                                    service    described     in the
                                                                    requirement is to be provided
                                                                    by higher level services
HM_OH_251   US10_1                               NC                 Scenario not covered
HM_OH_256   US10_2                               NC                 Scenario not covered
HM_OH_692   US10_2, US10_3                       NC                 Scenario not covered
HM_OH_693   US10_2, US10_3                       NC                 Scenario not covered
HM_OH_257   US10_2                               NC                 To be handled by higher level
                                                                    services
HM_OH_259   US11_1            HM OS              C
HM_OH_264   US11_2                               NC                 Not clear what the specific
                                                                    tools and functions are.
HM_OH_267   US12_1            HM OS              PC                 All transactions are protected
                                                                    against unauthorised access
HM_OH_268   US12_1                               NC                 No     confidentiality           level
                                                                    concept addressed           in     this
                                                                    phase of the project
HM_OH_272   US13_1            HM OS              C
HM_OH_277   US13_1            HM OS              C
HM_OH_278   US13_1            HM OS              C
HM_OH_273   US13_1, US13_2 HM OS                 C
                              HM UMS
HM_OH_274   US13_1            HM OS              C
HM_OH_275   US13_1            HM OS              C
HM_OH_276   US13_1            HM OS              C
HM_OH_284   US13_2            HM OS              C


                                             Pag. 175/182
              Title:           Architectural Design Technical Note
              Contract Ref.:   P-E190/DGIGSD-3556-05
              Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:    7
              Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007


                               HM PS
HM_OH_233    US9_1                                  NC               Products are not delivered to
                                                                     DAIL, but directly to users.
HM_OH_612    US10_3                                 NC               Scenario not covered
HM_OH_590    US10_3                                 NC               Scenario not covered
HM_OH_591    US10_3                                 NC               Scenario not covered
                               Monitoring & Control (M&C)
HM_M&S_287   US13_3            All,                 PC               All requests will be logged. No
                               HM M&C                                session mechanism.

HM_M&S_288   US13_3            All,                 C
                               HM M&C
HM_M&S_289   US13_3                                 NC
HM_M&S_290   US13_3                                 NC
HM_M&S_665   US13_3            HM M&C               C
HM_M&S_291   US13_3            HM M&C               C
                                      Pricing & Billing (P&B)
GS_P&B_304   US14_2                                 NC               FAS scenario not covered
GS_P&B_526   US14_2            GS OS                C                For orders only
GS_P&B_296   US14_2                                 NC
GS_P&B_297   US14_2                                 NC
GS_P&B_298   US14_2                                 NC
GS_P&B_299   US14_2                                 NC
GS_P&B_302   US14_2                                 NC
GS_P&B_666   US14_4                                 C
GS_P&B_668   US14_4            GS OS                C
HM_P&B_294   US14_1            HM OS                C                GetQuotation
HM_P&B_295   US14_1(Option                          NC               For GMES there are no such
             1)                                                      transactions
HM_P&B_303   US14_2            HM OS                C
HM_P&B_669   US14_4                                 C
670          US14_4                                 C
672          US14_4            HM OS                C
                               HM PS
673          US14_4            HM OS                C
                               HM PS
                                User Management (USM)
GS_USM_2     US8_2, US1_3      GS UMS               C
GS_USM_5     US1_1, US1_2      GS UMS               C

                                                Pag. 176/182
              Title:             Architectural Design Technical Note
              Contract Ref.:     P-E190/DGIGSD-3556-05
              Int. Ref.:         P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
              Proj. Ref.:        HMA-DD-DAT-EN-001                 Date:        14/09/2007


GS_USM_134   US5_3(Option        GS UMS             C
             2), US6_2           HM UMS
GS_USM_184   US6_2               GS UMS             C
                                 HM UMS
GS_USM_180   US6_2               GS UMS             C                  No such policy exists as yet
GS_USM_181   US6_2               GS UMS             C                  No such policy exists as yet
GS_USM_182   US6_2               GS UMS             C
                                 HM UMS
GS_USM_292   US14_1              HM UMS             C                  Billing issues have been ignored
                                                                       in this phase of the project
GS_USM_193   US6_3               HM UMS             PC                 Federation mechanism of the
                                                                       UM concept
GS_USM_165   US6_1,                                 C                  GS operators will have an HMA
             US6_1_1(Optio                                             identity
             n 1)
GS_USM_167   US6_1,        GS UMS                   PC                 GS may prefer to manage local
             US6_1_1(Optio                                             profiles rather than central
             n 1)                                                      ones, however this is not
                                                                       imposed by the system.
GS_USM_168   US6_1,        GS UMS                   PC                 Not yet clear how GMES users
             US6_1_1(Optio                                             will be registered at mission GS's
             n 2)                                                      required local accounts (e.g.
                                                                       SPOT Image)
HM_USM_170   US6_1,        US6_2, HM UMS            C
             US6_3
HM_USM_171   US6_1,        US6_2, HM UMS            C
             US6_3
HM_USM_172   US6_1,        US6_2, HM UMS            C
             US6_3
HM_USM_618                       HM UMS             PC                 At HMA client level; the
                                                                       minimum profile does not
                                                                       include all the parameters
                                                                       specified in the requirement.
HM_USM_636                                          NC                  At the moment only the user
                                                                       managment does not provide
                                                                       this information.
HM_USM_173   US6_1               HM UMS             C
HM_USM_188   US6_2, US6_3        HM UMS             C
HM_USM_174   US6_1, US6_2        HM UMS             C
HM_USM_175   US6_1,        HM UMS                   PC                 The registration / update user
             US6_1_1(Optio                                             profile    process    is   not
             n 1)                                                      completely specified.
HM_USM_176   US6_1,                                 TBD
             US6_1_1(Optio

                                                Pag. 177/182
                Title:           Architectural Design Technical Note
                Contract Ref.:   P-E190/DGIGSD-3556-05
                Int. Ref.:       P-E190/DGIGSD-0399-06             Issue:   1   Rev.:    7
                Proj. Ref.:      HMA-DD-DAT-EN-001                 Date:        14/09/2007


              n 2)
HM_USM_179    US6_1              HM UMS             C
                     Announcement of Opportunity Management (AOM)
GS_AOM_625                                          NC                 Scenario not covered
GS_AOM_305    US14_3                                NC                 Scenario not covered
HM_AOM_563    US14_3                                NC                 Scenario not covered
HM_AOM_307    US14_3                                NC                 Scenario not covered
HM_AOM_309    US14_3                                NC                 Scenario not covered
HM_AOM_644                                          NC                 Scenario not covered
                                      Processing (PROC)
GS_PROC_494   US17_1                                NC                 Scenario not covered
GS_PROC_570   US17_1                                NC                 Scenario not covered
GS_PROC_572   US17_1                                NC                 Scenario not covered
GS_PROC_574   US17_1                                NC                 Scenario not covered
GS_PROC_575   US17_1                                NC                 Scenario not covered
GS_PROC_576   US17_1                                NC                 Scenario not covered
496           US17_1                                NC                 Scenario not covered
HM_PROC_577   US17_1                                NC                 Scenario not covered
HM_PROC_578   US17_1                                NC                 Scenario not covered
HM_PROC_579   US17_1                                NC                 Scenario not covered
HM_PROC_580   US17_1                                NC                 Scenario not covered
HM_PROC_581   US17_1                                NC                 Scenario not covered
HM_PROC_582   US17_1                                NC                 Scenario not covered
                                 Archiving & Inventory (ARCH)
GS_ARCH_315   US16_1                                NC                 Scenario not covered
GS_ARCH_619                      GS OS              C
GS_ARCH_622                      GS OS              PC                 No formal        agreed   product
                                                                       format list
GS_ARCH_314   US16_1                                NC                 Scenario not covered
GS_ARCH_685   US9_5              GS VFTP            C                  Virtual FTP Service scenario.
HM_ARCH_316   US16_1                                NC                 Scenario not covered
HM_ARCH_317   US16_1                                NC                 Scenario not covered
HM_ARCH_610                                         NC                 Scenario not covered
HM_ARCH_686   US9_5              HM VFS             C
HM_ARCH_687   US9_5              HM VFS             C
HM_ARCH_688                      HM VFS             C
                                      Dissemination (DIS)

                                                Pag. 178/182
              Title:            Architectural Design Technical Note
              Contract Ref.:    P-E190/DGIGSD-3556-05
              Int. Ref.:        P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
              Proj. Ref.:       HMA-DD-DAT-EN-001                 Date:        14/09/2007


GS_DIS_75    US3_1, US9_1       GS OS              C
GS_DIS_230   US9_1                                 NC                 The user cannot specify the FTP
                                                                      URL where put the data.
GS_DIS_263   US11_2, US10_3 GS OS                  C
GS_DIS_244   US9_3              GS OS              C
                                HM OS
GS_DIS_231   US9_1(Option       GS OS              C
             1)
GS_DIS_232   US9_1(Option                          NC                 IT is not possible to specify 2
             2)                                                       different delivery addresses in
                                                                      the ordering ICD.
GS_DIS_246   US9_3              GS OS              C
GS_DIS_583   US9_4                                 NC                 Scenario not covered
GS_DIS_584   US9_4                                 NC                 Scenario not covered
GS_DIS_585   US9_4                                 NC                 Scenario not covered
HM_DIS_421                      HM OS              C
HM_DIS_235   US9_1(Option       HM OS              PC                 Option 3 covered only
             2), US3_1_3
HM_DIS_420   US9_1(Option                          NC
             2)
HM_DIS_586   US9_4                                 NC                 Scenario not covered
HM_DIS_587   US9_4                                 NC                 Scenario not covered
HM_DIS_588   US9_4                                 NC                 Scenario not covered
                                    Flight Dynamics (FD)
GS_FD_126    US5_X              GS PS              C                  SPS EO has not yet completely
                                                                      specified how these information
                                                                      are made available.
GS_FD_135    US5_X              GS PS              C                  SPS EO has not yet completely
                                                                      specified how these information
                                                                      are made available.
GS_FD_136    US5_X              GS PS              PC                 SPS EO has not yet completely
                                                                      specified how these information
                                                                      are made available.
                                                                      Nominal or recent orbit data
                               Ground Stations Network (GSN)
GS_GSN_210   US7_2                                 NC                 Scenario not covered
HM_GSN_206   US7_1, US7_2                          NC                 Scenario not covered
HM_GSN_207   US7_1, US7_2                          NC                 Scenario not covered
HM_GSN_208   US7_1, US7_2                          NC                 Scenario not covered
HM_GSN_209   US7_1, US7_2                          NC                 Scenario not covered
HM_GSN_213   US7_2                                 NC                 Scenario not covered

                                               Pag. 179/182
                     Title:            Architectural Design Technical Note
                     Contract Ref.:    P-E190/DGIGSD-3556-05
                     Int. Ref.:        P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                     Proj. Ref.:       HMA-DD-DAT-EN-001                 Date:        14/09/2007


HM_GSN_214         US7_2                                  NC                 Scenario not covered
HM_GSN_215         US7_2                                  NC                 Scenario not covered
HM_GSN_218         US7_2                                  NC                 Scenario not covered
HM_GSN_219         US7_2                                  NC                 Scenario not covered
HM_GSN_220         US7_2                                  NC                 Scenario not covered



8.3    Scenarios vs. Protocol traceability Matrix

Scenario                         Support         Protocol / Architecture
Use case 1 - The user/operator wants a harmonised access to the same service across the
mission ground segments

US1_1 - Standardised GS          Yes               HTTP [RD42], SOAP [RD45], WSDL
service                                            [RD08], ws-addressing [RD25]
US1_2 - Compound services        Yes               BPEL [RD24]
US1_3 - Access to the GS         NO                N/A
services through the use of
Mission Furnished Items
Use case 2 - The user/operator wants to discover available data across multiple –missions

US2_1 - Replicated catalogue          NO          N/A
US2_2 - Delegated catalogue           Yes         EbRIM [RD47], [AD11], [AD08], [RD44],
                                                  GML [RD28]
US2_3 - Interoperable            Yes              EbRIM [RD47], [AD11], [AD08], [RD44],
catalogue interfaces                              GML [RD28]
Use Case 3 - The user/operator wants to place and monitor HM orders

US3_1 - HM ordering function          Yes          Order ICD [AD05], Programming ICD
                                                   [AD10]
Use case 4 - The user/operator want an observation with certain sensing characteristics,
without the need to know all about the satellites

US4_1 - Spatio-temporal order    Yes                Programming ICD [AD10]
definition
US4_2 - Mission-independent      Yes                Programming ICD [AD10]
spatio-temporal order definition
Use case 5 - The user/operator wants to be able to dispatch HM orders with a high
likelihood of acceptance

US5_1 - Advertising pre-planned Yes               Programming ICD [AD10], WFS [RD30]
acquisitions
 US5_2 - Advertising sensing     Yes              Programming ICD [AD10]
opportunities and constraints
 US5_3 - Cooperative planning    Yes              Programming ICD [AD10]
of the acquisition schedule
 US5_4 - Delegation of planning No
for sections of users
Use case 6 - The user/operator wants seamless access to the services of any mission from
a single login

US6_1 - GS level policy               Yes                  Policy Enforcement Point [RD27],

                                                      Pag. 180/182
                     Title:            Architectural Design Technical Note
                     Contract Ref.:    P-E190/DGIGSD-3556-05
                     Int. Ref.:        P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                     Proj. Ref.:       HMA-DD-DAT-EN-001                 Date:        14/09/2007


Scenario                         Support              Protocol / Architecture
enforcement                                            [RD46]
US6_2 - Delegated policy         Yes                   Policy Enforcement Point [RD27],
enforcement                                            [RD46]
US6_3 - Cooperative policy       Yes                   Policy Enforcement Point
enforcement
Use case 7 - The user/operator wants flexibility to enable the location of downlink to be
specified to other than nominal mission ground stations

US7_1 - Peer-to-peer ground      No
stations
 US7_2 - HM stations             No
management
Use case 8 - The user/operator wants access to details of the services provided by the
missions

US8_1 - Mission details provided Yes                UDDI [RD12]
at service registration
 US8_2 - Dynamic service         Yes                UDDI [RD12], CSW [RD32], [RD44]
discovery
Use case 9 - The user/operator wants access to mission’s archived products in standard
format

 US9_1 - Standard electronic     Yes               FTP [RD43], LDAP [RD49]
and/or hard-copy
dissemination
 US9_2 - Online Data Access      Yes               FTP [RD43], LDAP [RD49], WCS [RD31],
(ODA)                                              WMS [RD29], WFS [RD30],
 US9_3 - HM Subscription service Yes               Order ICD [AD05]
 US9_4 - Satellite multicast     Yes               TBD
service
Use case 10 - The user/operator wants to place orders that depends on the output of
other missions

US10_1 - Mission-in-the-loop          No
service
US10_2 - Orders dependencies          Yes                  BPEL [RD24], Programming [AD10],
                                                           Order ICD [AD05]
US10_3 - Inter-linked Orders     No
Use case 11 - A user/operator wants to place a high-priority order

US11_1 - High-priority orders    Yes               Order ICD [AD05]
US11_2 - International Charter:  Yes               Order ICD [AD05]
Space and Major Disasters
Use case 12 - A user/operator wants to place a confidential order

US12_1 - Confidential orders     TBD
Use case 13 - The user/operator wants to manage and control his HM requests
US13_1 - Order monitoring        Yes             Order ICD [AD05]
US13_2 - Order cancellation      Yes             Order ICD [AD05]
US13_3 - Central requests        Yes             EO DAIL
monitoring
US13_4 - HM Help &               Yes             N/A
Documentation Desk

                                                      Pag. 181/182
                     Title:            Architectural Design Technical Note
                     Contract Ref.:    P-E190/DGIGSD-3556-05
                     Int. Ref.:        P-E190/DGIGSD-0399-06             Issue:   1   Rev.:   7
                     Proj. Ref.:       HMA-DD-DAT-EN-001                 Date:        14/09/2007


Scenario                         Support          Protocol / Architecture
Use Case 14 - The user/operator wants a coherent HM pricing and billing mechanism

US14_1 - Pricing and billing in  No
the HM environment
US14_2 - Pricing and billing via Yes                GCM GS
a Financial Accounting System
US14_3 - HM Announcement of No
Opportunities Management
US14_4 - Quota management        Yes                TBD
for GMES requests
Use Case 15 - The user/operator wants notification of product availability

US15_1 - Notification of product Yes              WS Notification (TBC)
availability
Use Case 16 - The missions want to share and exchange archived products

US16_1 - Sharing of archives     No                 Only via Online data Access
Use Case 17 - The user/operator wants his processing algorithms to be applied on the
archived data

US17_1 – User-Driven Processing       No                   Draft ICD available
On-Demand




                                                      Pag. 182/182

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:8
posted:8/19/2011
language:English
pages:182