Thursday Feb 19, 2015

HTTP/2 is done

...well almost! There are still some minor processes to go through before they are published as official RFCs but the IESG has formally approved the HTTP/2 and HPACK specifications! So clearly, it’s safe to say that HTTP/2 is done! And given how vital the HTTP protocol is in today’s world, this is really important news.

The fact that HTTP/2 is binary based (Vs. HTTP 1.x being text based) removes lot of technical barriers that (text-based) HTTP 1.x had and allows the introduction of new capabilities. Those new capabilities (e.g. stream multiplexing over a single TCP connection, stream prioritization, server-push, etc.) are more than welcome as they will reduce the overall Web latency. HTTP/2 will also help to get rid of the various “hacks” (e.g. file concatenation, domain sharding) that were put in place to work-around the HTTP 1.x limitations (e.g. Head-of-Line blocking).

HTTP/2 maintains a high-level compatibility with HTTP 1.x and preserve a lot of its predecessors concepts (e.g. URI, headers, etc.). So from a Java EE developer point of view, the HTTP/2 impact will be relatively minimal and only a few HTTP/2 aspects will be exposed to the developer through the Servlet API (Server-Push & Stream Prioritization). This work is conducted right now in the Servlet 4 (JSR 369) Experts Group (see EG discussions here).

And even if you are not a Web-tier developer, it is important to understand HTTP/2 and what it brings. For that, you are strongly encouraged to watch the session that Ed Burns and Shing wai Chan (Servlet 4 Specification Leads) gave during last JavaOne on HTTP/2 and the Servlet 4 plans (slides here).

Tuesday Nov 18, 2014

JavaOne Replay: "Into the Wild with Servlet Async IO"

Greg Wilkins has an impressive 'Web pedigree’; he is the founder and lead developer of Jetty.  Greg is a long-time member of the Servlet Expert Group; he is also a member of the IETF HTTP/2 working group member, etc.!

During his JavaOne session, Greg gave a deep technical overview on Asynchronous IO using the Servlet API.  Greg starts by explaining what asynchronous means in the context of a Servlet. He then goes and explains the Servlet 3.0 asynchronicity support.  The rest of the talk is then spent on the Servlet 3.1 API and how to write effective asynchronous servlets (and how the inner-working of the API).  Greg also shares some of the motivations behind the Servlet 3.1 API and the technical choices behind it. Not only that, Greg is also talking about some 'potential more obvious technical options' and why those options were not selected at the end.

This technical session provides different angles (e.g. Servlet API explanations, some deep technical points such as some of the Jetty implementation details but also best practices advices, etc.).  Overall this session is highly recommended for anyone who want to understand asynchronicity in the context of the Servlet API.

You can find Greg's slides here.

Friday Jul 25, 2014

Using Server-Sent Events (SSE) with Nothing More Than Servlet

As many of you know, HTML 5 Server-Sent Events (SSE) stands between the two extremes of completely stateless REST/HTTP and fully bidirectional WebSocket. It is a relatively simple mechanism that allows for sending data from the server to the client once a connection is established via plain HTTP. An interesting side-effect of this basic simplicity is you could conceivably use SSE with nothing more than the plain Servlet API. The downside of taking this approach is that you don't have the much higher level, easier to use specialized APIs for SSE such as the ones long included in Jersey (and now being proposed as part of Java EE 8).

The GlassFish team's own Shing Wai Chan explores the idea of using SSE from plain Servlets in an excellent recent post. The post is a very good way of understanding how SSE actually works under the hood. Besides demonstrating the basics of SSE from an HTTP perspective, the post also shows the JavaScript SSE API available on the browser as well as using the Servlet 3 async API and Java EE 7 concurrency utilities with Servlet based SSE.

Thursday Jul 24, 2014

Servlet 4.0

The Servlet API is one of the most used API, if not the most used API of the Java EE Platform! It was revised for Java EE 7, Servlet 3.1 (JSR 340) added quite some new capabilities such as support for the HTTP 1.1 upgrade mechanism (required for supporting WebSocket for example), non-blocking asynchronous IO, various security related improvements and so on. Shing Wai Chan (Spec Lead of Servlet 3.1) has just posted a draft proposal for the Servlet 4.0 JSR.

Moving from 3.1 to 4.0 clearly means that this will be a major revision of the Servlet specification and it has a key theme, i.e. HTTP/2. It will be the first new version of the HTTP protocol since the current version (HTTP 1.1) which was standardized ... end of the last century (RFC 2616)! HTTP/2 will bring many improvements over HTTP/1.x. In his draft proposal, Shing Wai lists the HTPP/2 features that he expects to be exposed by the Servlet 4.0 API:

  • Request/Response multiplexing
  • Stream Prioritization
  • Server Push
  • Upgrade from HTTP 1.1 

HTTP 1.x is a fairly simple request/response protocol. Things will probably change with HTTP/2 multiplexing capabilities, so some of the paradigms we know since years will have to evolve too! And since it is not a small task to drive a major evolution of such an important API, Ed Burns will help Shing Wai and will co-lead this JSR with him.

HTTP/2 will be the key theme of Servlet 4.0 but the Expert Group will probably tackle additional capabilities.

In terms of timing, we expect Java EE 8 to support Servlet 4.0 but there is a constraint: HTTP/2 itself! At this stage, HTTP/2 is still in active development. It is however expected to be completed well in advance of the completion date of Java EE 8. In his proposal Shing Way explains why it is now relatively safe to consider adding HTTP/2 support to the Servlet API.

So make sure to check the Servlet 4.0 draft JSR proposal and give your feedback before the proposal is submitted to the JCP.

PS: you can now follow @Servlet_Spec on Twitter! 
PPS: feedback can be sent to the Servlet Spec User mailing list (registration is only required to post to the list, not to read it)

Wednesday May 28, 2014

Adding SSE support in Java EE 8

SSE (Server-Sent Event) is a standard mechanism used to push, over HTTP, server notifications to clients.  SSE is often compared to WebSocket as they are both supported in HTML 5 and they both provide the server a way to push information to their clients but they are different too! See here for some of the pros and cons of using one or the other.

For REST application, SSE can be quite complementary as it offers an effective solution for a one-way publish-subscribe model, i.e. a REST client can 'subscribe' and get SSE based notifications from a REST endpoint. As a matter of fact, Jersey (JAX-RS Reference Implementation) already support SSE since quite some time (see the Jersey documentation for more details).

There might also be some cases where one might want to use SSE directly from the Servlet API. Sending SSE notifications using the Servlet API is relatively straight forward. To give you an idea, check here for 2 SSE examples based on the Servlet 3.1 API. 

We are thinking about adding SSE support in Java EE 8 but the question is where as there are several options, in the platform, where SSE could potentially be supported:
  • the Servlet API
  • the WebSocket API
  • JAX-RS
  • or even having a dedicated SSE API, and thus a dedicated JSR too!
Santiago Pericas-Geertsen (JAX-RS Co-Spec Lead) conducted an initial investigation around that question. You can find the arguments for the different options and Santiago's findings here.

So at this stage JAX-RS seems to be a good choice to support SSE in Java EE. This will obviously be discussed in the respective JCP Expert Groups but what is your opinion on this question?

Monday Nov 11, 2013

HTTP Session Invalidation in Servlet/GlassFish

HTTP session invalidation is something most of us take for granted and don't think much about. However for security and performance sensitive applications it is helpful to have at least a basic understanding of how it works in Servlets.

In a brief code centric blog post Servlet specification lead Shing Wai Chan introduces the APIs for session invalidation and explains how you can fine tune the underlying reaper thread for session invalidation when it is needed in GlassFish 4. Don't hesitate to post a question here if the blog is not clear, this is a relatively esoteric topic...

Tuesday Jun 25, 2013

deny-uncovered-http-methods in Servlet 3.1

Servlet 3.1 is a relatively minor release included in Java EE 7. However, the Java EE foundational API still contains some very important changes. One such set of features are the security enhancements done in Servlet 3.1 such as the new deny-uncovered-http-methods option.

Servlet 3.1 co-spec lead Shing Wai Chan outlines the use case for the feature and shows you how to use it in a recent code example driven post. You can also check out the official specification yourself or try things out with the newly released Java EE 7 SDK.

Thursday May 30, 2013

Non-Blocking I/O in Servlet 3.1

Servlet 3.1 is a relatively minor release slated for Java EE 7. However, the Java EE foundational API still contains some very important changes, especially for folks building on the Servlet API. One such feature is the newly added support for non-blocking I/O to empower low-latency, high throughput applications, protocols and web frameworks.

Servlet 3.1 co-spec lead Shing Wai Chan shows you how in a recent code example driven post. Incidentally, Servlet 3.1 recently had it's final release. You can now check out the official specification yourself. You can also try the API out with a GlassFish promoted build.

Thursday May 09, 2013

HTTP Upgrades in Servlet 3.1

Servlet 3.1 is a relatively minor release slated for Java EE 7. However, the Java EE foundational API still contains some very important changes, especially for folks building on the Servlet API. The newly added support for HTTP protocol upgrades is a great example. The upgrade facility has been there since HTTP 1.1, but just hasn't been used that widely. It facilitates building richer protocols on top of HTTP. Under the hood, this is exactly the mechanism that HTML 5 WebSockets use (as you know, we now have excellent support for WebSockets in Java EE via JSR 356). You can most certainly use HTTP protocol upgrades in similarly powerful and innovative ways yourself.

Servlet 3.1 co-spec lead Shing Wai Chan shows you how in his recent code example driven post. Incidentally, Servlet 3.1 recently passed it's final approval ballot. You could check out the proposed final draft yourself.

Tuesday Jan 15, 2013

Servlet 3.1 in Public Review

Servlet 3.1 is now in public review. Although it is a relatively minor release for the mature Servlet API, this release has a number of important changes, particularly for enabling higher-level frameworks. The Public Review Draft for Servlet 3.1 will end on February 11th so now is the time to download the spec and send in any comments that you might have.

Servlet spec lead Shing Wai Chan is kind enough to summarize the changes and invites you to learn more. The page also contains a download link to the draft spec as well as a link to Shing Wai Chan's JavaOne presentation on Servlet 3.1.

Stay tuned for more JSRs making progress as the steady march towards the Java EE 7 release keeps rolling forward!

Tuesday Mar 01, 2011

More Java EE 7 content: Servlet, EL, JMS and JSF updates

Following-up on to yesterday's post on JSR 342 (Java EE 7), there are actually four other JSRs that have been filed :
JSR 340: Java Servlet 3.1 Specification
JSR 341: Expression Language 3.0
JSR 343: JavaTM Message Service 2.0
JSR 344: JavaServerTM Faces 2.2

JCP - Java Community Process

Servlet 3.1 should offer easier to build asynchronous applications (extending the work done for 3.0), support and utilize Java EE concurrency APIs, support WebSockets, offer multi-tenant isolation support and more. The co-spec leads are Shing Wai Chan and Rajiv Mordani.

Expression Language (EL) 3.0, which used to be defined as part of the JSP expert group, now has a dedicated JSR due to its relationship with other parts of the platform such as CDI and JSF. The goal there is to consider support for projection and collection, date types (with appropriate comparison operators) and maybe equality, string concatenation, and sizeof operators. Kin-man Chung is the specification lead.

JMS 2.0 should bring to this API some long awaited EoD (Ease of Development) love, clarification of the relationship between the JMS and other Java EE specifications and a new mandatory API for the integration of any JMS provider in Java EE application servers. Nigel Deakin is the spec lead for this one.

JavaServer Faces (JSF) 2.2 will continue to focus on ease of development, better portlet integration but also consider new features (HTML 5 and others), and of course work on fixes. The plan is to finish before the end of this calendar year (2011). Check out Ed Burns' recent post on this.

All JSRs are now up for voting and slatted for inclusion in Java EE 7, thus hopefully joining JPA 2.1 and JAX-RS 2.0 in the list of "work in progress" JSRs. Speaking of JAX-RS, Marek, the new co-spec lead has a quick update.

Sunday Apr 04, 2010

Leveraging Servlet 3.0 - Authentication without Forms using GlassFish v3 and Vaadin

The new Servlet 3.0 specification in JavaEE 6 (JSR website, JavaOne Session, VC podcast) packs many new features, including Annotations, Dynamic Registration, Pluggability and Asynchronous Support.

Servlet 3.0 also includes quite a number of security improvements, as described by Kumar a couple of months ago in a Summary of new Security Features in Servlet 3.0. As Ron explains, one of the themes is that Java EE 6 and Servlet 3.0 Converge on Container Security Functionality, another is extra functionality, as explained by Nithya's 3 recent posts ([1], [2], [3]) covering http-method-omission element in web.xml, and the authenticate and login methods of HttpServletRequest.


A great example of the new functionality is Bobby's Authentication Without the Form where he modifies the RIA app in Creating Secure Vaadin Applications using JavaEE 6 to use the new login machinery and thus remove the need for extraneous JSP files.

Bobby's very complete post includes full source code and a nice Screencast; note it requires a recent build of GlassFish 3.0.1 due to a bug in 3fcs.

You may also want to refer to the JavaEE 6 javadocs (e.g. HttpServletRequest) and to the JavaEE 6 Tutorial: Part I (e.g. see Web Application Security) and Part II (requires free registration).

I had not noticed Vaadin previously but it seems to be gaining some popularity; its programming model is strongly server-centric and generates client-code via GWT. You can see a Online Sampler and it recently deployed a Component Directory; its KB has a number of articles on how to use it with GlassFish Server. They also announced deals recently with BlackBelt Factory and with our old Liferay friends.

While chasing the sources for this spotlight I bumped into a number of other Java-based RIA frameworks including: Echo and ZK as well as frameworks like Flex/BlazeDS, GWT, and the JSF-based frameworks we know.

Wednesday Mar 24, 2010

Initial GlassFish v3 Performance


GlassFish v2 has excellence performance and GF v3 has a lot of new code, so it would not be surprising if there was some initial performance degradation, to be "fixed" in a later release. Turns out that this is not the case: Scott (Mr. Performance) reports that the performance of v3 is actually higher, and scales better, than v2. One of the benefits of cleaner code!

Check out Scott's Initial Report on GlassFish v3 Performance

Monday Jun 08, 2009

NetBeans 6.7 RC2 Now Available - And Writting Servlet 3.0 and EJB 3.1 Applications


The second release candidate for NetBeans 6.7 is now available - check RC2 Download Page and James' Writeup. The next RC should be the final.

Note that NB 6.7 still includes the old "GFv3 Prelude" release and you need to manually install GFv3 Preview (the J1 release). For example, check Arun's writeup for has a detailed explanation on how to use NB 6.7 to write Servlet 3.0 and EJB 3.1 Applications