Application Servers

1
Application Servers

• Gökçe Banu Laleci

2
aim

• for building integrated, enterprise-class
  applications that share information, deliver
  services, and automate collaboration among
  networked companies at Internet volume and speed
• separate of presentation, business logic, and
  data
• provide the underlying core functionality
  necessary for the development and deployment of
  business-driven application
• connect legacy systems, and Web Services

3
Why?

• applications with complex business logic
• potentially servicing tens of thousands of
  concurrent users in real-time
• require a scalability and reliability
• Distributed system
• Stock trading system
• Banking application

4
What you need?

• RMI
• Load balancing
• Transparent fail over
• Back-end integration
• Transaction
• Clustering
• Dynamic redeployement
• Clean shutdown

• Logging and auditing
• System management
• Threading
• Message-oriented middleware
• Object life cycle
• Resource polling
• Security
• Caching

5
Adds..

• a new layer of functions and services between Web
  servers and underlying applications and databases

6
What do they provide

• speeds application development and relieves
  developers of the effort and expense of creating
  these crucial services on their own
• Load balancing
• Fault tolerance
• Web Services
• Legacy integration
• Transaction management
• Security
• Messaging
• Multi-threading
• Persistence
• Database connectivity
• Resource pooling
• Development, testing, and packaging facilities

7
Single server / clustered servers
8
J2EE based..
9
J2EE based

• BEA WebLogic Java Application Server
• IBM WebSphere Java Application Server
• Oracle 9i Java Application Server
• Sun ONE Java Application Server (iPlanet)
• HP Application Server (HP-AS) (Bluestone)
• JBoss Application Server
• Enhydra Application Server

10
J2EE Components used..

• Java Servlets Java Server Pages (JSP)
• Enterprise Java Beans (EJB)
• Java Transaction API (JTA)
• Java Transaction Service (JTS)
• Java API for XML Parsing (JAXP)
• Java Messaging Service (JMS)
• Message Driven Beans (MDB)
• Remote Method Invocation (RMI)
• Java Database Connection 2 (JDBC2)
• Java Connector Architecture (JCA)
• Java Naming and Directory Interface (JNDI)
• JavaBeans Activation Framework (JAF)

11
Three layered architecture

• The presentation layer
• managing the user interfaces of applications,
  including desktop applications, Web browsers, and
  pervasive devices
• The business layer
• contains the business logic
• The back-end layer
• provides connectivity with enterprise systems
  and databases

12
Three layered architecture
Hosting Organization
Subscriber 1
Subscriber 2
Subscriber 3
13
Presentation Layer

• Thin clients
• such as Web browsers that send HTTP requests and
  receive HTTP responses for static HTML or dynamic
  Web pages built by Java Servlets and Java Server
  Pages (JSPs)
• Thick clients
• such as Java applets and applications, ActiveX
  controls, or Visual Basic clients that run on a
  desktop and communicate with BEA WebLogic Server
  through CORBA, Java RMI,IIOP, or COM

14
Presentation Layer

• Pervasive devices
• including wireless phones, PDAs, smart
  appliances, and other emerging remote clients
  that communicate with the server via specific and
  usually very compact
• can generate WML pages from Servlets and JSPs.
• Web Services
• that connect to the system using Web Services
  technologies, such as SOAP,UDDI, and WSDL

15
Presentation Layer

• Provides a Web Server
• Servlet and JSP results caching and JSP tags
  caching
• provides high-reliability, scalability,
  monitoring, and other features required by
  enterprise applications
• plug-ins for Apache, iPlanet, and Microsoft IIS
  Web servers

16
Additional Features

• Virtual hosting
• www.company1.com and www.company2.com
• Clustering
• scalability and high-availability
• insulates clients from hardware or power failures
  by eliminating single points of failure
• Load balancing
• Incoming requests can be distributed across
  multiple instances of AS

17
Additional Features

• High availability with transparent fail-over
• The data contained in Web components can be
  replicated across multiple machines
• In the event of a failure, current client
  session information is maintained
• disk-based persistence
• in- memory replication of a client s session
  state

18
Business Layer

• contains the applications business logic
  independent of the user interface, including
  distributed components, running in the
  application server environment
• Enterprise Java Beans

19
Enterprise Java Beans

• Reusable server components
• A manageable, discrete chunk of code implementing
  a set of well defined interfaces
• it has to be compliant to a well defined
  interfaces
• To be reusable
• To be able to use the AS functionalities

20
Java Beans vs. EJB

• Generic java component model
• Can be either visible or not
• Local to a single process on the client side
• Uses BeanInfo classes to define themselves

• Standard for building distributed systems
• Non-visible remote objects
• Remotely executable comp. deployed in the server
• Uses Deployment descriptor to describe itself

21
Why EJB

• Architectural independence from middleware
• WORA for sever side components
• Establishes roles for application development
• Take care of transaction management
• Provides distributed transaction support
• Portable
• Integrates seamlessly with CORBA

22
The EJB architecture
23
What do containers provide

• Remote invocation
• Pool and cache services
• Security
• Transaction
• Integration with external data sources

24
Containers

• Interface btw EJBeans outside world
• EJB Clients never access an EJB directly- any
  access is done through container-generated
  methods in turn invoke bean methods

25
Home interface

• Contains factory methods for locating, creating
  and instances of EJBs
• The EJB developer defines the Home Interface for
  his bean
• Object generated by the Container vendor

26
An example
27
Remote Interface EJBObject

• Lists the business methods present in EJB
• Interface defined by the developer
• Object created by the container vendor
• Clients use this object to invoke business methods

28
An example
29
EJB Client

• Finds EJB containers using JNDI
• Uses EJB container to invoke EJB methods
• Uses Home Object to locate, create or destroy and
  EJB class
• Uses the EJBObject instance to invoke methods

30
JNDI

• Client API provides naming directory services
  for Java Apps
• Does not replace DNS, CORBA, RMI etc
• Allows multiple directory services co-exist
• Provides a federated name server

31
An example

• // get the JNDI naming contextContext
  initialCtx new InitialContext ()// use the
  context to lookup the EJB Home interfaceAccountHo
  me home (AccountHome)initialCtx.lookup
  ("com/gopalan/Account")// use the Home
  Interface to create a Session bean objectAccount
  account home.create (1234, "Athul",
  1000671.54d)

32
EJB Types

• Entity Beans
• Session Beans
• Message-Driven Beans

33
Entity Beans

• Used to represent business data in an
  application
• Correspond with information stored in databases
  or other persistent storage
• Have primary key
• Participate in transactions
• Long-lived
• Can survive EJB server clashes
• Multiple clients can access and work with the
  same entity bean
• When not used
• Preserved in persistent location and returned to
  the pool
• When used
• Can be cached

34
Entity Bean Interface

• ejbActivate ()
• ejbLoad ()
• ejbPassivate ()
• ejbRemove ()
• ejbStore ()

35
Persistence

• Container Managed
• Container is responsible for saving state of bean
  
• Container needs to generate DB calls
• Bean persistence is independent of data source
• specify container-managed fields in Deployment
  Descriptor

• Bean Managed
• Bean is itself responsible for saving its own
  state
• Bean needs to code its own DB calls
• Bean persistence is hard-coded and is hence less
  adaptable

36
Session Beans

• Execute on behalf of a single client
• They may or may-not be transaction-aware
• They may or may-not update data in the underlying
  database
• Their lifetime is limited to that of the client
  and hence they are relatively short-lived
• They do not survive server crashes
• They do not represent data in the database
• Since they only represent conversational state
  with a single client, their identity is hidden

37
Stateless/Stateful

• Stateless Session Bean
• Have no internal state
• need not be passivated or activated
  
• Objects can be pooled to service multiple clients

• Stateful Session Bean
• Have internal state
• need to handle Activation/Passivation
• One Session Bean object per client

38
Message-Driven Beans

• Do not have home or remote interface
• Used to integrate with JMS
• Called JMS message consumers
• Listen from a message from JMS server
• Performs a set of actions defined when message is
  received

39
Deployment Descriptors

• While deploying your EJB to container
• Provide a deployment descriptor file (xml)
• JNDI name
• Transactional rules
• Security roles and permissions of a component

40
Additional Features

• Instance pooling
• pre-load a given number of instances and prepare
  them for use, thereby saving time by not having
  to create a new instance for each request
• Clustering
• EJBs can be deployed in a cluster of BEA WebLogic
  Servers
• by means of distributed naming and directory
  facilities

41
Additional Features

• High availability with transparent fail-over
• replicate state that EJB hold across a cluster of
  separate physical AS processes
• creating redundancy in case of
• transparently fail-over to a backup machine in
  the cluster in the event of a failure
• Load balancing
• route requests from remote clients to EJB
  components using a predetermined algorithm or
  custom-algorithm

42
Additional Features

• EJB Caching
• store a configurable number of EJBs in memory to
  save on database access
• In case another instance of the server in the
  cluster updates the same bean, all the cached
  instances of the bean cached in the cluster will
  be invalidated, and reloaded with the next access
• increases performance and reduces the load on the
  database

43
Back-End Layer

• provides access to other enterprise systems
• databases, ERP, CRM, mainframe or other existing
  applications
• Integration layer
• messaging, e-mail, Web Services, and other
  technologies to connect and communicate with
  enterprise systems

44
Databases

• JDBC
• Thin clients servlet, JSP
• Thick clients RMI to remote databases
• most recommended way is to use entity beans and
  benefit from the underlying services
• Connection pooling

45
Integration

• integrating new applications with any legacy
  Enterprise Information System (EIS)
• J2EE Connector Architecture (J2CA)
• CORBA
• integration with legacy systems that implement
  the CORBA specifications
• COM/DCOM (COM)
• bi-directional interoperability with Microsoft s
  COM
• can access data in Microsoft applications,
  communicate with Visual Basic clients

46
JCA

• a standard architecture for connecting the J2EE
  platform to heterogeneous EIS systems
• ERP, mainframe transaction processing, database
  systems, and legacy applications not written in
  the Java programming language
• enables the integration of EISs with application
  servers and enterprise applications
• By defining a a set of scalable, secure, and
  transactional mechanisms

47
JCA

• enables an EIS vendor to provide a standard
  resource adapter for its EIS
• The resource adapter plugs into an application
  server, providing connectivity between the EIS,
  the application server, and the enterprise
  application
• An EIS vendor needs to provide just one standard
  resource adapter which has the capability to plug
  in to any application server that supports the
  J2EE Connector architecture

48
JCA

• Multiple resource adapters are pluggable into an
  application server
• enables application components deployed on the
  application server to access the underlying EIS
  systems

49
JCA
50
Resource Adapter

• To achieve a standard system-level pluggability
  between application servers and EISs, the J2EE
  Connector architecture defines a standard set of
  system-level contracts between an application
  server and EIS
• The resource adapter implements the EIS-side of
  these system-level contracts

51
Resource Adapter

• system-level software driver used by an
  application server or an application client to
  connect to an EIS
• By plugging into an application server, the
  resource adapter collaborates with the server to
  provide the underlying mechanisms, the
  transactions, security, and connection pooling
  mechanisms
• A resource adapter is used within the address
  space of the application server

52
Application Contract

• An application server and an EIS collaborate to
  keep all system-level mechanisms, such as
  transactions, security, and connection
  management, transparent from the application
  components
• A Connection Management contract
• A Transaction Management contract
• Security contract
• A Message Inflow contract
• A Lifecycle Management contract
• A Work Management contract

53
Web Service Support

• Automatically wraps the business components in to
  Web services
• Support for WSDL and UDDI
• Publish, search, host
• Support for Web Services Security standard
• Reliable SOAP implementation
• based on a sequence of asynchronous SOAP
  communications, receipts, and notifications
• guaranteed delivery, exactly-once delivery,
  ordered conversation
• A set of convenient graphical tools for
  development, search, and composing of the Web
  Services
• BEA WebLogic Workshop

54
Messaging

• Asynchronous method invocations
• Why?
• Performance
• Reliability
• Support for multiple senders and receivers

Message Oriented Middleware
Application
Application
55
MOM

• Provides
• Guaranteed message delivery
• Fault tolerance
• Load balancing of destinations
• Subscription mech.
• Proprietary solutions
• Tibco Rendezvous
• IBM MQSeries
• BEA Tuxedo/Q
• Microsoft MSMQ

56
Java Message Service

• API
• Write code to send and receive msg
• Service Provider Interface (SPI)
• Plug in JMS drivers
• to allow existing companies to JMS-enable their
  applications without impacting client-side
  development
• Supports
• Publish/subscribe
• Point-to-point

57
JMS System

• ConnectionFactory
• Connection
• Session
• Destination
• MessageProducer
• MessageConsumer
• Message

58
JMS Connection Factory
2Create Connection
3Create Session
JMS Connection
Serialized Message Connection
Client
JMS Session
5Create Producer or Consumer
JMS Producer Or JMS Consumer
6Send or Receive Message
1RetrieveJMS Driver Connection Factory
4Lookuo JMS Destination
JMS Driver Client Runtime
JNDI
Naming Service
59
Example

• try
• queueConnectionFactory (QueueConnectionFactory)
• jndiContext.lookup("QueueConnectionFactory")
• queue (Queue)jndiContext.lookup(queueName)
• try
• queueConnection
• queueConnectionFactory.createQueueConnection()
• queueSession queueConnection.createQueueSession
  (false, Session.AUTO_ACKNOWLEDGE)
• queueSender queueSession.createSender(queue)
• message queueSession.createTextMessage()
• for (int i 0i ltNUM_MSGSi)
• message.setText("This is message "(i 1))
• System.out.println("Sending message"
  message.getText())
• queueSender.send(message)

60
EJB JMS Integration

• Message Driven Beans
• Do not have home/remote interface
• Just to consume messages
• Not a component interface
• onMessage method
• Why not use existing beans
• Threading
• Life cycle management

61
Security

• Java Authentication and Authorization Server
  (JAAS)
• Encryption
• Auditing
• HTTPS,
• basic HTTP authentication with Base64 encoding
  for services protected by firewalls
• Role based security
• User and group definition
• Built-in security data store retains the
  role,profile,and entitlement data,and is built on
  a highly optimized LDAP directory
• Single Sign-On
• WS-Security

62
Adding security to EJB

• JAAS
• Portable interface
• Java applications to remain independent from
  underlying authentication technologies
• Authentication
• Basic
• Digest
• Certificate

63
Authorization

• Programmatic
• Hard code security checks in to your bean code
• Declarative
• Through deployment descriptor
• Container handles the rest

64
Role based

• Each user must be uniquely identified
• User should be assigned one or more security
  roles
• Each security role is assigned a set of method
  permissions

65
Example role definition
66
Example method permission
67
Transaction

• A series of operations that appear to execute as
  one large atomic operation
• All-or-nothing
• Allow multiple users to share the same data
• ACID
• Atomicity
• Many operations are bundled together and appear
  as one atomic unit

68
ACID

• Consistency
• A transaction leaves the system in a consistent
  state
• Isolation
• Protects concurrently executing transactions from
  seeing each others incomplete results
• Durability
• Guarantees that updates to managed resources,
  such as database records, survive failures

69
Transaction

• Type
• Flat
• Nested
• Rollback is not an undo logic
• Resource managers are transaction aware
• They do no not make the changes persistent until
  a commit statement issued

70
EJB and transactions

• EJB never interact with a transaction manager or
  a resource manager
• The container handles all the low-level things
• Demarcating transactional boundries
• Programmatically
• Declaratively
• Client-initiated

71
Programmatic Transactions

• Put the transaction logic in to your application
  code
• The programmer is responsible for issuing
• begin, commit and abort

Client Code
EJB Container
1call method
2delegate
EJB object
3call begin
Transaction Service
EJB
5call commit or abort
4perform business operations
72
Declarative Transactions

• EJB container handles
• Declare in deployment descriptor

73
Declarative Transactions
Client Code
EJB Container
3call begin
Transaction Service
1call method
EJB object
5call commit or abort
2delegate
EJB
4perform business operations
74
Client Initiated Transactions
EJB Container
3call begin
Client Code
Transaction Service
5call commit or abort
1call method
EJB object
2delegate
EJB
4perform business operations
75
Container-Managed Transactions

• Bean deployer has to provide instructions to the
  container
• Deployment descriptor
• Transaction Attributes
• Entire bean
• Individual methods

76
Transaction Attribute Values
77
Transaction Attribute Values
78
Programmatic Transactions

• CORBAs Object Transaction Service (OTS)
• Multiple parties participating in a transaction
• Basic interfaces that transactional object,
  resources, resource managers, and transaction
  managers use to interoperate

79
Java Transaction Service

• Corba OTS
• Java Transaction Service
• Java Transaction API
• JTA?JTS? OTS
• To have various vendors to interoperate
• Used by AS
• JTA
• Application developers
• Programmaticaly control transaction boundaries

80
Java Transaction API

• begin()
• Commit()
• getStatus()
• rollBack()
• setRollbackOnly()
• setTransactionTimeout()

81
Example