The Kitchen in the Zoo - spring tag

GlassFish 3 In 30 Minutes

Sat, 08 May 2010 21:40:00 GMT

The aim: Set up a simple Java EE 6 project on GlassFish v3 in no time at all. The project must include: email, JMS, JPA, web and EJB (session bean, message driven bean and a timer bean). It must also include security and transactions.

Sounds like a lot, but thanks to Java Enterprise Edition version 6, setting up a project like this and configuring all the resources in the Application Server are really easy! I chose GlassFish because its open source, has a useful little Admin Console and I've never developed with it before.

Before I started I downloaded Java SE 6 (update 20), Mysql Server, the Mysql JDBC Driver and the GlassFish Tools Bundle for Eclipse, which is a WTP Version of Eclipse 3.5.1 with some specific bundles for developing and deploying on GlassFish.

The process I wanted to implement was simple: a user goes to a website, clicks a link to a secure page and logs in, after which a message is persisted to the database and an asynchronous email gets sent. The user is shown a confirmation. In the background theres also a task which reads new messages from the database and updates them so they are not processed a second time.

The design was to use a servlet for calling a stateless session EJB, which persists a message using JPA and sends a JMS message to a message driven bean for asynchronous processing. The MDB sends an email. A timer EJB processes and updates any messages it finds in the database. Additionally I set a requirement to use only the newest technologies in Java EE 6, my servlet and beans were configured using annotations. The following sequence diagram shows the rough design:

The first challenge was to configure my resources in GlassFish. I started the preinstalled server instance which is shipped with this special Eclipse and opened the admin console at localhost (got the port number from the log console).

Without deploying any apps, I configured the following:

1) JDBC Connection Pools, which contain the connection details to the database - one for data, one for a security realm. When creating them, I used default settings apart from:

Pool for Data:

  <jdbc-connection-pool datasource-classname="com.mysql.jdbc.jdbc2.optional.MysqlXADataSource" res-type="javax.sql.XADataSource" name="testPool" ping="true">     <property name="URL" value="jdbc:mysql://localhost:3306/test" />     <property name="Url" value="jdbc:mysql://localhost:3306/test" />     <property name="User" value="root" />     <property name="Password" value="password" />     .     .   <jdbc-connection-pool>

Pool for Security Realm:

  <jdbc-connection-pool driver-classname="com.mysql.jdbc.Driver" res-type="java.sql.Driver" name="realmPool" ping="true">     <property name="URL" value="jdbc:mysql://localhost:3306/test?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8" />     <property name="password" value="password" />     <property name="user" value="root" />   </jdbc-connection-pool>
2) JDBC Resources, which is where you set the JNDI names for your JDBC Connection Pools.

  <jdbc-resource pool-name="testPool" jndi-name="jdbc/test" />   <jdbc-resource pool-name="realmPool" jndi-name="jdbc/realm" />
3) JMS Resource - one connection factory for sending messages, and one destination which is the queue which references a physical destination in the jms service (which gets automatically added further down in the admin console under the JMS Service).

  <admin-object-resource res-adapter="jmsra" res-type="javax.jms.Queue" description="a test queue" jndi-name="jms/destinationResource">     <property name="Name" value="test_destination" />   </admin-object-resource>   <connector-resource pool-name="jmsConnectionPool" jndi-name="jmsConnectionPool" />   <connector-connection-pool name="jmsConnectionPool" resource-adapter-name="jmsra" is-connection-validation-required="true" connection-definition-name="javax.jms.ConnectionFactory" transaction-support="XATransaction" />
4) A Javamail Session, so that my app could send email over POP3.

  <mail-resource host="localhost" store-protocol="POP3" store-protocol-class="com.sun.mail.pop3.POP3Store" jndi-name="mail/Session" from="boss@maxant.co.uk" user="boss">     <property name="mail-password" value="boss" />   </mail-resource>
5) Under Configuration / Security, I set up a JDBC realm which used the realm database connection pool which was configured above.

  <auth-realm name="database-realm" classname="com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm">     <property name="jaas-context" value="jdbcRealm" />     <property name="datasource-jndi" value="jdbc/realm" />     <property name="user-table" value="party" />     <property name="user-name-column" value="login" />     <property name="password-column" value="password" />     <property name="group-table" value="role" />     <property name="group-name-column" value="role" />     <property name="db-user" value="root" />     <property name="db-password" value="password" />     <property name="digest-algorithm" value="none" />   </auth-realm>
Here is the domain.xml file (GlassFish's main configuration file, located under either %glassfishv3_install%/glassfish/domains/domain1/config if you installed the server, or under %GlassFish-Tools-Bundle-For-Eclipse-1.2-Install&/workspace/.metadata/.plugins/com.sun.enterprise.jst.server.sunappsrv92/domain1/config if you installed the GlassFish Tools Bundle for Eclipse).

Put the Mysql J/Connector JAR into %GlassFish-Tools-Bundle-For-Eclipse-1.2-Install%/glassfishv3/glassfish/lib or %glassfishv3_install%\glassfish\lib. GlassFish already contains Mail, Activation and JMS JARs on its classpath, so there is nothing else to do here.

Using Eclipse, create a new EAR project, as well as a new web module. Once created, right click on the running server and click "add / remove". Add the new EAR so that its deployed, and once deployed, return to the admin console.

You can now set up a virtual server (host) so that you can run multiple domains using the same server (something you might realistically want to do with a prodution server). To do this, you either need to modify a DNS server so that multiple domains resolve to your IP address, or you can modify the hosts file (on windows its c:\windows\system32\drivers\etc\hosts) and add a domain. In the admin console, set up a new virtual server by refering to that domain, and setting its default application to the one you just deployed. That way, any HTTP request which comes in for that domain is sent to your web application. To enable a request like "http://testwsmaxantcouk:8084/" to be redirected to "index.jsp" in your app, you need to set the context root of the webapp to "/", in application.xml or the EAR:

  <application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:application="http://java.sun.com/xml/ns/javaee/application_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_5.xsd" id="Application_ID" version="5">     <display-name>Seven     <module>       <web>         <web-uri>SevenWeb.war</web-uri>         <context-root>/</context-root>       </web>     </module>   </application>
In order for this configuration to work, you need to create a database and relevant schema, which you can do using the three SQL files inside the download at the bottom of this article, to create the database, create tables for the realm and application, and insert some initial data into them.

The next step is to add your servlet. I used the eclipse wizard to add a new servlet, which generates a class into your web project with Java EE 6 annotations:

  @WebServlet(name = "SevenServlet", urlPatterns = { "/SevenServlet" })   public class SevenServlet extends HttpServlet {   .   . The servlet delegates its work to a stateless session EJB, which ensures that a transaction is started. The EJB can also be used to check security, although the servlet needs to be deployed within a security context in order to get the web container to automatically reply with a redirection to the login page, in the case where the user is not logged in. In Java EE 6, you do this also using annotations:

  @Resource(name="java:app/SevenEJB/EJBSeven")   private EJBSevenLocal ejbLocal;
When the container finds this annotation in an servlet, it injects the EJB automatically.

The EJB is declared with some annotations and resources too:

  @DeclareRoles({Roles.REGISTERED})   @Stateless   @TransactionManagement(TransactionManagementType.CONTAINER)   public class EJBSeven implements EJBSevenLocal {   .   .
This tells the EJB container that the EJB is stateless, uses container managed transactions and may be used by users with roles "registered". The following resources are declared:

  @Resource(mappedName = "jms/destinationResource")   private Queue q;   @Resource(mappedName = "jmsConnectionPool")   private QueueConnectionFactory qcf;   @Resource   private SessionContext sessionContext;   @PersistenceContext(unitName="MessageManagement")   private EntityManager em;
These resources are a JMS connection factory, and a queue, for sending the asynchronous message. The session context is the EJBs session context which allows the EJB to query users roles and rollback transactions, amongst other things. A JPA Entity Manager is also declared allowing the EJB to use the database. Finally, the business method declared in the EJB interface is implemented:

  @Override   @RolesAllowed({Roles.REGISTERED})   @TransactionAttribute(TransactionAttributeType.REQUIRED)   public String execute(String command) {   .   .
The annotations above tell the container that the user must be in the given role in order to call this method, and that a transaction is required.

Next, the message driven bean is implemented:

  @MessageDriven(     activationConfig = { @ActivationConfigProperty(       propertyName = "destinationType", propertyValue = "javax.jms.Queue"     ) },     mappedName = "jms/destinationResource")   public class MDBean implements MessageListener {   .   . The annotations above tell the container which messages should be sent to the onMessage(Message) method of the bean. This bean too has resources, namely a mail session, for sending email:

  @Resource(name="mail/Session")   private Session mailSession;
The timer EJB is also implemented:

  @Stateless   @TransactionManagement(TransactionManagementType.CONTAINER)   public class EJBTimerSeven {     @PersistenceContext(unitName="MessageManagement")     private EntityManager em;   .   .
In order for the timer bean to use the entity manager within a transactional context (so that it can for example update or insert data), it too needs a declaration that it uses container managed transactions. The method which is scheduled is defined next:

  @Schedule(second="0", minute="*/1", hour="6-23", dayOfWeek="Mon-Fri", dayOfMonth="*", month="*", year="*", info="MyTimer")   @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)   private void scheduledTimeout(final Timer t) { . .
Note that there is nothing in this beans definition that makes it a timer bean. Rather the method which is to be called when the schedule fires, is simply annotated. I could have just as easily added this method to the main EJB in my project. The schedule pattern is similar to scheduling a cron job in unix, and the second part to ensuring that this methods actions on the entity manager are committed is to add the TransactionAttribute annotation, in this case ensuring that a new transaction is started.

The last thing I needed was a class for JPA, to represent the table I want to write to:

  @Entity   public class Message {     @GeneratedValue(strategy=GenerationType.IDENTITY)     @Id     private int uid;     @Column(name="sender")     private String sender;     @Column(name="when_sent")     private Timestamp whenSent;     .     .
This classes annotations show that its a persistable entity using JPA (the @Entity annotation), that the "uid" attribute is the primary key and is generated by the database and that the other attributes map to given columns in the database. Using these very simple annotations and configuring the entity manager using the follwing simple XML, JPA is enabled and it becomes very simple to use indeed.

  <persistence>     <persistence-unit name="MessageManagement">       <jta-data-source>jdbc/test</jta-data-source>       <class>uk.co.maxant.test.Message</class>     </persistence-unit>   </persistence>
This XML file is saved as "persistence.xml" and dropped into the META-INF folder of the EJB project.

So, setting up a Java EE 6 enterprise application is really simple! Here are some comments...

Remember that when calling services (EJBs) from your web layer (servlets or in JSF backing beans), that you should always call a façade whose job is to ensure that a transaction is started. In fact, you may have noticed that the realm JDBC resource was configured as a simple SQL Driver, whereas the JDBC resource for the application was set up as an XA Data Source. What's the difference? Well within the application we used JMS and the application database in the same business method of our EJB, which was run within a transaction. To ensure that either both resources were committed together, or neither, you MUST use XA. The JMS connection factory has a flag on it to say that it should be XA-enabled. The application which you can download at the end of this article contains a hyperlink for starting the process described at the top of the article, as well as another hyperlink for starting it with an error. Any errors that occur in your business logic, before the container attempts to commit resources, are not affected by XA. Rather, XA helps if one of the resources cannot commit, say due to a data constaint defined in the database. That means that if the container had sent the JMS message and then attempted to write data to the database and discovered the data was not valid, it would not commit the sending of the JMS message, so neither resource gets commited! It is important to understand the subtle differences in where the errors occur, in order to see the benefits of XA. For more information see Wikipedia

If you get the following error after deploying the EAR, don't worry, it's quite normal: "WEB9051: Error trying to scan the classes at .../eclipseApps/Seven/SevenEJB.jar for annotations in which a ServletContainerInitializer has expressed interest". See here.

GlassFish's log files can be found at either %glassfishv3_install%/glassfish/domains/domain1/logs if you installed the server, or under %GlassFish-Tools-Bundle-For-Eclipse-1.2-Install&/workspace/.metadata/.plugins/com.sun.enterprise.jst.server.sunappsrv92/domain1/logs if you installed the GlassFish Tools Bundle for Eclipse).

If you experience problems with the security realm, the logs don't give much information. The easiest solution is to set a breakpoint for exception com.sun.enterprise.security.auth.login.common.LoginException and when it comes up, you can debug the JDBCRealm class. You need to download the source which you can find under https://svn.dev.java.net/svn/glassfish-svn/trunk/v3/security/core (login with user "guest" and no password). More information for the JDBC realm can be found here. One other noteworthy point about realms and GlassFish is that unlike with Tomcat, you must state which realm to use for your web app. You can either do this in the sun-application.xml file, or by adding the realm-name element to your login-config element of web.xml. Both are shown in the download for this article (see bottom).

Until now, I have never used Java EE 6. I had got into the routine of using simple Spring for simple projects. But Java EE 6 is practically the same as Spring in terms of configuring services (EJBs) and adding security and transaction annotations. So I've started to ask myself what the advantage of Spring now is. Well Spring still offers simple database handling in terms of not having to worry about exceptions and being able to call Hibernate or other frameworks in a standard way, but JPA offers the same advantages. Spring also offers simplified sending of email, which Java EE 6 does not have, but this is no huge deal. One nice feature of Spring is that it includes AOP, which I have used mostly for improving on Spring Security (by simplifying it, search on this blog for more details). While Java EE 6 doesn't offer AOP out of the box, you can add it quite simply (see http://www.eclipse.org/aspectj). What's more, the security offered by Java EE is much more standard than that offered by Spring. To so summarise, it's getting hard to justify wanting or needing to use Spring. While it is sold as being light weight, modern Java EE app servers are themselves quite light weight, and thanks to "profiles" you can obtain even lighter weight versions of them. See the java.sun.com for more information.

You will notice that the JNDI names used in the resource annotations in my EJBs were added against "mappedName" attributes in the annotations, rather than "name". What that means is that the standard indirection mappings that one should use when deploying EJBs, has not been used, namely the resource "jms/destinationResource" MUST be present in the JNDI tree, rather than the container looking for this name in a mapping in the deployment descriptor. This is fine when deploying your own EJBs to your own app server, but the original idea of creating EJBs was that you would write them, and the deployer would decide how the resources are named, which hence requires a mapping. If you do provice a mapping in the deployment descriptors, then you should use the "name" attribute in the annotations. See here for more information.

The full source code can be downloaded here.

© 2010 Ant Kutschera

Social Bookmarks :

Enterprise GWT: Combining Google Web Toolkit, Spring and Other Features to Build Enterprise Applications

Mon, 25 Jan 2010 19:00:00 GMT

The following is just the introduction taken from a new white paper available at www.maxant.co.uk/whitepapers.jsp:

Google Web Toolkit (GWT) provides developers with a powerful means of developing
AJAX front ends without the worry of having to maintain complex Java script libraries to
support multiple browsers and browser versions.

GWT also provides support for Remote Procedure Calls (RPC) to the server. Since April
2009 the Google App Engine has existed, which allows developers to deploy their GWT
applications and also provides support for Java Data Objects (JDO) and the Java
Persistence API (JPA).

However what is missing for GWT to be deployed to a modern Enterprise environment is a service framework providing dependency injection and inversion of control (IoC),
transaction demarcation and security, such as that provided by Spring or Enterprise Java Beans (EJB) 3.0. Furthermore GWT does not define any patterns for User Interface
designs, or composite widgets.

This paper describes how to successfully integrate Spring into a GWT Application with the aim of creating a fully scalable development framework for deployment in the Enterprise and beyond (including simple and small applications), with very little start up time being required, because you can download the demo application. It includes UI Patterns and composite widgets to improve the development of the front end. This GWT Demo Application is live at http://gwtdemo.maxant.co.uk and is available for download at
http://www.maxant.co.uk/whitepapers.jsp.

(c) 2010 Ant Kutschera

Social Bookmarks :

Java EE Security and Spring

Tue, 02 Jun 2009 18:30:00 GMT

Spring Security (originally ACEGI) does not seem to work out of the box with Java EE security (see here). I guess the reason is clear, namely that the people from Spring don't want you to be tied into Java EE and that makes sense because Spring something that you can use without Java EE. But instead of having to learn something new and instead of having to configure my security in a non-standard way, I wanted a way to ensure my services are only called by someone with the right authorization, exactly when they are deployed in a Java EE environment.

Since a standard web application running in a Java EE container can be configured to have security, I expected to be able to configure Spring to use the web request to check the Principal for its security roles before calling a service, but that isn't possible. So, I set to work to quickly create a little library to help me out.

The first step was to implement a Filter in the web application so that it could intercept every call and insert the web request (containing the Principal) into a ThreadLocal variable. The idea was that the ThreadLocal variable could then be used further up the call stack to query the security roles of the authenticated user. The filter implementation looks like this:

public void doFilter( ServletRequest request, ServletResponse response, FilterChain chain)

throws IOException, ServletException {

//set the request in the security thread local SecurityHelper.set((HttpServletRequest)request);

chain.doFilter(request, response);

//all done, so remove references to unwanted objects

        SecurityHelper.finished();     }

The filter is configured in the Java EE web application's web.xml like this:
    <filter>         <filter-name>maxantSpringSecurity</filter-name>         <filter-class>             uk.co.maxant.spring.security.SecurityFilter         </filter-class>     </filter>         <filter-mapping>         <filter-name>maxantSpringSecurity</filter-name>         <url-pattern>/*</url-pattern>     </filter-mapping>The filter calls the SecurityHelper which uses a ThreadLocal variable to store the web request as follows. The web request can be used to gain access to the Principal, as well as ask if the Principal has a given role.
    private static ThreadLocal tls = new ThreadLocal();

public static void set(HttpServletRequest request){ tls.set(request); } public static boolean isInRole(String role){ HttpServletRequest req = tls.get(); if(req == null){ return false; }else{ return req.isUserInRole(role); } }

The Security Helper also contains an additional method which can be called to release the reference to the request. This is important because the web request contains a reference to the session and that might be large. We don't want to be holding on to such things for a long time as they may use memory unncessarily. This method can is called as soon as all security queries are finished, and is implemented as follows. For more information on thread locals and threads that are stored in pools, see here. public static void finished(){ tls.remove(); }

The final step was to configure my Spring configuration to setup an aspect to intercept all service calls. The advice which this aspect gives is whether the current user has the role required to call the method. The required role comes from an annotation added to the service methods and the current user comes from the Principal stored in the ThreadLocal from step one, above. If the user has rights, the service method is called. If not, a simple SecurityException is thrown, providing details about the missing roles. In cases where the user is not logged in, the Security Exception is also thrown. In cases where a Service method has no annotation, then no security is checked. The aspect is configured in the Spring configuration like this:

<bean id="security"
        class="uk.co.maxant.spring.security.SecurityAspect">
        
        <property name="order" value="2" />
    </bean>

<aop:config>
        
        <aop:aspect id="securityAspect" ref="security">
            <aop:pointcut id="serviceMethod"
                expression="execution(* uk.co.maxant.gwtdemo16.server.*Service.*(..))" />
            <aop:around method="checkSecurity"
                pointcut-ref="serviceMethod" />
        </aop:aspect>
    </aop:config>

The expression in the above pointcut needs to be configured to match your package and Service naming conventions.

The aspect itself is implemented like this:
    public Object checkSecurity(ProceedingJoinPoint call)             throws Throwable {         String[] requiredRoles = null;         MethodSignature ms =                        (MethodSignature)call.getSignature();         Method m = ms.getMethod(); //lets check it for the    // RolesAllowed annotation         RolesAllowed roles = m.getAnnotation(RolesAllowed.class); if(roles != null){             requiredRoles = roles.value();             for(String role : requiredRoles){ if(SecurityHelper.isInRole(role)){                     //ok, no problem, lets continue                     //with the call requiredRoles = null; //since we can now // carry out the call break;                 }             }         }             if(requiredRoles == null){             Object returnValue = call.proceed(); return returnValue;         }else{             String rrs = "[";             for(String s : requiredRoles){                rrs += s + ", ";            }            rrs = rrs.substring(0, rrs.length() - 2) + "]";                       throw new SecurityException("To call [" +                call.getSignature().toLongString() +                "] the user must be authenticated and " +                "authorized in these roles: " + rrs);       }     }
The annotation is defined as such:
    @Retention(value=RetentionPolicy.RUNTIME)     @Target(value={ElementType.METHOD})     public @interface RolesAllowed {         String[] value();     }

The annotation is used like this, on all service methods requiring security:
    @RolesAllowed ("registered")

What I now have is a simple library which I can configure using a Filter and an Aspect. Additionally to allow the user to log in in the first place, I can use a standard Java EE security constraint in my web application. The standard steps to use this security extension of Spring would be:

Add a security constraint to the web application
Add the annotation to the service methods requiring security
Add the filter to the web application
Add the aspect to the Spring configuration
Add the library to the classpath

I understand that Spring does not want you to need a dependency on Java EE, but on the other hand if I have that dependency due to other requirements, I do not want to have to configure my application using a third party security concept (Spring) as opposed to a standard one (Java EE). Spring Security is not even part of Standard Spring - it is downloaded seperately. The more extensions you use, the more skills your developers need. The maxant Spring Security extension provides a very simple way to secure your service methods.

Download the library including source code here.

Copyright (c) 2009 Ant Kutschera

Social Bookmarks :

Spring Services Anywhere

Thu, 07 Aug 2008 20:51:00 GMT

I recently embarked on some Spring "re-training" (I haven't looked at it in a few years and it was time to get my skills up to scratch again). Since the last time I looked at Spring, I have worked on a couple of rich (thick) client projects where it was almost impossible to find people with both server skills and GUI skills (the market is quite good at the moment and people like me with all those skills get snapped up very quickly ).

Anyway, since it is hard to find strong GUI programmers who also know how to deploy an app server and start it, it becomes desirable to be able to run the services inside the same JVM as the GUI programmer is developing in. There is then no wasted time due to EJB configurations and all the crap that comes with server development.

About 18 months ago, I got around the problem by quickly implementing a clever service locator. It worked brilliantly, the only real problem being that we had a few bugs because people had developed code which worked when services were local but not when they were remote. The effort in fixing those bugs was however minimal.

On my current project, we are using a proprietary framework based on Inversion of Control and Dependency Injection. Based upon its configuration, a client can call services locally or remotely too. If calling services remotely, they are invoked inside a stateless session bean which uses reflection and proxies in order to load the service and call its method. Transaction and security inteceptors are also in place ensuring that the services are called in the correct context. It is all very clever, but sadly proprietary (although at least we have the source code!).

Anyway, so as I am reading up on Spring, I am reminded how it too is intended to provide services independently of the environment in which it is running (that is, whether it is running in a stand alone application, inside a web container or an EJB container).

However, there is a marked difference compared to my Service Locator solution and the proprietary solution of my current project. In Spring, services are not automatically "remoted". To move services from a standalone application to run inside an EJB container, you need to write code which sits between the client and those services to allow them to be called.

In EJB 3.0, a stateless session bean is simply a POJO. If it is not deployed in a server, a standalone application which has that POJO on its classpath can call a method in the POJO (admittedly without security or transaction functionality).

In Spring, you deploy your service to a Web or EJB Container and that container can use the services, but the client is no longer able to call those services. At the best, you can "remote" your service so that it can be called through its interface, however, it will live inside the web container. If you want the client to be able to call your service that is now in the EJB container, you need to write an EJB with the correct interface to expose that services functionality.

Now, is that a problem? What's wrong with just using the web container or indeed just a web server? Ahhh... its not capable of handling transactions, I hear you say. True, but Spring provides mechanisms for applying a transactional context to your services. You can even use the transaction manager from your application server, so it will provide the same transactional functionality as provided to EJBs (for example XA compliant and having the ability to run across nodes in a cluster).

OK, OK, the web container doesn't provide security to service methods! Well, also not true, since you can use declarative and programmatic security from the web container to ensure the user can only use functionality for which they are authorised.

OK, but the web container isn't scalable/reliable/robust! Also not true, just like the EJB container, it has the ability to synchronise state across a cluster. And running in a cluster also means it is scalable, reliable and robust.

So, you might now start to agree, that actually, there is no need to run in an application server. Everything you do day in and day out can now be handled by Spring in the web container, ie. by a friendly cluster-aware web server like Apache Tomcat...

I wouldn't disagree with that statement. However, here are some reasons to run inside a full application server:

You need a JTA Transaction manager capable of propagating transactions across nodes in a cluster,
The enterprise architecture department in charge of specifying the environment you run in is also capable of specifying that services must run in the EJB layer,
You need to receive JMS messages in message beans
You need to use Timer Beans
You need a clustered JNDI tree as provided by your application server
You need access to resources which your application server can provide and manage (eg. JCA)

If you don't have any of these constraints, an you are committed to using Spring, then I currently do not see many reasons to run in anything other than a Java EE compliant Web Container. If you can think of other reasons to run in a full application server, please leave comments below.

Social Bookmarks :

Secure Remoting with Spring and JBoss

Thu, 07 Aug 2008 18:58:00 GMT

If you are faced with having to write a rich client application in a multi-tier Java EE environment, you will typically connect to the application server over RMI. In theory, you are meant to use the servers Application Client Container and deploy your application as a client in that container. You probably won't do that though, because the client container is unfriendly for many reasons:

As an example, the WebSphere 6.1 Client Container is a 200 megabyte install,
Client Containers tend to be started as batch commands which set up the environment in which your application will run. If you however have an application that is meant to be started with a sexy launcher, as is the case with Eclipse RCP applications, you will struggle to get the environment created properly by the launcher, and its not supported by the vendor anyway,
If you need to connect to the server securely (ie. so that serverside you have a valid security context allowing you to authorise users to call given services), then I personally have never been able to get the security callback mechanism to work. Theoretically you can tell the container to call your code at the point which it logs on to the server in order to get the credentials (eg. you can pop up a little login window),

For these reasons, I have never ever used a client container in a production environment. Instead I have repeatedly gone to the trouble of getting the client environment fit so that it can call the server over RMI with a security context. The problem is not only that this is painful, but that it is unsupported by the App Server vendor, and is almost guaranteed to break with the next release of the App Server, requiring further pain from a consultant in order to get be able to migrate to the next App Server version. Additionally, setting the environment for the Initial Context in a client, to connect to the server and find objects in the JNDI tree can be difficult and is often poorly documented (after all, you are meant to do it from inside the client container where you do not need to provide the environment yourself).

However, there is another way! In a previous article, I wrote about how I got an applet to send information back to the server by implementing a custom protocol containing serialised objects. In hindsight I discovered Hessian from Caucho which does a similar thing. Recently I have been looking into Spring which supports Hessian (Custom Binary over HTTP), Burlap (XML over HTTP) and its own kind of remoting, namely Java Serialisation over HTTP.

With little effort I was able to find out how to secure the HTTP connection with the server, meaning that I am now free to write an arbitrary rich client who can call services in a Java EE environment without the use of a Client Container, and without a non-supported RMI environment that is likely to not work after a server version migration. Woo Hoo! How? Easy, keep reading...

First, lets start with a little diagram:

This article won't go into detail about how to create an RCP application or plugin, and will simply call the remote service from a simple Java application. The steps involved in getting to where we are going are:

Add a Datasource to JBoss
Add Security to JBoss (using the datasource, although LDAP would be an option too)
Create a Web Application containing the service implementation
Create a client capable of calling the remote service

1) Add a datasource to JBoss

For this article, JBoss 4.2.2 was used. To add a datasource, create a configuration file:

<JBoss-Home>/server/<instance>/deploy/mysql-ds.xml

where <instance> was "default" in the case of this example. This example uses MySQL 4.1. This configuration file should contain the following:
<?xml version="1.0" encoding="UTF-8"?> <datasources> <local-tx-datasource> <jndi-name>jdbc/MySqlDS</jndi-name> <connection-url>jdbc:mysql://localhost:3306/test</connection-url> <driver-class>com.mysql.jdbc.Driver</driver-class> <user-name>user</user-name> <password>changeit</password> <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter</exception-sorter-class-name> <valid-connection-checker-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLValidConnectionChecker</valid-connection-checker-class-name> <check-valid-connection-sql>select 1</check-valid-connection-sql>  <metadata> <type-mapping>mySQL</type-mapping> </metadata> </local-tx-datasource> </datasources>

A restart of JBoss will make this datasource available in JNDI under the name java:/jdbc/MySqlDS.

2. Add Security to JBoss

Add the following application policy to:

<JBoss-Home>/server/<instance>/conf/login-config.xml

<application-policy name="SpringWeb"> <authentication> <login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule" flag="required"> <module-option name="dsJndiName">java:/jdbc/MySqlDS</module-option> <module-option name="principalsQuery"> select password from users username where username=?</module-option> <module-option name="rolesQuery"> select role, 'Roles' from roles where username=?</module-option> </login-module> </authentication> </application-policy>

Before it can work, you will need to add two tables to the database. The following is some SQL to do that:

create table users( username varchar(64), password varchar(64), primary key (username) ) type = innodb; create table roles( username varchar(64), role varchar(64), foreign key (username) references users(username), index (username) ) type = innodb; insert into users values('admin2', 'admin2'); insert into roles values('admin2', 'registered');

3) Create Web App

To create the web application you need the following files:

web.xml contains:
<?xml version="1.0" encoding="UTF-8"?> <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" id="WebApp_ID" version="2.5"> <display-name>SpringWeb</display-name> <context-param> <param-name>contextConfigLocation</param-name> <param-value>/WEB-INF/applicationContext.xml</param-value> </context-param> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> <servlet> <servlet-name>remoting</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>remoting</servlet-name> <url-pattern>/remoting/*</url-pattern> </servlet-mapping> <security-constraint> <display-name>secure remoting</display-name> <web-resource-collection> <web-resource-name>secure</web-resource-name> <url-pattern>/secure/*</url-pattern> <url-pattern>/remoting/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>registered</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> </login-config> <security-role> <role-name>registered</role-name> </security-role> </web-app>

In the above web.xml, I have configured a Spring ContextLoaderListener which uses the contextConfigLocation parameter to load the Spring configuration. A servlet has also been configured for the URL pattern "remoting" and this URL pattern has also been secured, requiring basic authentication in order to be requested.

remoting-servlet.xml contains:
<?xml version="1.0" encoding="UTF-8" ?> <beans> <bean name="/TestService" class="org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter"> <property name="service" ref="testService"></property> <property name="serviceInterface" value="uk.co.maxant.test.spring.service.TestService"></property> </bean> </beans>

The above remoting-servlet.xml is firstly named after the dispatcher servlet which was defined in web.xml. Secondly, it defines the service exporter and our service that we wish to make remote, namely "TestService". What is missing from the above is the definition of the "testService" bean. That definition is located under the applicationContext.xml:
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans"> <bean id="testService" class="uk.co.maxant.test.spring.service.TestServiceImpl" ></bean> </beans> That bean definition could equally have actually been included in remoting-servlet.xml.
Finally, the jboss-web.xml file contains the link between the security policy that was added to login-config.xml, and the web application:
<?xml version='1.0' encoding='UTF-8' ?> <!DOCTYPE jboss-web PUBLIC "-//JBoss//DTD Web Application 2.3V2//EN" "http://www.jboss.org/j2ee/dtd/jboss-web_3_2.dtd"> <jboss-web> <security-domain>java:/jaas/SpringWeb</security-domain> </jboss-web>

Next, on the web app classpath, we need to have two classes, namely the service interface and its implementation.
package uk.co.maxant.test.spring.service; public interface TestService { public String sayHello(String s) throws Exception; } package uk.co.maxant.test.spring.service; import javax.naming.InitialContext; import uk.co.maxant.test.TestBeanLocal; public class TestServiceImpl implements TestService { public String sayHello(String s) throws Exception { //for example, we could call an EJB here InitialContext ctx = new InitialContext(); TestBeanLocal bean = (TestBeanLocal)ctx.lookup("TestEAR/TestBean/local"); bean.doSomething(); return "hi there " + s; } } The web application now contains everything it needs to go. Restart JBoss and deploy the web application to it.

4) Create Client
All that is now left is to create a client that can call the remote service. Create a project with the following files:

To start with, the applicationContext.xml is a Spring configuration and looks like this:
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans"> <bean id="basicAuthenticationInvokerRequestExecutor" class="uk.co.maxant.spring.remoting.BasicAuthenticationInvokerRequestExecutor" > </bean> <bean id="testService" class="org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean"> <property name="serviceUrl" value="http://localhost:8080/SpringWeb/remoting/TestService" ></property> <property name="serviceInterface" value="uk.co.maxant.test.spring.service.TestService" ></property> <property name="httpInvokerRequestExecutor" ref="basicAuthenticationInvokerRequestExecutor" ></property> </bean> </beans>
In the Spring configuration above, the remote service is defined in terms of its URL and its interface class. The "basicAuthenticationInvokerRequestExecutor" bean simply tells the "HttpInvokerProxyFactoryBean" to use a special InvokerRequestExecutor which is capable of logging into the service. The BasicAuthenticationInvokerRequestExecutor basically comes from a Spring Forum, and is shown in its modified form next:
package uk.co.maxant.spring.remoting; import java.io.ByteArrayOutputStream; import java.io.IOException; import java.net.URI; import java.net.URISyntaxException; import java.util.ArrayList; import java.util.List; import org.apache.commons.httpclient.Credentials; import org.apache.commons.httpclient.HttpClient; import org.apache.commons.httpclient.UsernamePasswordCredentials; import org.apache.commons.httpclient.auth.AuthPolicy; import org.springframework.remoting.httpinvoker.CommonsHttpInvokerRequestExecutor; import org.springframework.remoting.httpinvoker.HttpInvokerClientConfiguration; import org.springframework.remoting.support.RemoteInvocationResult; public class BasicAuthenticationInvokerRequestExecutor extends CommonsHttpInvokerRequestExecutor { private String username; private String password; private boolean httpClientStateSet = false; public void setUsername(String username) { this.username = username; this.httpClientStateSet = false; } public synchronized void setPassword(String password) { this.password = password; this.httpClientStateSet = false; } protected RemoteInvocationResult doExecuteRequest( final HttpInvokerClientConfiguration config, final ByteArrayOutputStream baos) throws IOException, ClassNotFoundException { synchronized (this) { if (!this.httpClientStateSet) { final HttpClient client = getHttpClient(); final URI uri; try { uri = new URI(config.getServiceUrl()); } catch (URISyntaxException e) { final IOException ioe = new IOException(); ioe.initCause(e); throw ioe; } if (username != null && password != null) { Credentials defaultcreds = new UsernamePasswordCredentials( username, password); //the URI created above, could be used to fill //in the port and host, but its not actually required. client.getState().setCredentials(null, null, defaultcreds); //This is to make HttpClient pick the Basic authentication //scheme over NTLM & Digest List<String> authPrefs = new ArrayList<String>(3); authPrefs.add(AuthPolicy.BASIC); authPrefs.add(AuthPolicy.NTLM); authPrefs.add(AuthPolicy.DIGEST); client.getParams().setParameter( AuthPolicy.AUTH_SCHEME_PRIORITY, authPrefs); client.getParams().setAuthenticationPreemptive(true); } else { throw new NullPointerException( "Username and Password cannot be null"); } this.httpClientStateSet = true; } } return super.doExecuteRequest(config, baos); } }
This class uses the Apache Commons HttpClient to use basic authentication when it logs into the web application when it calls the remote service.

Finally, the code which calls the remote service:
package uk.co.maxant.test.spring.remoting.client; import org.springframework.context.ApplicationContext; import org.springframework.context.support.ClassPathXmlApplicationContext; import uk.co.maxant.spring.remoting.BasicAuthenticationInvokerRequestExecutor; import uk.co.maxant.test.spring.service.TestService; public class RemoteClient { public static void main(String[] args) throws Throwable { ApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml"); Object obj = context.getBean("basicAuthenticationInvokerRequestExecutor"); BasicAuthenticationInvokerRequestExecutor executor = (BasicAuthenticationInvokerRequestExecutor)obj; executor.setUsername("admin2"); executor.setPassword("admin2"); obj = context.getBean("testService"); TestService service = (TestService)obj; String s = null; int NUM_CALLS = 100; long start = System.nanoTime(); for(int i = 0; i < NUM_CALLS; i++){ s = service.sayHello("Remote client"); } System.out.println("Remote service says: " + s + " (called on average in " + ((System.nanoTime()-start)/1000000.0/NUM_CALLS) + "ms)."); } } On thing missing in the above description, is that the client needs a reference to the service interface. In this example, built in Eclipse 3.4, the client project simply has a reference to the web application project containing the service interface. In reality you would want to have this interface in a client library which both the web application and the client can refer to.

Now everything is in place to call services on a remote server from a client, securely, and independently of application server Client Container. I chose to use Spring HTTP Remoting with standard Java serialisation (as opposed to Hessian or Burlap, which have their own problems due to restrictive serialisation), which locks the client and server to compatible Java versions. However, Java serialisation has not changed much in a while and I have successfully tested a client running in Sun Java 1.3, calling a Sun Java 1.6 server!

That is the end of this article, I hope it works for you, and gives you an insight into how to securely call services in a Java EE application server without the need to use the client container. Good Luck!

Social Bookmarks :