COMPETITIVENESS AND INNOVATION FRAMEWORK PROGRAMME
ICT Policy Support Programme (ICT PSP)
ICT PSP call identifier: ICT PSP-2008-2
ICT PSP main Theme identifier: CIP-ICT-PSP.2008.1.1
Project acronym: SPOCS
Project full title: Simple Procedures Online for Cross-border Services
Grant agreement no.: 238935
Technical Overview of WP4 Interoperability
Framework and Development Activities - Update
Deliverable Id :
D4.7
Deliverable Name :
Open Modules
Status :
Draft
Dissemination Level :
SPOCS Internal
Due date of deliverable :
31.08.2011
Actual submission date :
31.08.2011
Work Package :
WP4 Interoperable eService Directories
Organisation name of lead contractor
for this deliverable :
BVA (DE)
Author(s):
Partner(s) contributing :
Fraunhofer FOKUS (DE)
Document: Modules: SPOCS.AT, ICTU (NL), YPES (GR), EBR
Feedback: all WP4 partners
Abstract: This deliverable provides the code of the open modules and describes an
updated technical overview of the modules, their technical integration, technical main
decisions and development guidelines. This deliverable represents the updates of
deliverable D4.4 including amendments from partners of the first piloting as well as
partners of the enlargement. The updated schemas, specifications and guidelines are
described in the dependent deliverable D4.6.
1
History
Version
2
Date
Modification reason
Modified by
0.1 15.06.2011
Initial draft and inclusion of D4.4 content
FOKUS
0.5 01.08.2011
Deliverable ready for Internal Review
FOKUS
0.7 <<T – 20 days>>
Deliverable ready for External Review
1.0 <<T – 5 days>>
Deliverable ready to be submitted to the
European Commission
Table of contents
History ....................................................................................................................................... 2
Table of contents ....................................................................................................................... 3
List of figures ............................................................................................................................. 6
List of Tables ............................................................................................................................. 7
List of Abbreviations ................................................................................................................... 8
1
Introduction to the deliverable ............................................................................................12
The project: SPOCS ..............................................................................................................12
1.1
Methodology ...................................................................................................................13
1.2
Relations to internal SPOCS environment ......................................................................13
1.3
Relations to external SPOCS environment .....................................................................14
1.4
Quality management ......................................................................................................14
1.5
Risk Management ..........................................................................................................14
2
2.1
2.2
3
3.1
Technical Overview ............................................................................................................15
Components ...................................................................................................................16
2.1.1
Search .................................................................................................................16
2.1.2
Transformation.....................................................................................................17
2.1.3
MIDB access........................................................................................................18
2.1.4
Outlook ................................................................................................................19
Information / Data Objects ..............................................................................................19
2.2.1
Equivalence Information ......................................................................................21
2.2.2
Change Information .............................................................................................23
2.2.3
Outlook ................................................................................................................24
Technical Decisions ...........................................................................................................25
Data Sources and Integration .........................................................................................25
3.1.1
Frontend vs. Backend Integration ........................................................................25
3.1.2
Quality Criteria Information Retrieval and Data Source Selection.........................26
3.2
Change Tracking ............................................................................................................26
3.3
MIDB Technology and Query Language .........................................................................29
4
4.1
3
Implementation ..................................................................................................................31
Development ..................................................................................................................31
4.1.1
Environment ........................................................................................................31
4.1.2
Programming Conventions...................................................................................31
4.1.3
Code / Inline Documentation ................................................................................31
4.1.4
4.2
4.3
4.4
4.5
4.6
5
Status and Outlook ..............................................................................................32
Dependency Management..............................................................................................32
4.2.1
Mechanism ..........................................................................................................32
4.2.2
Maven Project Object Model ................................................................................33
4.2.3
WP4 eServices Building Block Project Structure ..................................................34
4.2.4
Status and Outlook ..............................................................................................35
Project Versioning and Conventions ...............................................................................36
4.3.1
Versioning Schema ..............................................................................................36
4.3.2
SVN .....................................................................................................................36
4.3.3
Namespaces ........................................................................................................37
4.3.4
Status and Outlook ..............................................................................................37
Logging ..........................................................................................................................37
4.4.1
Mechanism and Conventions ...............................................................................37
4.4.2
Logging Levels.....................................................................................................38
4.4.3
Dependency to Monitoring ...................................................................................38
4.4.4
Status and Outlook ..............................................................................................38
Error Handling and Exceptions .......................................................................................38
4.5.1
Mechanism ..........................................................................................................38
4.5.2
Fault Conventions ................................................................................................39
4.5.3
Status and Outlook ..............................................................................................39
Testing and Quality Assurance .......................................................................................39
4.6.1
Mechanism and Test Methods .............................................................................39
4.6.2
Test Models, Cases and Conventions ..................................................................39
4.6.3
Test Automatisation .............................................................................................40
4.6.4
Test Results Presentation ....................................................................................40
4.6.5
Sonar and Quality Assurance ..............................................................................40
4.6.6
Status and Outlook ..............................................................................................40
Distribution and Change Management ...............................................................................41
5.1
Deployment for the Pilots ...............................................................................................41
5.2
Release Management ....................................................................................................41
5.3
Change Management .....................................................................................................42
Conclusions ...........................................................................................................................43
A.
Appendix A – Acceptance Criteria ......................................................................................45
B.
Appendix B – Risk List .......................................................................................................48
C.
Appendix C – Technical Code Lists ................................................................................50
4
D.
Appendix D – Enlargement Activities ..............................................................................51
E.
Appendix E – Task list before WP1 / WP4 scrum ...............................................................52
F.
Appendix F – Obsoleted Parts of Deliverable D4.4 ............................................................60
2 Technical Overview ................................................................................................................60
2.2 Components........................................................................................................................61
2.2.1 Sequences ................................................................................................................62
2.2.2 Access ......................................................................................................................65
2.2.3 Provision ...................................................................................................................66
2.2.4 Search ......................................................................................................................67
2.2.5 Transformation ..........................................................................................................68
3.4 Routing and Message Technology ......................................................................................69
5
List of figures
Figure 1: WP4 Relations to National Infrastructure and WP1 ....................................................15
Figure 2: Inter-WP Relations .....................................................................................................16
Figure 3: Overview WP4 Search Interface and Relations ..........................................................17
Figure 4: Overview WP4 Transformation Interface and Relations .............................................18
Figure 5: Overview WP4 MIDB Access (Example Service Entity)..............................................19
Figure 6: Overview Core Objects of MIDB and Schemas ..........................................................20
Figure 7: Multilingual Realisation (Update) ................................................................................21
Figure 8: Configuration Set .......................................................................................................21
Figure 9: Equivalence Information .............................................................................................22
Figure 10: Change Information (Update) ...................................................................................23
Figure 11: Overview WP4 Open Modules (OMs), their Integration Points (WP4 NCs) and the
Technical Use Cases they support (Deprecated) ......................................................................61
Figure 12: Inter-WP Relations (Deprecated) .............................................................................62
Figure 13: Sequence for search within MIDB (Deprecated) .......................................................63
Figure 14: Sequence for cross-border lookup scenario (usage of WP4 IL) (Deprecated) ..........64
Figure 15: Access Component (Deprecated) ............................................................................65
Figure 16: Access Components (Update) (Deprecated) ............................................................66
Figure 17: Provision Component for Search Core Info at MIDB Scenario (Deprecated) ............66
Figure 18: Provision Component for Lookup Full-Info Scenario (Deprecated) ...........................67
Figure 19: Search Component for SearchCore Info at MIDB Scenario (Deprecated) ................67
Figure 20: Search Component for Lookup Full Info Scenario (Deprecated)...............................68
Figure 21: Transformation Components (Deprecated) ..............................................................68
6
List of Tables
Table 1: Examples for Equvialence ...........................................................................................22
Table 2: Content table with version numbers ............................................................................28
Table 3: Change table for versioning.........................................................................................28
Table 4: Content tables with different version status .................................................................28
Table 5: Acceptance Criteria List ..............................................................................................47
Table 6: Example risk list ..........................................................................................................48
Table 7: Exception codes ..........................................................................................................50
Table 8: Task list before alignment of WP1 / WP4 development ...............................................57
7
List of Abbreviations
Abbreviation
Explanation
API
Application Programming Interface
CET
Central European Time
CIP
Competitiveness and Innovation Framework Programme
CR
Candidate for Release
CS
Configuration Set
CXF
CeltiXFire
DAO
Data Access Object
DB
Database
DNS
Domain Name System
DoW
Description of Work
EIF
European Interoperability Framework
eSD
eService Directory
EU
European Union
FK
Foreign Key
GA
General Available
HTML
Hypertext Markup Language
ICT
Information and Communication Technology
ID
Identifier
ISO
International Standardization Organization
JAX-B
Java Architecture for XML Binding
JAX-WS
Java API for XML – Web Services
JDK
Java Development Kit
8
JPA
Java Persistence API
JNDI
Java Naming and Directory Interface
JRE
Java Runtime Environment
JUnit
Java Unit Testing Framework
LIB
Library
MIDB
Meta Information Database
MS
Member State
NACE
Statistical Classification of Economic Activities in the European Union
NC
National Connector
OM
Open Module
OWL
Web Ontology Language
PHP
Hypertext Preprocessor
PK
Primary Key
POM
Project Object Model
PSC
Point of Single Contact
PSP
Policy Support Programme
QA
Quality Assurance
RDF
Resource Description Framework
RDFS
RDF Schema
REA
Real Estate Agent
SC
Service Catalogue
SCM
Source Code Management
SLF4J
Simple Logging Façade for Java
SOAP
Simple Object Access Protocol
SparQL
SparQL Protocol and RDF Query Language
SPOCS
Simple Procedures Online for Cross-border Service
9
SQL
Structured Query Language
SVN
Subversion
TA
Technical Annex
TSL
Trust-Service Status List
UDDI
Universal Description, Discovery and Integration
URL
Uniform Resource Locator
UTC
Coordinated Universal Time
UTF
Unicode System Transformation Format
WP
Work Package
WS
Web Service
WSDL
Web Services Description Language
WSLIB
Web Services Library
XML
Extensible Markup Language
XSD
XML Schema
10
Executive summary
SPOCS – Simple Procedures Online for Cross-border Services – aims at providing seamless
cross-border electronic procedures for setting up a business in another EU country in the
context of the Services Directive. The project builds on solutions developed in Member States
as they implement the Services Directive. Building on compliancy with the Services Directive,
SPOCS is also about competitiveness and it has been set up on the basis of the 2008 CIP ICT
PSP Programme of Work (project reference: 238935).
As described in the SPOCS Technical Annex, the current deliverable is the result of the task
“T4.10: Update Modules”. The update of the modules has to integrate the requirements from the
enlargement participants to enable them connecting with pilots from the first pilot phase and
including their approaches from the specific national infrastructure. The update is based on the
updated specifications and schemas as well as feedback of pilots related to the existing
architecture and scenarios. This deliverable represents the code of the modules and gives an
described technical overview.
After several discussions with enlargement participants and pilots from the first phase a
simplification of the WP4 architecture and scenarios was realized. The main purpose is to focus
on syndication as cross-border interoperability mechanism and use WP4 as connection between
National Connectors and the Meta Information Database storing the national and syndicated
foreign information in a common schema and with common loading and querying functionality.
Based on the decisions some components were merged like search and provision, some are
extended like transformation and some are deprecated like routing (see section 2).
The specific amendments and change requests of the partners are integrated in the update of
the specification and schemas as described in deliverable D4.6. This deliverable focuses on the
technical aspects and gives an overview about decisions and development as well as
implementation guidelines. From a technical perspective no major changes apart from the
described realignment of the components are required. The enlargement activities related to
technical descriptions are listed in the appendix D. Using different technologies in the
enlargement member states has actually no impact on the described SPOCS solution.
Section 3 describes main technical decisions. So far there are no major changes to the
description in D4.4.
As there were many bilateral discussions and explanations as well as missing documentation
about the implementation approach a section describing the main approaches is integrated. This
concentrates on the scope of developers for the SPOCS modules (see section 4) and for the
integration with and deployment to the national infrastructure (see section 5). The described
approaches are technical guidelines covering the lifecycle of the WP4 modules.
Every section is giving a status and outlook. There is still work to be done realigning and
refactoring some parts of the components as well as for the support of the lifecycle. Required
activities are planned and will include feedback from the piloting phase and results from the
semantic task within the next releases.
11
1 Introduction to the deliverable
WP4 is handling information needed to select the right procedures, documents, services and
eServices within an application process between Service Provider and Point of Single Contact.
WP4 focus on providing foreign information cross-border based on a common specification
implemented by open modules that enhance the Point of Single Contact solutions. The
information of different member states is combined to improve the user experience by wellknown services and documents from his home member state. Moreover WP4 is a basement to
support further alignment, discussions and orchestrations of services and eservices.
The deliverable D4.7 “Update Modules” provides the updated code of the WP4 open modules
and gives a technical overview of the component structure, decisions and implementation
guidelines. The update integrates requirements from the first piloting partners and the
enlargement particpants describing their technical infrastructure. The deliverable is an update of
deliverable D4.4 “Open Modules” and has a strong dependency to deliverable D4.6 “Updated
common governance scheme/guideline”.
The Open Modules are the implementation of the defined scenarios, architecture and
specifications updated by the feedback of the partners. The modules will be further developed
during the piloting phase as support (bugfixing) and integration of new or changed functionality
(new releases) and involvement of results of the semantic task (T4.11 / D4.8 – release 2.0).
The project: SPOCS
SPOCS – Simple Procedures Online for Cross-border Services – aims at providing seamless
cross-border electronic procedures for setting up a business in another EU country in the
context of the Services Directive. The project builds on solutions developed in Member States
as they implement the Services Directive. Building on compliancy with the Services Directive,
SPOCS is also about competitiveness and it has been set up on the basis of the 2008 CIP ICT
PSP Programme of Work (project reference: 238935).
In other words, SPOCS is expected to:

Improve the competitiveness of European businesses and particularly SMEs by
providing a fully interoperable PSC (point of single contact) across all Member States.

Enable all Member States to quickly adopt the solutions developed and enable all
businesses to benefit from the reduction of administrative burdens.
Furthermore, SPOCS is also expected to:
12

Build on MS activities as they implement the Services Directive

Improve the efficiency of cross-border cooperation

Support service innovations for businesses by reducing time and energy loss

Increase cross-border activities

Foster competitiveness and contribute to the development of trade

Accelerate the development of common technology requirements

Modernise the services offered by the public administrations.
The output of the project is to provide for the necessary building blocks to achieve the second
generation Points of Single Contact (PSC) by providing seamless cross-border electronic
procedures.
1.1 Methodology
The deliverable has four parts: the coding of the modules including inline documentation, the
onboarding of the enlargement participants related to technical issues, the description of the
technical overview within this document and the coordination of the activities with the pilots.
The coding was done by the development team. The development coordination was aligned with
the WP1 development activities as the dependency of both development activities is very strong
and the used resources are the same. Development coordination was changed from WP4
specific task list (appendix E) and coordination to WP1/WP4 scrum approach including different
user stories and acceptance tests for WP4. Further information is available through WP1.
The onboarding was realized through several bilateral discussions between enlargement
participants and WP4 coordination. The descriptions are organized by the enlargement
participants on their own. A basic analysis was made by the WP4 coordination. Feedback of first
pilots and enlargement was combined.
The technical overview is written as documentation of the activities and for getting a better
understanding through the implementation. The overview is written by the WP4 technical
coordination. Partner contribution was envisaged but not available.
The coordination with the pilots is also organized on bilateral and regular WP4 conference calls.
The results are integrated into the task list. After alignment of the development activities the
implementation issues are forwarded to this group and other issues are discussed bilaterally or
forwarded to WP5 and WP7.
There was no specific task force or group concentrating on a specific subtask. The results and
feedbacks are discussed in an open approach within the whole WP4 group. There is no
difference in requirements or priorities between amendments of enlargement participants or first
pilots. The priority is based on the given timelines and available resources.
Moreover all common procedures (e.g. QA) are used to align WP4 activities with SPOCS
framework.
1.2 Relations to internal SPOCS environment
The WP4 open modules are using results from WP1 to synchronize the information crossborder. Moreover the piloting feedback influenced the update of the modules and lead to
changes in the usage of the scenarios.
The update of this deliverable leads to the need of an update of the syndication and slight
adjustments of the National Connectors (WP5).
The dependencies are managed through conference calls and with WP1 through the combined
development coordination.
This deliverable is especially dependent on deliverable D4.6 describing the update of the
schemes and specifications as well as guidelines.
13
1.3 Relations to external SPOCS environment
The results of this deliverable are represented in the reference environment and can be used by
external stakeholders. There is actually no standardization activity as previously the semantic
tasks needs to produce first results and piloting feedback needs to show the usability of the
concept.
The basic solution is envisaged to be used also in different scenarios. The main idea of the
update is also to switch to uncoupled catalogues and directories that can be combined for
different objectives and projects. WP4 starts collaborating with specific member state projects.
Industry stakeholders are mainly involved through the piloting activities using WP4 results to
connect / enhance their products.
1.4 Quality management
The quality management follows the described quality assurance process from WP7. The
acceptance criteria are listed in the appendix. The quality assurance of the code is tested by the
specific developers (see also section 4.6). The technical overview is checked by several internal
and an external reviewer.
1.5 Risk Management
The risks have to be assigned to the different subtasks within this deliverable. For the coding
risks are discussed within the development team and forwarded to the WP and SPOCS
coordination. Risks are often addressed and measures defined. Most of the measures did not
lead to a complete successful handling. Impacts based on this are also addressed especially to
the SPOCS coordination and pilots.
The risks of this deliverable are listed in the appendix. The risks related to resources and
development is also listed in the risk reports for WP7 and the executive board.
Risks and problems are addressed by technical coordination through WP coordination up to
SPOCS coordination.
14
2 Technical Overview
This section gives an overview about the WP4 building block with the open modules /
components and the dependency to the national infrastructure and WP1 syndication. It is based
on the description of the scenarios within deliverable D4.2 “specifications”. The pilots will
concentrate on the usage of syndication as the interoperability mechanism related to
discussions with them. Thus the interoperability layer is not further developed until there is a
specific request from pilots.
The actual scenario for WP4 eservices is to query information through the search open module
and to load information through transformation and to cross-border synchronizing them through
WP1 syndication.
The old scenario description of deliverable D4.4 is updated through this section and the
obsoleted description attached in the Appendix F – Obsoleted Parts of Deliverable D4.4 for
information purposes related to the evolution of the WP4 solution. The main purpose is to focus
on syndication as interoperability mechanism, merge search and provision open module for
simplifying communication with the national connectors and to skip the access open module as
information is provided as Open Data.
cmp SPOCS
SPOCS
MS A
National Infrastructure
WP4 eserv ices
MS B
WP1 syndication
WP1 syndication
WP4 eserv ices
National Infrastructure
Figure 1: WP4 Relations to National Infrastructure and WP1
Figure 1 shows the dependency of WP4 eservices to the national infrastructure and WP1
syndication. The national infrastructure is using WP4 eservices open modules to load and
search the Meta Information Database (MIDB). The WP4 eservices open module is using the
syndication to provide national information for other member states. The WP1 syndication open
modules use the WP4 eservices open modules to integrate foreign information to the MIDB. The
WP1 and WP4 modules are used in both directions.
The national infrastructure manages to gather and provide the needed information within their
central or decentral structures from Service Catalogues, eService Directories and other
information sources. The invocation of the SPOCS open modules is done through the National
Connector developed by each piloting member state integrated to their Point of Single Contact
solution or a central instance handling the complete information management of this member
state.
The following sections describe the components and interfaces as well as the underlying
information structures for the MIDB. The updated specification of the MIDB is described in the
guidelines deliverable D4.6 as it concentrates on the semantic issues and the usage of the
attributes in specific contexts. Keep in mind that the following sections give just a technical
overview. There is also inline documentation provided with the WP4 eservices open modules.
15
2.1 Components
This section describes the WP4 eservices open modules and their relations including the
interfaces. WP4 eservices modules are related to WP1 for the syndication and to WP5 / piloting
for the connection to the national infrastructure. The specific interfaces and methods /
operations are described in the following sections.
Figure 2 shows the three main parts search, transformation and midb access. The search is
used for querying the MIDB to provide information about the services, eservices, organizations,
documents and professions including their relations to the National Connector. This National
Connector is requesting the information and then integrating the provided information to the
Point of Single Contact solution. The search is using the midb access for querying the tables in
the MIDB. The transformation is used for loading information to the MIDB through the midb
access and invocating the syndication modules. The syndication modules are delivering
information from foreign member states to the national MIDB instance.
Search and Provision from previous descriptions are merged to simplify the connection with the
National Connector. The Access is skipped as information is provided as Open Data.
cmp WP4 eserv ices
WP4 eservices
WP4 transformation
National Infrastructure
WP1 syndication
WP4 midb access
WP4 search
Figure 2: Inter-WP Relations
2.1.1 Search
Figure 3 shows that the WP4 search open module is invoked by the National Connector of the
Point of Single Contact solution. This National Connector invokes the operations of the
SearchInterface realized through the SearchOM. Offered are operations for querying services
and eservices based on the defined XML schema of the request. The request structure will
evolve within the upcoming releases as well as the amount of offered operations always related
to requirements of the pilots. The search is offered as web service. Future releases will separate
more consequently between Java implementation and Web service implementation.
16
cmp WP4 search
WP4 search
«interface»
SearchInterface
National
Infrastructure::
National Connector
+
+
handleSearchErequest(RequestEservice) : List<AnswerEservice>
handleSearchRequest(RequestService) : List<AnswerService>
SearchOM
WP4 midb access::
Client
Figure 3: Overview WP4 Search Interface and Relations
The SearchOM is invoking the Client class of the midb access to retrieve the needed information
from the MIDB. The SearchOM is handling the extraction and building of the XML based
requests and answers.
2.1.2 Transformation
Figure 4 shows the invocation of the transformation module by the National Connector. The
National Connector can invoke the Java interface or the Web service interface. Both interfaces
are offering the same operations for loading and obsoleting service, eservice, organization,
document, profession and equivalence information. The interfaces are realized through the
components TransformationOM (Java interface implementation) and TransformationImpl (Web
service interface implementation). The TransformationImpl is handling the WSDL and XSD
based entities and operation and invokes the relevant operations within TransformationOM with
the MIDB based entities. The TransformationOM is handling the MIDB based entities and
invokes the relevant data access objects through the *Home classes. The *Home classes are
handling the operations through the Hibernate persistence layer.
17
cmp WP4 transformation
WP4 midb access::
DocHome
WP4 transformation
WP4 midb access::
Eserv iceHome
Java API
«interface»
TransformationInterface
+
+
+
+
+
+
+
+
+
+
+
+
loadDocument(Doc) : void
loadEquivalence(String, String, String) : void
loadEservice(Eservice) : void
loadOrganization(Org) : void
loadProfession(Prof) : void
loadService(Service) : void
obsoleteDocument(String) : void
obsoleteEquivalece(String, String) : void
obsoleteEservice(String) : void
obsoleteOrganization(String) : void
obsoleteProfession(String) : void
obsoleteService(String) : void
WP4 midb access::
OrgHome
TransformationOM
WP4 midb access::
ProfHome
WP4 midb access::
Serv iceHome
National
Infrastructure::
National Connector
WP4 midb access::
Equiv alenceHome
Webservice
«interface»
Transformation
+
+
+
+
+
+
+
+
+
+
+
+
loadDocument(Doc) : void
loadEquivalence(String, String, String) : void
loadEservice(Eservice) : void
loadOrganization(Org) : void
loadProfession(Prof) : void
loadService(Service) : void
obsoleteDocument(String) : void
obsoleteEquivalence(String, String) : void
obsoleteEservice(String) : void
obsoleteOrganization(String) : void
obsoleteProfession(String) : void
obsoleteService(String) : void
TransformationImpl
Figure 4: Overview WP4 Transformation Interface and Relations
2.1.3 MIDB access
Figure 5 shows as example the invocation of related data access classes by the ServiceHome
class. Invoked are the text and all mapping objects between two entities. Simple mappings
between entities are directly stored through the data access class. The *Home classes are also
handling the change tracking.
18
cmp Serv iceHome
SagencyHome
SinterHome
Serv iceHome
SesHome
StextHome
NeeddocHome
OutdocHome
Figure 5: Overview WP4 MIDB Access (Example Service Entity)
2.1.4 Outlook
The components and there relations will be further aligned to the practical needs of the pilots.
This could include e.g. extension of functionality for search module. Moreover the components
will be refactored related to separation of java interfaces and web services as well as
harmonisation of naming and structuring classes and operations.
Components and their functionality will be aligned with changes in the scenarios and
communication with the National Connectors and / or WP1 syndication.
Components might be changed or extended related to integration of another technology
approach based on the results of the semantic task.
2.2 Information / Data Objects
The section “Information / Data Objects” is taken from deliverable D4.4. It is only slightly
adjusted. The update of the MIDB schema with the specific changes of attributes is described in
deliverable D4.6. Based on the updated MIDB schema and the defined operations for the
interfaces WSDLs and XSDs are defined and classes generated upon them as well as on the
MIDB schema. The files are located in the resource folders and integrated into build and
generation processes.
19
Figure 6 shows the information objects and their relations considered by WP4. They are
Service, eService, Organization, (Process)Document and Profession. Service and eService are
the main objects for retrieval. For the first piloting phase, the relations of the information objects
are directly linked in the data model and schemes. Moreover Equivalence is shown as it has a
direct dependency to the SPOCS scenario. Equivalence is described in section 2.2.1.
class MIDB
Profession
Organization
cross-border
belongs to
offers
offers
Serv ice
Equiv alence
cross-border
eServ ice
electronically operates
cross-border
needs
produces
Document
Figure 6: Overview Core Objects of MIDB and Schemas
For the update version of the data model and scheme, an uncoupling of the information objects
is envisaged as this simplifies the complexity. The functionality will realise mechanisms to use
uncoupled information objects based on reference with SPOCS identifiers. The uncoupling was
realised for the XSD structure referenced by the transformation WSDL. Within the MIDB there
are still direct references to ensure backward compatibility. For release 2.0 a complete
uncoupling within the data structures and a linkage within the functionality of the modules is
envisaged. Moreover for release 2.0, an assessment of further information objects is planned.
Information objects can be split into several tables or classes to realise normalisation. Many-toMany associations are realised through junction tables. The association is actually directly
implemented in the data model and XML scheme. For release 2.0 only SPOCS identifiers
without internal identifiers and relations are envisaged. Furthermore, more detailed descriptions
of information objects can be found in deliverable D4.2 and D4.6.
Multilingualism is realised by establishing separated textual tables with one-to-many relations to
the information object. Each textual table is associated with one language.
The update uncoupled the direct association and replaced it with a referencing directly the ISO
coding and offering an uncoupled codelist language table as shown in Figure 7. The update
simplified the data model. Where necessary, navigation intelligence will be implemented by
functionalities of the Open Modules.
20
class MultilingualUpdate
Serv iceText
Serv ice
1
1..*
-
Language
Language: IDO639v3
-
ISO639v3: varchar
Configuration Set
(External code lists)
Figure 7: Multilingual Realisation (Update)
Next to the information objects some further entities are stored in the data model as shown in
Figure 8. The entities are uncoupled and could be externalised to a Configuration Set (CS) for
separating content and internal functionality.
The CS includes change (of national part) which is storing the version information for the
information that needs to be syndicated. Moreover CS is storing Access and Routing which are
necessary for the internal routing between the modules and the user verification for cross-border
search requests. Access and routing are deprecated related to the changed usage of the
interoperability framework as described before.
Also the CS contains the code lists. The associations are uncoupled, but for some codes only
referenced by internal identifiers. This will be changed with one of the next releases like done for
language.
class ConfigurationSet
Access
Routing
Change
Language
DocumentType
Status
SPOCSAttributes
Internal Functionality
Code Lists
Figure 8: Configuration Set
2.2.1 Equivalence Information
Storage of equivalence information is not changed as there is so far no feedback from the
piloting. Related to the semantic task and piloting feedback an update can be realised with one
of the next releases. The loading of equivalence information is now directly possible through the
transformation module.
21
Equivalence is stored based on information objects. Therefore always two identifiers are
combined to be equivalent. The data model uses the SPOCS defined identifiers, but is not
checking semantic correctness of equivalence. Thus the definition of equivalence between e.g.
organization and document is possible. Open Modules need to verify the semantic correctness.
Feedback of the pilots has to show whether more information, e.g. like for a thesaurus, is
needed. Key question is for example whether an equivalence relation is bidirectional regarding
the acceptance.
Figure 9: Equivalence Information

Equivalence stores the basic information about the equivalence of two information objects
o
id is the internal identifier for the MIDB equivalence table and primary key. As
equivalence information is actually not supposed to be syndicated or exchanged
a SPOCS identifier for the equivalence record is not necessary. Furthermore
piloting will show whether more types of relation are needed (e.g. parent-child).
o
id1 is the SPOCS identifier of object 1. id1 should be the more common object
(e.g. european or international identifier like NACE)
o
id2 is the SPOCS identifier of object 2. id2 should be the more specific object.
o
remarks can be used for further information on the equivalence relation defined
by id1 and id2.
The equivalence relation is bidirectional for technical purposes. It is recommended to set the
more common identifier as id1. If two identifiers of an equivalence relation have the same level
the id1 could be the one of the hosting country which established the equivalence the first time.
More information on naming scheme for SPOCS identifiers and equivalence is described in
D4.3 “guidelines” Section 3.1 and 3.4.
The following table shows one example of equivalence for real estate agent (EU to GR) and one
example of equivalence for birth certificate (EU to GR).
ID_1
ID_2
SPOCS:Prof:REA:EU.NACE:L68.3.1
SPOCS:Prof:REA:GR.Ermis:6831
SPOCS:Doc:Bi:EU.SPOCS:BiC
SPOCS:Doc:Bi:GR.Ermis:BiDoc1
Table 1: Examples for Equvialence
22
2.2.2 Change Information
Change information represents the versioning of the content of the MIDB. Versioning is a
requirement from WP1 and scenarios as the retrieval of content for a specific timestamp and
with a specific version is needed. Figure 10 shows the Service with its object and the separated
textual part. Versioning is based on information object level and not textual parts. This means
every change in a text or other associated table leads to an update of the complete entity.
Service has two attributes describing the actual version: version start number (vstart) and
version end number (vend). This allows marking a record when it was updated by another one.
The actual record has vend “null”. The textual part references the composite primary key of the
entity. The text part should be unique based on the composite primary key of the entity and the
iso code for the language (iso639v3). In further releases the actual internal identifier could be
exchanged by usage of a composite key based on the composite primary key of the entity and
the iso code.
Update, insert or delete of information to the MIDB needs to reflect the change tracking. The
difference of origin is marked by the origin attribute.
The change table stores the transactions related to an entity (objectid). The information can be
retrieved directly from the records, but the change table increases performance as only one
simple request is necessary. Thus Change includes the objectid which is a SPOCS identifier,
vstart and vend as well as a timestamp. Remarks are optional.
Further information on change tracking and an example is described in Section 3.2.
Figure 10: Change Information (Update)
23
The above mentioned and in Figure 10 shown tables have the following parameters:



Object / Entity table (e.g. Service) attributes (relevant extract):
o
id stores the SPOCS identifier and is primary key composite with vstart.
o
vstart stores the version number the record starts with and is primary key.
o
vend stores the version number the record ends with. If it is null than the record
is the actual one.
o
origin indicates the origin of the information based on national (N), foreign (F) or
local (L). The origin level is especially needed for the syndication as national
information is syndicated to others and foreign information is syndicated by
others.
Textual table (e.g. Stext for service texts) attributes (relevant extract):
o
id stores the internal identifier and is primary key.
o
service is the referenced SPOCS identifier of the entity (here service).
o
servicevstart is the vstart of the referenced entity (here service).
o
iso639v3 is the three character alphanumeric code for languages.
Change table
o
id stores the internal identifier and is primary key.
o
objectid represents the SPOCS identifier of an information object.
o
vstart stores the version number the record starts with.
o
vend stores the former version number which is now obsolete.
o
timestamp indicates the date and time when a version was created.
o
remarks are additional information related to the change tracking.
2.2.3 Outlook
The information / data objects are based on the specifications and the schemas (see deliverable
D4.2 / D4.6). As far as there are updates based on piloting experience or results from semantic
task the underlying schemas will be updated. The core approach as described in these sections
seems to be suitable and needs actually no update.
Equivalence information might be represented in a different way if the results of the semantic
task show a different structure and definition.
Change tracking might be changed or skipped based on the experience of the pilots and impact
analysis for other WPs, esp. WP1.
24
3 Technical Decisions
This section describes the main technical decisions made during the development task.
The section concentrates on integration, change tracking, MIDB storage technology and routing.
Furthermore technical decisions about used technologies and tools are described in the
Reference Environment1 especially the technical wiki.
This section is mainly copied from the old deliverable D4.4 where the decision has not changed,
thus for integration, change tracking and MIDB technology. The section routing is shifted as
obsoleted part to the “Appendix F – Obsoleted Parts of Deliverable D4.4” as the usage of the
interoperability mechanism “interoperability layer” is deprecated to usage of the syndication as
main mechanism.
There is no final decision about changing the change tracking mechanism, thus there is actually
no change on the description. Change tracking was slightly adjusted to different understandings
related to recording of updates, the usage of next internal number instead of always 1 for insert.
Change tracking was originally integrated as WP1 focused on this requirement. The piloting will
show whether a change tracking is really needed or whether the original requirement will be
changed like for WP1 to store within the MIDB only actual information and change tracking can
become obsolete at all.
MIDB technology decision will be further investigated within the semantic task.
3.1 Data Sources and Integration
This section reflects the technical decisions and recommendations for the integration and
connected data sources of the national infrastructure. The decisions from this subsection are
especially relevant for the information management related to the national infrastructure and the
role of the National Connectors.
3.1.1 Frontend vs. Backend Integration
Integration can be realized on different levels. This section marks the difference between
frontend and backend integration as it is relevant for the information flow and the functionality of
the Open Modules.
Frontend integration means that the integration functionality is located between the portal or
solution and the application. Within SPOCS WP4 this would mean that the integration point for
the information is located directly at the PSC portal or solution. Based on the defined
architecture, the National Connectors are the integration point between PSC and SPOCS
common solution. The advantage is that the solution can have various presentation layers.
Backend integration means that the user is working only with one application and integration is
realised behind this application. The application is requesting functionality of other applications.
Within SPOCS WP4 the Open Modules of the Interoperability Framework are backend
integration to the NCs and PSC solution. The advantage is that the existing applications with
their functionality can be used.
The user of the portal or solution is not recognizing that different applications, and for SPOCS in
different member states, are connected through the WP4 interoperability framework.
1
https://dev.spocs.bos-asp.eu
25
The SPOCS WP4 solution with the common specifications and Open Modules is mainly a
backend integration using asynchronous communication. Results from SPOCS WP4
interoperability mechanisms are given to solutions or portals of Points of Single Contact. But the
results can also be used directly for presentation to the end-user, e.g. giving the XML answer
directly to the Service Provider maybe as part of a more complex information package or for a
further usage within a solution of the Service Provider. For the common SPOCS understanding
NCs are representing the frontend integration point.
3.1.2 Quality Criteria Information Retrieval and Data Source Selection
This Subsection marks some criteria that are relevant for information retrieval related to
technical decisions and especially the data sources. Thus this Subsection mainly reflects the
national infrastructure, which is the information source for SPOCS. The listed criteria are not a
comprehensive list, but reflect the main criteria discussed with member states. Moreover the
criteria have a strong dependency to the recommendations within deliverable D4.3.
The used data sources should be stable and have a long term perspective. The stability is a
main criteria as SPOCS is intend to support automated process chains and a missing source will
lead to failures for the processing. Moreover the stability includes not only the availability, but
also the stability of the structure. Thus the defined information model needs to be sustainable.
The provided information should be retrieved from official data sources that are storing quality
approved and reliable information. This is especially relevant for retrieving legal information and
data used within automated processes. The usage of community or industry based information
is not restricted, but needs quality mechanisms as established for the official ones.
The provided information should include traceability, thus that a user knows the original source
and the information generation path. Information should be collected from the original source or
from an official centrally organized data source.
The provided information has to use common code lists, thus no complex mapping or
conversion is necessary and the delivered information has always the same level of quality.
Provided information should be based on simple structures like directories or simple databases.
This allows a multiple usage of the content in different contexts and simplifies maintenance as
well as information management processes and responsibilities.
At least provided information should reflect the recommendations from the deliverable D4.3,
especially about how to write descriptions or models.
3.2 Change Tracking
Change Tracking concentrates on the decision about realisation of methods for managing
changes of the records leading to the need for documentation. The following Subsection
describes strategies as options for realising change tracking, the criteria for selecting an
approach, the decision for an approach and an example.
The change tracking strategies, also known as Change Data Capture (CDC), are describing the
methods and patterns of tracking the changes of data and therefore are part of the technical
decision for change management within WP4 IF especially the MIDB. Solutions often combine
the following approaches.
The decision is concentrating on the seven strategies:

26
Replication-based is realized by writing every change to a table or list

Trigger-based is a method where every manipulation leads to an action / event

Time-based is realized by attaching timestamps to every record and retrieve changes for the
defined intervals

Version-based is defining version numbers which increase for every change. A reference
table stores the occurrence of changes.

Status-based defines a status of a record and changes result in changes of the status value.

Log-based is a method where every manipulation is logged into a file and changes are
retrieved based on the logged meta information

Snapshot-based is realized by defining a timestamp and make a copy of all information at
this timestamp, changes between two snapshots can be assessed by comparison (delta)
Key criteria for the decision are the dependencies to other WPs and their methods including the
requirements from Member States as well as the implementation effort and sustainability
regarding the usage of WP4 IF.
Another core criterion is the level where changes are tracked. Possible levels are the full MIDB,
a table of an information object (e.g. service), a record of an information object or the supporting
textual table (e.g. service text). SPOCS concentrates on retrieval of information objects which
represent core information blocks, e.g. service, eService or organization. This is actually also
decided for the usage of SPOCS identifiers. If an extension of the SPOCS identifiers to the
textual elements is planned, a change of the level for versioning would be interesting. For
versioning see also Section 2.2.2.
WP1 requires snapshot mechanism for major releases (full information). Minor changes are
handled by fragments (differential updates with respect to another fragment or snapshot). Each
change of a record (fragment) is stored in the MIDB. Snapshot and fragment mechanisms are
described in deliverable D1.4.
The technical decision realizes the change tracking as described in 2.2.2.WP4 is using a
combination of timestamps, version numbers and snapshots. Transformation module and
syndication interface are handling the setting of the attributes for the specific methods.
Actual situation
The realized way to implement a history with snapshots and fragments in the database is the
use of two version columns in the object table. These columns are called “VersionStart” (vstart)
and “VersionEnd” (vend) indicating from which version to which version the data in that row is
valid.
The “Change” table supports the identification of loading transactions (insert, update, delete)
related to timestamps.
An example of a regular data table is Table 2.
SPOCS ServiceID
Name
Fee
VersionStart
VersionEnd
SPOCS:Service:REA:GR.Ermis:12345
Service REA in GR
10
1
2
SPOCS:Service:REA:GR.Ermis:12345
Service REA in GR
12
2
null
Service Bi in DE
50
1
2
SPOCS:Service:Bi:DE.Leika:67890
27
Table 2: Content table with version numbers
A corresponding change table is Table 3.
ObjectID
VersionStart
VersionEnd
TimeStamp
1
null
16.02.2011 18:07 UTC+2
1
null
17.02.2011 09:02 CET
2
1
18.02.2011 20:54 UTC+2
null
1
19.02.2011 06:36 CET
SPOCS:Service:REA:GR.Ermis:12345
SPOCS:Service:Bi:DE.Leika:67890
SPOCS:Service:REA:GR.Ermis:12345
SPOCS:Service:Bi:DE.Leika:67890
Table 3: Change table for versioning
“Service REA in GR” was inserted at the 16th.
“Service Bi in DE” was inserted at the 17th.”
“Service REA in GR” was updated on the 18th. regarding the fee.
“Service Bi in DE” was deleted at the 19th.”
By selecting the records with a timestamp before the given datetime, change table will present
the result set. This set has to be minimized by all previous records of an objectid with lower
vstart (skipping earlier versions of the update) and minimized by all previous records of an
objectid, if vstart is set to null (object deleted). The result produces the snapshot at the specific
time.
vend can be used for verification of status / snapshot calculation. Moreover it can be used to
check the integrity related to duplicates and missing version numbers.
The following table shows the status of the regular table for the 17.02.2011 10:00 CET.
SPOCS ServiceID
SPOCS:Service:REA:GR.Ermis:12345
SPOCS:Service:Bi:DE.Leika:67890
Name
Fee
Service REA in GR
10
Service Bi in DE
50
The following table shows the status of the regular table for the 18.02.2011 21:00 UTC+2.
SPOCS ServiceID
SPOCS:Service:REA:GR.Ermis:12345
SPOCS:Service:Bi:DE.Leika:67890
Name
Fee
Service REA in GR
12
Service Bi in DE
50
The following table shows the status of the regular table for the 19.02.2011 8:00 CET.
SPOCS ServiceID
SPOCS:Service:REA:GR.Ermis:12345
Name
Fee
Service REA in GR
12
Table 4: Content tables with different version status
Data manipulation use cases
Insert of a new object is realised by inserting a new row to the data table with the next free vstart
number. Also a new row within the change table with the objectid and this vstart and vend = null
and timestamp = time of the change has to be inserted.
28
Update is realised by selecting the actual row of the object (vend = null) and setting vend =
Vstart+1. A new row with the update is inserted into the data table with setting vstart = vend of
previous row and vend = null. Also a new row within the change table with the objectid and
vstart and vend (vstart of old record) and time is integrated.
Delete is realised by selecting the actual row of the data table and setting vend to vstart+1. Also
the change table gets a new record with objectid, vstart = null, vend = vstart of the old record
and the timestamp.
Note that this mechanism does not allow for high-throughput independent sequential updates on
the database as the change table becomes a bottleneck. However, for the purposes of SPOCS
this is not a problem as the data in the MIDB is fairly static.
In this scheme, obsolete data can be removed from the MIDB easily based on the version
number attributes.
Semantic and deployment support task will check whether the change table and the change
tracking at all can be skipped. This solution would be useful to simplify data model complexity.
Moreover semantic and deployment support task needs to assess data cleaning, data scrubbing
and data auditing strategies and methods related to the SPOCS needs.
3.3 MIDB Technology and Query Language
MIDB Technology and Query Language are concentrating on three main options:

Relational solution and SQL,

XML and XQuery / XPath,

Semantic Approach with RDF / RDFS / OWL and SparQL.
The WP4 group, especially the ones related to MIDB development, have discussed the different
solutions and possible implementation technologies. Criteria are based on implementation effort,
operational aspects, sustainability of solution and technical criteria like performance. The WP4
group had no final decision as the interpretation and analysis showed that the users and
developers within the different member states had different requirements. Some of them are
mandatory based on the political and legal bindings related to IT architecture and management,
e.g. no usage of Semantic Technologies or Open Source software. Some of the criteria are not
further interpreted as the project framework is defining requirements and objectives, e.g.
development of Open Modules.
Moreover some of the criteria are prioritised for realisation of release 1 (old SPOCS planning)
and some are shifted to update of open modules and release 2 (onboarding). Moreover
resource difficulties arise with the implication that advanced solutions like semantic approaches
needed to be postponed regarding the establishment of further experience in semantic
technology.
The relational solution is a well-established solution in most member states. The operators know
the technology very well and can easily adjust their implementations. Moreover relational
solutions are widely accepted by legal frameworks and have established persistence and
transaction functionalities. Nevertheless relational solutions are mostly static and dependent on
29
the defined data model. For relational database MySQL version 5.12 is used. The DB scheme
can be found in the appendix and is based on the defined specification in deliverable D4.2.
XML technology is widely used for information exchange and close to the defined message
formats. Necessary transformation needs less effort as different transformation options can be
realised. Moreover semantic information is, by the scheme, well defined. XML technology is not
widely used for storage of information.
Semantic technology is not widely established. Persistence solutions are very rare, especially in
the implementation of open source technology. The approach follows a more dynamic solution
and further focus onto semantic interoperability. For these criteria, semantic technology allows
the realisation of most of the objectives for WP4. For the semantic storage of information
different solutions are investigated. If semantic solutions are realised, SPOCS WP4 will
concentrate on Jena framework3 and persistence realisation with SDB4. It supports storage of
RDF in relational DBs and SparQL.
As a result, WP4 is realising a relational solution based on MIDB and internal SQL queries.
Results from MIDB will be provided by Java objects and transformed to XML format for
Provision OM. Syndication will handle RDF/XML (see deliverable D1.3 and D1.4). RDF as MIDB
technology will be integrated for the second phase and with the support of onboarding tasks
about semantic concept. Finally, WP4 has to support all technologies including transformation
between them. Transformation in the context of RDF is complex and needed especially for
syndication. Release 2 will align transformation of XML, relational DB and RDF within
transformation module.
Another discussed option, but with no actual result, is the usage of TSL approach for publishing
the service and eService information. Actually this solution is not verified and completely
assessed as it is mainly described for Certificate Authority services. Extended usage is
discussed within WP3, but needs further examination.
Framework solutions like UDDI etc. are integrated with their ideas, but with limitation to practical
solutions and needed effort it is actually not further assessed.
2
MySQL – http://www.mysql.com
3
Jena Framework – http://jena.sourceforge.net
4
SDB Persistence for Jena - http://openjena.org/wiki/SDB
30
4 Implementation
This section describes conventions and recommendations for the implementation. This and the
next section are requested by several partners developing national connectors and needed to
understand the coding and their frameworks. Thus the following parts are concentrating on the
frameworks and the specified conventions for the development. This section is new related to
deliverable D4.4. Some lines of the former section 4 “Implementation” where used as basis for
following parts like the dependency management, programming conventions, logging and
testing. Others are realigned to the updated specification part in deliverable D4.6.
4.1 Development
This section represents the development framework with the used development environment
and the programming conventions. It includes also recommendations for inline documentation.
4.1.1 Environment
The developer can choose an appropriate development environment. As recommendation the
developer should use Eclipse5 as most of the SPOCS WP4 developers are using this
environment and support is easier using the same. The developers have mainly used the Helios
version of Eclipse.
The environment needs to be enabled to communicate with the reference environment6,
especially the SVN. Therefore the developer has to setup the connection and plugins as
recommended in the development wiki of the reference environment.7
The environment needs to be set to UTF-8 to support multilingualism in coding.
4.1.2 Programming Conventions
The SPOCS WP4 application uses Java 1.6 as programming language.
The code has to fulfil the standard coding conventions thus the code becomes easily readable
and maintainable. This includes e.g. appropriate length of classes and methods,
comprehensible inline documentation, no usage of exceptions to control the application process,
no empty catch and else blocks, grouping of statements and methods.
4.1.3 Code / Inline Documentation
All classes, except generated ones from an automatic build, must include documentation. The
documentation consists of:

one common header based on the project and building block information,

one class description detailing the functionality of the class,

one description for each constant or property of the class,

one description for each method including constructors.
5
http://www.eclipse.org
6
See https://svnext.bos-bremen.de/SPOCS
7
See https://dev.spocs.bos-asp.eu/wiki/
31
The documentation has to be in comprehensible English and should use HTML tags for
structuring the documentation.
The documentation must be based on Javadoc8 including the usage of the common
annotations. The developer can use tools or plugins like Jautodoc9 for support and generation of
documentation if the tools / plugins are configured to produce comprehensible documentation.
Mainly the developer has to improve the generated documentation.
Class documentation must explain the objective of the class and if needed relations to other
classes.
Method documentation must explain the parameters, results and main functionality.
The developer can use specific comments related to single or groups of statements. This should
be done only for improving the readability.
The format has to be as defined in the default Eclipse configuration, especially the page margin
is a must-have.
4.1.4 Status and Outlook
The code is using Java 1.6, but not all options of this state-of-the-art version are used,
especially the annotation options. There should be improvements like using more annotations to
improve code clarity and simplify coding at all.
Moreover the code clarity needs to be improved related to different objectives also mentioned in
some of the following sections.
The code needs to be checked and aligned for the compliance to the programming conventions.
Inline documentation is done but needs to be aligned to the mentioned conventions and needs
to be improved to fulfil better readability and comprehensibility. This should include the
formatting of the code.
4.2 Dependency Management
The WP4 modules are using several external frameworks which need to be managed. Thus
WP4 is using the Maven mechanism and defines dependencies. The following section shortly
describes the main aspects using the mechanism and the structure of the project.
4.2.1 Mechanism
The WP4 modules are based on Maven.10 WP4 is using at least Maven with version 2.2.1. Thus
each project within the building block eServices defines a project object model (pom) file used to
support the project in the full lifecycle. This includes generation of code, compilation, building
and deployment.
The external dependencies are capsulated through repositories and Nexus server. The nexus
servers are mirrors used as interfaces and APIs for the dependency management. Referenced
are the main repositories of Maven11, Codehaus12, Atlassian13 and JBoss14. SPOCS is offering
8
http://java.sun.com/j2se/javadoc
9
http://www.jautodoc.sourceforge.net
10
http://maven.apache.org
11
http://search.maven.org
32
also a Nexus server within the reference environment to offer the own packages as well as main
3rd party libraries.15
Repositories are referenced in the pom.xml under repositories and pluginRepositories if they are
needed in a specific project or in the common part of a building block if they are needed often.
At least the SPOCS nexus is referenced in the common pom.xml as it is used for the distribution
management. The developers are using local settings.xml files for their Maven repositories.
Inherited libraries are exported from the external repositories to the local one.
For the development Maven and related plugins require to run a full java development kit (JDK)
and not only the runtime environment (JRE). The environment needs to be configured to use the
JDK directly, e.g. through extension of the environment configuration file (like eclipse.ini).
For the deployment the administrator and developer in the national infrastructure can use the
libraries directly from the nexus. Therefore an automatic release process would be needed, best
through a continuous integration tool like Hudson.
4.2.2 Maven Project Object Model
Each project defines a project object model file (pom.xml). Based on the project scope the
project is packaged as pom (only management), jar (libraries and java apps) or war (web apps)
project.
The pom defines the groupId, artefactId, version and parent information to resolve the
identification of the project within the nexus and dependency hierarchy. pom projects can be
used as parents. The path in the folder structure of the SVN needs to be set to appropriate level,
thus for parent projects one folder above.
The pom projects define properties for the encoding (UTF-8), the SPOCS nexus, the SPOCS
SVN and the child projects (modules). Moreover they define the path to SVN16 /source code
management - SCM), connection parameter to the issue management (JIRA)17 and the
continuous integration (Hudson)18.
Main task of the pom files are the definition of dependencies to libraries and projects (external
and internal) as well as the usage of plugins to support the lifecycle process, especially maven
plugins19.
The pom projects are defining the common dependencies, mainly under
dependencyManagement and the plugins under pluginManagement. The child projects can use
them as managed dependencies and plugins thus they do not need to address further properties
like version etc. At least they have to integrate used libraries and projects with their groupId and
12
https://nexus.codehaus.org
13
https://maven.atlassian.com
14
https://repository.jboss.org/nexus
15
https://dev.spocs.bos-asp.eu/nexus
16
http://subversion.apache.org
17
http://www.atlassian.com/software/jira
18
http://hudson-ci.org and http://hudson.java.net
19
http://maven.apache.org/plugins/
33
artifactId. The used dependencies and plugins can be extended with scope, configuration etc. to
be used within lifecycle activities like definition of output package for generated classes.
Some dependencies and plugins are often used like junit for the testing or javadoc plugin for the
generation of documentation based on the inline comments. They are recommended to be
managed by the parent projects.
4.2.3 WP4 eServices Building Block Project Structure
The eServices building block provided by WP4 defined the following project structure.

eservices-overall – common project managing the main objectives
o
eservices-midb-access – project for accessing the MIDB including DB based entities
and data access objects as well as all resources for setting up and running the
MIDB, generation of entities through Hibernate Tools20, SQL code development
and MIDB test management through MySQL Workbench21
o
eservices-transformation – project for loading information to the MIDB
o
eservices-search – project for querying information within the MIDB and providing it to
the national connectors
o
eservices-xml-model – project for XML based actions including the generated entities,
generation through JAX-B22
o
eservices-db-xml-conversion – project for transforming between DB and XML entities
o
eservices-routing – project offering routing information between different instances of
the SPOCS WP4 modules
o
eservices-integration-test – project offering testing for the usage of integrated modules
and projects
Subprojects can define own subprojects like for example for the transformation.

eservices-transformation – common project managing the transformation objectives
o
eservices-transformation-lib – interface project for the java connection to the midb
access and syndication (core part of transformationOM)
o
eservices-transformation-ws – webservice offering the connection to the
transformationOM
o
eservices-transformation-wslib – library of the generated WSDL and XSD based
entities to be used within the webservice, generation through CXF23 and JBossWS / JAX-WS24 as well as JAX-B25
20
http://www.hibernate.org/subprojects/tools.html
21
http://www.mysql.de/products/workbench/
22
http://jaxb.java.net/
23
http://cxf.apache.org/
24
http://www.jboss.org/jbossws
25
http://jaxb.java.net/
34
It is planned to refactor the project structure after having an updated architecture and improved
building and generation processes. For example the xml-model project could be included into
the wslib projects and the db-xml-conversion to the lib projects. Some of the projects seem to be
not used in future versions like the routing as the architecture changed. Testing should be
included into the specific projects.
Project names are using minus character where packages are using dots.
Each project uses the maven main source folder structure and within the defined package
naming (see 4.3.3). Thus the main folder structure based on the project scope can contain the
following:

src/main/java – java code

src/main/resources – resources needed for the operation

src/test/java – test code for the java code

target/wsconsume/java – generated code, here e.g. for the wslib
Further folders can be defined, e.g. for documentation, configuration, resources or testing if they
are not used operationally.
pom projects do not contain any source folder only the submodules (child projects) and the
pom.xml file.
4.2.4 Status and Outlook
The WP4 projects are defined and structured aligned to the actual status of the architectural
decisions and based on the described mechanism. They have to be aligned within future
releases. This includes the alignment of the dependencies and used plugins like the usage of
one wslib generation plugin and the definition of versions in the management instead within the
specific dependencies.
Moreover the lifecycle processes are used on a basic level. This will be extended related to
more automatisation on build / generation, testing and deployment / distribution / release.
The usage of different repositories has to be aligned based on the SPOCS nexus. The central
nexus needs to be part of the sustainability planning as the storage of code within only an
external forge or repository might not allow maintenance of 3rd party dependencies.
Moreover a standard pom for all SPOCS building blocks and a common naming for folders and
projects need to be further aligned. The common pom should manage the main dependencies
and plugins to simplify maintenance.
Further attributes should be included like categories or developers to increase quality of code
awareness outside SPOCS. The main objectives in this context are common conventions and
mechanisms for inline documentation including the generation of documentation that can be
navigated from stakeholders. Moreover documentation has to be increased on the scope of
manuals and hand-outs for architects and executives.
Another objective has to be the discussion of a test and / or production solution. Several times
the setup of a central instance for at least testing was discussed, but not used in a good
manner. Also the central instance could be a mirror to increase availability and performance.
This has to be discussed within sustainability actions and underlined with use cases and
scenarios.
35
4.3 Project Versioning and Conventions
The versioning represents a numbering schema for addressing different states of the application
or the code. Moreover this section is detailing some SPOCS WP4 wide technical conventions
like namespaces.
4.3.1 Versioning Schema
The versioning realized in a standard way based on the following structure:
<MajorVersion> . <MinorVersion> . <DeveloperVersion> . <BuildVersion> - <Qualifier>
All attributes are numbers except the qualifier which is a string.
The versioning has to realize at least the major version.
The versioning needs to connect to the common release plan. Every version number of a
component has to be aligned with the versioning to the release versions of the related building
block.
The major version represents a major release with major new and updated functionality. A major
version does not need to be backward compatible.
The minor version represents a minor release with small new functionality. A minor version
needs to be backward compatible.
A developer version is an update of a minor release related to fixed bugs and errors.
A build version is a specific developer version related to a specific build time. If necessary there
can be automatic daily builds on the code thus that always a daily fresh build of the code is
available.
The qualifier is a code for defining the status of a build. Different qualifiers are allowed to related
versioning standards. At least the SNAPSHOT qualifier has to be used to mark development
builds of the code used only by developers. Other qualifiers like CR, GA, ALPHA or BETA for
pre-releases etc. with their specific status in the development and release lifecycle have to be
defined by the common SPOCS release plan.
4.3.2 SVN
For the versioning of the code SVN is used. The SVN is available through the reference
environment.26
SVN offers a revision number for retrieving a specific state of the code. The revision number is
not related to the versioning itself.
Within the SVN the code for SPOCS WP4 is located under AllWPImplementation in the
SPOCS_WP4_OMs subfolder. The trunk is used for the development code, branches can be
used for diverting development activities and the releases are available under tags with their
specific version numbers.
Every code and folders generated by the build process as well as local settings have to be set to
ignore within SVN.
26
See https://svnext.bos-bremen.de/SPOCS
36
4.3.3 Namespaces
All WP4 projects are starting with “eservices-“.
SPOCS project defined a generic namespace for the code and the packages.
The packages within all SPOCS modules and components start with “eu.spocseu” followed by
the building block and the subprojects or submodules.
For WP4 the following main packages are available:

eu.spocseu.eservices

eu.spocseu.eservices.midb

eu.spocseu.eservices.transformation

eu.spocseu.eservices.search
The XML namespace should start with “http://example-domain.toplevel/eservices” where the
“example-domain.toplevel” is exchanged by the locally used namespace. For the development
the namespace is set to “http://www.eu-spocs.eu/eservices/ns/midb”. The namespace can be
differentiated by subfolders for modules or components.
4.3.4 Status and Outlook
The development is using the versioning schema and the SVN as described. For future versions
and the support phase a more detailed usage is envisaged.
There is actually no regular and especially no daily build of the code as the development is still
making major changes. Thus daily builds would not be without errors in code and dependencies.
Also there is actually no automatic release and build process through Hudson (continuous
integration).
Moreover a clear picture of package naming and namespaces will arise during the piloting
phase and the deployment within the national infrastructures. The naming for SPOCS common
packages will be aligned in upcoming versions.
4.4 Logging
The logging stores states of the application at a specific position in the programming code. It can
be enriched by information of used objects and variables.
Within the context of SPOCS WP4 logging is used for the development and for the maintenance
to retrieve bugs and errors within the code.
4.4.1 Mechanism and Conventions
An output through System.out is not allowed, especially for exceptions and errors including the
stack trace. A logging framework has to be used.
The logging is realised by the Simple Logging Facade for Java (SLF4J) 27 version 1.6.1.
The logging framework is defined as dependency within the Maven pom file. It refers to slf4j-api
and slf4j-log4j12.
27
37
See http://www.slf4j.org
The logging properties are stored in the log4j.properties file related to the defined logging levels.
The file is always located in the root of the resource folder.
The logging code lines are located within the specific methods.
Generated log statements like within the hibernate need to be refactored to slf4j conformity.
The logger statement is the first code line within a class to define a logger object based on the
class.
4.4.2 Logging Levels
The following levels are defined for the logging:

trace – for following the application process

debug – information for the development

info – information for the operation of the application

warn – for bugs and errors without impact to the functionality

error – for bugs and errors with impact to the functionality
4.4.3 Dependency to Monitoring
The logging should be used for monitoring the usage of the application. This is important for
maintaining the application on a technical level but also for improving the sustainability of the
architecture and for the business objectives.
4.4.4 Status and Outlook
The logging as described before is not realized in all classes and is not verified through the
correct usage related to the mentioned conventions and levels.
The logging needs to be improved until the end of the project to fulfil completely the mentioned
conventions and levels within every line of code.
The logging is actually not used for logging monitoring information on business objectives as
they are not defined until now in the piloting and sustainability documentations.
Moreover based on the monitoring concept and with respect to the security and privacy
constraints the usage of logging for the monitoring should be used until the end of the project.
4.5 Error Handling and Exceptions
The modules must send exceptions and handle errors. Therefore exceptions have to be defined
and errors to be handled.
4.5.1 Mechanism
The modules are not defining exceptions for used external frameworks, but they still will be
thrown if they arise. External exception can be thrown e.g. by the runtime environment (virtual
machine), Hibernate (persistence to MIDB) and if the web services are used by the SOAP,
Webservice or HTTP stack.
SPOCS is defining application exceptions for his own scope. The exceptions are focusing on
verification of parameters with checking for null, empty, semantically wrong (not fulfilling naming
38
schema) and referenced entities not registered (for uncoupled entities) or multiple entities
registered (MIDB corrupt / versioning corrupt).
Errors that are not handled by exceptions should be thrown only if fatal problems arise. They
have to be logged with error logging level.
4.5.2 Fault Conventions
The SPOCS application exceptions / faults follow a common structure. They extend the Java
Exception class and define

code,

description and

the current time.
The code is defined in an exception code list (see C.1 Exception codes).
The SPOCS application exception is used in the Java interfaces and libraries. For the web
services a XML based exception with the same structure is defined. The web services will
transform the SPOCS application exceptions into their structure.
4.5.3 Status and Outlook
The WP4 modules are using the exception mechanism and error logging. The usage needs to
be improved by aligning the different codes and by including further exception handling within
the modules. Where possible the exceptions should be defined and thrown by capsulated
classes like the UpdateChecker.
4.6 Testing and Quality Assurance
The code must be tested by the developers and a testing team. The developers are realizing
unit tests and the testing team is checking the integration between the modules and building
blocks (for WP4 especially with WP1).
4.6.1 Mechanism and Test Methods
External frameworks like junit28 and testng29 are used for testing. Each developer defines test
classes in the src/test folders with appropriate test data. Moreover for the integration test a
specific project is defined to run the test between different modules and building blocks.
4.6.2 Test Models, Cases and Conventions
The test data needs to be as realistic as possible, but also needs to be identifiable as test data.
The test cases should reflect at least all exception handlings and the correct operation. Test
cases can be consolidated to one test case if constraints are defined (e.g. successful obsoleting
is only possible if correct data is already in the MIDB).
28
http://www.junit.org
29
http://testng.org
39
4.6.3 Test Automatisation
The tests need to be integrated into the build and deployment process. For the development
stage they might be skipped. For releases they have to be in operation. Thus the tests cannot
be dependent on external configuration like existing data records in the MIDB. But they can be
dependent on the configuration for setting up the solution.
4.6.4 Test Results Presentation
Test results have to be represented to monitor the activities of the development. This can be
integrated into the Hudson monitoring but should also reflect offline documentation.
4.6.5 Sonar and Quality Assurance
The quality of code is important for the sustainability of the modules. Therefore a quality
assurance mechanism is established. This includes manual checks of the code as well as the
usage of Sonar.30 The quality assurance reflects the chosen architecture, coding rules,
comments / inline documentation and the unit testing. Results have to be shown online related
to the reference environment (integrated into continuous integration / Hudson) as well as within
offline documentation.
4.6.6 Status and Outlook
The testing is realized only on a basic approach with some relevant unit and integration tests
between WP1 and WP4. Simple test data is defined by the developers for their unit testing. The
unit and integration testing as well as the test cases and test data need to be improved.
Moreover the automatisation of testing needs to be integrated into the lifecycle process. Also the
quality check using, e.g. Sonar, needs to be setup integrated into a complete continuous
integration.
30
http://www.sonarsource.org/
40
5 Distribution and Change Management
This section describes how the WP4 results are distributed to the pilots and how their feedback
is integrated into the technical work. Therefore this section builds on the main approach of the
previous section, the description of the reference environment and the change management
plan. The description is a new section related to the deliverable D4.4.
5.1 Deployment for the Pilots
The results of the WP4 building blocks are automatically build as jar and war files by the specific
Maven lifecycle process. These files are distributed to the reference environment within the SVN
and Nexus. The pilots can integrate the results as external dependencies / packages to their
national connector implementation. If they are implementing their national connectors they can
check out the projects as maven projects and the build process generates all needed classes.
Based on the used results the pilots have to configure the settings of the MIDB connection to
their local MIDB within the midb-access projects hibernate configuration. In the future this
configuration will be aligned across the modules and checked for update to application contexts
and usage of JPA.31 This requires the usage of a managed application server including JNDI32
references. Moreover they can align the logging settings.
The pilots can use the Java interfaces (lib projects) or the web services for communication
between national connector and WP4 modules.
The national connectors themselves need to connect with the national infrastructure. Therefore
the pilots can define mirrors and / or wrappers to connect between national infrastructure and
WP4 modules. The national connectors are transforming the content to the SPOCS common
schema used in the WP4 modules.
The pilots need to reconfigure the address of the web services and if needed of the target
namespaces if they are establishing web services in their environment based on the SPOCS
offered solution. The XML based schema for the information based on the common specification
does not need to be reconfigured.
WP4 gives deployment best practices and guidelines within the next releases based on the
experience of the first and second piloting wave.
5.2 Release Management
This section is related to the described release plans in the change management (section 3).
The following text describes the planned activities for the WP4 releases. In the SPOCS context
a releases is a given package of code as a complete bundle for the specific building block.
SPOCS releases are only focusing on common code and not on national implementations and
connectors.
WP4 plans for major, minor and update releases. The major release includes major new and
updated functionality, but also cannot assure to be backward compatible. The minor releases
include only new functionality and improvements to the internal code. The updates are focusing
on solving bugs and errors. There can be further internal builds and updates without releases.
31
http://www.oracle.com/technetwork/java/javaee/tech/persistence-jsp-140049.html
32
http://www.oracle.com/technetwork/java/jndi/
41
WP4 plans the following releases:

Release 1.0 (May 2011) – includes the basic functionality to load, transform, search and
provide information.

Release 1.1 (June 2011) – includes the dependency to the syndication of information
between pilots.

Release 1.2 (August 2011) – includes the merged search and provision based on the new
architecture and the additional / updated functions for the extended data model.

Release 1.5 (September 2011) – includes improvements in project structure, error and
exception handling, documentation, testing and additional exchange of equivalence
information.

Release 2.0 (March 2012) – includes all feedback of pilots and the results of the semantics
task impacting to a major update of underlying data schema and maybe used technology.
There might be further releases between the planned ones to solve updated dependencies to
other building blocks or realized change requests of the pilots.
Release 2.0 is not required to be piloted but recommended to upgrade at least with the end of
the project as this major release includes all feedback of the pilots and work within the semantic
task.
Further information is described in the change management plan.
5.3 Change Management
The change management section describes the process how change requests are managed.
Before the complete establishment of the procedure as described in the change management
plan (section 2) issues and feedback was discussed in conference calls and listed in a
document whit defined tasks and assignment to partners. The list (see Appendix E – Task list
before WP1 / WP4 scrum) will not further used. Results are integrated into the aligned
development planning within the WP1 / WP4 scrum sessions including the backlog.
Further feedback on a technical level will be only through JIRA33 as described in the change
management plan. The internal planning will include the issues into the development planning of
WP1 and WP4.
Semantic and organizational issues as well as request about architecture and major new
functionalities will be previously discussed within WP4 conference calls.
33
http://www.atlassian.com/software/jira
42
Conclusions
This deliverable contains different objectives and tasks. The main purpose is to update the open
modules for WP4 based on the feedback of the first pilots and the enlargement participants.
Moreover this deliverable shows the progress of implementation and used environment.
In sum there is one major decision to focus on syndication as cross-border interoperability
mechanism. WP4 is concentrating on common schema for the MIDB and modules for loading
and querying the MIDB.
The update of the modules is also concentrating on further establishment of interfaces,
especially Web Service interfaces, and realignment of components and project structure. This is
done and will be continued within the next releases. Some previously modules are skipped like
access verification and routing as they are not needed anymore.
Thus the restructuring of the modules and the refactoring of the code lead to simplified modules
that can be used more efficiently in the piloting scenarios. The alignment with the pilots still
needs to be enhanced.
Further feedback and also further coding is expected based on ongoing feedback of the pilots
and results from the semantic task.
Extensions of the MIDB are integrated with the code, especially for document information and
relations between document and service as well as service and eService.
The main technical decisions are not changed. But there is still the request to further analysis
whether change tracking is needed or whether it can be skipped based on framework and
governance decisions. The analysis of the MIDB technology is mainly dependent on the results
of the semantic task.
Another main objective of the task and this deliverable is to improve code and documentation to
have a better understanding of the relations and functionality. This is done by realigning project
structure and introducing dependencies and lifecycle management. Moreover logging and error
handling is improved. Standards and conventions for the implementation are defined. Some of
them will be completely enhanced with the next releases.
An open issue is the uncoupling of the entities. For the transformation uncoupling was realized
to simplify maintenance. The MIDB schema can only be updated for this with release 2.0 as
otherwise a backward compatibility is not possible.
The deliverable shows the progress of using frameworks and extensions to fulfill the change
requests of the pilots. Restructuring and refactoring was done. Further requirements and
activities are defined and planned for the next releases. Further major improvements can only
be expected by release 2.0.
43
44
A. Appendix A – Acceptance Criteria
Acceptance criteria
Norm
Process
1.

Conform to SPOCS
template

Template issued by Gov2u(122009)
Check against template
by WP6
2.

Language & Spelling

English (UK)
Review by an English
language specialist by PD
3.

Readability
o related aim
groups
 Executive
Summary
(e.g. for
members of
the
Commission
or reference
groups, who
expect a
rapid
overview of
the results)


comprehensible English
Clear structure & interesting
presentation
Highlight of outcomes and
advantages
Review by PD
High
Review by each partner
and general review by
FOKUS
High
 Main Part
and
Conclusion
o


comprehensible for the
technical experts

Structured sections especially a
hierarchical structure

no complicated structure, no
nested sentences, - in this
context- no unusual vocabulary

Alignment between this
deliverable and the DoW
regarding the effected
account/statements about
objectives and the description
of the deliverable 4.6

No contradictions and
unnecessary repetitiveness
Priorit
y
High
Mediu
m
High
Review by FOKUS
High
Review by each partner,
FOKUS and PD
Layout
o
4.

5.

45
Clearness of the
sentences
Consistency with
description in DoW
Consistency within
the document
Examine this deliverable
and the DoW and
compare the effected
account/statements.
Explain differences and
methodology. Review by
FOKUS and partners
High
To check that there are no
contradictions and
needless repetitiveness
Review by FOKUS and
partners
High
6.

Content is suitable for
purpose
The deliverable fulfils the objectives
of the DoW (See some items in
next paragraph.
The deliverable provides the
needed facts to inform the target
groups, forms the basis for the
preparing and realisation the
second wave of the piloting phase.
7.

Contents is fit for use
This deliverable provides current
information for future users
especially for the second wave
piloting countries:
 Overview of WP4 and in
addition the integration of the
open modules by the countries
of the first wave of piloting
 Benefits from using WP4 are
marked,
 WP4 open modules are
interconnected with the
expected results as described.
 The documentation includes
the needed information for
specialists to handle the
integration
 The open modules implement
the specs from D4.2 the
experience of the first wave of
piloting countries
 The WP4 open modules can be
used from PSC to access SC
and SD corresponding the preassigned official process
 Partners of WP are aware of
this acceptance list.
 Commitment by every WP4
partner to the
WP4 functionality, process
integration and deliverable
input.
 Planning for the Work Package
8.

Commitment within
WP
9

Delivered on time
46
To check towards the
result list and usability.
Check for according
consequences resulting in
revised versions of D4.2,
D4.3. and D4.4
Reviewed by Work
Package Leader and SubLeader in collaboration
with relevant partners
(piloting countries) if
needed.
To Check towards this
result list and usability.
High
High
Reviewed by WPL in
collaboration with relevant
partners if needed.
(e.g. authors D4.7)
The experts of the
partners are involved in
QA-Process.
Review by e-mailing and
commitment by
conference call
High
Check the Project plan at
regular intervals and
contact the suppliers to
confirm the agreed
delivery dates
WP-Leader together with
Sub Leader
High
Table 5: Acceptance Criteria List
Legend:
Deliverable - a description of the deliverable for which the acceptance criteria must be met.
Acceptance criterion – a description acceptance criterion
Norm – a description of the norm that is applied to measure conformance
Process – a description of the process that is used to test conformance
Priority – the priority to meet a acceptance criterion (Low = nice to conform to, Medium =
important to conform to,
High = necessary to conform to)
47
B. Appendix B – Risk List
Threat
Consequence(s)
Modules are
not running

Pilots cannot go
live in time
Technologies
or external
frameworks
cannot be
integrated /
used

Pilots cannot go
live in time
Measure(s)
Major

Restructing of
changes in
modules, components,
specifications interfaces
and
scenarios
Missing
resources
and partner
contributions

Delays for
modules, deliverables and
pilots
Missing /
Lack of
expertise in a
specific
technology

Delays for
modules, deliverables and
pilots
Feedback
lead to
insolvable
issues

live
Quality of
code is not
good enough

Pilots need more
time to understand
integration and deployment
Missing /
Late
feedback

Coding without
alignment to pilots needs

Deliverables
provided to late

Update of
deliverable
Technical
Overview
deliverable is
not accepted
Pilots cannot go
Chance
Impact
Risk

Testing of modules

Improvement of code

Bugfixing

Change of underlying
frameworks and technologies

Change of concepts

Raising awareness at
pilots
L
H
M
L
H
M

Improvement of feedback
mechanisms

Raising awareness at
pilots

Increasing development
resources

Realigning concepts and
specifications

Realignment of work

Reconfiguration of
release scope and functionality

Improvement of
awareness and communication

Communication with
partners and coordination

Realignment of used
technologies
M
H
M
H
H
H
M
M
M

Complete restructuring of
architecture
L
H
L

Improve code clarity

Define conventions

Increase communication
with users

Increase awareness and
communication
H
L
L
H
M
M

Analysis of failures /
expectations

Increase resources for
deliverable update
M
H
H
Table 6: Example risk list
48
Legend:
Threat - Description of a potential danger towards the project.
Consequence - Description of the negative effect the threat can have towards the project.
Measure - Description of the measures that can be taken to prevent a threat from happening or to
reduce negative the effects.
Chance - Defines the likelihood of a threat to happen.
Impact - Measure of the negative effect on the project.
-
49
Risk - Chance * Impact, representing the priority.
C. Appendix C – Technical Code Lists
This section contains all implementation based code lists like exception codes. The content
based code lists like language are part of the updated MIDB schema and located in the
deliverable D4.6.
C.1 Exception codes
The following exception codes are defined until 29th July 2011.
Code
Description
001
at least one mandatory attribute null
002
origin is not N (National), F (Foreign) or L (Local)
003
identifier is not fulfilling the naming scheme
004
at least one associated entity is not registered
005
entity not registered
006
multiple entities registered - corrupt DB
007
code is not registered in MIDB
Table 7: Exception codes
50
D. Appendix D – Enlargement Activities
This section lists the undertaken activities describing the national architecture (Task T4.7) and
amendments to the schemas and specification (Task T4.8) from the enlargement partners
focusing on piloting. The descriptions shall be based on the same structure like for the
descriptions of the previous partners and with the same scope of service catalogues and
eservice directories. The basement is an analysis of D4.1 and D4.2 by the enlargement partners
and bilateral discussions with WP4.
Contributions:




Lithuania
o
Analysis of WP4 scenarios and components including an overview diagram and
questions
o
Comments on MIDB schema, esp. related to Service-Eservice relation and preconditions
o
Comments on Webservice interfaces
Romania
o
Comprehensive description (approx.. 70 pages) of national solution related to SPOCS
scope, scenarios, architecture
o
Results of the questionnaire
o
Feedback on schemas (no amendment so far)
Malta
o
Overview description of the national infrastructure related to SPOCS components and
scenarios
o
Feedback on schemas (no amendments so far)
Slovenia
o

Small verbal feedback with no amendment requests
Portugal
o
No specific feedback with amendment requests
The provided descriptions can be downloaded from the SPOCS website.
As an analysis there is no major barrier to use the described architectures. Microsoft and Oracle
solutions are not creating impacts. Some partners are using Tomcat servers instead of JBoss
thus there is an ongoing discussion within SPOCS at all about the used infrastructure. The main
changes are related to improve using web services for connecting National Connector and WP4
modules.
The other main analysis result is focusing on update of the schemas, scenarios and guidelines
as described in deliverable D4.6 (Task T4.8). The main impact was from Greece trying to use
Oracle database and Lithuania requesting a different scenario approach and thus further
mapping tables.
51
E. Appendix E – Task list before WP1 / WP4 scrum
The following list was used to gather open issues and define tasks for upcoming releases and
development / deliverable activities. The list was used before the alignment of WP1 and WP4
development activities. The issues are consolidated into user stories, tasks, etc. in the actual
planning and releases.
The priority column is just for information to show the status before the alignment. The priorities
and timelines are reorganised related to new resource planning and partner contributions. The
table is reduced by the owner column which related the assignment of partners to specific tasks
as it was not completed and not every task could be assigned to a partner.
The colours of the rows were used to show the status before the alignment. They had a direct
relationship to the timelines.
The table is representing more than just development activities. Activities outside the
development are assigned to the relevant task as described in the Technical Annex.
Nr
1
2
3
4
Description
Verification of cardinality between XSD and SQL
schemes
Multiple Output Documents, thus change of
cardinality
Definition and comparison of profession code lists
Details /
Practical
Example
1
2
Category
Data
Schemes
Data
Schemes
Semantic
Development
5
Description of deployment example incl. e.g.
jndi.properties, jboss configuration, maven build, …
Performance testing for collection handover
6
WP1-WP4 integration test
Test
7
Development
12
Update of change tracking, especially usage of
change table
Development of Webservice Interface for
Transformation
Possibility to create query which accepts ID of
document and returns info of service which issues
this document.
Why eService attribute “ServiceReference” is not in
MIDB?
eService is missing attribute “FurtherInformation”
(URL) which is present in Service
Why Service/eService PreConditions is mandatory?
13
Guidelines for validityStart field
8
14
Formatted text in text fields; limited set of supported
html tags could be defined
Change of cardinality for Condition
9
8
9
10
11
15
52
Test
3
Development
4
Development
5
Data
Schemes
Data
Schemes
Data
Schemes
6
7
10
Data
Priority /
Timeline
Mid May
(Rel. 2)
Mid May
(Rel. 2)
Mid Jun
(Rel. 2)
End May
(Rel. 2)
Mid Jun
(Rel. 2)
End Apr
(Rel. 1)
Mid Apr
(Rel. 1)
Mid Jun
(Rel. 2)
Mid Oct
(Rel. 3)
Mid May
(Rel. 2)
Mid Jun
(Rel. 2)
Mid Jun
(Rel. 2)
Mid Jul
(Rel. 2)
Mid Jun
(Rel. 2)
Mid May
Nr
Description
Details /
Practical
Example
(Rel. 2)
Mid Jul
(Rel. 2)
12
Data
Schemes
Mid Oct
(Rel. 3)
13
Data
Schemes
Data
Schemes
Data
Schemes
Mid Jul
(Rel. 3)
Mid Oct
(Rel. 3)
Mid Oct
(Rel. 3)
Mid Jun
(Rel. 2)
11
18
19
Uncoupling of information objects
14
20
Integration of version number into SPOCS identifier
=> proof whether needed and if needed also
integration by transformationOM
Skipping of semantics from SPOCS identifier =>
complete revision of identification scheme
17
21
22
Update of Technical Overview
Data
Schemes,
Semantics
Deliverables
23
Update of Guidelines
Deliverables
24
Assessment of ontology from WP1
Semantics
25
Semantics
26
Assessment of equivalence, is the actual structure
enough or do we need further attributes, e.g.
equivalence between neededdocs, localized docs
(see also Nr. 39)
Definition of equivalence exchange => if needed
27
Assessment of semantics for professions
Semantics
28
Definition / Update of ontology for professions
Semantics
29
Definition / Update of ontology for documents
Semantics
30
Definition / Update of ontology for services
Semantics
31
Definition / Update of ontology for eServices
Semantics
32
Definition / Update of ontology for organizations
Semantics
33
Definition / Update of ontology for responsibilities
and roles
Update of Data Scheme related to responsibilities /
roles
Update / Assessment of used formats for attributes
in MIDB
Assessment of structured legal descriptions =>
proof whether necessary
34
35
36
53
Priority /
Timeline
Schemes
Data
Schemes
To manage the ‘self-declaration scenario’ => proof
whether scenario can be handled with existing
document type
To manage the ‘geographical area’ concept (apart
from the textual attribute ‘Territory’ in ServiceText
and OrganisationText) => to be checked whether to
complex and not useful
Uncoupling of code lists
16
Category
Development
15
Semantics
16
Data
Schemes
Data
Schemes
Semantics
17
Mid Aug
(Rel. 2)
Mid Aug
(Rel. 2)
Mid Jul
(Rel. 2)
Mid Oct
(Rel. 3)
Mid May
(Rel. 2)
Mid Sep
(Rel. 3)
Mid Sep
(Rel. 3)
Mid Sep
(Rel. 3)
Mid Oct
(Rel. 3)
Mid Oct
(Rel. 3)
Mid Sep
(Rel. 3)
Mid Sep
(Rel. 3)
Mid Oct
(Rel. 3)
Mid Jul
(Rel 2)
Mid Nov
(Rel. 3)
Nr
37
Description
Details /
Practical
Example
Category
Assessment of conditions => proof whether
necessary
Update / Assessment of technical Interface
18
Assessment of localization => proof whether
necessary
Integration of TSL routing to other modules
20
21
45
Again Assessment whether access prove is needed
and if yes in which way
Update of list of attributes used for search
(SPOCSattributes table)
Assessment and update whether it is useful to
change from lists to collections (e.g. HashSet)
Update of guidelines related to the description of
scenarios, especially the two step scenario and
alternative solutions
Setup of an Triple Store
46
Description of an RDF solution for MIDB
Deliverable
47
Update of assessment related to orchestration and
process models incl. the question whether crossborder process chains make sense
Update and description of automated generation
process for development configuration
Update and description of builds and testing
Deliverable
38
39
40
41
42
43
44
48
49
50
51
52
53
54
55
56
57
54
19
Data
Schemes
Data
Schemes
Semantics
Development
Development
Development
22
Development
Deliverable
Development
23
Development
24
Development
Assessment of benefits and needed enhancements
for connection to the solutions of other regions
within the member state and connection to their
standards
SPOCS identifier for text records
25
Deliverables
26
Deliverable
Structuring of legal information that are the basis for
the relations within MIDB
Assessment which languages are supported by the
pilots, needed for the final report
What level of logging is needed for monitoring the
success; Assessment what can be taken from
existing logging and where update is needed;
definition of different logging levels and
standardized logging messages; assessment of
analytic tool and setup
Assessment of SPOCS WP4 results related to EIF
v2.0
Definition of a structure for semantic task and
deliverable
Recommendations for alignment of administrative
procedures in the cross-border context, including
27
Semantics
Deliverable
Semantics
Semantics
Deliverable
Priority /
Timeline
Mid Nov
(Rel. 3)
Mid Jul
(Rel 2)
Mid Oct
(Rel. 3)
Mid Aug
(Rel 2)
Mid Aug
(Rel. 2)
Mid Aug
(Rel. 2)
Mid Nov
(Rel. 3)
Mid Aug
(Rel. 2)
Mid Sep
(Rel. 3)
Mid Sep
(Rel. 3)
Mid Nov
(Rel 3)
Mid Jun
(Rel. 2)
Mid Jun
(Rel. 2)
Mid Oct
(Rel. 3)
Mid Jun
(Rel 2)
Mid Nov
(Rel. 3)
Mid Dec
(Rel. 3)
Mid Jun
(Rel. 2)
Mid Dec
(Rel. 3)
Mid Jun
(Rel. 3)
Mid Dec
(Rel. 3)
Nr
Description
Details /
Practical
Example
Category
59
options for automating process chains
Assessment and description of linked data and
semantic web technologies
Update of back office best practices
60
Update of guidelines for descriptions and formats
Deliverable
61
Update of versioning description, especially relation
to WP1
Check backward compatibility
Deliverable
Development
64
Documentation of source code, location of
JavaDoc; template and guidelines for describing
code
Add Equivalence exchange => see also Nr. 26
65
Add Attribute Category for Services
Semantics
66
Definition of Code List for Services Category
Semantics
67
Make test data more realistic
Test
68
Improve error handling including check of wrong
parameters (wrong length, missing setting of
reverse navigation using hibernate objects, …)
Check logger type
Development
Semantics
72
Sustainability activities, e.g. German usage of
release 3 results/plans
Integrate check for change table whether change
record already exists in the MIDB (failure handling,
inconsistent DB)
Bug with update / checkForUpdate mechanism
73
Improve coding of checkForUpdate methods
Development
74
How is delete of a service text without deleting
service realized?
Make the tables not case sensitive
Development
58
62
63
69
70
71
75
76
77
78
79
80
55
Change SQL Query in DAO objects for method
getNextInternalID to a hibernate based query; using
criteria etc. and not Query or SQLQuery
Make vstart and vend in change table mandatory
Error regarding parameters of getSearchResult in
ProvisionOM/Interface
Update of answer ID, should consist of datetime
and random number and sender
Improve NC interface and exchange “Object”
Semantics
Deliverable
Test
Development
Test
Development
Development
Data
Schemes
Development
Data
Schemes
Development
Development
Development
Priority /
Timeline
Mid Dec
(Rel. 3)
Mid Aug
(Rel. 2)
Mid Aug
(Rel. 2)
Mid Aug
(Rel. 2)
Mid Jul
(Rel. 2)
Mid May
(Rel. 2)
Mid May
(Rel. 2)
Mid Jun
(Rel. 2)
Mid Jun
(Rel. 3)
Mid Jun
(Rel. 2)
Mid May
(Rel. 2)
Mid May
(Rel. 2)
Mid Oct
(Rel. 3)
Mid Apr
(Rel. 1)
Mid Apr
(Rel. 1)
Mid May
(Rel. 2)
Mid July
(Rel. 2)
Mid Apr
(Rel. 1)
Mid Jun
(Rel. 2)
Mid May
(Rel. 2)
Mid Apr
(Rel. 1)
Mid Apr
(Rel. 1)
Mid May
Nr
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
Description
Details /
Practical
Example
parameter with specific ones
Fix errors in search and provision OM
Development
Prepare JUnit examples as templates for pilots, e.g.
especially the NationalConnector
Check SPOC WP4 solution on other environments
(e.g. Oracle and Microsoft)
Organization and documentation of Junit tests,
quick start codes for piloting countries developers.
Ensuring that Unicode character specification will
be present in all modules, MIDBs, etc.
MIDB creation script incompatible with Oracle
Development
Development
Test
Development
Data
Scheme
Development
Support for Oracle database throughout the OM
code? Including e.g. DATETIME-DATE and
LONGTEXT-CLOB => see also Nr. 83
Finalize maven configuration and release
Write installation manuals based on testing
experience => see also Nr. 4
Loading of dependent entitities through
Transformation OM should be separate from
services/eServices to increase effectiveness => see
in addition Nr. 19 (first additional methods rel. 2,
second uncoupling rel. 3)
Transformation API to include methods returning
lists of non-obsolete IDs to support loading of
deleted objects => proof whether findActuals
methods can deliver a full list of all actual objects
(through transformation)
Missing API for obsoleting organisations in MIDB
=> see also Nr. 90
Missing possibility to change name of
ProcessDocument in Transformation OM
ShortName seems too short (25 chars) in MIDB.
Category
Development
Development
Development
Development
Mid Jun
(Rel. 2)
Mid Jun
(Rel. 2)
Mid Jun
(Rel. 2)
Mid Oct
(Rel. 3)
Mid May
(Rel. 2)
Mid May
(Rel. 2)
Mid May
(Rel. 2)
Mid June
(Rel. 2)
Mid June
(Rel. 2)
Mid May
(Rel. 2)
Data
Schemes
Data
Schemes
Development
97
98
Synchronize folder structure in WP4 project
Development
99
Exchange all System.out.println with logger
statements
Check whether only one receiver for searchOM and
provisionOM is useful including realization
Align eclipse configuration, especially to avoid
errors with annotations like @override
Development
100
101
56
Mid Apr
(Rel. 1)
End May
(Rel. 2)
Mid Jun
(Rel. 2)
Mid Jun
(Rel. 2)
Do we need some kind of variants for services /
docs => see also Nr. 17 and 39
Upgrade WP4 project to CXF2.x and
DynamicWebProject2.5/3.0 facets
Usage of @override Annotationen
96
29
(Rel. 2)
Mid Apr
(Rel. 1)
Mid May
(Rel. 2)
Mid Jul
(Rel. 2)
Mid Jul
(Rel. 2)
Mid Jul
(Rel 2)
Mid Apr
(Rel. 1)
Mid Jul
(Rel. 2)
Development
Development
28
Priority /
Timeline
Development
Development
Development
Nr
102
103
104
105
106
Description
Details /
Practical
Example
Category
Priority /
Timeline
Check tests with a complete empty database as
getNextInternalNr() is producing
NullPointerException without any entries in the DB
Check whether a change of the database
configuration to JPA makes sense and realize it
Check NullPointerException on DAO/Home objects
Development
Mid May
(Rel. 2)
Development
Assess whether further plugins/tools can help WP4
development, testing and deployment, make a short
description
Realize syndication interface notification
Development
Mid July
(Rel. 2)
Mid June
(Re. 2)
Mid July
(Rel. 2)
Development
Development
End April
(Rel. 1)
Table 8: Task list before alignment of WP1 / WP4 development
Details:
1. Related to e.g. forms, conditions
2. Service XY produces Doc1 and Doc2
3. Germany has an PHP solution for connection to WP4 information in the national infrastructure
4. Heiko answered: “For release 1 you would need to retrieve the full service and eService from
foreign SC/eSD.”. Not sure if understood correctly: do this mean that we need to retrieve all
service info objects and iterate through them to find one which outputs certain document?
5. It would be more effective to be able to find related eServices directly from MIDB (not through
WP4 IL)
6. It is expected that LT eService descriptions will have this URL pointing to more detailed info.
7. LT do not expect to have any info for PreConditions field (what info which is not covered by other
fields is expected here?)
8. LT do not expect to collect dates of real start of services and/or organisations? Can it be left
unfilled or filled with other date (like date of data entry)?
9. Formatting like bullets, underlines or similar are usual in LT service descriptions
10. ITALY: the table 'Condition' could be used to represent the 'pre-requisites' needed to start a
service? Some examples regarding the Italian service ' applying for a REA license': to be of age,
to be an Italian or EC citizen, capacity to exercise civil rights, no bankruptcy, ...If so, a connection
table is needed alsom in this case, because the cardinality is n:m
11. ITALY: Another issue that could be interesting to address in MIDB is the 'self-declaration'
concept. According to a local legislation, in Italy a SP/enterprise sometimes may 'self-certify' or
'self-declare' some information, without providing specific certificates.Some examples of selfdeclarations: to have achieved a High Scool Diploma, to have an insurance guarantee, ... In
general (but not always) this concerns the information that can be provided by Public
Administrations. In case, a PA can check the truthfulness of these declarations by contacting the
corresponding PA.
12. ITALY: We have this case: the 105 Chambers of Commerce provide some services concerning
the chosen professions. The Chambers of Commerce are different organisations, located in the
Italian provinces; anyway the services concerning the professions are similar, also the input and
57
output documents are the same. How can we represent this fact in MIDB? If we have many
occurrences of 'Organisation' (one per each Chamber) we need to duplicate the 'Service'
occurrences, and this seems not logical ... may we use the table 'ServiceAgency'
13. Code lists are not directly defined as relation within MIDB, only the code is stored (e.g. for
language “de”, “gr” and no internal numbering) and the code lists are externalized or stored as
uncoupled tables in the MIDB; has to include the assessment whether we have all and the right
code lists
14. Relations of Information objects are not defined as relations within the MIDB, only the SPOCS
identifier is stored, allows less complexity and reusability in different context; leads to more
intelligence in modules and further development; e.g. getting a description owner would result in
two requests one for the service/eService and one for the organization
15. For the relation of an organization and a service or eService there might be a more generic data
structure called responsibility or roles, some examples are already defined like intermediary or
agency, maybe this should be an own information object; this should include e.g. the definition of
priorities for the relation of an organization to the eService in the context of a service and it
includes assessment of criteria for defining the responsibility (e.g. area, number of employees,
…)
16. Do we need more complex formats for some attributes, e.g. pricing to be able calculating with the
information and not only publishing them
17. Do we need detailed structures for legal descriptions, e.g. do we only reference to a legal basis or
do we process them anyhow?
18. Do we need more complex condition descriptions, How are they used, How can they be used?
19. Some communication adapter / technical interfaces need more than an address to be reachable
20. Do we need more localization directly integrated into data schemes?
21. This means another assessment whether there are information (full) that should be only available
to a restricted number of persons beside the core information; this includes an assessment for
open data; does it make sense to have also a central platform with all (core) information – e.g.
open cities project, open the information to society or other systems
22. WebService specifications prefer the usage of collection objects as parameter
23. The description should contain a complete description of what is needed to configure the
properties for code generation and persistence correctly (e.g. hibernate revenge, properties,
generation strategies, …)
24. This includes especially all maven, sonartype, svn, etc.
25. What are standards and requirements within your member states, make an update not only
concentrating on your piloting regions
26. SPOCS identifiers for text objects meaning an extension of SPOCS identifier for an existing
information object by text or version or …; relation to existing mechanisms like core and
extension texts, how are content management solutions realizing it, …
27. Responsibilities, services, eServices, organizations are oftenly described in a legal context, do we
want to structure them and work directly on them; leads e.g. to some kind of criteria catalogue,
rule-based solutions and inference engines
28. Length up to 200-300 chars is totally possible. For example unofficial friendly name of permit
could sound like „Licencija mažmeninei prekybai alumi ir pan. (ne daugiau 13 procentų), bei
natūralios fermentacijos sidru (ne daugiau 8,5 procento), parodose“.
58
29. how we should model the case than the same permit is issued by different LT municipalities.
Process (service) will be different for each municipality BUT it would be good to mark these
different services as a kind of “group” as output of these services is same (permit for different
territories)
59
F. Appendix F – Obsoleted Parts of Deliverable D4.4
This section contains obsoleted texts of the deliverable D4.4. The texts are still in the appendix
to show evolution of decisions on architecture and implementation.
The numbers are related to the headings in D4.4.
The first paragraph gives a short explanation for making this part obsolete.
2 Technical Overview
The technical overview is updated related to the realignment of the scope for the scenarios and
usage of the open modules. The focus for the piloting scenario is based on the interoperability
mechanism syndication. The interoperability layer is not further developed until a specific
request of pilots. Moreover provision and search module are merged. Access is skipped as the
provided information will be set as open data and thus a verification of the users not needed
anymore.
Information / Data objects are only slightly adjusted and integrated above.
The Section “Technical Overview” gives an overview about the Open Modules and how they are
related to each other. The main dependencies and components are also shown in Figure 11. It
is based on the description of the scenarios within deliverable D4.2 “specifications”. WP4
scenarios are using the Metainformation Database (1) storing the core information of services
and eServices, transformation module (2) for loading and updating data of the MIDB,
syndication (3) for synchronizing the MIDB information, search (4), access (5) and provision
module (6) for requesting and providing full information in the cross-border lookup scenario.
Integration points on the member states domain are the national connectors linking SPOCS
WP4 modules with the national infrastructure (Service Catalogue, eService Directory, User
Management, Point of Single Contact solution/portal).
60
Member State A
Member State B
WP4 INTEROPERABILITY FRAMEWORK (WP4 IF)
Use Case “Lookup full information”
(5)
Access
module
Use Case “Search Core Information”
(6)
Provision
module
UM
(4)
Search
module
PSC
optional
Use Case “Load & update MIDB”
(2)
Transformation
module
SC
(1)
MIDB
eSD
(7)
Orchestration
module
Use Case “Execute
semi-automatic
transaction” (optional)
(3)
Syndication
Interface
Use Case
“Syndication”
optional,will initially
NOT be available
SPOCS
configuration
Legend
internal connections
of WP4 IF and within MSs
are not shown
WP4 Open Modules
Existing national infrastructure
Integration Points
(WP4 National Connectors)
Figure 11: Overview WP4 Open Modules (OMs), their Integration Points (WP4 NCs) and the Technical Use
Cases they support (Deprecated)
The following sections detail the core objects / classes, sequences and components. Section
2.1.4 describes the information entities / objects used in the MIDB (DB model / SQL script) and
for the exchange format of the WP4 Interoperability Layer (XSD schema) including information
about WP4 Configuration Set, Equivalence and Change. Section 2.1 starts with a package
overview and dependencies to other WPs followed by a description of the sequences based on
the scenarios for search and lookup and ends with descriptions of the components as
mentioned in Figure 11.
Further detailing like interface descriptions, detailed sequences or method declarations can be
added if needed. Keep in mind that this section is giving just a technical overview. There is also
inline documentation provided with the Open Modules.
2.2 Components
The Section ”Components” describes the modules and their relations including the interfaces.
Figure 12 shows the modules of WP4 as described in the WP4 IF concept. WP4 modules are
related to WP1 for the Syndication scenario and to WP5 for the connection to the national
infrastructure. The specific interfaces and methods / operations are described in the following
Sections.
The following Subsections are describing Access, Provision, Search and Transformation. MIDB
and National Connectors are described as referenced objects. Configuration needed for WP4 is
actually part of the MIDB (see Section 2.1.4). Configuration might be shifted to “SPOCS
61
Common Package” in the Reference Environment what is also reflecting other WPs and
deployment. Moreover Syndication is already described in WP1 deliverable D1.4.
Figure 12: Inter-WP Relations (Deprecated)
Deployment of WP4 modules into the application server is done through the building process of
Maven and the underlying libraries and dependencies. The binaries and libraries as well as the
maven building file (pom.xml) are part of the WP4 distribution located in the Reference
Environment (https://dev.spocs.bos-asp.eu, https://svnext.bos-bremen.de/SPOCS/ ) in the
package “SPOCS_WP4_OMs”. National Connector needs to be deployed based on the internal
deployment process of the host (e.g the PSC).
Configuration of the hosting application server is necessary for the deployment including
deployment folder, setting of URLs and credentials for administration. This information is given
by your application server solution.
2.2.1 Sequences
Sequences are based on the scenarios described in deliverable D4.2. This Section concentrates
on the two scenarios “search within the MIDB” and “cross-border lookup”. “Loading” and
“Syndication” is not detailed in sequences but the related components are addressing the
procedural aspects.
62
sd Search
MS A
:NationalConnector
:SearchOM
:ProvisionOM
MIDB
handleSearchRequest()
getMIDBAnswer(request) :result
getSearchResult()
getAnswer()
Figure 13: Sequence for search within MIDB (Deprecated)
Figure 13 shows the sequence for search within the MIDB. All components and the MIDB are
deployed in the domain of MS A.
The National Connector is invoking the handleSearchRequest method of Search OM. The
Search OM is retrieving the information from the MIDB using data access objects. The result is
given as parameter to the getSearchResult method of the ProvisionOM. The Provision OM is
invoking the getAnswer method of the National Connector.
63
sd Lookup
MS A
:NationalConnector
:ProvisionOM
MS B
:SearchOM
:SearchOM
:AccessOM
:ProvisionOM
:NationalConnector
(foreign MS)
handleSearchRequest()
findOtherSearchOM()
:routing
createSOAP() :
SOAPmessage
handleSearchRequest()
verifyAccess()
verifyUser()
:boolean
:boolean
getSearchRequest()
handleAnswer()
findOtherProvisionOM()
:routing
createSOAP() :
SOAPmessage
handleAnswer()
getAnswer()
Figure 14: Sequence for cross-border lookup scenario (usage of WP4 IL) (Deprecated)
64
Figure 14 shows the sequence for cross-border lookup using the WP4 Interoperability Layer.
The National Connector of MS A is invoking handleSearchRequest method of Search OM of MS
A. The Search OM retrieves necessary routing information and creates the SOAP message.
SOAP message is sent cross-border to handleSearchRequest method of SearchOM of MS B.
The Search OM of MS B is invoking verifyAccess method of Access OM of MS B which is
invoking method verifyUser of the National Connector of MS B. The methods deliver the
verification result (boolean). If access is granted Search OM of MS B invokes the
getSearchRequest method of National Connector of MS B. The National Connector of MS B is
using the request for retrieving within the national infrastructure and invokes the handleAnswer
method of Provision OM of MS B. The Provision OM of MS B is retrieving routing information
and creates the SOAP message. After that Provision OM invokes the handleAnswer method of
Provision OM of MS A. The Provision OM of MS A forwards the answer by invoking the
getAnswer method of National Connector of MS A.
Messages are based on XML schema and using Java interfaces. The cross-border messages
between Search OMs or Provision OMs of different MSs are using standard SOAP envelopes
and Web Services.
The methods are mainly not delivering a result as the communication is asynchronous.
Requests are handled by Search OM and response (answers) is handled by Provision OM. The
update of the modules will assess the need for failure management and acknowledges as direct
results of invoked asynchronous methods.
2.2.2 Access
Access OMs are handling the verification of the requester for the cross-border lookup of full
information. This mechanism is established to protect the technical information used in
automated process.
Figure 15 shows the flow for the verification invoked by the Search OM for cross-border
requests. The Access OM is retrieving the MIDB for the user and checking the password.
Actually only a request within MIDB and only simple password mechanism is realized.
cmp Access
Search::SearchOM
AccessOM
verifyAccess
MIDB::MIDB
verifyUser
Figure 15: Access Component (Deprecated)
Figure 16 shows the change for the second piloting phase where the user verification will be
done through the NC, which is connected to the user management of the PSC portal / solution.
The NC will support a specific technology approach like LDAP or Active Directories. Access OM
will extract the user credentials and create a request as demanded by the NC. Moreover the
exchange of user information will be assessed, whether tokens or other secure transports are
possible. The five star solutions would implement STORK activities, but the first piloting has to
show whether such an advanced solution is necessary.
65
cmp AccessUpdate
Search::SearchOM
NationalConnectors::
UserManagement
AccessOM
verifyUser
verifyAccess
LDAP, Active Directory, ...
Figure 16: Access Components (Update) (Deprecated)
2.2.3 Provision
Provision OMs are handling the answers based on the SPOCS XML scheme. The flow is
separated to the two different scenarios: Search for core information in MIDB and Lookup of full
information at the foreign SC / eSD.
Figure 17 shows the flow for the provision of information invoked by a local search within the
MIDB (request FullInfo “false”).
The Search OM is requesting the result from MIDB and provides the Provision OM the result
based on Java objects generated on the database model. Therefore the Search OM invokes the
getSearchResult method (see Section 2.1.1). The Provision OM is than creating the XML
objects. At least the ProvisionOM invokes the getAnswer method of the NC.
cmp Prov ision
Search::SearchOM
NationalConnectors::
NationalConnector
Prov isionOM
getSearchResult
Java rel.DB objects
getAnswer
XML objects
Figure 17: Provision Component for Search Core Info at MIDB Scenario (Deprecated)
Figure 18 shows the flow for the provision of information invoked by the foreign NC based on a
cross-border full information lookup (request FullInfo “true”).
The foreign Provision OM handles the answer provided by the foreign NC and retrieves the
corresponding Provision OM of the request sender. Than the Provision OM processes the
provideExtAnswer method to send a cross-border message based on the defined XML schema
to the Provision OM in the domain of the request sending PSC. This Provision OM is handling
the answer and forwarding it to the NC by invoking the getAnswer method of the NC.
66
cmp Prov isionCrossBorder
SPOCS Cross border
XML
based on SPOCS xsd
provideExtAnswer
NationalConnectors::
NationalConnector
(foreign MS)
handleAnswer
NationalConnectors::
NationalConnector
Prov isionOM
handleAnswer
getAnswer
XML
based on SPOCS xsd
XML
based on SPOCS xsd
Figure 18: Provision Component for Lookup Full-Info Scenario (Deprecated)
2.2.4 Search
Search OMs are handling the requests based on the SPOCS XML scheme and retrieving the
MIDB. The flow is separated to the two different scenarios: Search for core information in MIDB
and Lookup of full information at the foreign SC / eSD.
Figure 19 shows the flow for the search of information invoked by the NC (request FullInfo
“false”).
The Search OM is requesting the result from MIDB and provides the Provision OM the result
based on Java objects generated on the database model. Therefore the Search OM processes
the getMIDBAnswer method. The Search OM is than invoking the getSearchResult method of
the Provision OM.
cmp Search
NationalConnectors::
NationalConnector
SearchOM
handleSearchRequest
MIDB::MIDB
getMIDBAnswer
XML
based on SPOCS xsd
Figure 19: Search Component for SearchCore Info at MIDB Scenario (Deprecated)
Figure 20 shows the flow for the search of information invoked by the NC based on a crossborder full information lookup (request FullInfo “true”).
The Search OM handles the request provided by the NC and retrieves the corresponding
Search OM of the request recipient. Than the Search OM processes the
provideExtSearchRequest method to send a cross-border message based on the defined XML
67
schema to the foreign Search OM in the domain of the request receiving PSC. This Search OM
is handling the request and verifying the access through Access OM. If access is granted
Search OM forwards the request by invoking the getSearchRequest method of the NC.
cmp SearchCrossBorder
SPOCS Cross border
XML
based on SPOCS xsd
provideExtSearchRequest
NationalConnectors::
NationalConnector
handleSearchRequest
SearchOM
handleSearchRequest
getSearchRequest
XML
based on SPOCS xsd
XML
based on SPOCS xsd
NationalConnectors::
NationalConnector
(foreign MS)
Figure 20: Search Component for Lookup Full Info Scenario (Deprecated)
2.2.5 Transformation
Transformation OMs are handling the loading of the national data to the MIDB. Moreover
Transformation OM offers transformation methods for other OMs to convert data from one
SPOCS format to another one. Transformation is internally handling the change tracking.
Figure 21 shows the flow for the uploading of information invoked by the NC. The
Transformation OM loads the data and converts them to the needed format of the MIDB. For the
first piloting phase the loading is realised by receiving Java objects based on the XML scheme
and the update of the MIDB is realised through the Java objects based on the relational MIDB
data model.
Future versions will support more formats for the loading from the NC as well as for the MIDB.
cmp Transformation
NationalConnectors::
NationalConnector
MIDB::MIDB
TransformationOM
loadData
updateData
XML
based on SPOCS xsd
Java rel.DB objects
later support of plain formats planned:
Mapping GUI [plain <-> XML SPOCS]
stored in simple list or CSV
later support of RDF Triple
Store and XML DB planned
Figure 21: Transformation Components (Deprecated)
68
3.4 Routing and Message Technology
The routing is obsolete as the architecture scope for using the interoperability mechanisms is
switched from supporting two approaches with the interoperability layer to exchange XML based
information and the syndication to synchronize the databases based on a feed. The syndication
will be the further supported mechanism and thus a routing is actually not needed for WP4.
WP1 has it’s own routing description. The described tables and functions etc. will be deleted for
upcoming releases.
For the first piloting phase, routing will be realised as a simple routing table. The routing
information is stored in the MIDB and consists of:

idRouting - Internal identifier for a unique record of the routing table. Represents the
primary key.

ModuleID – Represents a SPOCS identifier for the module. The ID is based on the
identification scheme and can have the types: SearchOM, ProvisionOM, SyndicationOM,
TransformationOM and AccessOM. The first three types are directly used within the
scenarios.

ModuleName – Represents the textual name of the module.

Address – Represents the URL of the module to be addressed within the scenarios.

ModuleOwner – Represents the name of the owner of the module.

Remarks – Optional attribute to allow further comments for the usage.
Routing can be retrieved through a Routing Open Module. The Routing OM can provide the full
Routing info or only the address based on type and owner. Moreover the Open Module can
provide a list of all routing addresses of a specific type to allow a notification mechanism like it is
needed for syndication.
The Open Modules of the WP4 Interoperability Mechanisms (WP4 Interoperability Layer and
Syndication) are registered as extension in a trusted service list (TSL - see deliverable D3.3).
The TSL mechanism allows a minimum level of trust to avoid electronic attacks.
Other routing alternatives like DNS are not further discussed as the decision of the Consortium
was to avoid central infrastructure regarding to the need of sustainability.
Exchange of routing information is not realised so far, but will be updated.
Another option is the storage of the modules as eService records. The feedback of the pilots will
assess whether this is another option.
The messages are transported based on SOAP and XML. The SOAP solution is used for all
cross-border transports. The feedback of the piloting phase might check whether further WP3
results can be used for routing and transport.
Between the Open Modules of one deployment, Java interfaces are used and Java objects
based on XML or relational data model are provided.
69