It always depends on your needs. jclouds provides a portable abstraction layer that allows you to talk to different clouds with the same code. It provides portable Compute, Blobstore and Load Balancing models and APIs you can use.
Each cloud, however, has its own semantics and specific features, and although jclouds does a good job in putting them together behind the portable abstractions, some provider specific things have to be done with the provider specific APIs. IT wouldn't make sense to promote every specific feature of every provider to the portable layer. That said, jclouds gives you the freedom to use the portable abstractions or the provider specific APIs. Is up to you. But even when you use the provider specific APIs to do concrete things, jclouds provides menu benefits: * You still have a consistent pattern to use APIs. All apis are constructed the same way and used in a similar fashion. You don't need to learn how a new library works if you want to use the specific API of several providers. * You keep your dependencies clean, as provider specific APIs don't bring new players. * You also benefit from the jclouds built-in HTTP features: smart retry policies, consistent error handling (guess how different APIs can populate similar errors? jclouds does a good job standardizing these behaviors), transparent pagination (you don't have to worry about getting the N page or even if the list is paginated, jclouds does it for you transparently), and more. * It deals with authentication, sessions, expired tokens, etc. In the end it is up to your use case. If you only need to talk with one cloud provider and there exist a library for it, perhaps it is better to just use that library, but jclouds is more than an "api aggregator" and does a great job also when using the provider specific APIs. HTH! I. On 24 September 2014 17:00, Steve Kingsland <[email protected]> wrote: > I'm trying to get code working which sets an ACL on an object when I upload > it to the BlobStore. I'm using the Jclouds S3 provider, and the closest > documentation I can find is from the "Using S3" example code at > http://jclouds.apache.org/guides/aws/: > > // when you need access to s3-specific features, > // use the provider-specific context > AWSS3Client s3Client = > AWSS3Client.class.cast(context.getProviderSpecificContext().getApi()); > > // make the object world readable > String publicReadWriteObjectKey = "public-read-write-acl"; > S3Object object = s3Client.newS3Object(); > > object.getMetadata().setKey(publicReadWriteObjectKey); > object.setPayload("hello world"); > s3Client.putObject(bucket, object, withAcl(CannedAccessPolicy.PUBLIC_READ)); > > context.close(); > > Problem is, the getProviderSpecificContext() method was apparently removed > in Jclouds 1.6. I think I can work around this using > contextBuilder.buildApi(S3Client.class) and the S3Object class to set the > ACL. > > But then if I have to use an S3-specific API to set an ACL, why not just use > the com.amazonaws.services.s3.AmazonS3Client client directly? How is Jclouds > actually benefitting me, if I'm using it to code directly to the S3 > provider? > > > Steve Kingsland > > > Senior Software Engineer > > Opower > > > We’re hiring! See jobs here
