Overview

• Caveat #1:  the numbers following topics are position paper numbers.  They are probably a poor guide for which papers cover which topics for several reasons:  (a) they are incomplete so more papers may cover a topic than are listed, (b) transcription from position paper to keywork to index lost information resulting in some papers being miscategorized, (c) the category scheme could use more work, and (d) errors inevitably creep in.
• Caveat #2:  It is worth pointing out the obvious -- workshop papers only begin to reflect the work of workshop participants and hardly reflect the work of others not participating in the workshop.

Instructions

• address email to thompson@objs.com
• subject "INDEX - paper XXX" where XXX is optionally your paper number
• the body of the message should be an html copy of this document with color-coded markup showing the changes

---

Defining the Problem and Solution Space

• Workshop Communities
• OMG, W3C, DARPA, dbworld, seworld
• research, industry/products, defense, standards
• Application Areas
• architecture analogy - buildings, bridges, building codes, …
• human analogy - nervous system, immune system, digestive system, … 3
• human analogy - marriage, family, work, school, church, teams, ...
• organizational analogy - hierarchical, matrix, virtual enterprise 3, cross enterprise, virtual office, span organization boundary
• internets, intranets, extranets, virtual private networks
• C4ISR 51, 53, 68, 69, 7185, 88
• logistics - material 40, information, software 27
• electronic commerce 4, 77, payment
• global transportation networks 6
• electric utility grids 97
• engineering design 20
• telco 10, 35, TINA 33
• semiconductor and manufacturing 3, 13
• healthcare 31,32
• public administration
• wireless 3
• collaboration
• separation in time and/or space
• collaboratories 75
• multimedia 10
• simulation 83, 85, HLA
• workflow 43
• Vision/Motivation 17, 25, 58, 82
• the problem
• huge investments in legacy monolithic stovepipe systems that cannot interoperate and are expensive to maintain and inflexible
• economy for component software is slow to materialize
• wanted
• software that functionally solves the problem, performs as needed, but is more configurable, adaptable, maintainable, evolvable, survivable, affordable, ... (see ilities)
• architecture-driven engineering
• accelerate economy of components
• approach:  component software
• megaprogramming 63, programming in the large 7
• system of systems 2, 95
• implies heterogeneity
• architecture driven design 6
• productivity 9 via reuse
• preserve investment in legacy code, move to open systems 88, 95, 106, continue to evolve 57, meet changing business needs
• rapid application development, component assembly 38,
• understandability, maintainability, affordability, reliability, trust, simplify training
• best of breed 54, plug-and-play, mix and match
• avoid reliance on single smart individual or company 9
• alternatives to component approach - TBD
• Barriers, Roadblocks
• to reuse 12, assumptions limiting reuse 27,
• design for reuse requires thinking
• expense to retrofit, difficult to predict 71
• rogue components 84
• large footprint 17
• distributed systems are less secure
• IDL mappings create complexity, harden boundaries
• need library, not executables 71
• too much knowledge required, complexity
• choice of infrastructure foundation as irrevocable commitment
• legacy constraints on solution
• component compatibility 57
• closed DBMS, compiler, workflow, ... don't provide enough hooks for application extension or for ilities
• middleware infrastructure required - how much, how standard?
• monolithic middleware 61 - are services portable across ORB vendors? nyet
• limitations of DCOM, CORBA 17, 69, 74, 78
• economy of components, tech transfer 4, 17, 55, 100
• immature
• component marketplace 7
• market sizes
• middleware marketplace
• much smaller than overall component market place
• prerequisite for component market place
• should be viewed as underware 61 (hidden from view)
• ISSUE:  will O/S absorb middleware?
• communities of interest 9
• vendor viewpoint
• how to build competitive advantage
• what constitutes (un)fair competitive advantage?
• customer viewpoint
• RAD, business process improvements
• how to preserve investment
• usability, stability, functionality
• decrease and amortize cost 2, always prefer pay me later to pay me now, want no discontinuiies
• does customer want dozens of different models to choose from and a price ladder or just a few distinct models to pick from (analogy with GM vs the competition)
• 5-10 components versus 1000s, pre-assembled systems versus toolkits
• winning the architecture wars
• does marketplace favor one dominant vendor, many middle tier vendors, millions of micro vendors
• is there an analogy to many varieties of Unix fragmenting the Unix markeplace
• is there an analogy to many varieties of object model forcing application builders to select one, which then locks in many or most other choices and also obsoletes the technology when that object model falls from favor?
• is there a danger with so few independent ORB vendors?
• will ORBs be subsumed into operating systems like TCP/IP
• is OMG behind in component models? how can it become more Java friendly?
• is a consistent architecture needed for component composition, complete with standards like OMG services - if so, is there an 80% solution that most will adopt?  Can it be grown to a 95% solution with openness addons?
• what are roadblocks and new ideas to make component marketplace take off
• house built on sand, what is preserved and for how long?
• microlicense
• how much should a component cost
• certification, level of assurance
• component catalogs, search engines 27
• Lessons Learned 51, 68, 69, 71, 78
• IDL2Java mapping not too seamless 67
• fractals - progressively more detail
• can't use commercial services, can't extend 71
• third party services
• peserve investment via modeling 31
• Architecture Challenge Problems
• integrating web and DBMS 38, 88
• integrating web and ORBs 38, 103
• validation:  can you construct an OODB (or workflow engine) from components/services like persistence, transactions, queries
• set up ski trip - pool of providers, negotiation, proposals
• survivability of component software 14

---

Technical Approaches

• Architecture 7, 17, 68
• definitions
• key concepts
• components
• connections, wiring 39
• constraints, design principles, building codes
• concepts
• cast as problem solving
• requirements 7
• abstraction
• views
• system of systems 2
• architectural principles and ilities -- see ilities
• architectural styles 6, 106
• features mismatch 51
• design patterns 80, 95, 100
• commitments 37
• aspect-oriented programming 43, 46
• foundations 13, 50, 52, 61, 64, 91
• rewrite logic 64
• subkinds
• reference architecture
• technical architecture
• application architecture
• domain specific software architecture (DSSA)
• ORBS and object service architectures 17
• architecture modeling 106, see Component Model
• architecture description languages (ADL) 80, 84, 91
• systems mentioned:  Rapide 6, ACME 6
• state machine modeling
• methodology
• from pattern to reference architecture to components to services 69
• operations on architectures
• decomposition, deconstruct operator 42
• assembly
• composing two heterogeneous architectures (e.g., web and ORB)
• subsetting an architecture
• customization 71
• instances of a general architecture 95
• if FW1 = FW2 except they vary wrt service X then are they interoperable modulo service X?
• replication of components
• locating gaps
• locating stress points
• deploying 63
• templates 80, unification
• framework for multi-level software engineering
• architecture alignment and mismatch
• ISSUE: initial architecture clean, warts appear during evolution.  fractal analogy - as time passes, entities always accrete more detail, new aspects
• ISSUE:  OMG does not have a standard way to specify connections and constraints tho the current Component Model RFP submissions address connections
• Standards of interest
• OMG 17
• W3C
• Javasoft
• ActiveX, DCOM+, ...
• IETF
• COE
• ODP
• WfMC
• X3H2
• Open Software Description 63
• Desktop Management Task Force 63
• ...
• Object Modeling 53
• ontology 68
• prototypes 40
• encapsulation prevents mix-and-match 37, fishnet lets apps bind to the level of abstration they need 74
• inheritance does not scale 8
• delegation 66
• reflection 64, 66
• UML 231
• web object model 22, 32, 38
• actors, multi agent 4, 10, 17, 23, 40, 56, 63, 82 objects versus agents, autonomous
• oo interaction protocols 43
• Taxonomy of Components
• application-specific frameworks
• vertical domain-specific application-generic components
• OMG domains like GIS, transportation, manufacturing, electronic commerce, telcos, ...
• STEP
• CIM framework
• business services like order entry, customer service
• ISSUE:  criteria for partitioning domain spaces, experience
• horizontal middleware components
• horizontal frameworks, common facilities
• workflow
• OODBMS
• GUI frameworks
• Business Object Frameworks
• horizontal services
• existing OMG services
• currently missing OMG services
• triggers as extensions to event service w filtering added 33, 71, 97
• version, CM 69, 91, 97
• caching, memoizing 68, 91
• replication 34, 65, 81
• publish-and-subscribe 30, 68, announce-listen 82, notification 33
• objects-web 69, 103
• situation model 69
• map service 68
• planning services 68, 71
• scheduling services
• simulation services
• meta components - component infrastructure
• IDL
• ORB
• interface repository
• event and interceptors, rules service, pre and post conditions, see intermediaries
• component models, see Component Model and Tools
• ilities - see ilities
• security services
• ISSUE:  what is the basis for this taxonomy?  what does it include, exclude, preclude, explain, not explain?  does every piece of software fit?  OA&D, compilers, ...? compound document frameworks like OpenDoc 39
• Component Model, Representing Components 7, 17, 18, 23, 66
• define (and differentiate) 12, 69
• class library
• component, brick 3
• service
• framework 4, 95
• common facility
• methodology:  from pattern to reference architecture to components to services 69
• concepts and properties of component
• granularity 35
• small number of large components versus large number of small components
• GUI button - framework - spreadsheet - legacy app
• legacy components as large black boxes
• abstraction layer, isolation, separation of concerns, aspects, orthogonal, independence, scope 43, 80, 91, 95, 102
• visibility - limited 7, opaque 84
• black, translucent, white box components 39
• hide unnecessary complexity 9
• hide methods and private aspects you don't want user to be aware of using IDL 67
• separate application logic from ilities, business rules, middleware concerns
• application-transparent X where X = {security, reliability, survivability, ...}, X-unaware 80
• hidden dependencies 13
• breaking encapsulation
• encapsulation prevents mix-and-match by hiding composition 37
• fishnet lets apps bind to the level of internal interface abstraction they need 74
• drill down thru abstraction layers 59
• components manage their own storage, don't assume different components will execute in the same address space, no co-location exploitation  7, 42
• services are stateless
• views 37, 38, 69
• multiple interfaces
• layered architecture 80
• boundary 36
• packaging 13
• interfaces, types, 42, reduction of surface area
• binding  7, 23, 66
• binding time - static versus dynamic, dynamically reconfigurable 49, 66, 68, 82
• loose versus tight coupling 33
• early 30 versus late
• broker, marchmaker, trader 25, 41, negotiation 25, 77, auction 77, alliance 43, discovery 82
• mismatch analysis
• type broker 55
• mediator 97
• gateway
• wrapper 51, 65
• indirection
• roles 23, 30, 66, 84
• control - who can bind in new components?
• component developer, component-based application developer, end user, security expert, system management expert, configuration control expert, network provider, dbms provider
• avoid making programmer expert in application and vertical technology 9
• context 23
• metadata 56
• introspection 25
• substitutability 7
• customization, specialization 71
• many instantiations 7
• component-based software must be programming language independent 8
• system linker required 8
• component as COTS
• economic unit 2
• component representations
• module interconnect formalism 30, 37, 50, 66, 71, 74, 78
• what architectural attributes to record? 10, 84
• design record
• specification 25
• features mismatch 51
• meta model 8
• relationship to MOP 88, OA&D, MOF, CBO?
• containment model 8
• container
• components and connectors 7, 23, 30109
• reified relationships/roles/connectors
• floor interfaces
• dependency graph, topology 63
• wrappers 65, 66
• GUI interface 30
• component composition 17
• glue code
• written by hand versus generated 7
• scripting 12, 57, 51, 70, 78
• Python 70
• JavaScript,
• Tcl
• service composition 17, 102, 103
• serial, parallel, compositional 36
• algebra
• via meta-level architecture( hierarchies) 38
• floor interfaces
• layers - is this idea useful? 7, 10
• inheritance versus delegation 67
• ORBs + populated set of services don't explain but don't preclude connecting up services in multiple ways.
• component acquisition/discovery
• using Web tools for 38
• issues
• no best scheme in factoring
• component model exposes versus encapsulation hides
• issue:  satisfying architecture constraints - do component models address how to do this?
• issue: representing patterns of interaction
• partial evaluation 42
• architectural principles
• OMG has a list of these - see OMG Object Services Architecture or any OMG RFP
• architecture properties, Ilities 17, 30, 37, 39, 40, 64, 80, 82, 95, 103, 106
• general
• meta-architecture 81
• non-functional requirements, aka generalized QoS
• design for -ility
• consistent, complete, gaps?
• ility pattern
• separate application logic from ilities 80, 95
• specific ilities
• functionality
• performance 38
• affordability 31, 59
• usability
• understandability
• simplicity 46, managing complexity
• stability
• reliablity
• availability 106
• fault tolerant 88
• scalability 17, 27, 33, 82, 103
• by federation 17, 41, 77, service replication 39, 40
• upwards, downwards 38
• distribution transparency 38
• evolvability 25, 37, continuous evolution
• openness
• plug ins 39, 40
• seamlessness
• flexibility
• configurable
• adaptable 49, 88
• security 36, 76, 82, 84
• safety
• trust 84
• high confidence 82
• information assurance
• survivability 9, 14
• timliness
• mobility 106
• QoS 10, 81, 88, 99
• uses as a general synonym for -ility
• used in the narrower bandwidth-aware sense 68, 69
• system monitoring 88
• system management, administration 35
• safety 15
• real-time 34, 37, 46, 59, 88, soft or hard
• managing inconsistency 69
• ility infrastructure
• QoS specifications 42
• bus architecture 91
• add or control ilities via communication path, connectors, abstraction layer -- see Intermediaries
• resource management 23, 81
• scheduling, time synchronization 99
• metadata
• repository
• MIB 10
• control 41
• centralized
• de-centralized 39, 40, 52
• autonomous 58
• coordinator 76
• policy 23, 25, 63, 69, 81, 84, 99
• enforcement 84, guardian 37, 76
• run-time 23
• composition or preservation of ilities
• end-to-end composition 36, 84
• top-to-bottom composition
• X-unaware vs. X-aware components
• bandwidth aware or unaware
• security unaware 80
• interoperability
• different definitions
• unplanned reuse
• components are interoperable if they can interoperate
• components are interoperable if they satisfy the replacement test
• component model interoperability: CORBA, ActiveX, Java Beans
• COM, CORBA, Bridge 53
• bidirectional mapping 53
• issues
• are all ilities the same complexity and handled by insertion into communication paths? 46
• ility tradeoffs 37, composing multiple ilities 23
• optimization versus modularity 25, 106, 42
• binary compatibility
• Intermediaries 30, 46, 66, 82, 84, 95, 102, 103, 109
• problem to avoid:  calls to ilities interspesed in code 95
• technical ideas
• interpose 66
• event and interceptors, rules service 101, pre and post conditions filters 33
• bidirectional mapping 53
• model-view-controller without a GUI as two abstractions interact via an intermediary object
• guards - the request must go through the middle layer 3
• middleman, trusted third party, certificates 82
• mediator
• examples
• DCOM+ interceptor 34, 98, CORBA security interceptor
• IDL2Java mapping 67
• web proxy intermediaries 102, 103, PEP 4, 102, 103
• uses
• place ilities in communication paths
• monitor 2
• debug 2
• Web 6, 17, 56, 102, 103
• web of trust
• web-ORB integration 38, 88, 103
• web object model 22, 32, 69
• ORBs 17
• services not tied to a particular ORB 3
• systems
• ILU 88, SYLU 88
• lightweight ORB 20, 38
• underspecified 69
• ActiveX, DCOM
• composition rules 52
• Metrics
• reuse statistics 100
• Tools
• architecture modeling tools 91
• architecture interchange formats 6
• OA&D, UML, MOF 13
• infrastructure for components
• GC 15
• deployment 25
• test
• failures 46
• debug 38, 58, 97
• monitor 97, audit trail 97 - capture, record, display, playback
• test automation fw
• communication flow, dependency analysis 2
• failure propagation, fault injection 2
• impact analysis 2
• conformance 13
• component catalog, repository, search engine 27
• visual component assembly tool 8, 10, 38, 39
• toolkits 51
• simulation