Spring Framework Overview

Spring makes it easy to create Java enterprise applications. It provides everything you need to embrace the Java language in an enterprise environment, with support for Groovy and Kotlin as alternative languages on the JVM, and with the flexibility to create many kinds of architectures depending on an application’s needs. Spring supports a wide range of application scenarios. Spring is open source. It has a large and active community that provides continuous feedback based on a diverse range of real-world use cases. The Spring Framework is divided into modules. Applications can choose which modules they need. At the heart are the modules of the core container, including a configuration model and a dependency injection mechanism. Beyond that, the Spring Framework provides foundational support for different application architectures, including messaging, transactional data and persistence, and web. It also includes the Servlet-based Spring MVC web framework and, in parallel, the Spring WebFlux reactive web framework. Spring came into being in 2003 as a response to the complexity of the early J2EE specifications. While some consider Java EE and Spring to be in competition, Spring is, in fact, complementary to Java EE. The Spring programming model does not embrace the Java EE platform specification; rather, it integrates with carefully selected individual specifications from the EE umbrella The Spring Framework also supports the Dependency Injection (JSR 330) and Common Annotations (JSR 250) specifications, which application developers may choose to use instead of the Spring-specific mechanisms provided by the Spring Framework.

01 Spring Overview from Jasdhir Singh

Overview of Scrum

Scrum is one of the most popular Agile methodologies. It is an adaptive, iterative, fast, flexible, and effective methodology designed to deliver significant value quickly and throughout a project. Scrum ensures transparency in communication and creates an environment of collective accountability and continuous progress. The Scrum framework,  is structured in such a way that it supports product and service development in all types of industries and in any type of project, irrespective of its complexity.

The key strength of Scrum lies in its use of cross-functional, self-organized, and empowered teams who divide their work into short, concentrated work cycles called Sprints

The Scrum cycle begins with a Stakeholder Meeting, during which the Project Vision is created. The Product Owner then develops a Prioritized Product Backlog which contains a prioritized list of business and project requirements written in the form of User Stories. Each Sprint begins with a Sprint Planning Meeting during which high priority User Stories are considered for inclusion in the Sprint. A Sprint generally lasts between one and six weeks and involves the Scrum Team working to create potentially shippable Deliverables or product increments. During the Sprint, short, highly focused Daily Standup Meetings are conducted where team members discuss daily progress. Toward the end of the Sprint, a Sprint Review Meeting is held during which the Product Owner and relevant stakeholders are provided a demonstration of the Deliverables. The Product Owner accepts the  Deliverables only if they meet the predefined Acceptance Criteria. The Sprint cycle ends with a Retrospect Sprint Meeting where the team discusses ways to improve processes and performance as they move forward into the subsequent Sprint.

Some of the key benefits of using Scrum in any project are:

• Adaptability—Empirical process control and iterative delivery make projects adaptable and open to incorporating change.
• Transparency—All information radiators like a Scrumboard and Sprint Burndown Chart are shared, leading to an open work environment.
• Continuous Feedback—Continuous feedback is provided through the Conduct Daily   Standup, and Demonstrate and Validate Sprint processes.
• Continuous Improvement—The deliverables are improved progressively Sprint by Sprint, through the Groom Prioritized Product Backlog process.
• Continuous Delivery of Value—Iterative processes enable the continuous delivery of value through the Ship Deliverables process as frequently as the customer requires.
• Sustainable Pace—Scrum processes are designed such that the people involved can work at a sustainable pace that they can, in theory, continue indefinitely.
• Early Delivery of High Value—The Create Prioritized Product Backlog process ensures that the highest value requirements of the customer are satisfied first.
• Efficient Development Process—Time-boxing and minimizing non-essential work leads to higher efficiency levels.
• Motivation—The Conduct Daily Standup and Retrospect Sprint processes lead to greater levels of motivation among employees.
• Faster Problem Resolution—Collaboration and colocation of cross-functional teams lead to faster problem solving.
• Effective Deliverables—The Create Prioritized Product Backlog process and regular reviews after creating deliverables ensures effective deliverables to the customer.
• Customer Centric—Emphasis on business value and having a collaborative approach to stakeholders ensures a customer-oriented framework.
• High Trust Environment—Conduct Daily Standup and Retrospect Sprint processes promote transparency and collaboration, leading to a high trust work environment ensuring low friction among employees.  
• Collective Ownership—The Approve, Estimate, and Commit User Stories process allows team members to take ownership of the project and their work leading to better quality.
• High Velocity—A collaborative framework enables highly skilled cross-functional teams to achieve their full potential and high velocity.
• Innovative Environment—The Retrospect Sprint and Retrospect Project processes create an environment of introspection, learning, and adaptability leading to an innovative and creative work environment.

Securing RESTful Web Services

Securing RESTful Web Services

This post describes how to secure Web services that conform to the Representational State Transfer (REST) architectural style using Java API for RESTful Web Services (JAX-RS).

We can secure the RESTful Web services using one of the following methods

• Updating the web.xml deployment descriptor to define security configuration.
• Using the javax.ws.rs.core.SecurityContext  interface to implement security programmatically.
• Applying annotations to your JAX-RS classes. 

Securing RESTful Web Services Using web.xml

We secure RESTful Web services using the web.xml deployment descriptor as we would for other Java EE Web applications.

To secure your RESTful Web service using basic authentication, perform the following steps:

1. Define a <security-constraint> for each set of RESTful resources (URIs) that you plan to protect.
2. Use the <login-config> element to define the type of authentication you want to use and the security realm to which the security constraints will be applied. 
3. Define one or more security roles using the <security-role> tag and map them to the security constraints defined in step 1. 
4. To enable encryption, add the <user-data-constraint> element and set the <transport-guarantee> subelement to CONFIDENTIAL 

<web-app>     <servlet>         <servlet-name>RestfulServlet</servlet-name>         <servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>     </servlet>     <servlet-mapping>         <servlet-name>RestfulServlet</servlet-name>         <url-pattern>/*</url-pattern>     </servlet-mapping>     <security-constraint>          <web-resource-collection>              <web-resource-name>Employees</web-resource-name>              <url-pattern>/employees</url-pattern>              <http-method>GET</http-method>              <http-method>POST</http-method>          </web-resource-collection>          <auth-constraint>              <role-name>admin</role-name>          </auth-constraint>     </security-constraint>         <login-config>             <auth-method>BASIC</auth-method>             <realm-name>default</realm-name>         </login-config>     <security-role>         <role-name>admin</role-name>     </security-role> </web-app>

Securing RESTful Web Services Using SecurityContext

The javax.ws.rs.core.SecurityContext  interface provides access to security-related information for a request. The SecurityContext provides functionality similar to javax.servlet.http.HttpServletRequest, enabling you to access the following security-related  information:

1. java.security.Principal object containing the name of the user making the request.
2. Authentication type used to secure the resource, such as BASIC_AUTH, FORM_AUTH, and CLIENT_CERT_AUTH.
3. Whether the authenticated user is included in a particular role.
4. Whether the request was made using a secure channel, such as HTTPS.

You access the SecurityContext  by injecting an instance into a class field, setter method, or method parameter using the javax.ws.rs.core.Context annotation.

package com.rest.helloworld; import javax.ws.rs.GET; import javax.ws.rs.Path; import javax.ws.rs.Produces; import javax.ws.rs.core.SecurityContext; import javax.ws.rs.core.Context; ... @Path("/stateless") @Stateless(name = "JaxRSStatelessEJB") public class MyApp { ...         @GET         @Produces("text/plain;charset=UTF-8")         @Path("/hello")         public String sayHello(@Context SecurityContext sc) {                 if (sc.isUserInRole("admin"))  return "Hello World!";                 throw new SecurityException("User is unauthorized.");         }

Securing RESTful Web Services Using Annotations

The javax.annotation.security  package provides annotations, defined below, that you can use to secure your RESTful Web services.

Restful Annotations

package com.rest.helloworld; import javax.ws.rs.GET; import javax.ws.rs.Path; import javax.ws.rs.Produces; import javax.annotation.Security.RolesAllowed; @Path("/helloworld") @RolesAllowed({"ADMIN", "ORG1"}) public class helloWorld {    @GET    @Path("sayHello")     @Produces("text/plain")    @RolesAllows("ADMIN")    public String sayHello() {       return "Hello World!";    } }

Other Modifiers for Members in Java

Other Modifiers for Members in Java

Certain characteristics of fields and/or methods can be specified in their declarations by the following keywords:

static Members: The declaration of static members is prefixed by the keyword static to distinguish them from instance members.

Static variables (also called class variables) only exist in the class they are defined in. They are not instantiated when an instance of the class is created. In other words, the values of these variables are not a part of the state of any object.

Static methods are also known as class methods. A static method in a class can directly access other static members in the class. It cannot access instance (i.e., non-static) members of the class, as there is no notion of an object associated with a static method.

final Members: A final variable is a constant, despite being called a variable. Its value cannot be changed once it has been initialized. This applies to instance, static and local variables, including parameters that are declared final.

A final variable of a primitive data type cannot change its value once it has been initialized.

A final variable of a reference type cannot change its reference value once it has been initialized, but the state of the object it denotes can still be changed.

A final method in a class is complete (i.e., has an implementation) and cannot be overridden in any subclass. Subclasses are then restricted in changing the behavior of the method.

abstract Methods: An abstract method does not have an implementation; that is, no method body is defined for an abstract method, only the method prototype is provided in the class definition. Its class is then abstract (i.e., incomplete) and must be explicitly declared as such. Subclasses of an abstract class must then provide the method implementation; otherwise, they are also abstract.

synchronized Methods: Several threads can be executing in a program. They might try to execute several methods on the same object simultaneously. If it is desired that only one thread at a time can execute a method in the object, the methods can be declared synchronized. Their execution is then mutually exclusive among all threads. At any given time, at the most one thread can be executing a synchronized method on an object. This discussion also applies to static synchronized methods of a class.

native Methods:Native methods are also called foreign methods. Their implementation is not defined in Java but in another programming language, for example, C or C++. Such a method can be declared as a member in a Java class definition. Since its implementation appears elsewhere, only the method prototype is specified in the class definition. The method prototype is prefixed with the keyword native. 

transient Fields: Objects can be stored using serialization. Serialization transforms objects into an output format that is conducive for storing objects. Objects can later be retrieved in the same state as when they were serialized, meaning that all fields included in the serialization will have the same values as at the time of serialization. Such objects are said to be persistent.

A field can be specified as transient in the class declaration, indicating that its value should not be saved when objects of the class are written to persistent storage.

volatile Fields: During execution, compiled code might cache the values of fields for efficiency reasons. Since multiple threads can access the same field, it is vital that caching is not allowed to cause inconsistencies when reading and writing the value in the field. The volatile modifier can be used to inform the compiler that it should not attempt to perform optimizations on the field, which could cause unpredictable results when the field is accessed by multiple threads.

Member Accessibility Modifiers in Java

Member Accessibility Modifiers in Java

By specifying member accessibility modifiers, a class can control what information is accessible to clients (i.e., other classes). These modifiers help a class to define a contract so that clients know exactly what services are offered by the class.

Accessibility of members can be one of the following:

• public
• protected
• default (also called package accessibility)
• private

A member has package or default accessibility when no accessibility modifier is specified. The member accessibility modifier only has meaning if the class (or one of its sub classes) is accessible to the client. Also, note that only one accessibility modifier can be specified for a member.

public Members: Public accessibility is the least restrictive of all the accessibility modifiers. A public member is accessible from anywhere, both in the package containing its class and in other packages where this class is visible. This is true for both instance and static members.(eg SuperclassA, SubclassB)

protected Members: A protected member is accessible in all classes in the package containing its class, and by all subclasses of its class in any package where this class is visible. In other words, non-subclasses in other packages cannot access protected members from other packages. It is less restrictive than the default accessibility(eg SuperclassA1, SubclassB1).

Default Accessibility for Members: When no member accessibility modifier is specified, the member is only accessible by other classes in its class's package. Even if its class is visible in another (possibly nested) package, the member is not accessible there. Default member accessibility is more restrictive than protected member accessibility.(eg SuperclassA2, SubclassB2)

private Members: This is the most restrictive of all the accessibility modifiers. Private members are not accessible from any other class. This also applies to subclasses, whether they are in the same package or not. Since they are not accessible by simple name in a subclass, they are also not inherited by the subclass. (eg SuperclassA3)