Software patterns and frameworks

cabbagepatchtapeInternet και Εφαρμογές Web

5 Φεβ 2013 (πριν από 4 χρόνια και 7 μήνες)

155 εμφανίσεις

Building Enterprise Applications:

Issues: Business and EIS Tier
Support

Outline notes with details covered in class

CS37420: Issues: Business and EIS Tier Support

2

Business/EIS tier development issues:
Object/Relational Mapping (ORM)


Basic idea: an object (entity) represents some
persistent state in an RDBMS and is kept in sync
with its database record (diagrams drawn in class)


Support for CRUD operations


Lot’s of platforms support ORM: e.g. Java
Persistence API, Ruby (Rails and Merb), PHP
(e.g. CAKE), .NET (LINQ)


SE31410: Server
-
Side Software development


3

Bookshop ORM UML Class Diagram

items

cartOrder

1

Why use ORM?


Why use this rather than direct access using SQL?


You focus on business code at OO level rather than
SQL or implementing data access object design pattern


You can rely on ORM framework to cache and
optimise synchronisation with the database


More reusable components


Disadvantage:


Possible least common denominator
problem...has to work with lots of RDBMSs
therefore only use features common to all


CS37420: Issues: Business and EIS Tier Support

6

CS37420: Issues: Business and EIS Tier Support

7

Business tier/EIS development
issues: Distributed transactions


Some revision:


Transactions must support ACID:


Atomic


Every task within a unit of work must complete successfully,
otherwise transaction aborted


Consistent


Atomicity, isolation, durability lead to consistent data.
Developer must also define database consistency constraints.


Isolated


Preventing interference from other transactions


Durable


Data written to disk before a transaction can fully commit

CS37420: Issues: Business and EIS Tier Support

8

Business tier/EIS development
issues: Distributed transactions


You will at least require support for local
transactions


For complex enterprise applications you
may wish to use distributed transactions


Support for Two
-
Phase Commit protocol


Example on next slide

Two
-
Phase Commit Protocol

Transfer

Money

ACCOUNT

ACCOUNT

From account

To account

1: adjust

balance (
-
10)

2: adjust

balance (10)

Two Phase Commit
Controller

3: commit

4: Query to

commit

5: Query to

commit

6: Agreement

or abort

7: Agreement

or abort

8: Commit/

rollback

9: Commit/

rollback

10: Acknowledgment

11: Acknowledgment

Phase one

Phase two

RDBMS1

RDBMS2

CS37420: Issues: Business and EIS Tier Support

10

Business tier/EIS development
issues: Distributed transactions


Does your RDBMS support all the standard
ANSI SQL isolation levels required by your
application?


What happens if several transactions wish
to access the same data?


Will one transaction stop another from
reading the data, or writing to it?


Reading uncommitted data could be disastrous!



CS37420: Issues: Business and EIS Tier Support

11

Business tier/EIS development
issues: Distributed transactions


Specify interaction between transactions
with respect to some data


Four different levels


TRANSACTION_READ_UNCOMMITTED


TRANSACTION_READ_COMMITTED


TRANSACTION_REPEATABLE_READ


TRANSACTION_SERIALIZABLE


Databases interpret isolation levels in
different ways, and not all are necessarily
supported: check your DB documentation


How isolation is enforced varies:


Pessimistic locking discussed


Optimistic locking discussed

CS37420: Issues: Business and EIS Tier Support

12