Component Software

1. Component Software An Introduction Martin Naedele Industrial Software Systems CHCRC.C2

2. Objectives • “Get the feel” for the concept of component-based SWE • What are components? • What are components not? • What are components good for? • Know the terminology and the important acronyms • Know where the limits and problems are Not • How do I do “X” with technology of vendor “Y”? • a programming course

3. Topic overview Part 1 The challenges of SWE - how can component SW help? 2 What is component software? 3 Elements of a component infrastructure 4 Specific component models 5 Developing SW with components - some guidelines 6 Problems and research issues 7 Sources of further information

4. Part 1 The challenges of software engineering - how can component software help?

5. Terms component • a piece of software, definition discussed later component-based software (CBS), aka component software, aka componentware • application built from components component-based development (CBD), aka component-based software engineering (CBSE) • the activity of building applications from components

6. NATO conf 1968 SW crisis SW engineering components Software engineering problems The “software crisis” (1968) still exists: • SW is late • SW is buggy • SW is expensive Component software - yet another “silver bullet”?

7. SWE problems and component SW • SW is late • SW is buggy • SW is expensive … because too often applications are created instead of constructed,requiring • re-invention • re-coding • re-testing Component-based software engineering can help because it focuses on reuseof • subsystems • infrastructure Also, applications are not adaptable to changes

8. Component-based software construction (1) components Component #1 construction application Component Component Component #1 #2 #4 Component #2 Component Component #3 #4 Component #3

9. Component-based software construction (2) application Component Component component #1 #2 New Component #4 Component Component #3 #4 update

10. Side remark: OO and reuse Object orientation is not primarily concerned with reuse, but with appropriate domain/problem representation using the technological enablers • objects • classes • inheritance • polymorphism [Wegener] Experience has shown that the use of OO does not necessarily produce reusable SW • fragile base class problem

11. Expectations from comp.-based development Reuse of components should • improve productivity, speed up development • reduce risk • improve robustness, increase quality • generate additional income Reuse has two forms reuse of a component in a different application fast construction reuse of an application of which parts have changed evolvability, extensibility

12. The promises of component SW - quotes Microsoft: “Monolithic solutions won’t work • No one vendor or one team of programmers can move fast enough • Need to leverage others’ work and to build and ship smaller pieces incrementally • Need to evolve smaller pieces asynchronously without sacrificing the whole” Gartner: “Component-based development is an evolving best practice” “By 2002, 70 percent of all new applications will be deployed using component-based application building blocks.” “... components can improve programmer productivity by 40 percent or more…” “Through 2004, IS organizations that are mature in CBD methods and that use a model-driven or pattern-based application development framework containing a large inventory of business components have the potential to be 5 to 10 times more productive than those that do not.”

13. Part 1 - Summary The challenges of SWE - how can component SW help? • Reuse is the solution to many problems in SWE • CBD focuses on SW reuse • CBD tries to avoid re-creation of code • OO is a technology that facilitates creation of new code (if necessary)

14. Part 2 What is a component?What is component-based software?

15. The history • Structured Analysis • functional decomposition, hierarchy • Object Orientation • encapsulation of state and behavior • domain modeling • interactions • inheritance • Frameworks • domain-specific reusable infrastructure • Patterns • reuse of abstract mechanisms, experience • Component-based SW • ??? interfaces Not really: 1968

16. Component definitions … are a hot academic research and dispute topic: client-centered connectors usable in unanticipated contexts events self-contained contracts reusable independently deployable compositional encapsulated visual programming provided interfaces distributable quality of service binary COTS required interfaces configurable boundaries

17. Component definitions … are a hot marketing topic: COM+ ActiveX DCOM controls Corba COM language independent EJB platform independent JavaBeans binary .NET builder tools

18. Pragmatic definition of CBS Components • independently deployable SW entities with a certain functionality which • can be composed into larger systems by means of dynamically discoverable, immutable interfaces following standardized conventions. Component-based software (CBS) consists of • connected components on multiple levels which also extensively use • services provided by the runtime infrastructure of the component model

19. Terminology • Component object, component instance: actual occurrence of a component in a running system • Component class: abstract template for the creation of component instances • Component:conceptual building block of a system, depending on context the term used for any of the above • Component model: conceptual and implementation framework for writing and working with components • languages, platforms • runtime infrastructure, functionality, and API • technical details of interface and distribution implementation • … more later Examples: MS COM, Sun EJB, Corba

20. IBar IFoo IFoo2 Interface Group of related methods that specifies a contract between user and provider of the interface • usually only syntax explicitly specified, semantics implicit • concept of a contract also includes • semantics • non-functional properties, quality of service • negotiation • once public, it must be immutablewith respect to • functionality • syntax • semantics • implementation may change at any time A component may provide / implement several interfaces

21. Interface description: (M)IDL (Microsoft) Interface Definition Language [ uuid(00112233-ABBA-ABBA-ABBA-BADBADBADBAD), object ] interface IAddressList { HRESULT addAddress ([in] name, [in] address); HRESULT deleteAddress ([in] name, [in] address); } • language independent interface specification • can be compiled into language dependent code skeletons

22. Infrastructure “30 % of SW development effort is spent on infrastructure that adds no value” • Goal Developer should concentrate fully on the application instead of spending time on reccurring side issues • Each commercial component model offers ready-made infrastructures for e.g. • transactions • distributed computing • persistence, DB access • security (access control) “The COM+ philosophy: The runtime does all the grungy stuff” [Microsoft] more later...

23. Multi-level programming • Performance oriented languages (C, C++) • Application development languages (Java, C#) • End-user languages/GUI builder (Visual Basic, visual programming, scripting) • Configuration (attribute based programming (ABP)) • security rules, user roles • database names • distributed deployment • feature set/available subsystems • transaction requirements … are set at installation time

24. Application Server Multi-level programming with application server An application server can be - a Web Server, - a Database Server - a CORBA Server - a TP-Monitor … Client Client ... Imperative Programming Server Component Server Component Transaction Security Resources ... Transaction Security Resources ... Attribute Based Programming

25. Multi-level programming Here: EJB approach Bean Provider A Application Assembler plugs beans together Deployer puts beans into containers Container Provider Server Provider Bean Provider B System Administrator configures and administrates enterprise environment [SUN]

26. CBS vs. subsystem structuring Component-based system • focus is on interfaces between units • multiple instances of one component (class) in the running system • composition, bottom-up System with subsystems • focus is on functional units • subsystem is singleton • structuring, top-down

27. Component aspects Depending on the point of view, components are units of • functionality • reusability • purchase/outsourcing • deployment • maintainability • quality management • documentation • … When discussing CBSE it is important to ensure that everybody talks about the same aspect.

28. Part 2 - Summary What is component-based software? • No clearly defined concept • No revolutionary technology • Most important features can be summarized as • interfaces • infrastructure • multi-level programming • CBSE is not really (only) about components

29. Part 3 Elements of a component infrastructureWhat does it offer?How does it work?

30. Infrastructure • All commercial component models offer runtime infrastructure support to allow the developer to concentrate on the business logic • infrastructure = middleware • certain architectural patterns can be found in all component models Knowing these patterns will make it easier to understand a particular vendors component infrstructure

31. Component infrastructure functionality (1) • runtime component/memory management • service/component discovery (naming, broker) • transparent distributed computing • security (access control) • persistence, DB access • transactions

32. Component infrastructure functionality (2) • message queues • event handling • fault tolerance • error isolation • load balancing, pooling • WWW connectivity • data exchange over open protocols

33. Communication Data Streaming Request/Reply Publish/Subscribe Message Queue Eventing Naming Service (HTTP,IIOP, RMI, DCOM) State Management DB Connection Pool Load balancing - Multi-Process - Multi-Thread Object Cache Object Cache Transaction Service Security Service Lifecycle Management Web Integration Legacy Integration EJB COM DB CORBA Servlets Business Logic (Components) Generic component runtime

34. Architectural pattern (1) Proxy, aka proxy-stub, aka stub-skeleton used for location transparency, distributed components, inter-process component access Data packaging (marshalling) and transfer transparent for the user „stub“ (local proxy) „skeleton“ (remote proxy) remote object client server

35. Interfacespecification in IDL Generation of proxies from IDL Part of CORBA, JavaIDL, or COM implementation IDL Compiler Client Stub Server Skeleton Proxies Programming language dependent source code to be compiled into client and server application

36. Location transparency aka distributed computing Goal Realization with proxy client server naming service/ broker

37. IBar IBar ISerialize ISerialize IFoo2 IFoo2 Architectural pattern (2) Allows object/components to “hibernate” Serialization used for storage or transmission • the component writes/reads itself to/from a stream • serialization is started using a specific interface of the component IBar ISerialize IFoo2 deserialization serialization

38. IFoo Architectural pattern (3) Inheritance by delegation used for implementation reuse • components do not use implementation inheritance to avoid dependencies and anomalies • a call to a method of an interface of a component is passed on (delegated) to a different component that implements the actual functionality delegation IFoo IFoo2

39. Architectural pattern (4) Interception used to give the runtime infrastructure control over calls to a component’s interface, e.g. for • access control • instrumentation and logging • location transparency (see proxy) • ... Server process Application Server Securityservice Application client IFoo IFoo

40. Architectural pattern (5) Dynamic connections, aka events used for communication between partners that are only known at runtime • follows publish-subscribe pattern • notification may be asynchronous <<Interface>> MyEventListener myEventOccured() aSender aReceiver addMyEventListener(this) myEventOccurred(...) removeMyEventListener(this)

41. Part 3 - Summary Elements of a component infrastructureWhat does it offer? How does it work? • All component models offer similar runtime infrastructure services, though under very different names • These services are implemented using certain architectural patterns

42. Part 4 Specific component models

43. Definition Component model Conceptual and implementation framework for writing and working with components • interface structure • interaction mechanisms • guidelines on implementation or A vendor’s approach towards writing components and providing infrastructure Presented here: • Microsoft COM / ActiveX • Microsoft .NET • OPC • Sun EJB • Sun JavaBeans • Corba

44. Purpose Not all component models have the same purpose • (D)COM, EJB, Corba: • distributed computing • infrastructure for multi-tier systems, integrated with middleware • components usually business objects • JavaBeans, ActiveX controls: • creation of GUIs • visual programming using builder tools • have design-time and run-time user-interface • have properties • communicate with events

45. COM

46. Microsoft COM (Component Object Model) • General purpose component model • Basic technology behind multiple marketing names • COM, DCOM, COM+, ActiveX, OLE, Automation • History • developed in 1995 • since W2K COM+ with enhanced infrastructure • since 7/00 future unclear because of .NET • Design goals • simplicity (of concept, not use!) • performance (zero sacrifice if used in process) • binary compatibility

47. Microsoft COM: key features • infrastructure ‘COM runtime’ built in on Win OS • ‘binary compatibility’, language independent • requires implementation of interface ‘IUnknown’ • uses ‘GUIDs’ (globally unique IDs) to name interfaces etc • location independence (in-process, cross-process, cross-machine) • supports distributed computing with DCOM wire protocol • component deployment as DLL or EXE • programming languages HTML/ASP, VB and VC++

48. Microsoft COM: location transparency (1) Client Server Object runningon client Remote object onany server COM over DCOM COM Object runningon client

49. Microsoft COM: infrastructure • transactions: MTS • message queues: MSMQ • database wrapping: OLE DB, ADO, ... • security functionality using WinOS • multi-user functionality using WinOS • broker/discovery: runtime + registry • multithreading

50. Microsoft COM: ActiveX • ActiveX controls: GUI component model on top of COM • certain additional conventions • visual programming with builder tools, e.g. VB • properties and events • downloadable code (web scripting) • security issues! (no sandbox, codesigning only)