Servlet 4.0: New Features for Java Microservices

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
Servlet 4.0: A new twist
on an old favorite
Dr. Shing Wai Chan
Ed Burns
Java EE Specification leads
3

Safe Harbor Statement
The 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.
4
E

• Ed Burns
– Servlet and JSF co-spec lead
– Frequent international conference
speaker
– Author of four Enterprise Java related
books from McGraw-Hill, including JSF
2.0 the Complete Reference
• Dr. Shing Wai Chan
– Servlet co-spec lead since 2011
– Expert Group and implementation
team member on many JSRs relating to
Servlet since 2001
5
Speaker Credentials
SE

Our Plan for Your Time Investment
The Contemporary Role of Servlets
New Features in Servlet 4.0
Opening Up Java EE
Summary
1
2
3
4
6
E

Introduction
Micro, Mono, Oh no?
7
E

J2EE Servlets: A Very Early Java Microservices Platform
• Consensus definition of Microservices: system is a collection of services,
each of which is
– Small
– Loosely coupled (can be composed)
– Isolated from other services
– Highly internally cohesive (does one thing)
– Can be managed, deployed, developed independent of others
– Is responsible for handling its own data
8
E

each of which is
– Small
• There is nothing stopping you from keeping your servlets small
• But in practice it was very easy to allow them to get pretty big, chains of servlets and filters
9
E

each of which is
– Small: maybe
– Loosely coupled (can be composed)
• Filters can compose pretty well
• Filter chain concept is expressly designed to support composing
10
E

each of which is
– Small: maybe
– Loosely coupled (can be composed): yes
– Isolated from other services
• Generally this is not how people use Servlets. An outage in a Servlet would prevent the entire rest
of the call flow from continuing
11
E

each of which is
– Small: maybe
– Isolated from other services: no
– Highly internally cohesive (does one thing)
• Generally Servlets are used as controllers or filters that act on an HTTP request and either pass it on
to some other service, or send a response.
12
E

each of which is
– Small: maybe
– Highly internally cohesive (does one thing): yes
– Can be managed, deployed, developed independent of others
• Yes the WAR file format has always allowed this.
13
E

each of which is
– Small: maybe
– Can be managed, deployed, developed independent of others: yes
– Is responsible for handling its own data
• Servlets generally don’t have much in the way of data, this was always handled by other parts of the
Java EE monolith. But whatever data a Servlet does have, it is generally not shared with other parts
of the system
14
E

each of which is
– Small: maybe
– Can be managed, deployed, developed independent of others: yes
– Is responsible for handling its own data: yes
15

The Power of JCP
• Servlets have adapted and incorporated new features from industry trends
and best practices all along
– Packaging concept: WAR
– Asynchronous
– Non Blocking IO
• Reactive/back pressure: onDataAvailable(), onWritePossible()
– Resource Injection
– HTTP/2
16
Incorporating Industry Trends and Maintaining Compatibility
E

Servlets Within a Contemporary Microservices System
• Some possible reasons to use Servlet for green-field development in the
Microservices style
– Constrained to use a specific software stack for non-technical reasons
– Team is risk averse in trying new technologies, but adventurous in trying new
architectures
– Want to take an incremental approach to adopting Microservices for green-field
• New Architecture, Old Stack
• New Architecture, New Stack
17
Green Field? Servlets would be a stretch…
E

Servlets as a Stepping Stone to a more “pure” Microservices
System
• EAR with WARs  separate WARs
• Rest Services in front of WARs
• Rest Services absorb functionalities of WARs
18
This is the more common case
E

New Feature Review
Servlet 4.0
19
Lots under the hood,
some good stuff on top of it
S

• Yes, everything from Oracle about
Java EE is on GitHub now.
• Samples for all these features are at
https://github.com/javaee/glassfish-samples
20
Try the Samples on GitHub
S

HTTP/2
• You already know why it's important, but briefly, it improves perceived
browser performance, through the use of
– Binary framing
– Stream multiplexing
– Header compression (HPACK)
– Server push
– Keeping the connection open, more than just keep alive
21
S

HTTP/2 in Servlet 4.0
• Most of what's great about HTTP/2 comes for free in using Servlet 4.0
– Binary framing
– Stream multiplexing
– Header compression (HPACK)
– Server push
– Keeping the connection open, more than just keep alive Server push
– …
22
S

A Common Use Case
23
S

Server Push in HTTP/2
“Server push allows a server to speculatively send data to a
client that the server anticipates the client will need, trading
off some network usage against a potential latency gain.”
RFC 7540
24
S

Server Push in HTTP/2
• Promised Requests
– Cacheable
– Safe
• Essentially read-only
– Without a request body
RFC 7540 / RFC 7231
25
GET
HEAD
POSTOPTIONS
TRACE
cacheableSafe
S

Server Push in Servlet 4.0
javax.servlet.http.PushBuilder
26
S

Server Push in Servlet 4.0
Server Push via Builder API
27
S

DEMO
28

HTTP Trailer
“… the sender desires to send metadata in the form of trailer
fields at the end of the message, the sender SHOULD generate
a Trailer header field before the message body to indicate
which fields will be present in the trailers.”
RFC 7230 / RFC 7540
29
S

HTTP Trailer
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
Trailer: foo
6rn
Hello rn
5rn
Worldrn
0rn
foo: barrn
rn
Example in HTTP/1.1
30
S

HTTP Trailer
• Pseudo-header fields MUST NOT appear in trailers
– Request
• :method, :scheme, :authority, :path
– Response
• :status
RFC 7540
31
S

HTTP Trailer
• Message integrity check
• Digital signature
• gRPC
– Required Trailer and HTTP/2
Use Cases
32
S

HTTP Trailer
Servlet Trailer API
33
package java.util.function;
@FunctionalInterface
public interface Supplier<T> {
T get();
}
S

HTTP Trailer
HTTP Request Trailer
34
S

HTTP Trailer
public class TestServlet extends HttpServlet {
@Override
protected void doPost(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
res.addHeader("Transfer-encoding", "chunked");
res.addHeader("Trailer", "bar1, bar2");
. . .
res.setTrailerFields(() -> {
Map<String, String> map = new HashMap<>();
map.put("bar1", "A");
map.put("bar2", "B");
return map;
});
. . .
}
}
Http Response Trailer
35
S

HTTP Trailer
HTTP Response Composite TrailerFields Suppliers
36
S

Mapping Discovery
• Allows for discovering how the current Servlet was reached
– Does not include mappings for Filters
– Accounts for all the various ways for the container to invoke a Servlet
• Container applies mapping rules
• Application code invokes
– getRequestDispatcher().forward()
– getRequestDispatcher().include()
– AsyncContext.dispatch()
– getNamedDispatcher()
37
E

Mapping Discovery
• Allows for discovering how the current Servlet was reached
– Does not include mappings for Filters
– Accounts for all the various ways for the container to invoke a Servlet
• Container applies mapping rules
• Application code invokes
– getRequestDispatcher().forward()
– getRequestDispatcher().include()
– AsyncContext.dispatch()
– getNamedDispatcher()
38
}
New request attributes
• INCLUDE_MAPPING
• FORWARD_MAPPING
• ASYNC_MAPPING
E

Mapping Discovery
• HttpServletRequest.getServletMapping()
– Returns immutable HttpServletMapping
• MappingMatch enum
39
E

Mapping Discovery
• HttpServletRequest.getServletMapping()
– Returns immutable HttpServletMapping
• matchValue
• pattern
• servletName
40
E

Request Encoding
• URL paths read from the wire are
specified to be in UTF-8
– Vendor specific configuration is allowed
• Clarifications on form data
• ServletContext.
setRequestCharacterEncoding()
• New XML element, ie
<request-character-encoding>UTF-8
</request-character-encoding>
Response Encoding
• ServletContext.
setResponseCharacterEncoding()
• New XML element, ie
<response-character-encoding>UTF-8
</response-character-encoding>
41
Encoding Clarifications
E

Odds and Ends
• Add Java SE 8 default methods
– ServletContextAttributeListener, ServletContextListener,
ServletRequestAttributeListener, ServletRequestListener,
HttpSessionActivationListener, HttpSessionAttributeListener,
HttpSessionBindingListener, HttpSessionListener
– Filter#init, #destroy
• Add GenericFilter and HttpFilter
Servlet 4.0 Ease of Use
42
S

Odds and Ends
• <default-context-path> element in web.xml
• ServletContext
– void setSessionTimeout(int minutes)
– ServletRegistration.Dynamic addJspFile(String name, String
jspFile)
43
S

Opening Up JavaEE 8
Overview and Servlet Perspective
44
E

J2EE 1.3
CMP,
JCA
Robustness J2EE 1.4
JAX-RPC
Mgmt,
Deploy-
ment
Web
Services
Java EE 5
Annotations,
EJB 3.0,
JPA, JSF,
JAXB
JAX-WS
Ease of
Development
Java EE 6
JAX-RS,
CDI,
Servlet 3.0,
Web Profile,
Pruning
Lightweight
1999 2001 2003 2006 2009 2013
Java EE 7
JAX-RS 2.0,
JSON-P,
WebSocket,
JMS 2.0,
Batch
Productivity
& HTML5
J2EE 1.2
Servlet,
JSP, EJB,
JMS
Enterprise
Java
Java EE 8 – The Next Step
Java EE 8
Servlet 4.0,
JAX-RS 2.1,
JSON-B
JSON-P 1.1,
Security
Modernization,
Simplification
2017
E

Eclipse Enterprise for Java (EE4J)
Moving Java EE to Eclipse Foundation
46
Technology
 Agile
 Flexible
 Open
 Compatible
Community
and
Vendors
Sponsorship
Join the discussion at ee4j-community@eclipse.org
Enterprise for Java
E

Eclipse Enterprise for Java (EE4J)
Project Overview
• Open process
• Collaboration: community, vendors, Eclipse
• Transition to EE4J in CY2018
– GlassFish 5.0/Java EE 8 RIs, TCKs, product docs
– Process for existing and new specs
– Compatibility process
• Technology evolution, MicroProfile integration
• Oracle Java EE Support through Java EE 8
– Continuity for Java EE community
47
 Agile
 Flexible
 Open
 Compatible
Enterprise for Java
E

Project Overview – Additional Detail
48
• Relicense Oracle Java EE 8 and GlassFish 5.0 technologies to EE4J - RIs, TCKs, and
product docs
• Build a compatible EE4J implementation that passes existing Java EE 8 TCKs
• Use existing javax package names, and component specification names for existing
JSRs for continuity
• Define a process by which existing specifications can evolve, and new specifications
can be included in the platform
• Recruit developers, vendors and other community members as sponsors – Oracle no
longer the platform “Spec lead”
• Evolve the platform and potentially incorporate Eclipse MicroProfile technologies
• Begin the above ASAP after Java EE 8 delivery to facilitate a rapid transition
E

Open Process
See Aquarium Blog for Updates
49
Join the discussion at ee4j-community@eclipse.org
E

Oracle Will Continue to Support Vendors/Licensees
• Oracle will honor existing agreements with vendors of Java EE
implementations
• Oracle will continue to offer renewals to license agreements
• Oracle will continue to support vendor/licensee implementations and
certifications as it has done prior to this announcement
• Oracle intends to support Java EE 8 through Sept 2025
• We expect licensees will plan migration to EE4J prior to 2025
• EE4J licensing/compatibility will be defined by the EE4J project
50
E

For Oracle Customers
WebLogic Server “Next” Release – Version TBD
• WebLogic Server “Next” – CY2018
• Commercial Java EE 8 Support
• Compatible with prior versions
• Available on premises
– Installers, Docker images
• Available in Oracle Cloud
– Java Cloud Service, Application Container Cloud
WebLogic Server “Next”
Java EE 8 Reference
Implementation
Java Cloud Service
Application Container Cloud
CY2017
CY2018
CY2018
51
E

Challenges I Can See for Servlet in EE4J
• Servlet has always been revised in lock-step with the whole EE platform
– Hard to make that agile
– Extremely high backward compatibility expectations
• Important Servlet EG Members that are not full “Java EE” vendors
– Jetty
– Tomcat
• Very large numbers of implementations
52
The next chapter is still unwritten
E

Benefits - A New, Open Direction Forward
• Agile - more rapid evolution of the technology
• Flexible - modern open source process and licensing
• Open – transparent process, broader vendor and community participation
• Compatible - Transition from Java EE 8 to new offering
• Multiple vendors and established foundation supporting the initiative
53
E

Summary
• Moving Java EE to EE4J
– In collaboration with the community
– More agile, flexible and open process
– Compatible implementation
– Evolve the platform
• Oracle will continue to...
– Support licensees/vendors
– Support existing WebLogic Server releases
– Invest in new WebLogic Server releases, capabilities
54
 Agile
 Flexible
 Open
 Compatible
Enterprise for Java
E

Summary
55

Summary – Servlet 4.0
• brings HTTP/2 to the Java EE Platform
• has significant incremental improvements
• maintains the backward compatibility promise for which EE is (in)famous
• reference implementation is GlassFish 5.0
– Only run in Java SE 8, not Java SE 9
– 5.0.1 plans to run on Java SE 9
56
S

Safe Harbor Statement
The preceding 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.
57

Servlet 4.0: New Features for Java Microservices

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Servlet 4.0: New Features for Java Microservices

Similaire à Servlet 4.0: New Features for Java Microservices (20)

Plus de Ed Burns

Plus de Ed Burns (11)

Dernier

Dernier (20)

Servlet 4.0: New Features for Java Microservices