mtat.03.229 enterprise system integration · 2013-09-09 · integration styles (classified by...

MTAT.03.229 Enterprise System Integration Lecture 2: Multi-tier applications and middleware Luciano García-Bañuelos University of Tartu

The Anatomy of an Enterprise System

MUTI-‐TIER APPLICATIONS & MIDDLEWARE LUCIANO GARCÍA-‐BAÑUELOS 1

Enterprise so@w

are PresentaCon

ApplicaCon logic

Data access

ApplicaCon layers

•  Users interact with the system through a presenta(on layer (aka user interface or UI)

•  The applica(on logic (aka business logic) determines what the system actually does: ◦  Enforces business rules ◦  Coordinates business processes

•  The data access layer facilitates the access to persistent data manipulated by the applicaCon logic. ◦  Includes access to databases, search engines, document managers and/or a file system.

Tiers or Layers? • N-‐Cer architectures aim at spliWng the applicaCon in components into different Cers/layers

• Tiers refer to physical distribu(on of components ◦  Components can be executed over a collecCon of computers

• Layers refer to logical separa(on of components ◦  Layered architecture: CommunicaCon should only happen with the conCguous layers

◦  Promotes reuse and logic independence (components should be seamlessly replaceable)

☛  The number of Cers in the system somehow reflects the evoluCon of so@ware architectures w.r.t. distribuCon


1-tier architecture •  All layers are bundled in a monolithic enCty

•  Typical “mainframe” architecture ◦  Users access the system through dumb terminals

◦  All computaCon happens in a single computer


Enterprise so@w

are PresentaCon

ApplicaCon logic

Data access Pros Cons No context switching in the control flow

Limited scalability due to restricCons in the number of processors

CentralizaCon eases resource management/sharing

O@enCmes the code is plaaorm specific, limiCng portability

Code highly opCmisable Intertwined code hindering maintenance

2-tier architecture (1/2) • With the introducCon of computer networks, computaCon started to be physically distributed

•  ApplicaCon layers are distributed depending on the compuCng power of clients: ◦  Thin clients execute only presentaCon layer ◦  Fat clients execute both presentaCon and applicaCon logic layers

•  The concept of API makes its appearance

•  Notable example: Database management systems ◦  The separaCon of data access layer promotes logical independence, reducing the impact of replacing a database technology on the presentaCon applicaCon logic layers


PresentaCon

ApplicaCon logic

Data access Enterprise so@w

are

Client

Server

2-tier architecture (2/2) • With the arrival of PCs, the presentaCon layer moved to the client ◦  Smartphones?

• With this approach, it is possible to have mulCple presentaCon layers ◦  Text (console) applicaCon ◦  Graphical user interfaces (e.g., Java swing) ◦  Web applicaCons (e.g., HTML5, Javascript, etc.)

• Web as the universal plaaorm for compuCng? ◦  Google’s Chromium OS


UI1

ApplicaCon logic

Data access Enterprise so@w

are

Clients

Server

UI2 UIn

Issues with 2-tier architecture • ProblemaCc for a client to access mulCple server applicaCons ◦  Server applicaCons do not know each other ◦  No common business logic

• The client if responsible for knowing where things are, how to get to them, and how to ensure consistency

• Liile can be done to solve the problem with the 2-‐Cer architecture

• One addiConal level of indirecCon is required: THE MIDDLEWARE


3-tier architecture: The middleware arrives • Middleware is a level of indirecCon between clients and other layers ◦  Simplifies the design of client applicaCons by reducing the number of interfaces

◦  Encapsulates integraCon logic and global applicaCon logic

◦  Locates resources, accesses them, and integrates results (mediates between applicaCon logic/data access layers)


PresentaCon

Local applicaCon logic

Local data access

Server A

Local applicaCon logic

Local data access

Server B

Middleware or global applicaCon logic IntegraCon logic

N-tier architecture •  N-‐Cer architectures result from connecCng several 3-‐ Cer systems and/or adding a layer to allow clients to access the system through a Web server (“Web layer”)

•  The Web layer is hosted in a Web applicaCon server: a middleware accessible through the Web.

• Web applicaCon servers are taking also parts of the funcConality of tradiConal middleware – the boundary between the Web layer and the middleware is blurred.


client

Data access layer

ApplicaCon logic layer

Enterprise so@ware

middleware

PresentaCon layer

Web server

Web browser

HTML filter

© Gustavo Alonso, ETH Zurich

Flexibility versus Performance •  The more boxes, the more modular the system: more opportuniCes for distribuCon and parallelism; more extensibility points.

•  The more boxes, the more arrows: more connecCons need to be maintained, more coordinaCon is needed. Complexity increases.

•  The more boxes, the greater the number of context switches and intermediate steps to get to the data. Performance degrades.

•  System designers try to balance the flexibility of modular design with performance demands.

MUTI-‐TIER APPLICATIONS & MIDDLEWARE

LUCIANO GARCÍA-‐BAÑUELOS 9

There is no problem in system design that cannot be solved by adding a level of indirecCon.

There is no performance problem that cannot be solved

by removing a level of indirecCon.

© Gustavo Alonso, ETH Zurich

Evolution of Information System Architectures


Workflow / Middleware

Client Device

Database System

Application

Data

Control Flow

User Interface

Application Logic

Application

Data

Integration Logic

User Interface

Application Logic

Database System

Application

Data

Integration Logic

Application Logic

User Interface

Client Device

Database System

Application

Data

Integration Logic

Application Logic

User Interface

BPMS / SOA Platform

Client Device

Database System

Application

Data

Integration Logic

Service

User Interface

Service Service

1960s 1970s 1980s 1990s 2000s

© Michael Rosemann, QUT

Integration Styles (classified by layer) • Data access level ◦  Shared/synchronized databases ◦  Data warehousing

• Application logic level ◦  Reuse application APIs ◦  File transfer ◦  RPC, message queues, workflow

• Presentation level ◦  Screen scraping, revamping ◦  Portlets, Web mashups

MUTI-‐TIER APPLICATIONS & MIDDLEWARE LUCIANO GARCÍA-‐BAÑUELOS 11 F. Daniel et al.: “Understanding UI Integration”.

IEEE Internet Computing 11(3) pp. 59-66, IEEE, 2007.

Integration Styles (classified by topology) Point-to-point integration ◦  DB synchronization ◦  File transfer ◦  RPC / RMI (without registry) ◦  Simple message queues

Hub-and-spoke integration ◦  Data warehousing ◦  Federated databases ◦  Message brokers ◦  Object brokers ◦  Enterprise Service Bus ◦  Workflow / BPM systems


Part II HANDS ON SPRING ROO


Running example Buildit is a construcCon company specialized in public works (roads, bridges, pipelines, tunnels, railroads, etc.). Buildit owns very liile equipment and instead it hires most of it. One of Buildit’s preferred plant hire supplier is Ren*t. Note: A piece of heavy equipment is called a “plant” in the construcCon jargon.


Exercise 1 ☛  Specify the Data model for the following scenario When a site engineer needs to hire a plant, he/she consults the catalogue of a plant supplier in order to idenCfy a plant that fulfills the requirements. Once the site engineer has idenCfied the required plant, he/she checks the plant’s availability during the required period of Cme as well as the price. If the plant is available, the site engineer creates a Plant Hire Request, which includes the idenCfier of the construcCon site where the plant is needed, the supplier of the plant, the plant’s idenCfier, the expected start and end date of the hire period and the cost of hiring the plant for this period of Cme. This cost is calculated based on the plant’s price per day of the selected plant and the number of days the plant is hired.


Spring Roo: Data access layer


Plant

id: Longname: Stringdescription: Stringprice: Float

Customer

id: Longname: StringvatNumber: String

PurchaseOrder

id: Longstart: Dateend: Datecontact: Stringcost: Float

persistence setup -‐-‐database DERBY_EMBEDDED -‐-‐provider ECLIPSELINK

en(ty jpa -‐-‐class ~.model.Plant

field string -‐-‐fieldName name field string -‐-‐fieldName descripCon field number -‐-‐fieldName price -‐-‐type java.lang.Float

Spring Roo: Presentation layer


web mvc setup web mvc all -‐-‐pakage ~.web

mtat.03.229 enterprise system integration · 2013-09-09 · integration styles (classified by...

Documents