RESTful(Microservices( - Java · Copyright©(2014 ,(Oracle(and/or(its(aﬃliates.(All(rights(reserved.(((Safe(Harbor(Statement The(following(is(intended(to(outline(our(general(productdirecAon.(Itis

RESTful Microservices In Java With Jersey

Jakub Podlešák So9ware Engineer Oracle, ApplicaAon Server Group September 29, 2014

Copyright © 2014, Oracle and/or its affiliates. All rights reserved.


Safe Harbor Statement The following is intended to outline our general product direcAon. It is intended for informaAon purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or funcAonality, and should not be relied upon in making purchasing decisions. The development, release, and Aming of any features or funcAonality described for Oracle’s products remains at the sole discreAon of Oracle.

4


Goal of The PresentaAon

5

To show how Jersey as JAX-‐RS 2.0 implementaAon could be used outside of a Java EE container in a light-‐weight fashion to implement RESTful micro-‐services in Java


Program Agenda

Microservices Primer

JAX-‐RS/Jersey Primer

Jersey features to support Microservices development

1

2

3

6


Microservices Primer

See this: hYp://www.slideshare.net/InfoQ/micro-‐services-‐java-‐the-‐unix-‐way

7


Microservices primer • Do not try to solve complex problems at once – I.e. avoid building a single monolithic applicaAon

• Break the big thing into several small parts •  You will end up with a number of small loosely coupled applicaAons – That can work together

8


Why to break it down? •  It is easier to design a small applicaAon that only does one thing •  TesAng is easier • … as well as deployment and maintenance •  Individual parts could evolve at different pace

9


Desired properAes of you microservices •  Small enough that it could fit into your head – Every applicaAon does only one thing (and does it well)

• Could be easily thrown away and re-‐wriYen • Clear boundaries – Remotely accessible uniform interface

10


ApplicaAon interface • Be of the web not on the web! • HTTP and universal media types can be consumed by different clients •  Looks familiar? You are right, this is REST

11


Deployment •  Select whatever container fits you best •  Standalone “container-‐less” deployment o9en recommended – Single jar file/OS service vs. a WAR in an applicaAon server

• Container selecAon does not maYer to applicaAon consumers – You have this uniform interface and clear boundaries, don’t you? – But you might also have some throughput requirements – Auto-‐scaling

12


Microservices summary • Many small apps •  Every app does only one thing (and does it well) • REST interface • Decoupled from each other and it’s clients • Deployable/Testable/Scalable individually

13


JAX-‐RS/Jersey primer •  JAX-‐RS 2.0 – part of Java EE 7 (2013) – defines a standard API for •  ImplemenAng RESTful web services in Java •  REST client API

•  Jersey 2 – provides producAon ready JAX-‐RS 2.0 reference implementaAon – brings several non-‐standard features

14


Why JAX-‐RS/Jersey? • REST is the natural way how to design Microservice interface •  JAX-‐RS provides widely adopted Java API for REST •  Jersey brings addiAonal features that could help with other aspects – Lightweight container support (switch back to Java EE if needed) – TesAng – Monitoring (Auto-‐scale) – Security – Redeploy – …

15


Selected Jersey features • Grizzly HTTP server support •  Test framework • ApplicaAon monitoring

16


Grizzly HTTP server support URI AppURI = URI.create("hYp://localhost:8080/user-‐management"); HYpServer hYpServer = GrizzlyH6pServerFactory.createH6pServer( AppURI, new JaxRsApplicaAon());

17


Grizzly HTTP server support – thread pool config HYpServer hYpServer = GrizzlyHYpServerFactory.createHYpServer(AppURI, new JaxRsApplicaAon(), false);

NetworkListener grizzlyListener = h6pServer.getListener("grizzly");

grizzlyListener.getTransport().setSelectorRunnersCount(4); grizzlyListener.getTransport().setWorkerThreadPoolConfig(

ThreadPoolConfig.defaultConfig().setCorePoolSize(16).setMaxPoolSize(16));

hYpServer.start();

18


Other supported containers •  Simple HTTP Server •  JeYy HTTP Container (JeYy Server Handler) •  Java SE HTTP Server (HYpHandler) • Other containers could be plugged in via org.glassfish.jersey.server.spi.ContainerProvider SPI

19


Jersey Test Framework • Based on JUnit •  Support for TestNG available • MulAple container support – Grizzly – In memory – Java SE HYp Server – JeYy – External container support

20


External Test Container •  You can test any (already running) REST applicaAon • No need to have Jersey on the other side • Use the following parameters: mvn test \

-‐Djersey.config.test.container.factory=org.glassfish.jersey.test.external.ExternalTestContainerFactory \

-‐Djersey.test.host=localhost -‐Djersey.config.test.container.port=8080

21


Monitoring support • Must be explicitly enabled – ServerProperAes.MONITORING_STATISTICS_ENABLED – ServerProperAes.MONITORING_STATISTICS_MBEANS_ENABLED – Register your own event listeners

• MonitoringStaAsAcs could be injected into any resource and reused: @Inject MonitoringStaAsAcs stats;

22


Summary • When wriAng microservices in Java, JAX-‐RS is a natural choice to implement REST interface •  Jersey brings several non-‐standard opAons that might be handy: – Lightweight container support (switch back to Java EE container if needed) – Test framework – Monitoring features (auto-‐scaling)

•  There is more to come in future Jersey versions

23


We Are Hiring! hYp://marek.potociar.net/2014/10/15/jersey-‐is-‐hiring-‐in-‐prague/ [email protected]

24


THANK YOU!

Documents

RESTful(Microservices( - Java · Copyright©(2014 ,(Oracle(and/or(its(aﬃliates.(All(rights(reserved.(((Safe(Harbor(Statement The(following(is(intended(to(outline(our(general(productdirecAon.(Itis