Architecture

Natty Gur

Introductions

• Enterprise architecture– Actually 5 different but tightly couple architectures

• Business.• Application (our main focus).• Software.• framework• Technological

– Analyze against several view points (matrix) :• Enterprise• Information.• Componential.• Engineering• Technical.

Introductions

• Enterprise architecture framework– Set of methodologies, frameworks in frameworks and

practical guide to create architecture.– Frameworks:

• TOGAF– URL : http://www.opengroup.org/architecture/togaf/.

• RM-ODP– URL :

http://www.enterprise-architecture.info/EA_Standards.htm & Books

• Zachman– URL : http://www.zifa.com/

Introductions

• Software/Application Architecture are:– Set of rules to define software/s building blocks,

relations between those blocks, there position over the enterprise and which kind of blocks to use:

• Of the shelf.• Reusing.• Developing.

• Architecture main guiding points are:– Coherent with enterprise goals (driven and NOT

leading).– Abstraction.– Loosely coupled.

Enterprise continuum

• Database of available architectures and patterns whether used or unused in your enterprise.– Add metadata such as :

• Add by (who can I ask questions).• Implement by systems.• Link to any sources.

– Add draw (one picture worth …)

• Should be use when creating Architecture to reuse existing resources.

• I’ll open wiki/site for that purpose, details - blog.

Enterprise continuum – partly list• System structure

– Layers.– Hexagonal.– Naked objects.– Entity oriented.– Pluggable.– SOA.

• Domain Logic– Transaction script.– Table module.– Domain model.– Service layer.

• DB mapping– Row gateway.– Table gateway.– Active Record.– Mapping.– Lazy load.

• Presentation– MVC – MVC II.– Front controller.– Page controller.– Application controller.

• State management– Server.– Client.– Database.– Hosted network node.

• Business transactions– Optimistic.– Pessimistic.– Crouse-grained.– Implicit.

• Storing objects in DB– Single table.– Concrete– Table.– Double.

Glorious days of layers• Concept – Systems building from components.• Motivation – separation of components by functionality for maintains

and reuse.• Description –

– Ordering components in layer. – Each inner layer should be called by outer layer. – No direct call to inner layer.

• (Layer vis Tier).• Advantage –

– easy to follow. – Split system into well define behavioral components.

• Problems – – how to access inner layer (for debugging purpose). – How to enable unknown consumers to call system (System of systems).

Hexagon Architecture

• Concept – UI/DAL aren’t always the “external” layers.• Motivation – No more layers. Every system “service”

might use or call domain logic• Description – domain exist in the center and can be

access by or access any “external services” via transformers.

• Advantage – – More flexible.– Suite system of systems.

• Problems – – not imposing strict system flow.– Takes time to get.

Entity oriented Architecture

• Concept – Enterprise domain build from Information entity.

• Motivation – Enable SOS that integrate UI,BL and DA.• Description – Entity expose services. Once certain

services call the flow is strict as in layers.

• Advantage – – Combination of Layers and Hexagonal advantage.– Helps system 80% maintains.

• Problems – Hard to implement.

UI BL X DA

gateway

Naked objects

• Concept – Defining system flow and logic in advance is wrong!

• Motivation – enable sequence less systems for maximum user flexibility.

• Description – creating just classes. Framework enable the user to create objects from classes and act upon them.

• Advantage – Flexible!!!• Problems – demand Infrastructure.

Naked objects - Demo

Pluggable architecture

• Concept – systems create from components therefore can be assemble dynamically.

• Motivation – Creating easy to change and maintain systems.

• Description – Every connection between components depend on Interface. Component call others by global name. External definitions (XML) set which actual class will be call for given global name. Or external file set which components will be load at system load.

• Advantage – – enable easily component replacing.– Enable assembling dynamic systems (versions).

• Problems – demand work.

Pluggable architecture - Demo

Domain Logic

• Transaction script.– Every transaction with all of activities in one

function.– Advantage : Easy to create.

– Disadvantage : duplicate code, problematic with complex logic.

Domain Logic• Domain model..

– OO reflection of logic and data.– Advantage : most flexible and feet complex

logic.

– Disadvantage : Lots of work (design and mapping)

– Simple & complex

– Store in OODB or session.

Domain Logic• Table module.

– Reflection of DB. Every table has class that handle table activities.

– Advantage : well adopted in .NET.– Disadvantage : Can’t deal properly with

complex logic. Less easy to maintain code (Flexible).

Domain Logic

• Service layer.– Handle application flow.– Exposing one interface of services to the

outside world.

– Advantage : callers not need to know inner system implementation. Easier to control outer request that required several actions in domain logic

Mapping to DB

• Table gateway.– Mapping DB table to domain logic class.– Hides SQL in one place.

– Stateless, just push data back and forth.– Returning map, value object, record set (.Net).

Mapping to DB

• Row gateway.– Mapping each table row to dedicate object.– Row gateway class handle just DB actions.

– Mixing DB access with logic more complex to test and maintain.

– Usually finder class added.– Convert data source types to in memory

types.

Mapping to DB

• Active record.– Record mapping and logic exist in one class.– Fit for simple domain model.

Mapping to DB

• Mapping.– Special class to translate DB data to domain

logic OO structure.– Collection and inheritance for example.

– Data classes are ignorance of data source, complete de-coupling.

– COMPLICATED! Use ORM tools.

Domain Logic & DB mapping sample

• word processors, databases, and spreadsheets revenue calculation.

OO structure to DB

• Single table inheritance.

• Concrete table inheritance.• Class table inheritance.

• Double mapping.

Presentation

• Page controller

• Front controller

• Application controller• MVC

Object-Relational Behavioural Patterns

• Unit of work: keep track of changes.– caller registration. – object registration.– unit of work controller.

• Lazy load.– Initialization.– virtual proxy.– value holder.– ghost.

• Identity map.

Offline concurrency

• Optimistic lock.

• Pessimistic lock.

• Coarse-Grained Lock.• implicit

Books

• Pattern Oriented Software Architects POSA I – II (ISBN 0471958697 ,ISBN: 0471606952).

• Patterns of Enterprise Application Architecture (ISBN-0-321-12742-0).