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

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

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

 

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

How to submit task

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

 

Never commit directly to master branch.