• Created by Unknown User (pau_minoves), last modified by Unknown User (isart_canyameres) on 01 Aug, 2012

End-User

End-users don't run their own instance of OpenNaaS. Instead, they consume OpenNaaS enabled services either directly from the web service or via additional middle-ware (i.e. cloud managers). In any case, we try to maintain pointers to known clients and connectors so interfacing with OpenNaaS is effort-less as possible. Take into account that for third party front-ends, documentation and support should be provided by the service provider.

If, instead, the end-user wants or needs to make direct calls to the OpenNaaS remote API, glance over System Architecture to get a grasp of the basic concepts around resources and capabilities. An example work-flow for an end-user consuming directly the OpenNaaS services would be:

  1. The user obtains OpenNaaS credentials via a Service Provider.
  2. The Service Provider will grant some infrastructure rights on the user. How this is achieved depends largely on the concrete use case. Most of the time, OpenNaaS will be embedded on a higher level workflow.
  3. Along with the credentials, an OpenNaaS REST API end-point for the appropriate OpenNaaS instance is provided.
  4. The user can use the OpenNaaS REST API end-point to bootstrap one of the existing clients or write his own.
  5. Once connected, the user can exercise his infrastructure rights against the OpenNaaS REST API. This might include instantiating or freeing infrastructure resources, as well as configuring those resources via their capabilities.

You'll need some kind of authentication in order to use the remote API. Which protocol is in place will depend on the OpenNaaS instance administrator setup. You can get and overall view of supported security protocols here. You can then explore the remote API.

Most interesting topics for end-users:

Service Provider

The service provider builds value services by, for example, aggregating third-party infrastructure resources and/or providing an improved infrastructure orchestration. Although this is traditionally a role performed by the infrastructure provider itself, the clear separation between infrastructure ownership and configuration rights enabled by OpenNaaS, allows for a clear separation of this role.

As a service provider you can consume the services from Infrastructure Providers and/or other Service Providers. In that case, see the End-User section above for pointers on how to interface with OpenNaaS. You can also host your own OpenNaaS instance in order to power your infrastructure services.

You are now ready to extending OpenNaaS and develop your NaaS enabled applications.

The typical work-flow for a Service Provider looks like:

  1. Deploy an OpenNaaS instance on a stable server or VM.
  2. Configure the instance with your choice of database and security schema.
  3. Acquire infrastructure or rights over third-party infrastructure owners or other service providers.
    1. Configure this infrastructure on your OpenNaaS instance.
  4. Create new services by either extending OpenNaaS or embedding it in higher level work-flow.
  5. Publish your services and gather your users (wink).

Most interesting topics for service providers:

Infrastructure Provider

Infrastructure owners can use OpenNaaS to expose all or part of their network resources and have tight control on how those are lent and exploited. This schema is for owners who prefer to rent raw infrastructure instead of creating value services themselves. For a mix role check Service Provider above.

The infrastructure provider should check the compatibility matrix for supported devices or additional needed drivers.

After getting an overview of OpenNaaS architecture and concepts, the provider needs to setup his own OpenNaaS instance. There are several security setups available that differ on the operator's policy and existing security infrastructure.

Infrastructure provider's work-flow is:

  1. Deploy an OpenNaaS instance on a stable server or VM.
  2. Configure the instance with your choice of database and security schema.
  3. Register the infrastructure that you want to expose into OpenNaaS.
  4. Lend to service providers.

Most interesting topics for infrastructure providers:

  • No labels