I have recently done a presentation of GWT 2.4
It is now available on slideshare.net :
I might work on it again later. To make it a bit nicer.
Here are the quick steps to configure a cluster of Jonas instances, with Apache and the module mod_jk.
The Apache web server receives the client requests and forwards them to one of the Jonas instances :
Apache is often the web server used in front of an application server (for instance Jonas).
You need a module like mod_jk to configure Apache with Jonas. Here are the details to configure that module (under RedHat Linux) :
1) Download and install the module mod_jk
mod_jk is an Apache module which can be used to forward a client HTTP request to an internal application server, using the Apache JServ Protocol (AJP).
To get it, type the following commands :
cd /usr/lib64/httpd/modules wget http://archive.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/linux/jk-1.2.31/x86_64/mod_jk-1.2.31-httpd-2.2.x.so chmod 755 mod_jk.so /etc/init.d/httpd restart
The module will show up in the modules folder of Apache : /etc/httpd/modules
2) Configure Apache and mod_jk
First, you need to load the mod_jk module into Apache when it starts.
In the main Apache configuration file, /etc/httpd/conf/httpd.conf, add the following line :
LoadModule jk_module modules/mod_jk.so
Then you need to specify the path to the workers properties file and configure the contexts and the workers which will handle these contexts :
<IfModule jk_module> JkWorkersFile /etc/httpd/conf/workers.properties JkShmFile /etc/httpd/logs/mod_jk.shm JkLogFile /etc/httpd/logs/mod_jk.log JkLogLevel debug JkLogStampFormat "[%a %b %d %H:%M:%S %Y] " JkRequestLogFormat "%w %m %V %T" JKMountCopy All # Send requests for context /blabla/* to worker named worker1 JkMount /blabla/* worker1 # Send requests for context /blabla* to worker named worker1 jkMount /blabla* worker1 # Send requests for context /blabla to worker named worker1 jkMount /blabla worker1 # Send requests for context /blabla/ to worker named worker1 jkMount /blabla/ worker1 # Send requests for context /anotherContext* to worker named worker1 jkMount /anotherContext* worker1
The line JKMountCopy All is very important. It copies the mount point definitions in all the virtual hosts.
Create and add the file workers.properties to /etc/httpd/conf/ :
# Worker list worker.list=worker1 # Define worker1 worker.worker1.port=8009 worker.worker1.host=127.0.0.1 worker.worker1.type=ajp13 worker.worker1.lbfactor=1 worker.worker1.cachesize=10 # Load-balancer worker.loadbalancer.type=lb worker.loadbalancer.balanced_workers=worker1 worker.loadbalancer.sticky_session=1 worker.loadbalancer.local_worker_only=1
Here I have created only one worker (worker1) because I just want to forward requests to an instance of Jonas. There is no load-balancing in this configuration since there is only one single instance.
loadbalancer is not a real worker, it is responsible for the management of several “real” workers.
3) Configure Jonas
To enable AJP connections to the 8009 port of the Jonas server, you need to create an AJP connector in the $Jonas_Base/conf/tomcat6-server.xml and $Jonas_Base/conf/tomcat7-server.xml files :
<!-- Define an AJP 1.3 Connector on port 9009 --> <Connector port="8009" protocol="AJP/1.3" redirectPort="9043" />
<!-- An Engine represents the entry point (within JOnAS/Tomcat) that processes every request. The Engine implementation for Tomcat stand alone analyzes the HTTP headers included with the request, and passes them on to the appropriate Host (virtual host). --> <!-- You should set jvmRoute to support load-balancing via AJP ie : <Engine name="Standalone" defaultHost="localhost" jvmRoute="jvm1"> --> <Engine name="JOnAS" defaultHost="localhost" jvmRoute="worker1">
Here is a schema that sums things up:
The other day I was asked by a coworker the difference between a proxy and a reverse-proxy.
These are 2 types of servers that are largely used in front of an application server. Many companies and schools filter their internal network through proxies.
So I made this drawing, I think it should come handy to a lot of people.
Many people are familiar with the proxy server that they need to configure in their browser to access the internet. But few people are familiar with the reverse-proxy server.
To sum things up :
1) The proxy server’s main job is to cache pages so it serves them if the client asks them again.
2) The reverse-proxy server’s main job is to secure the servers as it takes the incoming requests from the internet and forwards them to the servers. Other jobs are : load balancing, filtering and also caching.
The reverse-proxy can be located in a demilitarized zone (DMZ), that is a very secured area, between 2 firewalls for instance.
One thing to remember :
if the firewall is removed, the client still can access the internet. If the proxy is removed, the client cannot access the internet.
Today I wanted to experiment some load balancing with JBoss and Apache. For that I needed to run 2 JBoss servers on one single machine.
Server 1 is installed in D:\jboss-18.104.22.16800721-M4-Server1
Server 2 is installed in D:\jboss-22.214.171.12400721-M4-Server2
Of course if you run both servers at the same time, you will get errors such as “address already in use” because of services running on the same ports in both servers.
It turns out that you need to modify the D:\jboss-126.96.36.19900721-M4-Server1\server\default\conf\bindingservice.beans\META-INF\bindings-jboss-beans.xml file to avoid same port conflicts.
So I added 100 to all ports defined in that file, for server 1.
For server 2, I only modified the HTTP WEB SERVER port because port 8080 is already taken by Oracle.
There is no need to modify the D:\jboss-188.8.131.5200721-M4-Server1\server\default\deploy\jbossweb.sar\server.xml file.
I have recently been challenged by a colleague with a .Net background about the way I sometimes use session beans in web applications. Indeed, I like to implement DAOs as session beans.
Some people argue that it’s best not to directly implement CRUD methods in session beans.
The main reason being that they prefer to add another level of separation. For instance :
Session bean client
business object helper class
A good example of this approach is the old implementation (EJB 2.0) of the The Java Pet Store by Sun. (API : http://java.sun.com/blueprints/code/jps131/src/).
My opinion is that this level of separation is not always necessary. And I believe using session beans as DAOs makes even more sense now that in EJB 3.x we have the Java Persistence API (entitymanager) which already provides generic
database access methods (persist(), merge(), etc) :
Session bean client
Session bean DAO (JPA)
Entity bean (JPA)
Adam Bien explains it well in this post.
Here is another memento I wrote to remember the different approaches when writing EJB 3 or Web services.
|IN THE MIDDLE
|Develop entity beans first then derive db schema
|Develop db schema first and drive upwards to create entity beans from your schema
|Create entity beans and db schema and map both respectively
|contract first : in the top-down scenario, the developer first creates or is given the WSDL file for the service, and then must create a component to implement the operations.
|First you create a Java bean or EJB bean and then use the Web services wizard to create the WSDL file and Web service.
|In this case the starting point consists of both the WSDL file and the implementation component, and the developer must create additional support code that maps between the two.