CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932...

28
CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 [email protected] www.sice.umkc.edu/~leeyu

Transcript of CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932...

Page 1: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

CS590L - Lecture 11

CS590LDistributed Component Architectures

Yugi Lee

STB #555(816) 235-5932

[email protected]

www.sice.umkc.edu/~leeyu

Page 2: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@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++)

Page 3: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

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.

Page 4: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

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.

Page 5: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

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

Page 6: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

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.

Page 7: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

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.

Page 8: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

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.

Page 9: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

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.

Page 10: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

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.

Page 11: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

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.

Page 12: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

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

Page 13: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

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.

Page 14: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

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

Page 15: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

15CS590L - Lecture 1

Presentation & Discussion

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

Page 16: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

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

Page 17: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

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.

Page 18: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

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

Page 19: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

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)

Page 20: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

CS590L - Lecture 120

Distributed Component Archicture

Page 21: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

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

Page 22: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

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.

Page 23: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

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)

Page 24: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

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.

Page 25: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

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.

Page 26: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

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?

Page 27: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

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.

Page 28: CS590L - Lecture 1 1 CS590L Distributed Component Architectures Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu leeyu.

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.