JavaEE workshop #2

Kuba Hejda

(Java EE, Spring, Json, REST, ...)

Agenda

JavaEE
Dependency injection
Spring core
N-tier architecture
JSON
REST
Design patterns + Singleton pattern
Connect JIRA with IDE
How to submit task

JavaEE

26 specifications

INVERSION OF CONTROL

Inversion of control (IoC) is a programming technique in which object coupling is bound at run time by an assembler object and is typically not known at compile time using static analysis. In order for the assembler to bind objects to one another, the objects must possess compatible abstractions.
is a concept in application development
"don’t call me, I’ll call you"
one form is Dependency Injection (DI)

Inversion of control and DI explanation

Inversion of control

INVERSION OF CONTROL

The Spring container is at the core of the Spring Framework.
The Spring container uses dependency injection (DI) to manage the components that make up an application.
The container will create the objects, wire them together, configure them, and manage their complete lifecycle from creation till destruction.
The container gets its instructions on what objects to instantiate, configure, and assemble by reading configuration metadata provided. The configuration metadata can be represented either by
- XML,
- Java annotations,
- or Java code.

Spring framework

popular application development framework for enterprise Java
first release October 2002
current version 5.2.6.RELEASE
Features
- Dependency Injection
- Aspect-Oriented Programming including Spring's declarative transaction management
- Spring MVC web application and RESTful web service framework
- Foundational support for JDBC, JPA, JMS
- Much more…

Spring framework

DEPENDENCY INJECTION CONTAINERS

Spring BeanFactory Container

This is the simplest container providing basic support for DI. There are a number of implementations of the BeanFactory interface that come supplied straight out-of-the-box with Spring.

Spring ApplicationContext Container

The ApplicationContext includes all functionality of the BeanFactory, it is generally recommended over the BeanFactory. It adds more enterprise-specific functionality such as the ability to resolve textual messages from a properties file and the ability to publish application events to interested event listeners.

Beans

The objects that form the backbone of your application and that are managed by the Spring IoC container are called beans.

A bean is an object that is instantiated, assembled, and otherwise managed by a Spring IoC container. These beans are created with the configuration metadata that you supply to the container, for example, in the form of XML <bean/> definitions, in class form @Bean annotation, which you have already seen in previous chapters.

BEANS - DEFINITION

The bean definition contains the information called configuration metadata which is needed for the container to know the followings:
How to create a bean
Bean's lifecycle details
Bean's dependencies

JAVA BASED CONFIGURATION

Java based configuration option enables you to write most of your Spring configuration without XML but with the help of few Java-based annotations explained below.

Annotating a class with the @Configuration indicates that the class can be used by the Spring IoC container as a source of bean definitions.

The @Bean annotation tells Spring that a method annotated with @Bean will return an object that should be registered as a bean in the Spring application context.

ANNOTATION BASED CONFIGURATION

@Component	generic stereotype for any Spring-managed component
@Service	stereotype for service layer
@Repository	stereotype for persistence layer
@Scope	indicates the name of a scope to use for instances of the annotated type.

Class configuration

@Configuration
@Import
@Bean
@ComponentScan
...(spring MVC config, tx config)
Links
- tutorial

Spring boot

easy to create stand-alone, production-grade Spring based Applications
init or start.spring.io

Starters

set of convenient dependency descriptors that you can include in your application
contain a lot of dependencies

Multitier (n-tier) architecture

client-server architecture
Application logic is divided into components according to function
the presentation, the application processing and the data management are logically separate processes
The most widespread use of "multi-tier architecture" refers to three-tier architecture.

Multitier architecture

JSON

JavaScript Object Notation
transport data format
readeable
efficient

{
   "widget":{
      "debug":"on",
      "window":{
         "title":"Sample Konfabulator Widget",
         "name":"main_window",
         "width":500,
         "height":500
      },
      "image":{
         "src":"Images/Sun.png",
         "name":"sun1",
         "hOffset":250,
         "vOffset":250,
         "alignment":"center"
      },
      "text":{
         "data":"Click Here",
         "size":36,
         "style":"bold",
         "name":"text1",
         "hOffset":250,
         "vOffset":100,
         "alignment":"center",
         "onMouseUp":"sun1.opacity = (sun1.opacity / 100) * 90;"
      }
   }
}

HTTP

Hypertext Transfer Protocol
an application request-response protocol for distributed, collaborative, hypermedia information systems
Most used version HTTP 1.1, but since 2015 2.0
Methods: GET, POST, PUT, HEAD, DELETE, OPTIONS, PATCH

POST /test/demo_form.php HTTP/1.1
Host: w3schools.com
name1=value1&name2=value2

REST ( REpresentational State Transfer)

first introduced by Roy Fielding in 2000
style, not a standard
was used to design HTTP
There are 5 Major Concepts
- Resources
- Representations
- Operations
- Hypertext
- Statelessness

REST - resources

Every “thing”, every “resource” gets an identifier:
/game/robots/four-hand-george
The URL is the unified concept of an identifier on the web
- A URI identifies a resource by location, name, or both
- A URL is a subset of URI. It specifies where a resource lives and the mechanism to retrieve it.
- four-hand-george, the robot, is a “thing”, You can retrieve him using HTTP and he is located here: http://obeautifulcode.com/game/robots/four-hand-george
- So an ISBN number is a URI but not a URL (it unambiguously identifies a book, but does not define where or how to retrieve it)
REST says to identify everything that is worth being identified by your clients.
This leads to creation of resources not typically seen in application design. For
example, a process or process step, a sale, a negotiation or a request for quote.
/game/spaceships/upgrades/56789

REST - resources

Collections of things merit identification. They are things themselves:
/game/robots (all robots)
/game/spaceships?visability=invisible (all spaceships that are invisible)
Resources can be static or change over time:
/game/robots/four-hand-george (might always return the same information about a particular robot)
/game/spaceships/upgrades/567 (the status of spaceship upgrade is likely to change over time and the upgrade itself may be deleted after it is complete)
The same resource can be referred to by more than one URI:
/game/robots/four-hand-george
/game/spaceships/987/crew/four-hand-george (george identified as a crew-member of spaceship #987)
/game/robot-factory/output/123 (george identified as the output #123 of the robot factory)
Use the full URI namespace for identity. Don’t identify things using a method (operation) + parameters approach.
For example, this is not really an identifier:
/cgi-bin/getGameObject?type=robot&name=four-hand-george
An identifier should not contain tech implementation details (e.g. cgi-bin). Those may change over time.
Some benefits of URIs in the “identifier” style:
- Highly readable
- Easy to debug
- Easy for clients to construct

REST - operations

It's not about the 50 things you can do with a particular service (which is how SOAP developers
view the world). It's about using a standard set of things you can do (PUT, GET, etc.) with a set of
resources
So how do you FlyShip(id=“ship-123”, destination=Planets.Mars)?
PUT to /ships/ship-123/flightpath and send “destination=mars” in the body of the message
Instead of defining a new operation such as StopFlight(id) to stop the flight, do this:
DELETE /ships/ship-123/flightpaths/456

REST hypertext

HATEOAS
In REST, application state is transferred and discovered within hypertext responses.
A REST client needs less knowledge about how to interact with any particular service compared to
clients that interact with operation-centric services.
A client transitions through application states by selecting from links. So RESTful interaction is
driven by hypermedia, not out-of-band information.

{
  "_links" : {
    "self" : {
      "href" : "http://localhost:8080/persons" 
    },
    ... other links ...
    "profile" : {
      "href" : "http://localhost:8080/profile/persons" 
    }
  },
  ...
}

REST statelessness

Client is responsible for application state. The server is responsible for resource state.
Benefits:
- Client are isolated against changes on the server.
- Promotes redundancy - easy load balancing
- Compatible with reverse proxy in front of the server - Requests for a cached URI can be handled by the proxy instead of the server. Cache is cleared for not safe operation (PUT/...)

REST errors

using HTTP error codes
The status codes are grouped in categories (200 OK and 204 No Content are in the 2xx category which indicates that the action requested by the client was received, understood, accepted and processed successfully.
Clients doesn’t necessarily need to handle each and every individual code.
An error can be augmented with more details about what caused the error simply by including text in the body of the response.

REST links

REST client: Postman

Design patterns

provide solutions to common software design problems
GOF - authors of book

Singleton

restricts the instantiation of a class to one object
default spring bean type
wiki
Java implementation

IDEA shortcut of the day

Alt + Shift + N
Add JIRA server (https://ita2019java.atlassian.net)
Login to Jira -> Account settings -> Security -> Token API (create and manage tokens) -> Create token
Create changelist from issues

How to submit task

IDEA
- find your task
- start working - new change list, new git branch (with name feature/{JIRA_TASK_ID}_short-description)
Implement everything
- one commit
- message format "{JIRA_TASK_ID} - TASK_TITLE - description"
- push to remote brach - same name as local branch
Create Merge request from your remote brach to your master.
After code review and approve (by Kuba), merge to master

Never commit directly to master branch.

ITA 06 - W02

By IT-absolvent

ITA 06 - W02

Workshop #2

IT-absolvent

it-absolvent.cz

JavaEE workshop #2

Agenda

JavaEE

INVERSION OF CONTROL

Inversion of control

INVERSION OF CONTROL

Spring framework

Spring framework

DEPENDENCY INJECTION CONTAINERS

Beans

BEANS - DEFINITION

JAVA BASED CONFIGURATION

ANNOTATION BASED CONFIGURATION

Class configuration

Spring boot

Multitier (n-tier) architecture

Multitier architecture

JSON

HTTP

REST ( REpresentational State Transfer)

REST - resources

REST - resources

REST - operations

REST hypertext

REST statelessness

REST errors

REST links

Design patterns

Singleton

IDEA shortcut of the day

How to submit task

ITA 06 - W02

More from IT-absolvent