RESTful Microservices In Java With Jersey Jakub Podlešák Software Engineer Oracle, Application...

RESTful MicroservicesIn Java With Jersey

Jakub PodlešákSoftware EngineerOracle, Application Server GroupSeptember 29, 2014

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

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

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


Goal of The Presentation

To show how Jersey as JAX-RS 2.0 implementation 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


Microservices Primer

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

http://www.slideshare.net/InfoQ/micro-services-java-the-unix-way









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

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


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


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

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


Application 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


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

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


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


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

• Jersey 2 – provides production ready JAX-RS 2.0 reference implementation– brings several non-standard features


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 additional features that could help with other aspects– Lightweight container support (switch back to Java EE if needed)– Testing–Monitoring (Auto-scale)– Security– Redeploy–…


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


Grizzly HTTP server support

URI AppURI = URI.create("http://localhost:8080/user-management");

HttpServer httpServer = GrizzlyHttpServerFactory.createHttpServer( AppURI, new JaxRsApplication());


Grizzly HTTP server support – thread pool configHttpServer httpServer =

GrizzlyHttpServerFactory.createHttpServer(AppURI, new JaxRsApplication(), false);

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

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

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

httpServer.start();


Other supported containers• Simple HTTP Server• Jetty HTTP Container (Jetty Server Handler)• Java SE HTTP Server (HttpHandler)• Other containers could be plugged in via

org.glassfish.jersey.server.spi.ContainerProvider SPI


Jersey Test Framework• Based on JUnit• Support for TestNG available• Multiple container support– Grizzly– In memory– Java SE Http Server– Jetty– External container support


External Test Container• You can test any (already running) REST application• 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


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

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


Summary• When writing microservices in Java, JAX-RS is a natural choice to implement

REST interface• Jersey brings several non-standard options 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


Several Related sessions

Client Orchestration and Reactive Programming in JAX-RS Applications [CON3408]

Tuesday, Sep 30, 12:30 PM, Parc 55 – Mission

Real-World RESTful Service Development Problems and Solutions [BOF2105]

Monday, Sep 29, 7:00 PM, Moscone South 303

Securing JAX-RS Services With OAuth 2 [CON3774]

Tuesday, Sep 30, 12:30 PM, Hilton Golden Gate 6/7/8


BACKUP• JAX-RS/CDI demo on Grizzly HTTP server

RESTful Microservices In Java With Jersey Jakub Podlešák Software Engineer Oracle, Application...

Documents

Transcript of RESTful Microservices In Java With Jersey Jakub Podlešák Software Engineer Oracle, Application...