Over a million developers have joined DZone.

WildFly 8.0.0.Alpha3 Released with Support for EJB Invocations over HTTP

· Java Zone

Microservices! They are everywhere, or at least, the term is. When should you use a microservice architecture? What factors should be considered when making that decision? Do the benefits outweigh the costs? Why is everyone so excited about them, anyway?  Brought to you in partnership with IBM.

A week back we released WildFly 8.0.0.Alpha3 version. As usual the download is available on WildFly downloads page. This release comes within a month of the 8.0.0.Alpha2 release. Keeping up with the goals of WildFly 8, this new release contains additional EE7 support, certain bug fixes and also some WildFly specific features. The entire release notes are available here.

In this article, I'll provide some details about one of the WildFly features which has made into this release.

WildFly logo

WildFly ports


Traditionally, WildFly and previously named JBoss AS have opened different ports for different protocols and communication. For example, in the JBoss AS7 and now WildFly 8 series, by default the server opens the http port (which is by default 8080), remoting port (which is backed by JBoss Remoting and by default is 4447) and other such ports for usage by the applications deployed on the server. One of the goals of WildFly 8 (Final) is to have one single port open for all types of communication. This is meant to allow admins a better control of the server (firewall rules for example).

HTTP Upgrade support in Undertow


As some of you might know by now, the WildFly 8 series now uses Undertow as its web container. Undertow supports a standard feature called HTTP Upgrade. As can be read in that RFC, this feature allows the HTTP protocol to switch to a different protcol based on the presence of a header in the protocol data. This HTTP Upgrade feature acts as the backbone of the proposed "single port for communication" feature in WildFly.

EJB invocation over HTTP


Now that we have some background on HTTP Upgrade, let get to the details about the new feature that WildFly 8.0.0.Alpha3 introduces. Up until WildFly 8.0.0.Alpha2 (and previously in JBoss AS7 series) a project called JBoss Remoting has been the underlying protocol for remote communication with the server. The communication by default used to happen on the port 4447. Many of you will be familiar with this port, since this is what you used while looking up EJBs from a remote client.

Starting WildFly 8.0.0.Alpha3 (i.e. this new release), this port is no longer opened by WildFly by default. So how does one invoke EJBs or even use remote-naming (which too used this port) starting this version? The answer is simple, these remote clients will now have to use the HTTP port which by default is port 8080. The rest of the code will remain the same. This HTTP port is managed by the Undertow server which like I said earlier, has support for HTTP Upgrade. Internally, the EJB client API project (which is JBoss specific project dealing with remote EJB invocations) does the necessary plumbing to request Undertow to switch to JBoss "remoting" protocol while communicating on that HTTP port. Undertow then switches the protocol to "remoting" and the rest of the communication transparently happens as if it was the usual invocation on the remoting port.


So let's see some code to understand what exactly changes from previous version to the new version, from a remote client point of view. Let's take the example of the jboss-ejb-client.properties that's used to invoke EJBs. Earlier, you probably had: 

remote.connections=default

# the server hostname/IP
remote.connection.default.host=10.19.20.12

# the port for communication
remote.connection.default.port=4447

(and some other properties) 

Starting this release, the only thing that changes is the port number in that properties, rest of it remains the same. So: 

remote.connections=default

# the server hostname/IP
remote.connection.default.host=10.19.20.12

# the port for communication (the HTTP port)
remote.connection.default.port=8080


So that's it from a typical client point of view. 

For other new features and bug fixes, please take a look at the release notes.

Discover how the Watson team is further developing SDKs in Java, Node.js, Python, iOS, and Android to access these services and make programming easy. Brought to you in partnership with IBM.

Topics:

Published at DZone with permission of Jaikiran Pai, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}