Cloud Foundy Java Client V 2.0 #cf_tokyo

‹#›© 2016 Pivotal Software, Inc. All rights reserved. ‹#›© 2016 Pivotal Software, Inc. All rights reserved.
Cloud Foundry Java Client 2.0
Toshiaki Maki (@making)
Cloud Foundry Tokyo Meetup #1
2016-03-31

© 2016 Pivotal Software, Inc. All rights reserved.
Who am I ?
• Toshiaki Maki (@making)
• Sr. Solutions Architect
• Spring Framework enthusiast
Spring
Framework
徹底入門
(Coming Soon)
Perfect
Java EE
(Coming Soon)

Agenda
•How CF Java Client V1 was 😟
•How CF Java Client V2 looks 😎

Cloud Foundry Java Client V1
CloudCredentials credentials =
new CloudCredentials("username", "password"); 
CloudFoundryClient client =
new CloudFoundryClient(credentials,
URI.create("https://api.run.pivotal.io").toURL()); 
client.login();
// cf apps
List<CloudApplication> apps =
client.getApplications();
// cf app hello
CloudApplication app = client.getApplication("hello");

// cf push hello -p foo.jar -m 512m -i 2
client.createApplication("hello", new Staging(), 512,
singletonList("hello.cfapps.io"), emptyList()); 
client.uploadApplication("hello", new File("foo.jar")); 
client.updateApplicationInstances("hello", 2); 
client.startApplication("hello");
// cf logs
client.streamLogs("hello", new ApplicationLogListener() { 
public void onMessage(ApplicationLog log) {
System.out.println(log.getMessage()); 
} 
public void onComplete() {} 
public void onError(Throwable exception) {} 
});

Problems in V1
•Monolithic implementation
•No separation between API and Command
•Dependency on Spring Framework (RestTemplate)
•Blocking, Inefficient use of CC API
CF Java Client 2.0 design

Too many overloading…😫

130+ methods…😫

I don’t need MVC…😫

// cf apps
client.getApplications();
// cf app hello
client.getApplication("hello");
// cf push
client.createApplication(...); 
client.uploadApplication(...); 
client.updateApplicationInstances(...); 
client.startApplication(...);
Blocking 😫
Blocking 😫
Blocking 😫

https://lists.cloudfoundry.org/archives/list/cf-dev@lists.cloudfoundry.org/thread/W4455NML53LLSUSP25J2OXIYP2FNWUI4/

Project Structure in V2
cloudfoundry-client
cloudfoundry-operations
cloudfoundry-client-spring
Implements
Uses
CLI (cf ...)
REST API (CC API)
low level
high level

Class Diagram
CloudFoundryOperations
DefaultCloudFoundryOperations
CloudFoundryClient
SpringCloudFoundryClient
Uses
LoggingClient
SpringLoggingClient
Uses
Uses

In Future?
CloudFoundryClient
SpringCloudFoundryClient
RetrofitCloudFoundryClient
AndroidCloudFoundryClient
for non-Spring user
for Android user

SpringCloudFoundryClient cloudfoundryClient =
SpringCloudFoundryClient.builder() 
.host("api.run.pivotal.io")
.username("user")
.password("password") 
.build();
LoggingClient loggingClient = SpringLoggingClient.builder()
.cloudFoundryClient(cloudFoundryClient) 
.build();
CloudFoundryOperations operations =
new CloudFoundryOperationsBuilder() 
.cloudFoundryClient(cloudFoundryClient) 
.target("org", "space") 
.loggingClient(loggingClient) 
.build();
Builder Pattern

// cf apps
operations.applications().list();
// cf app hello
operations.applications()
.get(GetApplicationRequest.builder() 
.name("hello").build());
operations.applications() 
.push(PushApplicationRequest.builder() 
.name("hello").path("foo.jar") 
.memory(512).instances(2).build());
// cf logs hello
operations.applications().logs(LogsRequest.builder()

Problems in V1
•Monolithic implementation
•No separation between API and Command
•Dependency on Spring Framework (RestTemplate)
•Blocking, Inefficient use of CC API
CF Java Client 2.0 design
😄
😄
😄
What about this?

Non-Blocking!! Non-Blocking!!
•Go reactive! 😎
•Move imperative logic to async, event-driven,
functional-style code

Why Reactive?
http://www.slideshare.net/SpringCentral/reactive-web-applications-53170985
http://www.slideshare.net/SpringCentral/introduction-to-reactive-programming

Why Reactive?
https://spring.io/blog/2016/03/11/reactor-core-2-5-becomes-a-unified-
reactive-foundation-on-java-8#comment-2564120598

V2 supports Reactive Streams!!
•Non-Blocking APIs
// cf apps
Publisher<ApplicationSummary> apps
= operations.applications().list();

Reactive Streams
•Standard interfaces for asynchronous stream
processing with non-blocking back pressure
•De facto standard for interop between reactive
libraries
•Implemented by
• Akka Streams
• Reactor
• RxJava
• etc…
http://www.reactive-streams.org/

‹#›© 2016 Pivotal Software, Inc. All rights reserved.
Reactive Streams has 4 interfaces
public interface Publisher<T> {
public void subscribe(Subscriber<? super T> s);
}
public interface Subscription {
public void request(long n);
public void cancel();
}
public interface Subscriber<T> {
public void onSubscribe(Subscription s);
public void onNext(T t);
public void onError(Throwable t);
public void onComplete();
}
public interface Processor<T, R> extends
Publisher<T>, Subscriber<R> {}

Subscription SubscriberPublisher Application

subscribe(Subscriber)

onSubscribe(Subscription)

request(1)

request(1)
onNext(●)

request(1)
onNext(●)
request(2)

request(1)
onNext(●)
request(2)
onNext(●)

request(1)
onNext(●)
request(2)
onNext(●)
onNext(●)

request(1)
onNext(●)
request(2)
onNext(●)
onNext(●)
request(4)

request(1)
onNext(●)
request(2)
onNext(●)
onNext(●)
request(4)
onNext(●)

request(1)
onNext(●)
request(2)
onNext(●)
onNext(●)
request(4)
onNext(●)
onNext(●)

request(1)
onNext(●)
request(2)
onNext(●)
onNext(●)
request(4)
onNext(●)
onNext(●)
onComplete()

Reactive Streams with CF Java Client
// cf apps
Publisher<ApplicationSummary> apps = operations.applications()
.list();

// cf apps
.list(); 
services.subscribe(new Subscriber<ServiceInstance>() { 
Subscription s; 
public void onSubscribe(Subscription subscription) { 
this.s = subscription; 
subscription.request(1); 
} 
public void onNext(ServiceInstance i) { 
System.out.println(i.getName() + " : " + i.getService()); 
this.s.request(1); // one by one 
} 
public void onError(Throwable throwable) {} 
});

// cf apps
.list(); 
services.subscribe(new Subscriber<ServiceInstance>() { 
Subscription s; 
public void onSubscribe(Subscription subscription) { 
this.s = subscription; 
subscription.request(1); 
} 
public void onNext(ServiceInstance i) { 
System.out.println(i.getName() + " : " + i.getService()); 
this.s.request(1); // one by one 
} 
public void onError(Throwable throwable) {} 
});
😟
No higher level abstractions
like composition

Reactive eXtensions
• A pattern for composing potentially asynchronous and
event-based programs by using sequences or elements.
• On the JVM
• RxJava is the most used implementation
• Reactor Core is the main alternative
• Also for other languages, for example RxJava
• Some composition libraries doesn't follow closely RxPattern
(Akka) https://speakerdeck.com/sdeleuze/a-lite-rx-api-for-the-jvm?slide=9
http://reactivex.io/

Reactor
• Yet Another Rx library on the JVM
• Natively built on top of Reactive Streams
• Developed by Pivotal
• Reactor Core provides lite Rx API
• Flux / Mono
• CF Java Client V2 embraces Reactor Core
https://projectreactor.io/

Flux / Mono
• Both implement Publisher with Rx API
• Flux for 0..N elements
• Mono for 0..1 element

Flux
Flux<Integer> stream1 = Flux.just(1, 2, 3)
.map(x -> x * 2)
.filter(x -> x > 2); // 4, 6
Flux<String> stream2 = Flux.just("a", "b", "c");
Flux.zip(stream1, stream2) 
.consume(t -> System.out.println(t.t1 + ":" + t.t2));
Flux.merge(stream1, stream2) 
.consume(x -> System.out.println(x));

Flux
Flux<Integer> stream1 = Flux.just(1, 2, 3)
.map(x -> x * 2)
.filter(x -> x > 2); // 4, 6
Flux<String> stream2 = Flux.just("a", "b", "c");
Flux.zip(stream1, stream2) 
.consume(t -> System.out.println(t.t1 + ":" + t.t2));
Flux.merge(stream1, stream2) 
.consume(x -> System.out.println(x));
4:a
6:b
4
6
a
b
c

Mono
Mono<Boolean> result = Mono.just(true); 
result.consume(x -> System.out.println("result=" + x)); 
Mono<String> delayed = Mono
.delay(Duration.ofSeconds(1)) 
.after(() -> Mono.just("Hi")); 
delayed.consume(x -> System.out.println("result=" + x)); 
 
Mono<Void> noValue = Mono.empty(); 
noValue
.doOnSuccess(x -> System.out.println("finished!")) 
.subscribe();

Type comparison
No value Single value Multiple values
Sync
(JDK)
void T
Future<T>
Iterable<T>
Collection<T>
java.util.stream.Stream<T>
Async
(JDK)
CompletableFuture<Void> CompletableFuture<T> CompletableFuture<List<T>>
Reactive
Streams
Publisher<Void> Publisher<T> Publisher<T>
RxJava Observable<Void>
Completable
Single<T> Observable<T>
Reactor Mono<Void> Mono<T> Flux<T>

Reactor with CF Java Client
// cf apps
Flux<ApplicationSummary> apps = operations
.applications().list();
apps.map(app -> app.getName())
.consume(x -> System.out.println("name=" + x));
// cf app
Mono<ApplicationDetail> app = operations
.applications().get(GetApplicationRequest.builder() 
app.map(app -> app.getName())
.consume(x -> System.out.println("name=" + x));

Reactor with CF Java Client
Mono<Void> pushed = operations.applications()
.push(PushApplicationRequest.builder() 
.name("hello").path("foo.jar") 
.memory(512).instances(2).build());
pushed.doOnSuccess(x -> System.out.println("pushed!!"))
.subscribe();
// cf logs hello
Flux<LogMessage> logs = operations.applications()
.logs(LogsRequest.builder()

logs
.filter(log -> "RTR".equals(log.getSourceName()))
.map(LogMessage::getMessage)
.filter(msg -> msg.contains(" 500 ")) // 500 error
.userTimer(Timer.create())
.buffer(Duration.ofSeconds(10))
.map(List::size)
.filer(x -> x.size() > 5) // 5 errors in 10 sec
.consume(x -> {
System.out.println(x +" errors in 10 seconds!");
// some alerts
});
Simple log monitor

Prefer former simple one?
😟

Going Non-Blocking is difficult
Blocking API Non-Blocking API
😎
😭
difficult
easy

to Blocking is Easy
Mono<ApplicationDetail> app = ...;
ApplicationDetail detail = app.get();
Flux<ApplicationSummary> apps = ...;
Iterable<ApplicationSummary> summaries =
apps.toIterable();

Enjoy Reactive Programming with
CF Java Client V2
😘

Further Reading
• CF Java Client 
https://github.com/cloudfoundry/cf-java-client
• CF Java Client 2.0 design 
https://docs.google.com/document/d/1Ui-67dBPYoADltErL80xXYEr_INPqdNJG9Va4gPBM-I/
edit?pref=2&pli=1#heading=h.7gypq7vjwrk2
• A lite Rx API for the JVM 
https://speakerdeck.com/sdeleuze/a-lite-rx-api-for-the-jvm
• Reactor Core 2.5 becomes a unified Reactive Foundation
on Java 8 
https://spring.io/blog/2016/03/11/reactor-core-2-5-becomes-a-unified-reactive-foundation-on-java-8

Cloud Foundy Java Client V 2.0 #cf_tokyo

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (18)

Similar to Cloud Foundy Java Client V 2.0 #cf_tokyo

Similar to Cloud Foundy Java Client V 2.0 #cf_tokyo (20)

Recently uploaded

Recently uploaded (20)

Cloud Foundy Java Client V 2.0 #cf_tokyo