Hi Aliki
Furthermore, is there any documentation giving an overview of
jclouds entities and capabilities and/or an overview of abstraction
libraries for clouds for better understanding, as I couldn't manage
to find such myself?
Some of the links at the end will go into various topics in more
detail, but as an introduction let me try to explain a couple of key
concepts in jclouds:
* views or "portable abstractions"
* APIs
* providers
* contexts
Views
-----
Views are portable abstractions that are designed to allow you to
write code that uses cloud services without tying yourself to a
specific vendor. I often think of it like JDBC: rather than writing
code directly for a specific type of database, you write "generic"
database code, and the JDBC spec and drivers translate your generic
calls into ones that can be understood by a specific type of DB.
Obviously, views only make sense when there is a reasonably broad set
of functionality that is supported by multiple different vendors. In
the cloud space, jclouds currently supports three such views:
blobstore, compute, and loadbalancer (the latter is the one you found).
APIs
----
An API in jclouds describes the actual (often HTTP, but it depends on
the API) calls that can be made against a specific cloud to "do
stuff". In the case of popular APIs, such as the EC2 compute API, or
the S3 storage API, there may be one or multiple vendors running
clouds that support that particular API, e.g. EC2 is supported by
Amazon and OpenStack, amongst others.
There may also be multiple geographic locations of the same vendor
that support an API. For example, Rackspace's Cloud Servers API is
available both in the US and the UK.
Providers
---------
A provider in jclouds represents an instance of a vendor cloud that
supports one or more APIs. For example, Amazon offers EC2 through the
aws-ec2 provider, and Rackspace's Cloud Servers instance in the UK is
available via the rackspace-cloudservers-uk provider. Often, the
provider in jclouds is simply the API plus some instance-specific
instantiation values, such as the endpoint URL. In some cases, though,
the vendor decides to offer specific functionality that goes *beyond*
the API. For example, AWS EC2 gives you some options that other
providers that support the "standard" EC2 API do not.
Before talking about contexts, let's briefly discuss how these three
concepts work together inside jclouds, and which options you have as a
result:
1) APIs describe available calls for a specific "type of" cloud
By looking at the API defintion in jclouds, you can see the actual
calls that are available if you talk directly to this API.
2) APIs support views
Depending on the functionality provided by a particular API, it can be
used to implement a particular jclouds view. For instance, EC2
provides the right functionality to support the ComputeService view,
but is not useful for the BlobStore or LoadBalancer views. With some
clouds, one API can support multiple views.
2) Providers implement APIs, and describe available calls for a
specific vendor or cloud instance
Each provider in jclouds implements one or more APIs, which is why the
provider classes often extend the API classes. As discussed above,
some providers support calls in addition to those offered by the API,
which may or may not be optional (e.g. each Rackspace installation may
offer a different set of extensions).
By implementing APIs, providers obviously also support views, e.g. AWS
EC2 supports the ComputeService view because it implements the EC2 API.
What this means for you:
1) You can write highly portable code
If you stick with coding against views, you will be able to run the
same code against a large variety of different clouds, each with
potentially a different API. For example, if you're using
ComputeService, you could switch from AWS EC2 to vCloud without
changing your code.
It's like writing database code using the JDBC spec only: you should
be able to move from Postgres to MySQL without code changes.
2) You can use API-specific calls where needed
If the particular view(s) you talking to doesn't/don't allow you to do
exactly what you want, but the API you're talking to supports the
functionality you need, you can "unwrap" the view to access the
underlying API. This reduces the portability of your code, but you can
still move between providers that support that API.
For example, if you unwrap the EC2 API from a ComputeService view and
talk directly to that, you can't move to vCloud anymore. You can
change to a different provider that also supports the EC2 API, however.
3) You can use provider-specific calls if you really have to
If you really need to access a call offered only by a certain
*provider* (i.e. not even supported by the API, such as some of the
features of AWS EC2), you can unwrap the view to even access the
provider itself.
Obviously, this means your code is now tied to that specific provider,
but that may be perfectly acceptable.
So, finally...
Contexts
--------
A context represents a specific connection to a particular provider.
In that sense, it's not too different from a database connection you
make against a specific DB running in your environment. Once you have
a context (using a ContextBuilder) and are thus connected to a
particular cloud, you can either get hold of any portable view that's
supported by the provider you're talking to, or go straight to the API
or even provider level.
As mentioned above, you can also get a view back from the
ContextBuilder and *later* unwrap it to get at the underlying API or
provider.
As regards your load balancers: yes, if both Amazon ELB and
Rackspace's load balancer API support the LoadBalancerService view,
you should be able to write your code against that view and switch
between the two without changes.
Hope this helps!
ap
[1] http://jclouds.apache.org/documentation/jcloudsguides/
[2] http://jclouds.apache.org/documentation/userguide/
[3] https://github.com/jclouds/jclouds-examples
[4] http://markmail.org/thread/cpgnbgaj2l2zmfni
[5] http://markmail.org/thread/bakadhtc4cjgfmpk
