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

2. 2 CS590L - 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++)

3. 3 CS590L - 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.

4. 4 CS590L - 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.

5. 5 CS590L - 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

6. 6 CS590L - 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.

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

8. 8 CS590L - 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.

9. 9 CS590L - 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.

10. 10 CS590L - 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.

11. 11 CS590L - 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.

12. 12 CS590L - 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

13. 13 CS590L - 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.

14. 14 CS590L - 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

15. 15 CS590L - Lecture 1 Presentation & Discussion Each student will be participated in three types of presentations & discussion  Workshop  Paper  Project  Lab

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

17. 17 CS590L - 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.

18. 18 CS590L - 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

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

20. CS590L - Lecture 1 20 Distributed Component Archicture

21. 21 CS590L - 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

22. 22 CS590L - 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.

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

24. 24 CS590L - 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.

25. 25 CS590L - 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.

26. 26 CS590L - 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?

27. 27 CS590L - 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.

28. 28 CS590L - 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.