CS590L - Lecture 11

CS590LDistributed Component Architectures

Yugi Lee

STB #555(816) 235-5932

leeyu@umkc.edu

www.sice.umkc.edu/~leeyu

2CS590L - Lecture 1

General stuff

• Class hours: T/TH 2:00 – 3:15, FH260 • Office hours:

– Yugi Lee: T/TH 3:15-4:15 or by appointment

• Class page: www.sice.umkc.edu/~leeyu– Lecture notes will be available in advance

– Mailing List

• Suggested Prerequisites CS551 (Advanced Software Engineering) Middleware Technology, component-based model (UML),

Object-Oriented programming language (Java, C++)

3CS590L - Lecture 1

Reference books

• Evaluating Software Architectures: Methods and Case Studies by P. Clements, R. Kazman, M. Klein ISBN 0-201-70482-X

• Design Patterns: Elements of Reuseable Object-Oriented Software by E. Gamma, R. Helm, R. Johnson and J. Vlissides, Addison-Wesley, ISBN: 0-201-63361-2, Copyright 1995.

• UML Components by J. cheesman, J. Daniels. Addison-Wesley, October 2000.• Large-Scale, Component-Based Development, by Alan W. Brown, Prentice Hall, 2000,

ISBN: 0-13-088720-X. • Applying UML and Patterns - An Introduction to Object-Oriented Analysis and Design,

Craig Larman, Prentice Hall, 1998, ISBN 0-13-748880-7. • Component-Software - Beyond Object-Oriented Programming, Clemens Szyperski,

Addison-Wesley, Copyright 1998, ISBN 0-201-17888-5. • SOAP, Scott Seely, Seely, ISBN 0-13-090763-4.• Software Architecture in Practice, Len Bass, Paul Clements, Rick Kazman, Addison

Wesley, Copyright 1998, ISBN 0-201-19930-0.• Further material will be made available through handouts in class and through pointers to

relevant Web pages.

4CS590L - Lecture 1

Motivation

• As a software environment (i.e., WWW) is evolving very rapidly, it is necessary to understand the current trend of software systems and to identify the technologies and requirements for the system development.

• Some requirements and characteristics of the current system can be determined as comparability, heterogeneity, scalability and distribution.

• An emerging concept called "a component-based software" appears to be a solution for the development of software system.

5CS590L - Lecture 1

Course Objectives

• To introduce the concept of distributed component architectures, including its relationship to the object-oriented programming paradigm.

• To demonstrate the importance of reusability and focuses on design pattern and frameworks in distribute component architecture.

• To introduce different component frameworks, including Enterprise Java Beans, COM, CORBA, Web Services and discuss interoperability between applications built in different frameworks using .NET.

• To present primary issues in component frameworks, including events, properties, introspection and reflection, persistence, and packaging will be thoroughly reviewed.

• To describe software architecture and its evaluation mechanism for supporting components and theoretical foundations of components

6CS590L - Lecture 1

Course Requirements

• A research-oriented graduate course, – A substantial portion of the quarter will be devoted to

student presentations of techniques and research papers – Students will be expected to select a problem area in

distributed computing architecture and prepare an intensive presentation covering the methods and framework commonly employed to address their problem.

– A research paper on the application of a particular middleware architecture is also an acceptable topic.

7CS590L - Lecture 1

Course Requirements

• Discussion/Presentation: – The lecture/discussions are designed to be highly

participatory.

– Participation will include such activities as group discussions of topics through workshops; discussions with faculty and student groups on topics, research, and/or application problems;

– Short presentations on relevant papers and project results;

– Critiques of resource material, software, and other things related to distributed component architecture.

8CS590L - Lecture 1

Course Requirements

Critical Reading/Thinking: Students are required to read and assimilate information

from the readings beyond the material covered in class. Throughout the semester, papers and chapters of the

texts will be read and discussed.

9CS590L - Lecture 1

Course Requirements

Analytical Writing: Students are asked to think critically and reason about

information presented in the textbooks or papers. For example, a paper assignment might ask how different frameworks we are studying compare, or how existing technology, like the Web will evolve in the context of component software.

This critical evaluation requires that students offer their own understanding of the significance of what students have learned.

10CS590L - Lecture 1

Course Requirements

Discovery (Self-guided) Learning: The course project will require independent research and programming, and students are expected to be able to demonstrate ability of this kind.

11CS590L - Lecture 1

Assessment

• Group Project 40% Projects 1 – 5 30% Pair Programming (Labs 1 – 4) 10%

• Individual Work 60%– Papers 1 - 3: 30%– Presentation & Discussion 15%– Test 15%

Both components must be passed in order to pass the course.

12CS590L - Lecture 1

Group Projects

• Teams of Maximum 2 members, development of a component-based system.

• The overall assignment will be split into several steps that will be marked individually. Project 1 : Project proposal Project 2: System design Project 3: System implementation(1) Project 4: System implementation(2) Project 4: Documentation & final package

13CS590L - Lecture 1

Group Projects

• Building system followed by component-based design and programming

• Incremental outcomes going through Component-based software development process, such as requirement analysis, design, implementation, testing, and integration.

• Object-Oriented Specification/Design (UML/Together), Design patterns, styles, Object Framework building using XML, CORBA/COM/EJB, Web Services or .NET.

14CS590L - Lecture 1

Research Paper

• Goal: A research paper (Individual work)• Tentative paper topics:

– Paper 1: Software Architecture Evaluation– Paper 2: Design Pattern– Paper 3: Distributed Component Systems

15CS590L - Lecture 1

Presentation & Discussion

Each student will be participated in three types of presentations & discussion Workshop Paper Project Lab

16CS590L - Lecture 1

Contents of Lecture

Workshop 1: Software Architecture Design & Evaluation – Introduction to software architecture. Place of software

architecture process in the whole software life cycle.

– The issues surrounding modern software architecture: heterogeneity, reusability etc.

– The decisions making process leading to architecture definition. the interlocking views underlying the architecture of a software intensive system.

– Evaluating Software Architectures: Architecture Tradeoff Analysis Method (ATAM), Software Architecture Analysis Method (SAAM), Active Reviews for Intermediate Designs (ARID).

17CS590L - Lecture 1

Contents of Lecture

Workshop 2: Design Patterns– Overview of design patterns. Introduction of the

techniques and notations provided by the UML for modeling design patterns and architectural patterns.

– Overview of Java design patterns. Introduction to Design Patterns, Behavioral Pattern (Visitor, Iterator, Observer) MVC pattern, Creational Patterns (Factory, Singleton), Broker Pattern.

18CS590L - Lecture 1

Contents of Lecture

Workshop 3: Distributed Component Architecture• Characteristics of Current Computing environment and

Requirements, Component-based development? Importance of software architecture?

• Object Oriented Middleware Technologies (CORBA , EJB, COM): Architecture, services, facilities, application design and Implementing

• Web Services: Simple Object Access Protocol (SOAP) and Universal description, discovery, and integration.

• Software Agent: Intelligent agent, Interface agent, Mobile agent.• Microsoft's new .NET Framework: Introduction to the .NET

platform, Object-oriented programming in C# , COM, COM+, and .NET interoperability, ASP and ASP.NET programming for Web development

19CS590L - Lecture 1

Contents of Lecture

Workshop 4: Advanced Topics• QoS

- Real-time architecture design - Process-oriented architecture design- Fault-tolerant architecture design - Secure software architecture design

- Architectural Composition- Integration of legacy systems - Embedded systems architecture design

- Tools: - Version-control and configuration management (VCCM) - Project management (PM)

CS590L - Lecture 120

Distributed Component Archicture

21CS590L - Lecture 1

Today’s Computing Environment

• Today, anything and anyone must be net-enabled.

• Automated business processes, products, and software systems need to evolve in “E-Time”.

• Everything must be changeable, extensible, adaptable.

• Quality is an important issue.

• How can we balance these forces

22CS590L - Lecture 1

Today’s Software Systems?

• A software environment (i.e., Internet) is evolving rapidly and software requirements and technologies are also evolving very rapidly.

• Some requirements and characteristics of the current system can be determined as comparability, heterogeneity, scalability, openness, security and distribution.

• Are you ready for this? It is necessary to understand the current trend of software systems and to identify the technologies and requirements for the system development.

23CS590L - Lecture 1

Problems to be tackled

• Web- and Net-based Integration of Applications, Services, and Systems

• Quality of Service issues such as availability, resource and time constraints, ...

• Deployment of Automated and Autonomous Systems

• Smart Services that share and distribute context

• Flexible Data Exchange

• Software as Service (aka ASP)

24CS590L - Lecture 1

Evolving Requirements and Technologies

• In the stone ages (i. e., a few years ago) – most applications were non- distributed, running in an almost

homogeneous enviroment, developed with a “stable” set of requirements, using a limited set of external interfaces, using proprietary technology. This approach does not work anymore.

• In the new age (i. e., since the Web) – most applications are: distributed, running in an increasingly

heterogeneous environment, developed with an “instable” set of requirements, interoperating with many different external interfaces, using standard technologies. This approach works but has some drawbacks.

25CS590L - Lecture 1

Why “agility” does matter

• Developers cannot make too many assumptions about usage contexts and environments a priori.

• Developers don‘ t live on an island and must interoperate with legacy code.

• Running applications must be reconfigured instead of recompiled.

• Software Engineering must cope with change requests in Internet time.

• Programmers need to develop and deploy their software on different heterogeneous machines and devices.

26CS590L - Lecture 1

Architectural consequences

• Software should not be designed as monolitic unit but partitioned into composable services that can be spontaneously connected and orchestrated by business/ technical processes (component- based software).

• “Software entropy” should be maximized: loosely coupling between peers, decentralized information access, reflective approaches (Just- in- Time Integration).

• Software must be e- nabled. Legacy code must be integrated in order to protect investments.

• Can today‘s Web technologies offer an appropriate solution?

27CS590L - Lecture 1

But there are some limitations ...

• While the backend has always been subject to evolutionary change, the frontend remained the same:– Only human users can access services and information.– Backend and frontend denote different worlds connected

by HTTP but separated by the Web Server barrier.• Using Java applets and middleware doesn‘t work because

– security restrictions imposed by firewalls,– huge number of different middleware technologies

available.

28CS590L - Lecture 1

Web-Middleware-Archtecture

• The Web as Middleware Technology • What we need is middleware that supports a Web of

loosely coupled, composable, networked services. – We need standard middleware to connect applications, services,

and legacy systems.

– We need XML applications for data formating and transfer between these software peers.

– We need Web protocols for interoperability.

• However, these technologies are currently not well integrated with each other.