Building applications with a db-back-end€¦ · Building applications with a db-back-end Content: I Program architecture I Back-end I Front-end I Middle-tier (where things happen)

Building applications with a db-back-end

Content:

I Program architecture

I Back-end

I Front-end

I Middle-tier (where things happen)

I (Very little on) distributed systems.

•

DD2471 (Lecture 09) Modern database systems & their applications Spring 2011 1 / 16


Content:


I Back-end

I Front-end



•



Content:


I Back-end

I Front-end



•



Content:


I Back-end

I Front-end



•



Content:


I Back-end

I Front-end



•



Content:


I Back-end

I Front-end



•


What will we do on the lab assignments

Content. . . :

I Build back-ends in more than one way

I With pluggable front-ends (in more than one way)

I Build an application (logic layer/middle-tier)

I With authentication

•



Content. . . :





•



Content. . . :





•



Content. . . :





•



Content. . . :





•


Application architecture

In the past application programs were centered around the database and it wasaccepted that everything except database management was lousy.

Interaction was a catastrophy and error management a nightmare.

4GL (as they were called) still exist and have their place in rapid prototyping buthave to a large extent been replaced by EGL (Enterprise Generation Languages)that can deliver almost full-fledged application programs, but mostly need somefinal tweaking. •












Application architecture . . .

Monolithic programs are often called 1-tier as there is no separation of concern atall. Smalltalk (1979) changed the situation with the introduction of their division ofprograms in a model containing a data structure and the operations on data in thatdata structure, a controller that managed all user stimuli and a view componentmanaging all visualization, called Model-View-Controller (MVC).

View

Application program

Model

Controller

User

•



There are variations to the concept

View

Application program

Model

Controller

User

View

Application program

Model

Controller

User

•



There was some criticism (it was difficult to spearate view and controller) andother models popped up, e.g. PAC* (Presentation-Abstraction-Control), thatfocused on the MVC shortcomings and on making the same separation ofconcerns on all levels of the program.

For a while there were many different systems but today only MVC and PAC* havesurvived. Many of them were agent-based: MVC, PAC*, ALV, LIM and York. Theyimplemented modules that worked as “free agents” responding to stimuli fromother “agents”.

•



There was some criticism (it was difficult to spearate view and controller) andother models popped up, e.g. PAC* (Presentation-Abstraction-Control), thatfocused on the MVC shortcomings and on making the same separation ofconcerns on all levels of the program.

For a while there were many different systems but today only MVC and PAC* havesurvived. Many of them were agent-based: MVC, PAC*, ALV, LIM and York. Theyimplemented modules that worked as “free agents” responding to stimuli fromother “agents”.

•



Presentation Abstraction

Controller

PC

A

PC

A PC

A

PC

A PC

A

•



The difference between MVC and PAC* is small. In MVC the view is responsiblefor output to the GUI and the controller takes care of user stimuli (from the GUI)while in PAC* all interaction is managed by the presentation module.

MVC arrived with Smalltalk in 1979 and never changed since 1980 (duringinteraction “childhood”) and PAC* appeared 1987 and got its final design 1997.

MVC is designed by a few people during the early days of interaction design whilePAC* is the result of many researchers work during a lot of years.Still they are strikingly alike – honor to the Smalltalk team that pioneered the work(and later built the first MacOS . . . )

•






•






•



V C

M

User

P C

A

User

•



About 1985 applications programs started to appear that had a distinct internalorganization:

Persistence layer

Presentation layer

Business logic layer

where the persistence layer manages data storage and reading from stored data,the business logic layer does the actual processing and the presentation layermanages presentation and the reception of user stinuli.

•



About 1985 applications programs started to appear that had a distinct internalorganization:

Persistence layer

Presentation layer

Business logic layer

where the persistence layer manages data storage and reading from stored data,the business logic layer does the actual processing and the presentation layermanages presentation and the reception of user stinuli.

•



But . . . there were short-cuts to get better performance.I even have a book on how to avoid the logic layer when presenting information.The image is from the book:

XLib

X Toolkit Intrinsics

Motif Toolkit

GUI

•



Computer are better, faster and have much more primary memory today.Short-cuts are exploitation possibilities for people with insidious objectives.

Security is often more important than performance and performance is mostlybetter than just good enough, maybe with an exception for graphics in certaingames. •



Computer are better, faster and have much more primary memory today.Short-cuts are exploitation possibilities for people with insidious objectives.

Security is often more important than performance and performance is mostlybetter than just good enough, maybe with an exception for graphics in certaingames. •



MVC is the buzzword of the day in industrial applications, though in a PAC*-likevariant (it is actually more PAC* than MVC). Even the subparts of the programsare layered to allow for isolation and as sparse as possible communicationbetween all parts of the application.

In large applications with many programmers / programmer teams this is the onlyfeasible road to success.

•



MVC is the buzzword of the day in industrial applications, though in a PAC*-likevariant (it is actually more PAC* than MVC). Even the subparts of the programsare layered to allow for isolation and as sparse as possible communicationbetween all parts of the application.

In large applications with many programmers / programmer teams this is the onlyfeasible road to success.

•



OS

DBMS

GUI

Business logic

Persistence layer

communication

•



Sun (nowadays ORACLE) recommend J2EE as infrastructure for full-fledgedapplications.

UDDAebXML

RMI−IIOP

Entity Bean

Session Bean

driven Bean

Java AppletJava Application

HTML−client

EJB Message−

Session Bean

Session BeanSession Bean

Persistence layer

Business layer

Servlet JSP

Web server

Message client C++−client

Business system

SOAP

WSDLHTTPSHTTP

RMI−IIOP

RMI−IIOPCORBA/IIOPMessage sending

Application server

Presentation layer

•



But it is a heavy and “invading” architecture that is suitable if you use all of it.There are stubs for all standard components which generate massive amounts ofcalls even if you don’t implement components.Performance suffer a great deal unless you can make use of it all and if you don’thave a competent server.

There are newer architectures that are not as “invading” and well worth ananalysis both on usage of the infrastructure and also on scalabitlity.

••



But it is a heavy and “invading” architecture that is suitable if you use all of it.There are stubs for all standard components which generate massive amounts ofcalls even if you don’t implement components.Performance suffer a great deal unless you can make use of it all and if you don’thave a competent server.

There are newer architectures that are not as “invading” and well worth ananalysis both on usage of the infrastructure and also on scalabitlity.

••


Documents

Building applications with a db-back-end€¦ · Building applications with a db-back-end Content: I Program architecture I Back-end I Front-end I Middle-tier (where things happen)