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.