Resin Java EE Web Profile and Beyond!!
You have no doubt heard of Java EE Web Profile. In the words of Rod Johnson, founder of the spring framework project, “Java EE 6 Gets it Right”.
Java EE Web Profile is the standard for servers that are more focused on web development using the pieces of the traditional Java EE stack that matter the most. You could say it is all of the stuff with none of the fluff. It allows vendors to create a slim focused application server. In our opinion, it allows vendors to provide an application server that fits the most common case of Java EE development. It has allowed Caucho to focus on what Resin does best, Java EE web development without the distraction of features that our clients don’t use.
From the
“(2007) The reach of the Java EE platform has become so broad that it has lost some of its original focus. To refocus the Java EE platform on particular classes of developers and applications, we propose the introduction of Java EE platform Profiles. Profiles will reference the Java EE platform, as defined by the JCP process, and may include a subset of Java EE platform technologies, additional JCP technologies not part of the base Java EE platform, or both. In addition to defining the base Java EE platform, this specification will define the rules for referencing Java EE platform technologies in Java EE Profiles.”
One of the very first profiles was the Java EE Web Profile and Resin was the first vendor to support this profile. The Web Profile includes support for Servlets, JSP, JPA, JSF, Facelets, CDI, JTA and EJB 3.1 light. It is everything you need from soup to nuts to build a web application.
Resin supports these standards and adds support for messaging (JMS), fault tolerant distributed caching, cloud computing, Health Monitoring, HTTP proxy, HTTP cache, virtual hosting, URL rewriting and an load balancer which is optimized for cloud computing. It is everything you need to scale your web application.
We find that many folks are building their own web stack with sort of a Dr. Frankenstein approach. The theme of this article is:
Is the capability that you are adding “part of” and “designed to work with” the rest of you stack, and is the capability cloud aware? Is the capability easy to configure? Can you get support for this capability? Because if the capability is “part of” and “designed to work with” the rest of your application infrastructure then you are that much closer to providing solutions instead of wasting all of your time on support and configuration.
Ask yourself this? If it is hard to configure a Web Proxy or Load Balancer or a distributed cache, will I have time? What if it was easy and already part of the solution you are using? What if your solution grew with your needs without costing you a fortune in licenses or in hidden support costs?
messaging, JMS
Often times it makes sense to offload processing to a background task. One way to do this is to send a message to said background task. For a web app, this allows you to have faster response time as you can be assured that the task will happen as the message to perform the task is in the queue and you can have a more responsive web interface.
A popular option for messaging is to use JMS. You might for example use the very configurable ActiveMQ.
ActiveMQ for example has its own way to handle clusters and clouds. Some of these ways are not very friendly to a cloud computing environment (like trying to use JGroups on an Amazon EC2 or Rackspace platform). In the end it becomes yet another thing to configure and manage.
Resin comes with JMS built in. The JMS that is built in uses the same internal messaging and caching that Resin cache support and Resin’s distributed Session management uses. Therefore it is not another system to integrate and and adapt to your environment. It is another aspect of the system that you already use and trust. Cloud support is already built in.
Another advantage of Resin’s JMS support is that there is very little configuration. With world class Resin support and JMS that is “part of” and “designed to work with” Resin, you are that much closer.
Resin does not preclude the use of ActiveMQ, but for most use cases, you can get by with Resin’s JMS support, and it is nice to have one cloud/clustering architecture to support instead of two. Resin will cost you a lot less maintenance headaches and you can always decide later to use ActiveMQ. Resin’s JMS is easier to configure and use.
Distributed Caching
Distributed Caching is the tip of the spear for performance and scalability. Domain objects can be related to other objects that are related to other objects, which you may all need to render a set of web pages. Getting related records out of a transactional store can be expensive and spikes in website usage can complicate things further. Also if there are some computations that you need to each time whose outcome does not change often, it does not make sense recalculate them every time.
Memcached is a fault resistant distributed cache that went from relative obscurity in 2007 to surpassing the number one commercial distributed cache leader in mind share. Memcached is the number one open source distributed cache solution in the Java world as well as recently more developers are using Memcached then use ehcache on the Java platform. In short there is a lot of pent up demand for distributed caching in the Java world. Although, not a cure-all, distributed caching is becoming a bigger part of many architectures.
A common use case is to check the distributed cache for a key, usually some sort of object identifier, and then grab said item from cache instead of reconstructing it from multiple database calls and calculations. The net effect is less load on your database and a system that can do better under load as a cache lookup is relatively inexpensive.
One problem with memcached is it is always distributed. You don’t have the notion of a local copy that can be served quickly.
Resin comes with distributed caching support that uses the JCache interface. The distributed cache that is built in uses the same internal messaging and caching that Resin JMS support and Resin’s distributed Session management. Unlike ehcache there are not 50 different ways to configure how it does is distribution (JGroups, RDMBS, JMS). Therefore Resin distributed cache is not another system to integrate and and adapt to your environment. It is another aspect of the system that you already use and trust. Cloud support is already built in.
Another advantage of Resin’s distributed support is that there is very little configuration. With world class Resin support and a distribute cache that is “part of” and “designed to work with” Resin, you are that much closer.
Resin does not preclude the use of memcached or ehcache or Coherence, but for most use cases, you can are much better off from a performance perspective as well as support using Resin’s distributed caching.
Resin’s distributed cache like ehcache and Coherence has local copies of the data that can be replicated and copied to each node as needed. Therefore servicing requests for cache items with cache keys can be extremely quick and much more internal network efficient then using memcached. Another clear advantage of Resin’s cache support is that it is easy to configure and use. It also endeavors to support standards like JCache and CDI, which make the usage standard. Again it is nice to have one cloud/clustering architecture to support instead of many. It will cost you a lot less maintenance headaches.
Cloud Computing
The advantage we get from deploying applications to the cloud is the ability to scale up processing nodes (Java EE servers) rapidly if needed. And the ability to re-purpose processing nodes (spin down, re-purpose and spin back up) when needed as well. This can be in a public cloud setting like Amazon EC2 or in a private cloud (VMWare vCloud) or some combination thereof.
We find that many solutions are just not sure how to handle the cloud. Reducing the amount of moving parts you have in your architecture facilitates running your application in public clouds and private clouds. Resin 4 was redesigned from the ground up to support cloud computing. To find out more about Resin cloud computing concepts, we invite you to read Resin fullfills the vision of Cloud computing in a Java EE environment.
Health Monitoring
It is not enough to have a cloud. You want a cloud of manageable nodes. You want to be able to monitor, control and at times debug your cloud.
Also with Resin you can manage entire pods from load balancer to http proxy cache to triad to individual dynamic servers with a single admin tool. This admin tools allows you to profile, analyze GC, Heap, PermGen, OS memory, monitor threads, inspect memory usage at the class level, and other Java VM graphs and OS graphs from one console for every node in the pod. The support the admin tool provides rivals that of some dedicated profiling tools but does it for your entire pod. Now you can really see what is going on in the cloud.
You can also employ Resin Health Watches to auto-manage your cloud. You can also setup up health watches so you know when some critical situation has been released and then take some action to monitor, diagnose and control your cloud. Resin also integrates with Nagios, Tivoli and HP OpenView.
HTTP Proxy, Virtual Hosting, URL rewriting
Apache HTTPD serves 60% of all traffic on the web. It is often used in front of Java application servers. It servers requests to backend Java EE servers which handle the request letting Apache HTTPD handle all requests for static images, static pages, and other static resources. Apache HTTPD usually sits on the public Internet accessible side of a DMZ or perimeter network.
Apache HTTPD provides virtual hosting, which many websites and Java EE application must employ. Virtual hosting is “a method for hosting multiple domain names on a computer using a single IP address. This allows one machine to share its resources, such as memory and processor cycles, to use its resources more efficiently.” ([http://en.wikipedia.org/wiki/Virtual_hosting Wikipedia article on virtual hosting])
Apache HTTPD also provides a rewrite engine that allows URL rewriting. A rewrite engine “is software that modifies a web URL’s appearance (URL rewriting). Rewritten URLs (sometimes known as short, fancy URLs, or search engine friendly - SEF) are used to provide shorter and more relevant-looking links to web pages. The technique adds a degree of separation between the files used to generate a web page and the URL that is presented to the World.” (Wikipedia under rewrite engine).
Typically you connect Apache HTTPD to your Java EE server via an Apache module. Which apache module depends on your application server. Many application servers support AJP protocol and can work with the connectors that support this protocol. Other do not, and must be configured using mod_http_proxy. Thus you may use
mod_jk, mod_jk2, mod_proxy_http, mod_proxy_ajp and mod_proxy together, mod_jserv, mod_webapp or some other modules. Which modules that work with which version of Apache HTTPD and which version of your application server may be difficult to ascertain as “it isn’t unusual to stumble across some really bad, out of date advice” and documents (Tomcat expert). Also different modules provide different features sets from load balancing to SSH transmission between Application Server to Apache HTTPD.
Enter stage left, Resin application server. Resin can use Apache HTTPD on the front end and in fact ships with mod_caucho to connect Apache HTTPD and Resin. The mod_caucho Apache module is well supported by the same world class support as the rest of Resin.
In addition to that, you do not actually need Apache HTTPD at all. Resin is a full web server. It supports virtual hosting. It supports URL rewriting. It can do everything you typically need Apache HTTPD to do, but much more efficiently, cloud aware and with a lot less configuration. With world class Resin support and a full functioning web server that is “part of” and “designed to work with” Resin, you are that much closer. You can put your Resin web tier in the DMZ to communicate with your Resin application tier.
Since Apache HTTPD is written in C and Resin is written in Java, you may be concerned with speed and scalability. Don’t be. Resin outperforms Apache HTTPD. Resin’s TCP/IP layer is written in very tight C code. Resin is and has always been a Java EE speed demon.
A bit of a side note, but Resin also ships with LAMP already installed. Resin supports PHP through it Quercus.
Quercus is a PHP clone written in Java. It is included in Resin and since it compiles to Java, it is much faster than standard PHP. Quercus is able to run MediaWiki and about a dozen other famous PHP applications without modification. It is very compatible to PHP and unlike PHP it can communicate freely with Java libraries. You can even subclass a Java class in PHP.
HTTP Cache
Resin’s Apache HTTPD dueling does not stop there. Resin’s web tier has load balancing and HTTP caching built in. No need to configure yet another module or install SQUID.
It is not unheard of for some organizations to use SQUID for caching HTTP results. SQUID “reduces bandwidth
and improves response times by caching and reusing frequently-requested web pages”.
This support is built into Resin. The application tier servers can deliver the right headers automatically to the Resin web tier servers.
There is very little work and configuration to do since again, our HTTP cache support was built into Resin.
Although a common case, configuring an HTTP cache can be tricky at best. With world class Resin support and an HTTP cache that is part of and designed to work with Resin, you are that much closer.
Load Balancer
Resin’s pod load balancer is cloud aware. This means it smart enough to allow the new dynamic server some time to warm up and install its applications from the triad before it starts sending it requests. The pod load balancer can truly balance the load based on the true load on each node, not just random round robin load balancing employed by many hardware load balancers. The load balancer can also act as an http proxy cache to increase throughput by caching images, css files and other web resources as well as live in the DMZ with the rest of the Resin web tier. As always, Resin does not preclude the use of other load balancers, but if you use the Resin load balancers, you will have an optimized performance benefit, easier cloud aware configuration and easier support and configuration overall.
What you get
What you get with Resin is a complete Web Profile with all of the pieces you need to build a true web solution in Java using Java EE (and/or PHP). Since adding HTTP Proxy, HTTP cache, load balancing, cloud computing, distributed caching and JMS are easy and well supported. It is easier for you to focus on building your application. Also if you are going to utilize cloud computing, it is good to know that you are using a provider whose application server is built with cloud computing in mind. Also by going with one set of cloud computing architecture, you don’t have to worry about so many moving parts as you deploy your solution to the cloud.
References: