ec-unit 1a enterprise foundations

7/28/2019 EC-Unit 1A Enterprise Foundations

http://slidepdf.com/reader/full/ec-unit-1a-enterprise-foundations 1/52



11 January 2011 2

Enterprise ComputingEnterprise Foundations



A method for managing your business or

enterprise:

A decision making tool

A change management tool

The knowledgebase of your business orenterprise



focused on Information

Technology

(IT is only a part or subset of enterprise

architecture)



How do you manage the increasing

complexity of your enterprise?

How do you manage the increasing rateof change?

How do you meet the demands of yourconstituency (or customers) quicker andmore efficiently?



When someone leaves your enterprise,

do you retain their knowledge?



Thousands of years of history wouldsuggest the only known strategy for

addressing complexity and change is

architecture.



Architecture

If it gets so complex you can’t

remember how it works, you

have to write it down…

If you want to change how it

works, you start with what you

have written down…



It provides a method for writing things

down (develop blueprints)

It shows you the impact of “moving awall” (complexity and change)

It provides the plan on how to “movethe wall” (change management)

It helps you retain employee

knowledge (becomes knowledgebaseof enterprise)

If you don’t have architecture, you change by

trial and error (which is high risk)


http://slidepdf.com/reader/full/ec-unit-1a-enterprise-foundations 10/52Distributed Systems 10

Software Concepts

DOS (Distributed Operating Systems)

NOS (Network Operating Systems)

Middleware

System Description Main Goal

DOSTightly-coupled operating systemfor multi-processors andhomogeneous multicomputers

Hide andmanagehardwareresources

NOS Loosely-coupled operating systemfor heterogeneousmulticomputers (LAN and WAN)

Offer local

services toremoteclients

Middleware Additional layer atop of NOSimplementing general-purposeservices

Providedistributiontransparency



Uniprocessor Operating System

Separating applications from operating systemcode through a microkernel.



Distributed Operating System

Tightly-coupled operating system for multi-processors and

homogeneous multi-computers. Strong transparency.



Distributed Systems 13

Distributed Operating Systems

Allows a multiprocessor ormulticomputer network resources to beintegrated as a single system image

Hide and manage hardware and software

resources provides transparency support

provide heterogeneity support

control network in most effective way

consists of low level commands + localoperating systems + distributed features

Inter-process communication (IPC)




remote file and device access

global addressing and naming trading and naming services

synchronization and deadlock avoidance

resource allocation and protection

global resource sharing deadlock avoidance

communication security

no examples in general use but many

research systems: Amoeba, Chorus etc. seeGoogle “distributed systems research”




Network Operating System

Loosely-coupled operating system for heterogeneous

multi-computers (LAN and WAN). Weak transparency.




Network Operating System

extension of centralized operating systems offer local services to remote clients

each processor has own operating system

user owns a machine, but can access others

(e.g. rlogin, telnet) no global naming of resources

system has little fault tolerance

e.g. UNIX, Windows NT




Middleware System

Additional layer on the top of NOS implementing general-

purpose services. Better transparency.




Examples: Sun RPC, CORBA, DCOM, Java RMI(distributed object technology)

Built on top of transport layer in the ISO/OSI 7 layerreference model: application (protocol), presentation(semantic), session (dialogue), transport (e.g. TCP orUDP), network (IP, ATM etc), data link (frames,checksum), physical (bits and bytes)

Most are implemented over the internet protocols

Masks heterogeneity of underlying networks,hardware, operating system and programminglanguages – so provides a uniform programmingmodel with standard services

3 types of middleware:

transaction oriented (for distributed database applications)

message oriented (for reliable asynchronous communication)

remote procedure calls (RPC) – the original OO middleware




ItemDistributed OS

Network OS

Middleware-based OS

Multiproc. Multicomp.

Degree of transparency Very High High Low High

Same OS on all nodes Yes Yes No No

Number of copies of OS 1 N N N

Basis forcommunication

Sharedmemory

Messages Files Model specific

Resource management

Global,

central

Global,

distributed Per node Per node

Scalability No Moderately Yes Varies

Openness Closed Closed Open Open

Comparison between Systems




Enterprise(J2EE) Application Model



11 January 2011 21Enterprise ComputingEnterprise Foundations



22

A software system provides a solution to a

problem in the real world. Consists of two essential components:

Model: abstraction of a part of the real world

Algorithm: captures the computations involved

in manipulating or processing the model.

AlgorithmModel

Software system

Real world

Abstraction

Interpretation



23

Programming languages

Tools to describe computer models

Programming models

Computation-oriented model (50s ~ 60s)

Data-oriented model (70 ~ 80s) Object-oriented model (90s ~ )

Balanced view between data and computation

Component Based Model (2000 ~



24

Possible to directly represent real world objects inthe computer system

Software systemReal world

Data-oriented model

Software systemReal world

Object-oriented model



25

Key characteristics

Consists of a number of success iterations

Each iteration produces a working program

Build system incrementally

Monolithic approach of waterfall model

Benefits

Facilitates and manage changes

Minimize and prevent changes

Examples

Rational Unified Process (RUP)

Extreme Programming (XP)



26

Approach

Focuses on improving the maintainability andreusability of software systems through a setof techniques, notations, tools, and criteria.

Activities Conceptualization

Object-oriented analysis and modeling

Object-oriented design

Implementation

Maintenance



27

Conceptualization

To establish the vision and core requirements of thesoftware system to be developed.

Object-oriented analysis and modeling

build models of the system’s desired behavior, using

notations such as the Unified Modeling Language (UML).

capture the essential relevant aspects of the real worldand to define the services to be provided and/or theproblems to be solved.

simplify reality to better understand the system to bedeveloped.



28

Object-oriented design

To create an architecture for implementation. Represented in terms of objects and classes

and the relationships among them.

Implementation:

To implement the design by using an object-oriented programming language (e.g., Java)

Maintenance:

To manage post delivery evolution effectively.



29



11 January 2011Enterprise ComputingEnterprise Foundations 30



Component-based software engineering

(CBSE) is an approach to softwaredevelopment that relies on software reuse.

Failure of object-oriented development tosupport effective reuse. Single object

classes are too detailed and specific.

Components are more abstract than objectclasses and can be considered to be stand-

alone service providers.



Independent components specified by

their interfaces.

Component standards to facilitatecomponent integration.

Middleware that provides support forcomponent inter-operability.

A development process that is geared to

reuse.



Apart from the benefits of reuse, CBSE is

based on sound software engineeringdesign principles:

Components are independent so do notinterfere with each other;

Component implementations are hidden;

Communication is through well-definedinterfaces;

Component platforms are shared and reduce

development costs.



Component trustworthiness - how can a

component with no available source code betrusted?

Component certification - who will certify thequality of components?

Emergent property prediction - how can theemergent properties of component compositionsbe predicted?

Requirements trade-offs - how do we do trade-off

analysis between the features of one componentand another?



Components provide a service without regard

to where the component is executing or itsprogramming language

A component is an independent executable entitythat can be made up of one or more executable

objects;The component interface is published and all

interactions are through the publishedinterface;



Councill and Heinmann:

A software component is a software element that conformsto a component model and can be independently deployed and composed without modification according to acomposition standard.

Szyperski: A software component is a unit of composition with

contractually specified interfaces and explicit context dependencies only. A software component can bedeployed independently and is subject to composition by third-parties.



The component is an independent,

executable entity. It does not have to becompiled before it is used with othercomponents.

The services offered by a component aremade available through an interface andall component interactions take placethrough that interface.



Provides interface

Defines the services that are provided by thecomponent to other components.

Requires interface

Defines the services that specifies whatservices must be made available for thecomponent to execute as specified.



Provides int erfaceRequires int erface

Component

Defines the servicesfrom the component’s

environment that it

uses

Defines the servicesthat are provided

by the component

to other components



Provides int erfaceRequires int erface

Data collector

addSensor

removeSensor star tSensor

stopSensor

testSensor

listAllrepor t

initialise

sensorManagement

sensorData



Components are deployable entities.

Components do not define types.

Component implementations are opaque.

Components are language-independent.

Components are standardised.



A component model is a definition of standards

for component implementation, documentationand deployment.

Examples of component models

EJB model (Enterprise Java Beans)

COM+ model (.NET model) Corba Component Model

The component model specifies how interfacesshould be defined and the elements that shouldbe included in an interface definition.



Component model

InterfacesUsage

information

Deployment

and use

Interface

definition

Specific

inter faces

Composition

Naming

convention

Meta-data

access

Customisation

Packaging

Documentation

Evolution

suppor t



Component models are the basis for middlewarethat provides support for executingcomponents.

Component model implementations provide: Platform services that allow components written

according to the model to communicate;

Horizontal services that are application-independentservices used by different components.

To use services provided by a model,components are deployed in a container. This isa set of interfaces used to access the service

implementations.



Platform services

AddressingInterface

definitionComponent

communications

Exception

management

Horizontal services

Security

Transaction

management

Concurrency

Component

management

Persistence

Resource

management



Components developed for a specific

application usually have to begeneralised to make them reusable.

A component is most likely to bereusable if it associated with a stable

domain abstraction (business object). For example, in a hospital stable domain

abstractions are associated with thefundamental purpose - nurses, patients,

treatments, etc.



Components for reuse may be specially constructed bygeneralising existing components.

Component reusability

Should reflect stable domain abstractions;

Should hide state representation;

Should be as independent as possible;

Should publish exceptions through the componentinterface.

There is a trade-off between reusability and usability

The more general the interface, the greater the

reusability but it is then more complex and hence lessusable.



The development cost of reusable

components may be higher than the cost of specific equivalents. This extra reusabilityenhancement cost should be anorganization rather than a project cost.

Generic components may be lessspace-efficient and may have longerexecution times than their specific

equivalents.



When reusing components, it is essential to

make trade-offs between idealrequirements and the services actuallyprovided by available components.

This involves:

Developing outline requirements;

Searching for components then modifyingrequirements according to availablefunctionality.

Searching again to find if there are bettercomponents that meet the revisedrequirements.



1. What is enterprise architecture?

2. Explain DOS, NOS & Middleware.

3. What are the three types of middleware?

4. What are the two essential components of a softwaresystem?

5. What are the four types of programming models?

11 January 2011 Enterprise ComputingEnterprise Foundations 51



1. Why enterprise architecture needed in organisations?

2. Describe object-oriented development.

3. Describe Component based development.

4. Draw the flow chart of the CBSE process and brieflydescribe each step.

ec-unit 1a enterprise foundations

Documents