J2EE Tiering

From sheep
Revision as of 21:19, 14 September 2021 by Martin (talk | contribs) (Created page with "= Multi Tier Architecture = Client Server architecture with presentation, processing, data management being seperated Typically: * Layer - Logical * Tier - Physical Presenta...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Multi Tier Architecture

Client Server architecture with presentation, processing, data management being seperated

Typically:

  • Layer - Logical
  • Tier - Physical

Presentation Tier <-> Business processing <-> Data management

Two Tier

Disadvantages:

  • Fails to separate business logic from presentation
    • less reuse
  • Easily compromised integrity
    • Each client may have different business rules
  • Difficult to administer
  • Exposure to security issues
    • Distributed DB access in each client
  • Limited scalability
    • Network resources required for each client
    • Limited resources such as DB connections required for each client
    • Slow network - more DB strain
    • can not add more machines to business tier
  • Restricted clients
  • Limited presentations - PC/Phone/...
  • Difficult to debug/fault find/monitor
  • Hard to maintain - difficult to update clients/fix/ensure everyone has right version

Three Tier

Split Presentation tier from Business tier

Used in most ERP Enterprise Resource Planning solutions

  • systems specialising in high volume transactions CICS, Tuxedo

Problems:

  • complexity
    • distribution, multi threading, security
  • system level complexities of distribution
    • use of application frameworks such as TP Transaction Processing
    • application server
  • Lack of portability - each framework has own API
  • Vendor incompatibility - no standard interoperable protocol
  • Limited adoption - limited tools programmers typically only support one framework
  • Historically not web compatible - proprietary client/appserver protocol - most now support web

J2EE Application Architecure

Supports 2 and 3 tier architecture

2tier.png 3tier.png

4 Programming Environments

  1. Web container - presentation logic
  2. EJB container - business logic
  3. Application client container - J2EE app client - see J2EE_API and Services#JEE_5_API_and_Services
  4. Applet container

Advantages of EJB Development environment

  • Simplicity provides frameworks for: security, transactions, muti threading, distribution, resource pooling, secure protocols
  • Standards - Application portability - eases porting to other vendors platforms
  • Component reuse - Beans - reusable business block
    • can customise per deployment
    • multiple applications share same bean and business logic
  • clearly defined roles allow larger teams
  • deployment in different environments - separates business logic from deployment configuration
    • encourages tooling from vendors to support and reduce errors
  • distributed environment independent from topology
  • application interoperability
  • integrates with systems other than java
    • JCA and JMS allows integration with ERP, DBMS in a standard way
  • Tooling and resources - standard lead to tools for development and maintenance

Customer Benefits

  • choice of server - price - features
  • application management - sophisticated tools for management/monitoring/analysing
  • integration with existing systems and data - reuse
  • security - separation of roles - both people and software

More tiers

  • increase extensibility, manageability, security
  • decrease performance - increases latency

2 tier vs 3 tier

  • Advantages
    • gain performance network latency by bringing closer application server and DB
    • better reliability - have control over server environment
    • easier to extend
    • easier to manage/optimise
  • Disadvantages
    • loose performance if CPU bound

Key terms:

Availability

  • often coupled with SLA

availability = (available time)/(time possible)

Capacity

number of jobs/time unit

Extensibility

Economically add/modify functionality

Flexibility

Ability to support architecture/hardware changes - location independent code helps

Manageability

Mange health of system - upgrades

Reliability

Integrity and consistency of transactions and application

  • MTBF 10^5 hours - for 1 box => MTBF 10^15 hours for 3 boxes

Performance

Response time

  • SLA
  • ability to control expensive requests
  • process & network

Scalability

Increase quality of service as load increases

  • Vertically scale - add more memory/CPUs
  • Horizontally scale - add more servers - requires load balancer - also increases availability/reliability

Security

Ensure information modifications and disclosures meet security policy

Testability

Confirm expected results

  • monitoring

Two tier

Good for:

  • homogeneous environment
  • static business rules
  • small business <100 users
  • often decision support services
  • low interaction

Moving business logic to DB limits growth - difficult to scale

  • stored procedures lack rich development tools - debugging/test/VCS

Three tier

Good for:

  • 100s of users
  • batch jobs (tend to tie up 2 tier clients)
  • high transaction load
  • changeable business rules



Load balancing

Distributes load across machines

Replication

http://en.wikipedia.org/wiki/Replication_(computer_science)

Active replication

  • Clustering
  • Each request is applied on every system
  • An interceptor is used to
  • Equivalent to a hot backup
  • Multi-primary - (multi-master in DB terms)
  • Requires distributed concurrency - e.g. distributed lock manager
  • Cluster is horizontally scalable by adding more machines

Passive replication

  • High availability
  • A request is applied on one system then replicated to the others
  • Equivalent to a warm backup

Backup - copy of data unchanged for long periods - replicas - frequently updated quickly loose historical state

Applet Client Tier

http://java.sun.com/blueprints/qanda/client_tier/index.html

Applet client should talk to web container not EJB container

  1. JRE may not support direct EJB communication
  2. Firewalls may prevent direct EJB communication
  3. Exposing the EJB container to the internet so client can communication is a security risk
  4. Servlet layer decouples the applet from the business layer - Facade Pattern


J2EE Notes

Annotations: replace deployment descriptors

  • put resources in code next to where they are used


Dependency injection: Hides lookup and creation of resources

  • EJB, Web container and clients
  • container inserts references to components/resources using annotations


Solves scalability, accessibility, manageability

  • Splits business and presentation tiers

Tier.png

Considered 3 tier due to number of machines

  • Makes business tier multi-threaded - and web tier

Security: can be defined at deployment time

  • provides a standard login mechanism - authentication

J2EE component: self contained software unit

  • application - classes & files
  • communicates with other components
  • well formed
  • compliant with specification
  • deployed and managed by J2EE server
  1. Application clients and applets - run on client
  2. Servlets/JFS/JPS - web components -run on web server
  3. EJB - business components - run on application server
  • Web tier - interface, session, input, dialogue, display management
  • Appserver tier - process managment, development, enactment, monitoring, resourcing
  • EIS tier - DBMS - data and file services - ensures consistency, locking, replication

Resources named rather than location based - aids flexibility (moving)/scalability (adding)