SDP Labs

Aim of the RA

Telefónica is opening some of its network capabilities to Third Parties through a SDP (Service Delivery Platform) platform, exposing a number of APIs (SOAP, REST). These APIs, can therefore be used by companies and developers to build a new generation of telecommunication enabled applications and services.
In the Panlab framework, some of the Telefónica network capabilities have been exposed as open APIs through the testbed SDPlabs. The developed RAs are the following:

 SDP RA: This is the main Resource Adapter that performs general configuration operations needed by the rest of RAs (Provisioning and Security).
 SMS RA: Allows sending SMS messages through the mobile network.
 Contacts RA: Allows for the retrieval of a user contact list.
 Presence RA: Provides an application for detecting a user from a mobile network.

Implementation

The mission of the implemented Resource Adapters consists of provisioning all the data necessary to configure each of the services which are publically exposed by the SDPLabs testbed. The main principles in which the SDPLabs testbed capability opening is based are the following ones:

• An external Application Provider (a third party company) is allowed to use the capabilities offered by SDPLabs in order to develop a number of client applications (called Consumers, in the TID’s terminology).
• Each Consumer (application) is allowed to use one or more SDPLabs capabilities.
• Each Consumer can allow one or more final users to use its services (i.e. to use an application).
• Access to applications is granted by Consumers and by the global SDPLabs platform using an  OAuth authorization schema.

The provisioning process for SDPLabs consists, in general, of two main phases:

1. A general configuration phase including the provisioning of a test Application Provider, a test Consumer and a all the permissions needed to be granted to the Consumer to access different kinds of capabilities (SMS sending, presence detection, access to contact lists, etc).
   
2. A specific configuration phase consisting of access granting to test final users. This final step enables the developers to test the complete behavior of their applications when used by final users.
   

The first phase of the SDPLabs configuration process, which is common for all the final services to be exposed by TID’s platform, is implemented by the SDP Resource Adapter. The second phase is implemented by the rest of the resource adapters for each of the basic SDPLabs public enablers (SMS RA, Contacts RA, Presence RA).
The way the RAs are interacting with the other components can be seen in the figure below. It is necessary to remark that some of the resulting data retrieved by the SDP RA as result of its provisioning operations need to be used by the rest of resource adapters. Therefore, reference dependency exists between these RAs.

([])
The following table contains the main operations performed by the TID SDPLabs resource adapters. Since the SDPLabs is a static preexistent platform, the Create operation has no effect over the whole system. Any further configuration operation will be performed via the Update operation.
Each of the basic CRUD operations is in charge of invoking a sequence of basic provisioning operations, some of which are contained in the following table.

RA's basic provisioning operations:


The final configuration is completed through a sequence of invocations to a set of internal private provisioning APIs exposed by the SDPLabs platform. As shown in the following schematic sequence diagram, these APIs are invoked by means of SOAP and/or REST interfaces; therefore, the machinery needed for the consumption of this kind of operations needs to be included in the resource adapter’s code (such as Axis based client libraries).

Sequence of provisioning operations performed for the Update method in the SDP Resource Adapter:


Sequence of provisioning operations performed for the Update method in the SMS Resource Adapter:


([])

CRUD operations implementation

The implementation of these operations consists of a set of RA specific methods (written in Java as part of template-based OSGi Java classes) that will be called when invoking one of the operations, triggering the execution of a sequence of provisioning operations, making use of a set of TID’s internal SDP REST and SOAP based APIs.

The CREATE operation will not perform any real action over the SDP Labs since it is a static preexistent platform. Any further configuration operation will be performed via the UPDATE operation. The SMS is already created.

The RETRIEVE operation can be used to retrieve the security credentials and other provisioning information generated by SDP RA to be used by the rest of resource adapters (SMS/Contacts/Presence RA). In other words the RETRIEVE operation obtains configuration to be used by another RA in the case of SDP_RA, or obtains configuration parameters from the SDP_RA in case of the SMS_RA.

The UPDATE operation refering to the SDP_RA, runs the following methods: addServiceProvider(), addConsumer(), and addHiring() which not only are creating the application provider and the associated consumer accounts but also provide a consumer name for the consumer RA and generate the consumer’s security credentials to be sent to the other RAs to be used for OAuth authorization: the consumer key and the consumer secret, following the terminology used in  RFC 5849. The application provider parameters to be provided to the SDP_RA are: Name, Telephone, Address, and Email.

The SMS/Contacts/Presence_RA receives the following parameters: login, password, msisdn, email The UPDATE operation, referring to the SMS/Contacts/Presence_RA, calls the following methods: addUser(), getRequestToken(), authorizeRequestToken(), getAccessToken(), and sendEmail() which are used to create and configure the SMS user, generating and distributing via email valid OAuth security credentials to Panlab users. OAuth security credentials are generated based on:

• A REST API defined, implemented and added to SDPLabs platform.
• An additional SOAP API for OAuth credentials validation, added to TID’s SDPLabs platform
• The email parameter provided to SMS/Contacts/Presence_RA by the user
• The consumer key & consumer key secret provided by the SDP_RA
• The generated credentials are sent by the SMS/Contacts/Presence_RA to the user using the provided email parameter. The sent email contains the following information: the OAuth consumer key, the OAuth consumer secret, the OAuth new user’s token and token secret.

The DELETE operation removes the application provider and the associated customer accounts by calling the removeHiring(), removeConsumer(), and removeServiceProvider() methods in the reverse order as they have been added for the SDP RA. In the case of the SMS/Contacts/Presence RA the test user is removed and the security credentials are revoked.

In case of the SMS_RA the user is removed and the security credentials are being revoked.

Testing feedback

1. Uploading the RA

Some initial problems have been found when trying to upload the RAs of type:

java.lang.NoClassDefFoundError: org/apache/axis2/AxisFault

The cause of these could be the following issues:

1.1 Missing Axis libraries
The problem could be that the needed axis libraries are not packed properly into the RA jar bundle. To pack all the axis libraries within the bundle, at the command prompt in the “dist” directory of the Net Beans project type:

jar uvf  <NameOfJarFile>.jar /lib

which will pack the libraries found in /lib within the <NameOFJarFile>.jar

1.2 Previously not removed active/inactive bundles
In the case that the libraries have been packed successfully, the problem could be the active/inactive bundles that have been previously unsuccessful uploaded/removed. It turns out that in some cases the bundles are not removed properly from the PTM remaining registered in Oscar (although the bundles are not present in the PTM they appear present in the Oscar process list - active/inactive -). This could be due to:

• previous attempts to upload a RA (that was not uploaded properly)
• previous attempts to remove a RA (that was not removed properly)
• unexpected, (unplanned) server shutdown
• and possibly due to stopping Oscar without the “shutdown” command (using CTRL +C)

Solution 1:
The jars can be downloaded from:

•  http://svn.panlab.net/filedetails.php?repname=PII&path=%2FWork+packages%2FWP2-Infrastructure%2Fdev%2Fptm%2FRALCommon.jar
•  http://svn.panlab.net/filedetails.php?repname=PII&path=%2FWork+packages%2FWP2-Infrastructure%2Fdev%2Fptm%2FRALManager.jar

Update the bundles ral-common and ral-manager with the appropriate jar using the following commands:

ps

to the Oscar console to see what ID is ral-common and Resource Adapter Manager have

update <ral-common-ID> file:/{path to RALCommon.jar}

update <Resource Adapter Manager-ID> file:/{path to RALManager.jar}

refresh

– to refresh the package

Solution 2:
Update the profile directory pii-ral-cmd found in /{user_home_director}/.oscar The profile can be found in:

•  http://svn.panlab.net/filedetails.php?repname=PII&path=%2FWork+packages%2FWP2-Infrastructure%2Fdev%2Fptm%2FRALManager.jar

Solution 3
If solution 1 does not work this can also be solved by typing

ps

at the Oscar console, which will display all bundles with their Id, state (active/inactive), and name. After this at the Oscar console one needs to type:

uninstall <id> <id>...

in order to remove the unwanted bundles, where <id> are the ID's of the unwanted bundles (type help for more info about the allowed commands). Then, followed by the

shutdown

command to stop Oscar, restart Oscar and try to upload again.

Recommendation: Make a “refresh” command at the Oscar console after each change (including changes in the PTM).

2. Size upload limit

Due to the fact the the RA needed to use Axis2 libraries, these needed to be packed inside the RA bundle so our final RAs size were 13, 78 Mb for the global RA (SDP_RA) and 24 Mb for the SMS RA. The RAL had to be modified due to the fact that it did not permitted uploading of RA that exceed 2 Mb.