JBOSS: Deploying data sources

Let application server
manage your database connections using a data source. The application server can then manage the database connections by pooling them and by providing connections to the application when it needs them.

 

Deploy, a *-ds.xml file. You can use any name for the file that you like, as long at the suffix is –ds.xml.

 

The <local-tx-datasource>
tag defines a particular type of data source that handles local transactions. Three different data source types are available, each of which handles transactions differently.

 

<local-tx-datasource> : Identifies a data source that uses transactions, even distributed transactions within the local application server, but doesn’t use distributed transactions among multiple application servers.

 

<xa-datasource>:
Identifies a data source that uses distributed transaction among multiple application servers. This option isn’t shown in the example, but would appear in place of the <local-tx-datasource> tag.

 

<no-tx-datasource>: Identifies a data source that doesn’t use transactions.

 

In most cases, you’ll use <local-tx-datasource>
because it handles transactions within a single application server. If you’re clustering your application servers or wanting to use distributed transactions among multiple application servers, then you should use <xa-datasource>.

 

Note that both <local-tx-datasource>
and <xa-datasource> handle distributed transactions involving multiple data sources.

 

The difference is that <local-tx-datasource> handles them only within a single running application server, whereas <xa-datasource> handles them among many running application servers.

 

On the other end of the spectrum, if your applications only read from the database,

Then using <no-tx-datasource>
would be appropriate.

 

<jndi-name> : Name used to look up the data source in the JNDI namespace. The java: prefix is automatically added to this name.

 

<min-pool-size>

<max-pool-size>

<idle-timeout-minutes>

<blocking-timeout-millis>

<exception-sorter-class-name>

<check-valid-connection-sql>

<transaction-isolation>

 

You can define multiple data sources within a single *-ds.xml file

 

The *-ds.xml file goes into the deploy directory. Yes, that’s right; it’s treated as an application, specifically as a service. Second, you must provide the JAR file for the JDBC driver for the database. Place the driver JAR file in the server/xxx/lib directory.

 

Once the data source is deployed, the application server creates several MBeans for the data source

 

You can also place the *-ds.xml file in the EAR file

Data Source configuration for JBOSS

Data Source configuration for JBOSS

1. In web.xml (\WEB-INF\web.xml) add the following

<resource-ref>

<description>

Resource reference to a factory for java.sql.Connection

instances that may be used for talking to the database

that is configured in server.xml in TOMCAT.

For JBOSS- jboss-web.xml and *-ds.xml

</description>

<res-ref-name>jdbc/SampleDB</res-ref-name>

<res-type>javax.sql.DataSource</res-type>

<res-auth>Container</res-auth>

</resource-ref>

1. In jboss-web.xml (\WEB-INF\ jboss-web.xml) add the following

<resource-ref>

<res-ref-name>jdbc/SampleDB</res-ref-name>

<jndi-name>java:/jdbc/SampleDS</jndi-name>

</resource-ref>

(res-ref-name in web.xml and jboss-web.xml should be the same)

(jdbc/SampleDS should match with jndi in *-ds.xml)

1. Add the following msssql-ds.xml (at server\default\deploy)

   <datasources>

   <local-tx-datasource>

   <jndi-name>jdbc/SampleDS</jndi-name>

   <connection-url>jdbc:jtds:sqlserver://localhost:1433/sampleDB</connection-url>

   <driver-class>net.sourceforge.jtds.jdbc.Driver</driver-class>

   <user-name>sa</user-name>

   <password>dev123456</password>

   <check-valid-connection-sql>SELECT 1 FROM sysobjects</check-valid-connection-sql>

   <metadata>

        <type-mapping>MS SQLSERVER2005</type-mapping>

   </metadata>

   </local-tx-datasource>

   </datasources>

2. Add the required jar files in \server\default\lib FOLDER

Cheers!

Spring: AOP

Aspects are often described in terms of advice, pointcuts, and joinpoints.

Advice: the job of an aspect is called advice; Advice defines both what and the when of an aspect describing the job that an aspect will perform, advice addresses the question of when to perform the job. Before a method or after the method is invoked.

Joinpoint: A joinpoint is a point in the execution of the application where an aspect can be plugged in. This point could be a method being called, an exception being thrown, or even a field being modified. These are the points where your aspect’s code can be inserted into the normal flow of your application to add new behavior.

Pointcut: pointcuts define the where. A pointcut definition matches one or more joinpoints at which advice should be woven

Aspect: An aspect is the merger of advice and pointcuts

SPRING: AOP:Advice

Any functionality that exists in an application, but cannot be added in a desirable way is called a cross-cutting concern.

That cross-cutting concern is called aspect-oriented programming (AOP). It deals with the functionality in applications that cannot be efficiently implemented with pure object-oriented techniques.

One of the core features of AOP frameworks is implementing cross-cutting concerns once and reusing them in different places and in different applications. In AOP jargon, the implementation of a cross-cutting concern is called an advice.

AOP frameworks allow you to define which advice is applied to which methods

 

ADVICE

Spring AOP supports four advice types that each represents a specific scenario for advice implementations:

Around advice: Controls the execution of a join point. This type is ideal for advice that needs to control the execution of the method on the target object.

Before advice: Is executed before the execution of a join point. This type is ideal for advice that needs to performan action before the execution of the method on the target object.

After advice: Is executed after the execution of a join point. This type is ideal for advice that needs to perform an action after the execution of the method on the target object.

Throws advice: Is executed after the execution of a join point if an exception is thrown. This type is ideal for advice that needs to performan action when the execution of the method on the target object has thrown an exception.

BeanFactory

It is an implementation of the “Factory Design Pattern”; It is a class whose responsibility is to CREATE and DISPENSE beans. A bean factory is a general-purpose factory, creating and dispensing many types of beans. It is also able to create associations between collaborating objects as they are instantiated. A bean factory also takes part in the lifecycle of a bean, making calls to custom initialization and destruction methods, if those methods are defined.

There are many implementations of BeanFactory in Spring.

org.springframework.beans.factory.xml.XmlBeanFactory It loads its beans based on the definitions contained in an XML file

BeanFactory factory = new XmlBeanFactory(new FileSystemResource(“beans.xml“));

JBOSS: Encrypting web communication

Enabling HTTPS

To handle HTTPS requests, you must do the following:

 

■ Create or obtain a certificate for your server.

■ Make sure that certificate is in a keystore.

■ Define a secure HTTP connector.

■ Point the connector to your keystore

 

In order to enable HTTPS in JBoss Web Server, you have to obtain or create a keystore with a certificate for your server

 

After creating the keystore with a certificate in it, you must set up a connector in JBoss Web Server to listen for the SSL traffic.

 

A secure HTTP connector that points to keystore

<Connector port=”8443″

…

scheme=”https”

secure=”true”

clientAuth=”false”

keystoreFile=”${jboss.server.home.dir}/conf/server.keystore”

keystorePass=”serverpass”

sslProtocol = “TLS” />

 

After enabling this connector, clients can access your secure server using their web browsers.

 

Enabling transport guarantees

If you want an application to only be accessed securely? Java EE defines a mechanism called a transport guarantee
that allows you to specify this.

 

The transport guarantee is defined in the security-constraint
element in your application’s standard web deployment descriptor, WEB-INF/web.xml.

 

If a transport guarantee is enabled and a user tries to access your application through an insecure connector, the connector forwards the request to the port specified by the redirectPort
attribute

 

The transport guarantee itself is defined in the security-constraint block in

your application’s WEB-INF/web.xml file, as follows:

<security-constraint>

…

<user-data-constraint>

<transport-guarantee>

CONFIDENTIAL

</transport-guarantee>

</user-data-constraint>

</security-constraint>

The value of the transport-guarantee
element can be one of three options: CONFIDENTIAL,

INTEGRAL, and NONE.

 

A setting of CONFIDENTIAL
specifies that the application requires that data be transmitted to prevent other entities from observing the contents of the transmission.

 

A setting of INTEGRAL
means that the data sent between a client and the server can’t be changed in transit. As far as JBoss Web Server is concerned, if the transport guarantee is set to CONFIDENTIAL
or INTEGRAL, insecure requests for the URLs defined in the security-constraint block get redirected to the secure connector (using SSL).

Setting the transport guarantee to NONE
is the equivalent of not setting the transport guarantee at all.

 

 

Spring: Security Basics

Spring Security is a security framework that provides declarative security for your Spring-based applications. It provides handling authentication and authorization, at both the web request level and at the method invocation level.

For securing web applications, Spring Security uses servlet filters that intercept servlet requests to perform authentication and enforce security. When securing methods, Spring Security uses Spring AOP to proxy objects, applying aspects that ensure that the user has proper authority to invoke the secured methods.

Security Interceptors:

The actual implementation of a security interceptor will depend on what resource is being secured. If you’re securing a URL in a web application, the security interceptor will be implemented as a servlet filter. But if you’re securing a method invocation, aspects will be used to enforce security. It does not actually apply security rules. Instead, it delegates that responsibility to the various managers.

• Authentication managers
• Access decisions managers
• Run-as managers
• After-invocation managers

Authentication managers:

The authentication manager is responsible for determining who you are. It does this by considering your principal (username) and your credentials (password). The authentication manager is a pluggable interface-based component. This makes it possible to use Spring Security with virtually any authentication mechanism you can imagine. Spring Security comes with authentication managers.

Access decisions managers:

The access decision manager performs authorization, deciding whether to let you in by considering your authentication information and the security attributes that have been associated with the secured resource. The access decision manager is also pluggable.

Run-as managers:

A run-as manager can be used to replace your authentication with an authentication that allows you access to the secured objects that are deeper in your application. Run-as managers are an optional security component and are not necessary in many applications secured by Spring Security.

After-invocation managers:

The after-invocation manager enforces security after the secured resource is accessed. The after-invocation manager also has the option of altering the returned value to ensure that the user is only able to access certain properties of the returned object. Applications only need an after-invocation manager if the application’s security scheme requires that access be restricted at the domain level on a per-instance basis.