Created IChassisCapability interface.

IChassisCapability is defined and ChassisCapability implements it.

ChassisCapability implementation is independent of sendMessage method, as this method is to be removed.
But still sendMessage is used in refreshActions.

createActionAndCheckParams method has been created in Abstract capability to reuse it in others.
ICapablity does not extend ILifecycle.

We don't want to export ILifecycle interface together with ICapability.

ICapabilityLifecycle interface has been created. It export ILifecycle methods and extends ICapability.
Resource uses ICapabilityLifecycle to manage it's lifecycle. IResource interface exports them as ICapabilities.

To get a particular capability from a resource, a method in Resource should be used:
- resource.getCapabilityByType(String capabilityName)
- resource.getCapabilityByInterface(Class<ICapability> interfaze)

KarafCommands should use these methods.
Added TODOs for removing some abstract methods in Abstractcapability.

Methods to remove are the ones regarding lifecycle.
autobahn: Add first revision of Autobahn driver

This patch adds support for requesting and shutting down
connections via the Autobahn BoD.

This initial version hardcodes most connection parameters due
to lack of support for such parameters in OpenNaaS (bandwidth,
vlan ID, lifetime, etc). Once OpenNaaS BoD support has been
extended, the driver can be extended too. Consider this driver
a use case to drive the OpenNaaS BoD support forward.

The initial version lacks support for queue transactions. This
is because the Autobahn webservice is stateless and does not
support explicit transaction demarcation. Poor man's
transaction support without isolation could be achieved
by rolling back the creation/release manually (by releasing
or recreating), although there is no guarantee that a released
resource can be rereserved (it may have been taken by other
reservations). Implementing this is not straightforward as
OpenNaaS lacks support for a queue context or some other
way of maintaining state accross actions that are part of the
same queue execution. Once such support is added the poor man's
transaction support can be implemented.

The Autobahn driver requires access to both the user access
point and adminstration webservice interfaces of Autobahn.
These are by default published on the same port, so the
protocol context URI is simply the base URI for both services.
Eg:

protocols:context bod:autobahn autobahn http://autobahn.example.org:8080/autobahn/

The driver will internally append "uap" or "adminstration" to
this URI.

Access to the administrative interface is required as it is
otherwise not possible to query the list of existing reservations.

Note that OpenNaaS provides no user interface for inspecting the
model of the BoD resource. You either have to know the network
interfaces of Autobahn (by using the Autobahn GUI) or you have
to inspect the OpenNaaS log files.

Note that the Autobahn reservation process is asynchronous. When
OpenNaaS executes the request action, the driver only submits a
reservation request. Setting up the reservation can possible take
minutes (in multidomain setups). Therefore the driver will create
a link in the resource's model for any reservation not in a
finished state. Autobahn does allow a callback to be registered,
but this requires that OpenNaaS implements a particular webservice
and that there is connectivity from Autobahn to OpenNaaS (no
firewall). In either case, OpenNaaS doesn't know about such
asynchronous changes, so even if we implemented the callback
interface, we wouldn't be able to react to reservation changes
outside the execution of a queue.

As mentioned above, a reservation is represented as a link in
the model. It is set on the source's linkedTo field. Note that
Autobahn supports creating multiple reservations between the
same two ports (interfaces): Each reservation can use a
different VLAN ID. Since an interface in OpenNaaS only has one
linkedTo field, such reservations cannot be represented in
OpenNaaS.

Note that the NSI protocol treats interfaces differently: NSI
uses the concept of a network service endpoint, and such an
endpoint incorporates the VLAN. Ie VLAN isn't a property in NSI.
Instead, if you have two interfaces A and B, and a VLAN range
of 1000-1002, then you have service endpoints A-1000, A-1001,
A-1002, B-1000, B-1001, B-1002 (or whatever naming scheme the
NSA chooses to implement). In that case you can indeed only
have one connection between two endpoints (which would be
interfaces in OpenNaaS). The problem here is that often one
cannot connect all endpoints, eg A-1000 and B-1001 are not
connectable (depends on the hardware, of course). My point is
that BoD systems are sufficiently different from each other
that it may become difficult to make a common abstraction
in OpenNaaS (or that it will require extensive configuration
info to map between OpenNaaS' representation and the
representation in the BoD system - something that would be
a pain to maintain).

Authentication in Autobahn is disabled by default and it not
supported by the initial revision of this driver.

Integration tests are missing. These will be added soon.
bod: Add VLAN ID, reservation period, and capacity parameters

The patch extends the OpenNaaS BoD subsystem with features
required to make it useable with Autobahn.

The Autobahn driver is updated to use the new features.

I added the Joda Time library as a dependency.
bod: Add CLI support for listing interfaces and links

The patch adds the l2bod:interfaces and l2bod:links commands
to list the interfaces and links registered in the model of a
BoD resource.
autobahn: Add transaction support

I found a solution to the problem of attaching cross-action
state during queue execution: A thread local variable holds
the log. As long as all actions on a queue are executed
from the same thread, this solution will work nicely.

Callouts to Autobahn are now performed by commands queued
for execution during confirm. In case of restore the commands
know how to undo what they did.

The pattern I follow here sort of replicates some of the
functionality of QueueManager: Queuing, execution and rollback
of commands is not unlike the queueing, execution and rollback
of actions done by QueueManager. I get the feeling that
the Action concept could be improved such that the execute and
undo actions could be part of the actions themselves, thus
avoiding the need to implement something like the Transaction
class in the driver.
autobahn: Added Response items to ActionResponses

Action responses can contain a list of Response objects. These
document the actions performed on behalf of the action and their
result. This is convenient now that the bulk of the processing
happens in the ConfirmAction and the RestoreAction.

It is also convenient to use this to report on discovered ports
in GetTopologyAction.

This patch refactors the transaction code of the Autobahn driver
to generate Response objects.

Unfortunately the OpenNaaS QueueManager execute output only
contains this information in case of failures. In case of success
the QueueManager replaces the ActionResponse with an empty one.
autobahn: Add status query to submit service command

SubmitServiceCommand now blocks until the service
either reached the SCHEDULED state or the ACTIVE state
(depending on whether the service is flagged for
immediate processing or not).

This also means that the SubmitServiceCommand can
now fail after having submitted the service. This
required minor changes to the Transaction object.
bod: Usability improvements in listing of links and interfaces

The network model used for BoD resources doesn't capture all
properties of the Autobahn BoD driver. This patch adds some of
this information to the output of l2bod:interfaces and l2bod:links,
but without adding Autobahn specific properties to the generic model.
Merge commit '4e18c1135b2122e4dd36ca4c4e3c39a1fbaab3bc' into feature/autobahn
Added missing @Injects in integration tests
Added missing imports that broke compilation in previous commit (3cbb3d7b8c).
Fix gave up waiting for service error.

This error was appearing together with the following one, being this one the cause:
org.apache.aries.jpa.container   | No JTA datasource could be located using the JNDI name osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jdbc/opennaas-resources)
javax.naming.NameNotFoundException: osgi:service/javax.sql.DataSource/"(osgi.jndi.service.name=jdbc/opennaas-resources)"

The problem was that resource repositories required a service published in org.opennaas.core.resources bundle, but that dependency was not specified in blueprint configuration files. As a result, repositories for resources were considered active although a service they depended on was not. During execution, if the required service was not active, the mentioned "Gave up waiting for service" error appeared.

This patch adds a depencendy for required service in resource repositories bundles (network, router, bod, roadm), using the blueprint configuration files.

Two consecutive executions of all tests have been launched, without noticing the mentioned error.
add eliRigol to add_remotes.sh
Merge pull request #122 from isartcanyameres/fix/gave-up-waiting-for-service-error

Fix/gave up waiting for service error
Merge pull request #123 from isartcanyameres/feature/add-eliRigol-to-remotes

Feature/add eli rigol to remotes
Removed sendMessage() method from ICapability.

AbstractCapability was using this method, so it has been refactored too:
- Created IQueueingCapability with required operations to create actions and queue them.
- Made AbstractCapability implement IQueueingCapability.
- Update AbstractCapability methods to use IQueuingcapability ones instead of sendMessage
With above changes, sendMessage is not required any more in ICapability and can be removed.
The problem is sendMessage is used also as each operational capability interface.

Instead of changing each capability implementation, we added a temporary hack:
- Capabilities using sendMessage as operational interface now have this method declared in their specific operational interfaces.
This hack should be removed when desired interfaces are defined.

Karaf commands have been updated to cast required capability to its operational interface,
thus, gaining access to desired methods (sendMessage included).

This patch also:

- Removes abstract methods for managing lifecycle in AbstractCapability.
Capabilities using them now override the corresponding ICapabilityLifecycle methods.

- Removes setState method from ICapabilityLifecycle interface.
Script and descriptors used at FP7 Review.
Merge branch 'develop' of github.com:dana-i2cat/opennaas into feature/capabilities-interface