March 7, 2015

Java Enterprise Beans Fundamentals

JavaEE Essentials – Enterprise Beans

Components

Session Bean

  • Series of methos encapsulated in a bean
  • Stores only local data
  • Used to execute main bulk of program
  • Associated with single client session
  • Can execute a single or series of transactions
  • State is managed by the EJB container

Stateful

  • Runs i a client bean session
  • Associated with a client state

Stateless

  • Any client can invoke the methods
  • Can keep state that lasts for the duration of the invocation

Singleton

  • Once per application
  • Keeps state for duration of application execution
  • Bean equivalent of global variables
  • Perform startup and cleanup tasks

Entity Bean

  • Associated with a data set not a session
  • Esentially permanent
  • Uniquely identified by a primary key
  • Don’t necessarily require a client

Message Bean

  • Receives JMS messages asynchronously and acts upon them
  • Does not have a client interface
  • Can only respond to single client message
  • Used to handle special events

Programming on a Server

  • Watch out for latency and rw conflicts

Latency

  • Limited communication speed
  • Reduce through workflow balancing

Concurrent access

  • Mutliple requests to shared resources

Session & Entity Objects (Coarse Grained)

  • Interfaces with blocks of data
  • Deals with more complex data

Session objects

  • Created within a specific client session
  • Lasts as long as the client
  • Keeps Conversational State (a connection with one or more clients)
  • Coarse grained

Entity objects

  • Persistent across multiple clients and instantiations
  • Keeps state with a primary key that identifies the bean
  • Client uses key to reconnect to bean if it exists
  • If bean is not available, it can be recreated with the persistent data
  • Coarse grained

Client vs Server side

  • Main difference is program output
    • Server produces data for client
    • Client presents data to user
  • Beans primarily for server programs

Server

  • Work with databases
  • Display pages
  • Validate and handle user input
  • Authentication, verification and monitoring

Client

  • Interface with server
  • Generate dynamic web pages
  • Taking in user input
  • Work with local storage
  • Send/receive requests with server

Bean lifecycle

Stateless Session Bean

Uncreated -> setSessionContext -> Active -> ejbRemove -> Destroyed
ejbCreate

Stateful Session Bean

Uncreated -> setSessionContext -> Active -> ejbPassivate -> Passive
ejbCreate ejbActivate <- Passive -> ejbRemove -> Destroyed

Entity Bean

Uncreated -> setEntity -> Pool -> ejbActivate -> Active
ejbPassivate
create
ejbCreate
ejbPostCreate
Pool <——————— remove
ejbRemove

Message Bean

Uncreated -> setSessionContext -> Active -> ejbRemove -> Destroyed
ejbCreate
-> onMessage -> OnMessage
Active <—————–

Parallellism

  • Most beans don’t use concurrency since they are only accessible by one client at a time
  • Multiple clients -> multiple beans
  • Databases must also handle paralellism
  • Singleton Session Beans must take parallelism into consideration to handle multiple clients
    • Use @Lock(Write) at methods to protect from writing and writing
    • Use @Lock(Read) at methods to protect from duplicate reading
    • Use @AccessTimeout(value=100) to control timeout for concurrent access
    • Use @ConcurrencyManagement(Bean) for bean control
      • “volatile, synchronized” and other mechanisms can also be used

Exclusive Read Exclusive Write (EREW)

  • One CPU can access a memory location at a given time
  • Other CPU’s will be locked out
  • Safe but slow

Concurrent Read Exclusive Write (CREW)

  • Allows multiple reads
  • Only 1 can write
  • Faster the EREW

Concurrent Read Concurrent Write (CRCW)

  • No restrictions on reading and writing
  • No locking algorithm
  • Very fast but requires careful programming

Maximising performance

  • Minimize computations
  • Minimize length of non-parallizable sections
  • Minimize overhead cpu<->cpu communication
  • Find paralellism possibilities, refactor
  • Load balance to keep processors working at all times
  • Minimize communication overhead

Security

Declarative

  • Simple
  • Based on user roles and access methods
  • Uses access levels
  • Can map users to more general roles with lots of users
  • On class: @DeclareRoles(values = {“admin,guest”})
  • On method: @RolesAllowed(value = {“admin”}) (@Deny @Allow)

Programmatic

  • Harder
  • More powerful and easy to make mistakes
  • Methods:
    • Invoked in method
    • SessionContext.getCallerPrinciple()
    • SessionContext.isUserInRole()

Asynchronous methods

  • Apply to method or entire class
  • Methods return void or Future result type
  • Use: @Asynchronous annotation
  • Use: AsyncResult to cast result

Transactions

  • Failures are ok, clients can re-send
  • Much more efficient to allow occasional failures
  • Sometimes necessary to NOT fail or fail in SPECIFIC way
  • Multiple steps trated as single unit of work
  • Use: @TransactionAttribute to mark methods for transactional behaviour
    • required
    • requiresNew
    • mandatory
    • supports
    • notSupported
    • never