Unit 1 Enterprise Foundations

Balasubba Raman Guruswamy

11 January 2011

Enterprise Computing Enterprise Foundations

11 January 2011

Enterprise Computing Enterprise Foundations

A method for managing your business or enterprise: A decision making tool A change management tool The knowledgebase of your business or enterprise

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 rate of change? How do you meet the demands of your constituency (or customers) quicker and more efficiently?

When someone leaves your enterprise, do you retain their knowledge?

Thousands of years of history would suggest the only known strategy for addressing complexity and change is architecture.

If it gets so complex you cant remember how it works, you have to write it down

Architecture
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 a wall (complexity and change)

It provides the plan on how to move the wall (change management) It helps you retain employee knowledge (becomes knowledgebase of enterprise) If you dont have architecture, you change by trial and error (which is high risk)

Software Concepts
System Description Tightly-coupled operating system for multi-processors and homogeneous multicomputers Loosely-coupled operating system for heterogeneous multicomputers (LAN and WAN) Additional layer atop of NOS implementing general-purpose services Main Goal Hide and manage hardware resources Offer local services to remote clients Provide distribution transparency DOS

NOS

Middleware

DOS (Distributed Operating Systems) NOS (Network Operating Systems) Middleware

Distributed Systems 10

Uniprocessor Operating System

Separating applications from operating system code through a microkernel.

Distributed Systems

11

Distributed Operating System

Tightly-coupled operating system for multi-processors and homogeneous multi-computers.

Strong transparency.

Distributed Systems

12

Distributed Operating Systems

Allows a multiprocessor or multicomputer network resources to be integrated 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 + local operating systems + distributed features Inter-process communication (IPC)

Distributed Systems 13

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. see Google distributed systems research

Distributed Systems

14

Network Operating System

Loosely-coupled operating system for heterogeneous multi-computers (LAN and WAN). Weak transparency.

Distributed Systems

15

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

Distributed Systems

16

Middleware System

Additional layer on the top of NOS implementing generalpurpose services. Better transparency.

Distributed Systems

17

Examples: Sun RPC, CORBA, DCOM, Java RMI (distributed object technology)
Built on top of transport layer in the ISO/OSI 7 layer reference model: application (protocol), presentation (semantic), session (dialogue), transport (e.g. TCP or UDP), 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 programming languages so provides a uniform programming model 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
Distributed Systems 18

Comparison between Systems

Item Degree of transparency Same OS on all nodes Number of copies of OS Basis for communication Resource management Scalability Openness Distributed OS Multiproc. Very High Yes 1 Shared memory Global, central No Closed Multicomp. High Yes N Messages Global, distributed Moderately Closed Network OS Low No N Files Per node Yes Open Middlewarebased OS High No N Model specific Per node Varies Open

Distributed Systems

19

Enterprise(J2EE) Application Model

Distributed Systems

20

11 January 2011

Enterprise Computing Enterprise Foundations

21

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.

Software system Abstraction Real world Interpretation Model Algorithm

22

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 ~

23

Possible to directly represent real world objects in the computer system

Data-oriented model

Object-oriented model

Real world

Software system

Real world

Software system

24

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)
25

Approach

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

Activities

Conceptualization
Object-oriented analysis and modeling Object-oriented design

Implementation
Maintenance
26

Conceptualization

To establish the vision and core requirements of the software system to be developed. build models of the systems desired behavior, using notations such as the Unified Modeling Language (UML). capture the essential relevant aspects of the real world and to define the services to be provided and/or the problems to be solved. simplify reality to better understand the system to be developed.

Object-oriented analysis and modeling

27

Object-oriented design

To create an architecture for implementation.

Represented in terms of objects and classes and the relationships among them.
To implement the design by using an objectoriented programming language (e.g., Java) To manage post delivery evolution effectively.

Implementation:

Maintenance:

28

29

11 January 2011

Enterprise Computing Enterprise Foundations

30

 Component-based software engineering (CBSE) is an approach to software development that relies on software reuse. Failure of object-oriented development to support effective reuse. Single object classes are too detailed and specific.

Components are more abstract than object classes and can be considered to be standalone service providers.

 Independent components specified by their interfaces.

Component standards to facilitate component integration. Middleware that provides support for component inter-operability.

A development process that is geared to reuse.

Apart from the benefits of reuse, CBSE is based on sound software engineering design principles:

Components are independent so do not interfere with each other; Component implementations are hidden; Communication is through well-defined interfaces; Component platforms are shared and reduce development costs.

Component trustworthiness - how can a component with no available source code be trusted?
Component certification - who will certify the quality of components? Emergent property prediction - how can the emergent properties of component compositions be predicted? Requirements trade-offs - how do we do trade-off analysis between the features of one component and another?

Components provide a service without regard to where the component is executing or its programming language
A component is an independent executable entity that can be made up of one or more executable objects; The component interface is published and all interactions are through the published interface;

Councill and Heinmann:

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

Szyperski:
A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third-parties.

The component is an independent, executable entity. It does not have to be compiled before it is used with other components.
The services offered by a component are made available through an interface and all component interactions take place through that interface.

Provides interface

Defines the services that are provided by the component to other components. Defines the services that specifies what services must be made available for the component to execute as specified.

Requires interface

Requires int erface Defines the services from the component s environment that it uses Component

Provides int erface Defines the services that are provided by the component to other components

Requires int erface

Provides int erface addSensor removeSensor star tSensor stopSensor testSensor initialise repor t listAll

sensorManagement Data collector 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, documentation and deployment. Examples of component models

EJB model (Enterprise Java Beans) COM+ model (.NET model) Corba Component Model

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

Customisation Naming convention Composition Interface definition Specific inter faces Meta-data access Documentation Packag ing Evolution suppor t

Interfaces

Usage information Component model

Deploy ment and use

Component models are the basis for middleware that provides support for executing components. Component model implementations provide:

Platform services that allow components written according to the model to communicate; Horizontal services that are application-independent services used by different components.

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

Horizontal services Component management Concurrency Transaction management Persistence Resource management Security

Platform services Addressing Inter face definition Exception management Component communications

Components developed for a specific application usually have to be generalised to make them reusable. A component is most likely to be reusable if it associated with a stable domain abstraction (business object). For example, in a hospital stable domain abstractions are associated with the fundamental purpose - nurses, patients, treatments, etc.

Components for reuse may be specially constructed by generalising existing components.

Component reusability

Should reflect stable domain abstractions;

Should hide state representation;

Should be as independent as possible; Should publish exceptions through the component interface. The more general the interface, the greater the reusability but it is then more complex and hence less usable.

There is a trade-off between reusability and usability

The development cost of reusable components may be higher than the cost of specific equivalents. This extra reusability enhancement cost should be an organization rather than a project cost. Generic components may be less space-efficient and may have longer execution times than their specific equivalents.

When reusing components, it is essential to make trade-offs between ideal requirements and the services actually provided by available components. This involves:
Developing outline requirements; Searching for components then modifying requirements according to available functionality. Searching again to find if there are better components that meet the revised requirements.

1. 2. 3. 4.

What is enterprise architecture? Explain DOS, NOS & Middleware. What are the three types of middleware? What are the two essential components of a software system? 5. What are the four types of programming models?

11 January 2011

Enterprise Computing Enterprise Foundations

51

1. 2. 3. 4.

Why enterprise architecture needed in organisations? Describe object-oriented development. Describe Component based development. Draw the flow chart of the CBSE process and briefly describe each step.

11 January 2011

Enterprise Computing Enterprise Foundations

52