Dear Wiki user, You have subscribed to a wiki page or wiki category on "Jclouds Wiki" for change notification.
The "Core Concepts" page has been changed by AndrewPhillips: https://wiki.apache.org/jclouds/Core%20Concepts New page: = jclouds Core Concepts = An attempt to explain a couple of key concepts in jclouds: * Views or "portable abstractions" * APIs * Providers * Contexts == Views == [[http://javadocs.jclouds.cloudbees.net/org/jclouds/View.html|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: * [[http://javadocs.jclouds.cloudbees.net/org/jclouds/blobstore/BlobStore.html|blobstore]] * [[http://javadocs.jclouds.cloudbees.net/org/jclouds/compute/ComputeService.html|compute]] * [[http://javadocs.jclouds.cloudbees.net/org/jclouds/loadbalancer/LoadBalancerService.html|loadbalancer]] == 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 [[http://javadocs.jclouds.cloudbees.net/org/jclouds/ec2/EC2Api.html|EC2 compute API]], or the [[http://javadocs.jclouds.cloudbees.net/org/jclouds/s3/S3Client.html|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 [[https://github.com/jclouds/jclouds/blob/master/providers/aws-ec2/pom.xml#L29|aws-ec2 provider]], and Rackspace's Cloud Servers instance in the UK is available via the [[https://github.com/jclouds/jclouds/blob/master/providers/rackspace-cloudservers-uk/pom.xml#L29|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 which are not available from other providers that support the "standard" EC2 API. Before talking about contexts, let's briefly discuss how views, APIs and providers work together inside jclouds, and which options users have as a result: ==== 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. ==== 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. ==== 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 users === ==== Users 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. ==== 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 [[http://javadocs.jclouds.cloudbees.net/org/jclouds/View.html#unwrap()|"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 any more. You can change to a different provider that also supports the EC2 API, however. ==== 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 (via [[http://javadocs.jclouds.cloudbees.net/org/jclouds/ContextBuilder.html|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.
