Service Metadata Publisher (SMP) is a component of eDelivery that is responsible for Capability Lookup: once the sender discovers the address of the receiver's SMP (Service Metadata Publisher), it is able to retrieve the needed information (i. e. metadata about the location and capabilities) of the receiver. With such information, the message can be sent.

In other words, the SMP is a register of the message exchange capabilities and location of participants. The SMP is usually distributed.

SMP is used in Dynamic discovery mode to help route the messages to the correct recipient

To ensure that an SMP is needed for your implementation, an "Assessment Tool " is provided to help you define your needs 

The SMP communicates with the Web services offered by the targeted SML using SOAP requests over HTTP/HTTPS.

SMP being fully developed in Java is therefore portable to any platform supporting the Oracle Java JRE/JDK 7/8.

SMP has been deployed and tested successfully on Windows and Linux platforms.

Open JDK or other manufacturers JRE/JDK are not supported.

SMP can be deployed on the following application servers:

• Apache Tomcat 8.0.x

• WebLogic 12c

Users of other application servers may benefit from the "Support for additional Application Servers" space driven by the users of eDelivery. Specific patches for supporting additional application servers can be developed and published.

The eDelivery SMP profile version 1.10 and DomiSMP version 4.2 only support the OASIS SMP 1.0 specification.

Upcoming versions of the eDelivery SMP profile (2.0) and DomiSMP (5.0) will support both the OASIS SMP 1.0 and OASIS SMP 2.0 specifications. No other specifications are supported.

Please refer to the question “What specifications are supported by the eDelivery SMP profile and the DomiSMP sample implementation?” for information about the specifications supported by DomiSMP.

DomiSMP can only be used in networks that rely on a supported specification. Please refer to the web site and/or help desk of the specific network in which you would like to use DomiSMP to find up to date information regarding the specification(s) it supports to determine if DomiSMP can be used in that network.

SMP can use the following database backends:

• MYSQL 5.x and above

• Oracle 11 and above

The SMP artifacts are freely downloadable from the "SMP Digital portal".

eDelivery SMP supports the following specifications:

• SMP 2.5 and below support PEPPOL specification

• SMP 3.0 and above support OASIS specification

Yes, SMP is released under the "European Union Public Licence".

The SMP source code is available in the SMP project git repository.

The JDBC drivers can be downloaded from the official websites of the manufacturers:

• MYSQL JDBC Driver

• Oracle JDBC Driver

As the SMP uses the Apache Log4j for logging, it is configured in the embedded WEB-INF/classes/log4j.properties.

The SMP ‘.war’ file must be redeployed and restarted after modifying the ‘log4j.properties’ file.

Two cases are possible: 

• Your certificate is still valid: go to Case 1

• Your certificate is already expired: go to Case 2

CASE 1:  Your SMP certificate is still valid

The following procedure is to be followed while the certificate that is already registered in the SML is still valid. The SMP must call the Webservice operation PrepareChangeCertificate in BDMSLServiceInterface to change the certificates in SML on a predefined future date. The operation PrepareChangeCertificate expects a new trusted certificate.

Pre-requisites:

• The current certificate of the user is valid, 

• The new certificate must be compliant with user permission rules for SMP in SML,

• The user has the new certificate for the SMP(s).

Description:

This operation allows a SMP to prepare a change of its certificate. It is typically called when an SMP has a certificate that is about to expire and already has the new one. This operation must be called while the certificate that is already registered in the SMP is still valid.

If the migrationDate is not empty, then the new certificate MUST be valid at the date provided in the migrationDate element.

If the migrationDate element is empty, then the "Valid From" date is extracted from the certificate and is used as the migrationDate. In this case, the "Not Before" date of the certificate must be in the future.

Error management: 

• Fault: unauthorizedFault - returned if the caller is not authorized to invoke the PrepareChangeCertificate operation

• Fault: badRequestFault - returned in one of thoses cases:

  • The supplied request does not contain consistent data, 

  • The new certificate is not valid at the date provided in the migrationDate element,

  • The migrationDate is not in the future, 

  • The migrationDate is not provided and the "Not Before" date of the new certificate is not in the future, 

  • The migrationDate is not provided and the "Valid From" is in the past.

• Fault: internalErrorFault - returned if the BDMSLservice is unable to process the request for any reason.

CASE 2: Your SMP certificate is already expired

The following procedure must be followed to update the existing SML registrations currently linked to the Old certificate when the Certificate of SMP is already expired:

1. In SML Database, the existing registrations are linked to the old certificate and these registrations need to be updated when changing certificate in order to support updates or removal of old SML entries with the new certificate.

2. You need to send the details for the new certificate to eDelivery SUPPORT CEF-EDELIVERY-SUPPORT@ec.europa.eu and request the update for a specific time.

The information you need to provide is: your new certificate file(.cer), the serial number, the SMP ID and the environment (Production or Acceptance).

Example: 

• New Certificate file Zipped and attached to the mail

• SMP ID:Test_SMP_ID

• Serial Number: 0BF1 1660 4702 F47B F02E 0491 ED54 3C9B 

• Environment: Acceptance

1. The Sending Access point calculates the hash of the Receiving's Participant ID and uses it to build the Receiving's domain addresses in the DNS.

2. The Sending Access point gets the SMP address, which contains the Receiving Access point Metadata, from the DNS using the previously calculated domain addresses. The eDelivery or other clients would normally look up these Receiving domain addresses on either the NAPTR(Name Authority Pointer) record, the CNAME(Canonical Name) record, or both records from the DNS.

SMO is the acceptance environment of the SMP.

The eDelivery specification does not specify whether the access to the metadata hosted in the SMPs should be restricted or not.

No restrictions are applied by default, but each business domain can choose to limit the access.

Access to the SMP metadata can be restricted by using HTTPS/basic authentication, TLS mutual authentication, VPN, etc, if needed.