But I always wanted to know what is the difference between a View and Api? Can I have different View other that ComputerServiceContext for a compute provider?
BK is correct in pointing out the difference between the general ComputeService and the provider- or API-specific *Api classes: if you stick to ComputeService where you can, your code will remain portable. Use the API classes to access provider or API-specific features.
As regards Views and Apis: Apis are the actual, API- or vendor-specific clients that talk directly to vendor-specific APIs to "make things happen". If jclouds only offered Apis, it would be useful, but you won't be able to write any portable code.
That's why jclouds also provides a number of abstraction layers *on top of* Apis: ComputeService and BlobStore being the two most commonly used ones, although there are others.
When you use a ComputeService or BlobStore in jclouds, of course the actual calls eventually have to be made via the specific API of the target provider you happen to be talking to. jclouds takes care of the plumbing necessary to match the ComputeService or BlobStore methods to the underlying APIs.
In that sense, ComputeService and BlobStore provide an "abstract view" of an underlying "real" API or provider. The fundamental principle of a View is that you can "reach in" to the view and get that actual API "out". That's why ComputerService and BlobStore both extend View.
I hope that helps to explain why the question of "whether you can have a View other than ComputeServiceContext for a compute provider" doesn't make sense as stated: by definition, the whole purpose of ComputeService (a ComputeServiceContext is just a "factory" for making these) is to talk to a compute provider via that provider's API class or classes.
But a provider's API class or classes can indeed implement *multiple* abstractions, so you could "reach in" to a BlobStore and a ComputeService and get *the same API* back.
Hope that helps! ap
