db lm wp ns gw njs hullo! i'm a synopsis, NOT a synApsis! testing 1.. 2.. 3.. db lm wp ns gw njs hullo! i'm a synopsis, NOT a synApsis! testing 1.. 2.. 3.. db lm wp ns gw njs hullo! i'm a synopsis, NOT a synApsis! testing 1.. 2.. 3.. db lm wp ns gw njs hullo! i'm a synopsis, NOT a synApsis! testing 1.. 2.. 3.. db lm wp ns gw njs hullo! i'm a synopsis, NOT a synApsis! testing 1.. 2.. 3.. Date[ June 24, 1998] Recordnr[ ] Stored[ Composition papers Who[ M.-C. Shan, J.W.Davis, et al Title[ Business Process Flow Management and its Application in the Telecommunications Management Network Published[ HP-Journal, October 1996 Keywords[ workflow, composition, Comment[ Summary[ The paper describes HP OpenPM, now called changengine and used by several banks. It is advanced workflow technology based on a framework approach for reusability. Goals of changengine: - substantial evolution from traditional workflow technologies - for distributed heterogenous computing environment (several procotols via wrappers) - it is a middleware system for procedural automation of a business process by managing the sequence of process activities, including the invocation of appropriate human, instrument or computer resources. - content, structure of process can be preplanned or ad hoc Main elements: - Process engine: based on the business process definition (graphically, rules) the process engine determines when something takes place and triggers activities. - Resource executive: manages resources - BOW: business object wrappers Definition of process: Graph containing work nodes and rule nodes. Each work node can again be a process containing work nodes and rule nodes. Work nodes have status initial or fired. Forward arcs denote normal execution flow, and they form directed acylic graph. Each work node can only have incoming arc, whereas rule nodes can have several incoming arcs (they have rules to deal with that). Both kind of nodes can have several outgoing arcs. Backward arcs are reset arcs, i.e. when they fire, everything in their loop is reset, and started tasks are aborted. Nodes fire like in a petri-net. Rules: e.g. "if Customer.approval = TRUE then arc 5" Events: rule nodes can also raise evens, which themselves can fire rules nodes that have subscribed to that event. Events are modelled like specific kind of nodes, like a shortcut for not drawing to many arcs across the graph. This kind of graph allows to describe: - sequencing and timing and dependancy of business activities, - data and physical agent allocation of business activities - business rules and organization policies Mapping of process definition to execution: Work node -- process activity(task) -- invocation of an operation on business objects(resource) during execution of a process BOW: BOW's wrap business objects and interface to the process engine via CORBA. Towards business objects they interface with various protocols, e.g. also DCOM and DNA. Business objects are catalogued in a library. Interfaces: from process engine are CORBA and WfMC (Workflow Managmenet Coalition standard interface) Optimization: Data handler: allows seperation of application specific data and process-relevant data needed for rule nodes, thus reducing amount of data flow. Resource manager: for automatic workload balancing. Statistical data: bottleneck analysis, flow optimization. References: - paper gives further references (not very new) - Reed Letsinger and Michael VantHilst at HP labs - webpage: www.pwd.hp.com/cyc/af/50/ is behind firewall Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J.M.Voas Title[ The Challenges of Using COTS Software in Component-Based Development Published[ IEEE Computer, June 1998, Vol31 No6, Guest Editors introduction Keywords[ COTS Comment[ Summary[ Software we acquire elsewhere: - COTS: commercial of the shelf - CAS: commercially available software - NDI: nondevelopmental item ==> used as components or componentware to build component-based software or systems of systems Problems in using componentware: - Components may integrate perfectly during development, but not behave perfectly at rntime. - We have process models for developing software from requirements, but not yet for acquiring software. - COTS are delivered as black box ==> how to determine that they behave safely, securely, and reliably? - How to access the quality of COTS? How to access suitability? Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J.McDermid Title[ The Cost of COTS Published[ IEEE Computer, June 1998, Vol31 No6, an interview Keywords[ COTS Comment[ Quite quite an interesting interview discussing general cost issues of COTS in contrast to bespoke (custom solutions), especially for safety- and reliability-critical system. The article is very critical towards COTS, mainly talks from a viewpoint of critical systems (process control systems, not information systems). Summary[ Promises of COTS: eliminate sfotware development project that overrun time and cost, greater ability to interoperate diverse systems, quickly evolve large systems, lower costs COTS nowadays: GUIs, operations systems, databases ==> mainly large components (and what about CERN-libraries, statistic tools etc.?) Risk mitigation: Problem: COTS are often build without a strict process and documentation control, no clear QA, and are delivered without appropriate documentation of the process, and without e.g. complete test-suites etc. (solutions: certification, using an escrow i.e. depositing the documentation at a bank for the case the company disappears). How to access the quality? - retrospective assessment is more expensive than assessing the software when developing it, if possible at all (code analysis) - each upgrade has to be assessed anew - software has not been written with the goal to access it (whereas bespoke for critical systems is structured and written in order to be accessed) - accessing needs also been done for all unwanted functionality (additional effort not necessary for bespoke) How to demonstrate the desired level of reliability, availability, integrity? - unwanted functions with dangerous side-effects How to control future of a COTS-component? - component can go out of business - new releases with unwanted functions - cost of upgrading - wrappers do not solve any of above problems Cost-tradeoff between COTS and bespoke: - price of purchase versus development - price of assessing quality of COTS to desired quality level - price of integrating COTS - price for upgrades, price for accessing upgrades, price for integrating upgrades - risk of vendor going out of business and expected life-time of system COTS can offer historical data for its quality (e.g. OS but not things like Microsoftword which get updates too often), bespoke has not historical data but you know what you are developing and can assess that. Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J. M.. Voas Title[ Certifying Off-the-Shelf Software Components Published[ IEEE Computer, June 1998, Vol31 No6, an interview Keywords[ COTS Comment[ Summary[ Three questions must be answered positively before using/certifying a COTS-component for a specific environment: 1 Does component C fill the Developer's needs? 2 Is the quality of component C high enough? 3 What impact will component C have on system S? Ways to answer that is by: a Black-box testing (answers question 1) b System-level fault injection c Operational system testing a and b together answer 2 and 3. Black-box testing: - best to build own oracle that tests comonents against needs of user and not against vendors specification - can fail to exercise important/faulty portions of the code System-level fault injection: Instead of the component a fault injector is put into the system (just the minimum amount of surrounding components is used) that works nearly like the component but randomly makes wrong results. Can the system stand that? Operational system testing: Problem: enormous amount needed for components that rarely fail. Advantage voer system-level fault injection: tests the real wrong behaviour. Remedy if component is not save enough: wrappers. Problem: Wrapper may not catch all the behaviour of a component. Date[ July 29, 1998] Recordnr[ ] Stored[ file-cabinet, Papers Composition Who[ J. Magee, N. Dulay, J. Kramer Title[ Regis: A Constructive Development Environment for Distributed Programs Published[ IEE/IOP/BCS Distributed Systems Engineering, 1(5): 304-312, Sept 1994. Keywords[ Comment[ Other papers about Regis/Darwin: Ng, K. and Kramer, J.; Automated Support for Distributed Software Design, appeared in 7th International Workshop on Computer-aided Software Engineering (CASE 95) Mostly describes the Software Architect's Assistant, a visual tool to set up distributed systems. Magee, J. and Dulay, N. and Eisenbach, S. and Kramer, J.;Specifying Distributed Software Architectures, appeared in 5th European Software Engineering Conference (ESEC 95) Presents a formal model of Darwin in Robin Milner's Pi-Calculus. Magee, J. and Dulay, N. and Kramer, J.; Regis: A Constructive Development Environment for Distributed Programs; IEE/IOP/BCS Distributed Systems Engineering},Volume = {1},Number = {5},1994 Describes the most recent distributed execution environment for Darwin-structured applications. Summary[ Darwin is a configuration language, Regis is a system supporting Darwin and generating the distributed systems specified in Darwin. For each component an interface is specified that contains all incoming and outgoing links. These can be of different types (pipes, ports...). The communications are implemented by special C++ components. The components to be configured/assembled can be either composite components, consisting of a set of lower level components, or computation components. Latter are written in C++ and must inherit from a predefined class process. Darwin also allows to imbed directly program code in the component descriptions. Components are garbage collected after termination. Regis runs on a Unix environment, the components can run on different Unix-workstations. A mapping file defines on which processor of the multicomputer which component is run. My conclusions: Regis supports program generation for a homogeneous environment. The distribution seems only to be local - I do not know if it is suited for servers located outside the intranet. The components that are composed are controlled entirely by the configuration language and by Regis (automatic garbage collection) - no autonomous servers that exist and run independant of the client. No equivalents to "EXAMINE", "ESTIMATE". Legacy code probably could be brought in, but I have not seen this issue being specifically adressed. As far as I know, no commercial application. Notes of Louis: I looked at a bunch of papers from Imperial College, London. The head of that group is Jeff Kramer, the relevant URLs are: Regis: http://www-dse.doc.ic.ac.uk/~regis/ Darwin: http://www-dse.doc.ic.ac.uk/~jsc/research/darwin.html Some of their work is relevant for RapArch, Architecture, and RapNet (see below). Regis has been in use since 1992. Darwin/Regis ============ Regis is a programming environment aimed at supporting the development and execution of distributed program. A Regis program consists of loosely coupled components either directly written in C++ (primitive components) or constructed out of simpler subcomponents by using the Darwin language. As such, Darwin is an Architecture Description Language (ADL) remarkably similar to the RAPIDE ADL. The Regis environment lets you develop the individual C++ components and the composition using Darwin, then compiles everything into executables and runs it on distributed sites. Regis/Darwin is restricted to the design/implementation phase. Once the program is compiled, installed and running, it is on its own, there is no support for ongoing analysis. One '95 paper said they will do run-time monitoring and management, but that will probably be primitive (i.e. just monitoring if they still run) and may not even exist. They stress the fact that a Regis program can be distributed (a la mobile agents), but I don't think that is the exciting thing about it. The Darwin ADL -------------- Darwin boxes are called "components", action declaration are called "services", arrows are called "bindings". Like RAPIDE, Darwin specifies both provided as required services. Services are typed and type conformance is enforced. Darwin allows hierarchical composition of components as well as parametrization, a component can consist of n subcomponents, with n decided statically at run time or dynamically at runtime. The latter is what they call dynamic architectures. In both cases, all n components have the same type, bindings, etc. This is just simple instantiation of a class. In some aspects Darwin is more general than Rapide ADL. The communication mechanism is not restricted to events. Darwin supports any communication mechanism (events, streams, RPC, etc. In Regis, the mechanism is then implemented as a C++ class). Thus the type of an action denotes the C++ class that implements it. A Darwin filter on a stream of characters would look like component filter { provide output; require input; } A funny thing happens when one looks at services of type "port". A port is used to send messages through and is interpreted in a procedure call style. Thus, to send a message, a sensor *requires* a port, the "output" becomes "required". The following comes from their paper and seems wrong for a RAPIDE person (at least for me). component sensor { provide input; require output; } I guess they run into this problem because they support both push (stream, event) and pull (port) communication with others. Pi-calculus ----------- Darwin is also specified in Milner's \pi-calculus. This is an elementary calculus for describing and analyzing concurrent, independent processes that communicate via channels. A subset of the Pi-calculus (http://www.cwi.nl/~arie/picalc.html) seems to be a candidate for our RapNet composition language. Software Architect Assistant ---------------------------- Regis comes with a graphical architecting tool called Software Architect Assistant (SAA), similar to RapArch. In comparison to RapArch, SAA's focus is more on providing semantics and ease-of-use and less on providing fancy drawing capabilities. All "boxes" have the same size, and "arrows" are laid out automatically by the tool and cannot be changed. (See http://www-dse.doc.ic.ac.uk/sel/sereports/rj1/rj1.html for an evaluation.) On the other hand, boxes and arrow have full semantic meaning, and correctness is checked at data entry point. The graphical and the textual view are always consistent. I especially like the separation between connections and interfaces. The "arrow" is just a line, the ending points indicating in which direction it points are part of the "box". This makes sense, because when you define a box, it is already clear which "actions" are "required" and which are "provided". SAA also displays nicely how services are connected when components are hierarchically encapsulated in each other. SAA also supports libraries of components, that can be included as sub-components in other components and it can read Darwin (textual) code not written by SAA. The SAA exports RTF reports that can be directly imported into word processors. Date[ August 5, 199] Recordnr[ ] Stored[Composition, filecabinet Who[ I. Ben-Shaul, et.al. Title[ HADAS: A Network-Centric Framework for Interoperability Programming Published[ International Journal of Cooperative Informaion Systems, 1997 Keywords[ heterogeneity, RMI, HADAS, coordination language, Comment[ Very interesting approach. More focused on roaming agents. Summary[ Challenge: Compose, configure and execute network-centric applicatins made up of widely-distributed components. Major problem: global interoperability Examples: active, intelligent information agents; inter-organization collaborative workflow systems, e-commerce, large-scale concurrent computations Main ideas of HADAS (=heterogeneous autonomous distributed abstraction system): - autonomy of objects: administrative autonomy (==> evolving over time), design autonomy (heterogeneity) - network centric framework - no central agent like a broker, fully decentralized (==> possible by using RMI) - dynamic and programmable approach to interoperability, peer-to-peer configuration agreement - ISL as coordination lanague Approch: - a (reflective and mobile object model abstracting components - a Java-based framework in which components live and communicate - a higher-order interpreted coordination language that manipulates components Basic architecture: The comonponents are distributed object managers. These not only implement various ilities like security and unique id and persistence, they also contain or wrapp the effective behaviour offered by this component. These objects communicate with each other mainly over RMI. They could also use ftp, http or amp. The whole HADAS system is written in Java. Access to legacy components is by wrappers - these wrappers, written mainly in Java, e.g. access CORBA-components etc. If necessary, they also use native code. As all of HADAS is Java, data is communicated in Java format. For type- mismatches, peer-to-peer dynamic wrappers exist that transform data. Levels of interoperability in Hadas: - interconnectivity infrastructure (in Java), reflective object model supporting mutability and mobility - integration : who can access whom? - configuration: dynamic agreemant between sites over use of comonents - coordination: control and dataflow between components, ISL Configuration: The operation to be called is link. What link does is: it copies a suitable ambassador objects to the other site. These ambassador objects then act like stubs. Ambassadors for the same siteobjects on various sites may have different dynamic parts in them. Each object supports methods like: add, remove (a method dynamically), invoke (a method with given parameters), describe (the offered methods). Ambassadors: - not just stubs, they have HADAS methods (install, update) - they have dynamic transformers (wrappers) and can evolve dynamically by interacting with hosting environment Reflective object model: - objects can answer questions about itself (given by Java) - object can change itself (addDataItem, addMethod, setMethod), trivial in Java - security specifications per method (probably all from Java) Wrappers: - dynamic linking to Java components - accessing C++ code with JNI - CORBA-HADAS, static wrapping - HTTP/CGI out and in transformer, dynamic wrapping Coordination, ISL: The language used is Scheme, implemented in Java. It supports weak typing and allows to encode higher-order procedures. http://www.dsg.technion.ac.il db lm wp ns gw Date[ May 27, 1998 ] Recordnr[ 1 ] Stored[ Composition Who[ Scott M. Lewandowski Title[ Frameworks for Component-Based Client/Server Computing Published[ ACM Computing Surveys, Vol.30, No.1, March 1998 Keywords[ CORBA, compound document, DCOM, JAVA, business object Comment[ Summary[ General impression: very pro CORBA, does not mention RMI, paper tries to cover a large area with doubtful success Middleware is defined to include the APIs used by clients to request a service from a server, the physical transmittion of the request to the network, and the rewulting transmission of data for the client back to the network. Middleware is run on both the client and server ends of a transaction. Three different kinds of middleware: - database middleware (ODBC, SQL, Oracle Glue) - groupware middleware (Lotus Notes, Microsoft Exchange) - inernet middleware (HTTP, secure socket layer) - object middleware (CORBA, DCOM) Furthermore: fundamental/generic middleware against domain-specific middleware. Fundamental: distributed file system, RPC, authentication... Various kind of systems: - fat servers versus fat clients: data on server, UI on client - is the application logic on the server or the client? - three-tier systems: application logic is separate ==> new level of autonomy for applicatino logic. Ex: web-applications with browser, applets or cgi-scripts, database - four-tiers: e.g. with additional second tier for unifying view of the data of the databases of first tier, (CHAIMS with new architecture would also be 4 tier system) CORBA is great!!!?? - "Technologies such as Java and object request brokers (ORBs) promise to provide seamless integration among all platforms within a few years." - "only CORBA and DCOM provide viable long-term solutions to the challenge of a standardized framework for object-based client/server systems, others do not have enough features or as great an installed base..." - yet CORBA is much better, because in DCOM e.g. no real objects (objects have no state, they are just procedures ==> handles to objects are arbitrary and only garuantee interface not object-state, no unique object identifier, no persistency supported) - also DCOM objects cannot automatically support multiple interfaces, - also clients cannot request for a specific given server, - also only using WindowsNT security model and no own universal security mechanism like CORBA - CORBA and Java are made for each other and together will win (???) ==> platform for universal network computing can be created using Java as mobile code systems and CORBA as integration technology Claims (not really true in my view): - java-interfaces and CORBA-IDL's are very similar (RMI transports code and methods, not just data!! ==> totally different kind of distributed programming) - CORBA allows parameters of any type (yes, it allows more than CGI, but not "any") Selfmanaging objects: - take responsibility for their own resources, work across networks, interact with other objects - smallest ones are components like activeX controls - ===> solid event model necessary that allows objects to broadcast specific messages and generate certain events (events = synchronisation objects) - ===> transparency of location and implementation is important (as offered by CORBA) BOMSIG (Business Object Model Special Interest Group), as example for framework on top of CORBA - no references given - promotes three-tier framework for buisness objects, consisting of business object logic, business proces objects, presenation object (differences not clear to me) Compound document framework (another example of a framework on top of CORBA) njs Date[ 11:31:04 ] Recordnr[ ] Stored[ Papers Composition Who[ J.R.Callahan, J.M Purtilo, University of Maryland Title[ A Packaging System for Heterogeneous Execution Environments Published[ IEEE Transactions on Software Engineering, vol.17, 1991, pp.626-635 Keywords[ MIL, Polygen, Polylith Comment[ more for small, on-one-site components, strenth is partitioning and automatic reasoning about possible configurations, yet automatic generation is limitied to certain environments Summary[ Polylith: TCP/IP-based communication systems for various languages. Polygen: Composotion and reasoning tool. What it is about: - generation of custom interface software for heterogeneous configurations. - in contrast to other approaches, not only stub generation, but inserting configuration methods needed to integrate an application (e.g. main, wrappers/dispachter program for LISP-procedures, byteswap functions for adjusting integers to various representations, rendezvous functions) - polygen changes source code and adds necessary lines and stubs so they can work over network - all is automatic, user just has to specify desired geometry - logical design is separated from the geometry Composition process: Starting point: several source files (C, Ada, Pascal, Lisp) that contain modules(procedure calls) to be composed. In the extraction phase, module specs are gained from the source files, or these module specs already exist. Module specs: are written in Polylith MIL (module interconnection language). It contains the interfaces a module offers and uses and the parameters of these procedure calls. In the composition phase, the user adds the design and annotated design (with geometric data) to the specs. The design says which modules are to be used, which communication system, where the modules are. Then in the generatin phase POLYGEN makes a package based on the configuration rules it has. Configuration rules are added by the Polygen system maintainer and say what kind of modules can be connected how. A package (valid configuration represented in an executable makefile and generated stubs and interfaces) is gained by an interference mechanism that uses partitioning. Module assertions are converted to prolog statements. Based on configuration rules, partitions are created.... Finally in the construction phase an executable is generated by running the makefile that polygen has created in the generation phase. Partitioning: Partitions are sets of compatible components. They can be represented by directed, acyclic graphs,whose internal nodes represent integration methods and temrinal nodes represent source components. Valid partitioning: has only a single root. Weaknesses: - source code must be changed and recompiled - right now only for Polylith-TCP/IP - data-conversion relies on underlying communication tool - good for putting together inhouse modules - rather targeted at smaller modules - no optimization, scheduling etc... Date[ August 21, 19] Recordnr[ ] Stored[ see library Who[ Charles W. Krueger Title[ Software Reuse Published[ ACM Computing Surveys, Vol. 24, No. 2, June 1992 Keywords[ reuse, abstraction Comment[ Summary[ Abstraction: Abstraction and reuse are two sides of the same coin. Many references given for that. Abstraction occurs in layers. In each layer we can distinguish between the abstraction specification, and the abstraction realization (contains hidden parts of the abstraction).Specification contains fixed part and variable part of the abstraction. 4 facets of software reuse are looked at in the paper, though all build on top of abstraction: - abstraction: what the abstraction is at all - selection: how users find abstractions, requires consice specifications - speciliations: choosing the abstraction realisations and the correct flexible parts - integration: interface of an abstraction, how are abstractions integrated in complete software system Reuse is being looked at in the following fields: 1) High-level languages: - reusable artifacts are the language elements, which abstract assembly language patterns. - variable parts are the statements and conditions we can fill in - integration is done by compilers, hidden parts (assembler language) are never visible - cognitive distance to a problem at hand is quite large (yet smaller than with pure assembler) 2) Design and Code scavenging - code scavenging: copying small code fragments without changing - design scavenging: copying larger code fragments containing a design pattern, and changing details yet keeping overall design; or making new code based on earlier experiences - very informal, not always worth while - no hidden parts of abstraction, specialization and integration require intimate knowledge of the code - if large pieces of good code can be reused without looking too much into it, the cognitive distance is small 3) Source Code Components Main contrast to code scavenging: components are build to reuse. The description here is a little bit outdated. He mentions mathematical analysis libraries and ADA-components. Nowadays, we would add JFC, MFC, RoqueWafe etc. Integration has been improved by todays OO-languages, specialization has been clearly "reduced" to parameters and inheritance. Selection is getting better by good browsers, web-pages etc.... 4) Software Schemas Quite outdated, the mentioned tools have not made it. Schemas seem to be quite similar to templates and design patterns. The foculs lies on higher level semantics descriptions of components, and of schemas how things work together (just design patterns). 5) Application generators Whole applications are generated, e.g. parser and compiler generator. Only certain rules, modules, elements, diagrams are written. The rest is generated. The abstractions come directly from the application domain. Cognitive distance is very small. 6) Very High-level Languages VHLL = executable specification languages Developing in a VHLL is similar to developing in a HLL (writing program that gets compiled). Like application generators, VHLL will generate the applications, yet VHLL are general purpose. VHLL want higher levels of specification without sacrificing computational generatily. - VHLLs are often very slow, yet execution efficiency is sacrificed for implementation and modification effencency - VHLLs are often based on some higher level mathematical model Examples for VHLLs: - SETL: based on set theory, good for easy use of abstract data types - PAISLey: functional programming, ..... - MODEL: declarative constraint language Main concern: execution speed. 7) Transformational systems 8) Architectural abstractions - come directly from application domain Date[ July 8, 1998 ] Recordnr[ ] Stored[ bookshelf? Who[ P. Bassett Title[ Managing for Flexible Software Manufacturing Published[ IEEE Computer, vol31, no7, July 1998 Keywords[ Comment[ Summary[ The article discusses reuse, the reason why it does not happen, and proposes some remedies. Reasons why reuse does not happen: - Old manufacturing culture: we only trust our own software, and distrust other software; "our software will be far better" - Management supports these habits Management strategies to overcome old culture: 1) Promoting reuse within same project, i.e. avoiding perfectionism and over-generalisation syndrom. 2) Own and manage multiproject assets centrally by central profit-centre that rents out component engineers (actual glue) that help individual projects to use these components fast and effectively. Architectures for reuse, two types: 1) Execution architectures: system is encapsulated into executable modules, e.g. many OO-architectures, CORBA, n-tiered client-server, ... Point of view is runtime. 2) Construction architectures: the executable modules are partitioned into reusable components according to the isolation of change. Point of view is construction time, the goal is to localize the effects of change, to reduce complexity and ensure as much independance between components as possible, so when making changes to API's, data structures etc, as view components as possible have to be touched. ==> reuse is enhanced. Infrastructure for reuse: We have infrastructures for execution architectures (e.g. ORB's), but not really for construction time. It is hard to access and find multiple sources of supply of components. With infrastructure also come basic metrics that would give information about the return of investment in components. Flexible Software Manufacturing - a new paradigm? What it means: components that have the capability to adapt/customize themselves to concrete requirements. How does CHAIMS relate to this? - we are not changing any megamodules in the composition process, we may only add mediator megamodules to complete certain suites of megamodules - yet the megamodule providers can provide more or less suitable megamodules ==> ideally they package the functionality in such a way that the megamodule can be used in as many different settings as possible (minimal interface yet still flexible enough for many uses). The article also mentions some books about reuse, e.g. McClure 1997, Jacobson 1997, Date[ June 18, 1998] Recordnr[ ] Stored[ Who[ Michael VanHilst (works now at HP-Labs), D. Notkin Title[ Using Role Components to Implement Collaboration-Based Designs Published[ OOPSLA 96 Keywords[ aspect-oriented programming, roles, collaborations, roles as code entities Comment[ nice idea, might become an additional implementation paradigm, compareable to model-view-controller Summary[ Problem statement: Collaborations are modelled in the design. They show interactions between different roles (not really between different classes)==> collaborations as collections of roles. A role specifies a part of a single object that participates in a particular collaboration. One class can play several roles in differing collaborations; the same role is not implemented by the same class throughout all applications using that collaboration pattern. How could the notion of roles brought over to the implementation? Code reuse, system evolution: Collaborations in the design are derived from use-case-like scenarios in the requirements analysis. By having role-entities in the code, these use-cases could be reflected directly in the code, preserving this complementary view to the static class view. How? Inheritance is a logical glue for composing roles into classes, but: - inheritance must be delayed until whole composition and order of composition is known (compile-time, not code-writing time) - bindings to types must be delayed as well, so that roles can be coded independant of the specific classes taking them on, and thus be reused ==> class template for each role that is parameterized by each of the collaborator and by the class taking on the role itself ==> class then extend these templates, replacing the collaborators by the actual classes ==> a class having several roles is extended several times, each time the higher level class becomes a parameter in the next template to be extended ==> inheritance chain (but only simple inheritance is used) In order to get the right order in the inheritance chain, a roles/responsibility matrix is made. It helps to determine which roles (object methods) extend each other, and thus should override each other by calling the original one in case not the extended one is used. Related concepts: subject-oriented programming mixins Date[ November 2, 1] Recordnr[ ] Stored[ Papers sonst Who[ Michael M. Gormann Title[ The Essential Paradigm for Successful Information Technology Standards Published[ http://www.wiscorp.com/p115.htm Keywords[ standards, NIST, Comment[ Good entry paper. Summary[ The author emphesizes that there exist three main factors that must be fulfilled in order for a standard to be sucessful: - significant market share vendor community - publically developed, available, and evolving standard - enforced conformance tests Successful means the standard is adopted by a wide range of vendors. The paper discusses these points taking the SQL-standard and NIST who has given up conformance tests. The paper also shows the consequences for individual clients as well as the industry as a whole when successful standards do not exist (locked into one vendor, disabling competition by market leaders, high prizes for non-competitive products). Lost of references. hullo! i'm a synopsis, NOT a synApsis! testing 1.. 2.. 3.. Date[ June 24, 1998] Recordnr[ ] Stored[ Composition papers Who[ M.-C. Shan, J.W.Davis, et al Title[ Business Process Flow Management and its Application in the Telecommunications Management Network Published[ HP-Journal, October 1996 Keywords[ workflow, composition, Comment[ Summary[ The paper describes HP OpenPM, now called changengine and used by several banks. It is advanced workflow technology based on a framework approach for reusability. Goals of changengine: - substantial evolution from traditional workflow technologies - for distributed heterogenous computing environment (several procotols via wrappers) - it is a middleware system for procedural automation of a business process by managing the sequence of process activities, including the invocation of appropriate human, instrument or computer resources. - content, structure of process can be preplanned or ad hoc Main elements: - Process engine: based on the business process definition (graphically, rules) the process engine determines when something takes place and triggers activities. - Resource executive: manages resources - BOW: business object wrappers Definition of process: Graph containing work nodes and rule nodes. Each work node can again be a process containing work nodes and rule nodes. Work nodes have status initial or fired. Forward arcs denote normal execution flow, and they form directed acylic graph. Each work node can only have incoming arc, whereas rule nodes can have several incoming arcs (they have rules to deal with that). Both kind of nodes can have several outgoing arcs. Backward arcs are reset arcs, i.e. when they fire, everything in their loop is reset, and started tasks are aborted. Nodes fire like in a petri-net. Rules: e.g. "if Customer.approval = TRUE then arc 5" Events: rule nodes can also raise evens, which themselves can fire rules nodes that have subscribed to that event. Events are modelled like specific kind of nodes, like a shortcut for not drawing to many arcs across the graph. This kind of graph allows to describe: - sequencing and timing and dependancy of business activities, - data and physical agent allocation of business activities - business rules and organization policies Mapping of process definition to execution: Work node -- process activity(task) -- invocation of an operation on business objects(resource) during execution of a process BOW: BOW's wrap business objects and interface to the process engine via CORBA. Towards business objects they interface with various protocols, e.g. also DCOM and DNA. Business objects are catalogued in a library. Interfaces: from process engine are CORBA and WfMC (Workflow Managmenet Coalition standard interface) Optimization: Data handler: allows seperation of application specific data and process-relevant data needed for rule nodes, thus reducing amount of data flow. Resource manager: for automatic workload balancing. Statistical data: bottleneck analysis, flow optimization. References: - paper gives further references (not very new) - Reed Letsinger and Michael VantHilst at HP labs - webpage: www.pwd.hp.com/cyc/af/50/ is behind firewall Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J.M.Voas Title[ The Challenges of Using COTS Software in Component-Based Development Published[ IEEE Computer, June 1998, Vol31 No6, Guest Editors introduction Keywords[ COTS Comment[ Summary[ Software we acquire elsewhere: - COTS: commercial of the shelf - CAS: commercially available software - NDI: nondevelopmental item ==> used as components or componentware to build component-based software or systems of systems Problems in using componentware: - Components may integrate perfectly during development, but not behave perfectly at rntime. - We have process models for developing software from requirements, but not yet for acquiring software. - COTS are delivered as black box ==> how to determine that they behave safely, securely, and reliably? - How to access the quality of COTS? How to access suitability? Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J.McDermid Title[ The Cost of COTS Published[ IEEE Computer, June 1998, Vol31 No6, an interview Keywords[ COTS Comment[ Quite quite an interesting interview discussing general cost issues of COTS in contrast to bespoke (custom solutions), especially for safety- and reliability-critical system. The article is very critical towards COTS, mainly talks from a viewpoint of critical systems (process control systems, not information systems). Summary[ Promises of COTS: eliminate sfotware development project that overrun time and cost, greater ability to interoperate diverse systems, quickly evolve large systems, lower costs COTS nowadays: GUIs, operations systems, databases ==> mainly large components (and what about CERN-libraries, statistic tools etc.?) Risk mitigation: Problem: COTS are often build without a strict process and documentation control, no clear QA, and are delivered without appropriate documentation of the process, and without e.g. complete test-suites etc. (solutions: certification, using an escrow i.e. depositing the documentation at a bank for the case the company disappears). How to access the quality? - retrospective assessment is more expensive than assessing the software when developing it, if possible at all (code analysis) - each upgrade has to be assessed anew - software has not been written with the goal to access it (whereas bespoke for critical systems is structured and written in order to be accessed) - accessing needs also been done for all unwanted functionality (additional effort not necessary for bespoke) How to demonstrate the desired level of reliability, availability, integrity? - unwanted functions with dangerous side-effects How to control future of a COTS-component? - component can go out of business - new releases with unwanted functions - cost of upgrading - wrappers do not solve any of above problems Cost-tradeoff between COTS and bespoke: - price of purchase versus development - price of assessing quality of COTS to desired quality level - price of integrating COTS - price for upgrades, price for accessing upgrades, price for integrating upgrades - risk of vendor going out of business and expected life-time of system COTS can offer historical data for its quality (e.g. OS but not things like Microsoftword which get updates too often), bespoke has not historical data but you know what you are developing and can assess that. Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J. M.. Voas Title[ Certifying Off-the-Shelf Software Components Published[ IEEE Computer, June 1998, Vol31 No6, an interview Keywords[ COTS Comment[ Summary[ Three questions must be answered positively before using/certifying a COTS-component for a specific environment: 1 Does component C fill the Developer's needs? 2 Is the quality of component C high enough? 3 What impact will component C have on system S? Ways to answer that is by: a Black-box testing (answers question 1) b System-level fault injection c Operational system testing a and b together answer 2 and 3. Black-box testing: - best to build own oracle that tests comonents against needs of user and not against vendors specification - can fail to exercise important/faulty portions of the code System-level fault injection: Instead of the component a fault injector is put into the system (just the minimum amount of surrounding components is used) that works nearly like the component but randomly makes wrong results. Can the system stand that? Operational system testing: Problem: enormous amount needed for components that rarely fail. Advantage voer system-level fault injection: tests the real wrong behaviour. Remedy if component is not save enough: wrappers. Problem: Wrapper may not catch all the behaviour of a component. Date[ July 29, 1998] Recordnr[ ] Stored[ file-cabinet, Papers Composition Who[ J. Magee, N. Dulay, J. Kramer Title[ Regis: A Constructive Development Environment for Distributed Programs Published[ IEE/IOP/BCS Distributed Systems Engineering, 1(5): 304-312, Sept 1994. Keywords[ Comment[ Other papers about Regis/Darwin: Ng, K. and Kramer, J.; Automated Support for Distributed Software Design, appeared in 7th International Workshop on Computer-aided Software Engineering (CASE 95) Mostly describes the Software Architect's Assistant, a visual tool to set up distributed systems. Magee, J. and Dulay, N. and Eisenbach, S. and Kramer, J.;Specifying Distributed Software Architectures, appeared in 5th European Software Engineering Conference (ESEC 95) Presents a formal model of Darwin in Robin Milner's Pi-Calculus. Magee, J. and Dulay, N. and Kramer, J.; Regis: A Constructive Development Environment for Distributed Programs; IEE/IOP/BCS Distributed Systems Engineering},Volume = {1},Number = {5},1994 Describes the most recent distributed execution environment for Darwin-structured applications. Summary[ Darwin is a configuration language, Regis is a system supporting Darwin and generating the distributed systems specified in Darwin. For each component an interface is specified that contains all incoming and outgoing links. These can be of different types (pipes, ports...). The communications are implemented by special C++ components. The components to be configured/assembled can be either composite components, consisting of a set of lower level components, or computation components. Latter are written in C++ and must inherit from a predefined class process. Darwin also allows to imbed directly program code in the component descriptions. Components are garbage collected after termination. Regis runs on a Unix environment, the components can run on different Unix-workstations. A mapping file defines on which processor of the multicomputer which component is run. My conclusions: Regis supports program generation for a homogeneous environment. The distribution seems only to be local - I do not know if it is suited for servers located outside the intranet. The components that are composed are controlled entirely by the configuration language and by Regis (automatic garbage collection) - no autonomous servers that exist and run independant of the client. No equivalents to "EXAMINE", "ESTIMATE". Legacy code probably could be brought in, but I have not seen this issue being specifically adressed. As far as I know, no commercial application. Notes of Louis: I looked at a bunch of papers from Imperial College, London. The head of that group is Jeff Kramer, the relevant URLs are: Regis: http://www-dse.doc.ic.ac.uk/~regis/ Darwin: http://www-dse.doc.ic.ac.uk/~jsc/research/darwin.html Some of their work is relevant for RapArch, Architecture, and RapNet (see below). Regis has been in use since 1992. Darwin/Regis ============ Regis is a programming environment aimed at supporting the development and execution of distributed program. A Regis program consists of loosely coupled components either directly written in C++ (primitive components) or constructed out of simpler subcomponents by using the Darwin language. As such, Darwin is an Architecture Description Language (ADL) remarkably similar to the RAPIDE ADL. The Regis environment lets you develop the individual C++ components and the composition using Darwin, then compiles everything into executables and runs it on distributed sites. Regis/Darwin is restricted to the design/implementation phase. Once the program is compiled, installed and running, it is on its own, there is no support for ongoing analysis. One '95 paper said they will do run-time monitoring and management, but that will probably be primitive (i.e. just monitoring if they still run) and may not even exist. They stress the fact that a Regis program can be distributed (a la mobile agents), but I don't think that is the exciting thing about it. The Darwin ADL -------------- Darwin boxes are called "components", action declaration are called "services", arrows are called "bindings". Like RAPIDE, Darwin specifies both provided as required services. Services are typed and type conformance is enforced. Darwin allows hierarchical composition of components as well as parametrization, a component can consist of n subcomponents, with n decided statically at run time or dynamically at runtime. The latter is what they call dynamic architectures. In both cases, all n components have the same type, bindings, etc. This is just simple instantiation of a class. In some aspects Darwin is more general than Rapide ADL. The communication mechanism is not restricted to events. Darwin supports any communication mechanism (events, streams, RPC, etc. In Regis, the mechanism is then implemented as a C++ class). Thus the type of an action denotes the C++ class that implements it. A Darwin filter on a stream of characters would look like component filter { provide output; require input; } A funny thing happens when one looks at services of type "port". A port is used to send messages through and is interpreted in a procedure call style. Thus, to send a message, a sensor *requires* a port, the "output" becomes "required". The following comes from their paper and seems wrong for a RAPIDE person (at least for me). component sensor { provide input; require output; } I guess they run into this problem because they support both push (stream, event) and pull (port) communication with others. Pi-calculus ----------- Darwin is also specified in Milner's \pi-calculus. This is an elementary calculus for describing and analyzing concurrent, independent processes that communicate via channels. A subset of the Pi-calculus (http://www.cwi.nl/~arie/picalc.html) seems to be a candidate for our RapNet composition language. Software Architect Assistant ---------------------------- Regis comes with a graphical architecting tool called Software Architect Assistant (SAA), similar to RapArch. In comparison to RapArch, SAA's focus is more on providing semantics and ease-of-use and less on providing fancy drawing capabilities. All "boxes" have the same size, and "arrows" are laid out automatically by the tool and cannot be changed. (See http://www-dse.doc.ic.ac.uk/sel/sereports/rj1/rj1.html for an evaluation.) On the other hand, boxes and arrow have full semantic meaning, and correctness is checked at data entry point. The graphical and the textual view are always consistent. I especially like the separation between connections and interfaces. The "arrow" is just a line, the ending points indicating in which direction it points are part of the "box". This makes sense, because when you define a box, it is already clear which "actions" are "required" and which are "provided". SAA also displays nicely how services are connected when components are hierarchically encapsulated in each other. SAA also supports libraries of components, that can be included as sub-components in other components and it can read Darwin (textual) code not written by SAA. The SAA exports RTF reports that can be directly imported into word processors. Date[ August 5, 199] Recordnr[ ] Stored[Composition, filecabinet Who[ I. Ben-Shaul, et.al. Title[ HADAS: A Network-Centric Framework for Interoperability Programming Published[ International Journal of Cooperative Informaion Systems, 1997 Keywords[ heterogeneity, RMI, HADAS, coordination language, Comment[ Very interesting approach. More focused on roaming agents. Summary[ Challenge: Compose, configure and execute network-centric applicatins made up of widely-distributed components. Major problem: global interoperability Examples: active, intelligent information agents; inter-organization collaborative workflow systems, e-commerce, large-scale concurrent computations Main ideas of HADAS (=heterogeneous autonomous distributed abstraction system): - autonomy of objects: administrative autonomy (==> evolving over time), design autonomy (heterogeneity) - network centric framework - no central agent like a broker, fully decentralized (==> possible by using RMI) - dynamic and programmable approach to interoperability, peer-to-peer configuration agreement - ISL as coordination lanague Approch: - a (reflective and mobile object model abstracting components - a Java-based framework in which components live and communicate - a higher-order interpreted coordination language that manipulates components Basic architecture: The comonponents are distributed object managers. These not only implement various ilities like security and unique id and persistence, they also contain or wrapp the effective behaviour offered by this component. These objects communicate with each other mainly over RMI. They could also use ftp, http or amp. The whole HADAS system is written in Java. Access to legacy components is by wrappers - these wrappers, written mainly in Java, e.g. access CORBA-components etc. If necessary, they also use native code. As all of HADAS is Java, data is communicated in Java format. For type- mismatches, peer-to-peer dynamic wrappers exist that transform data. Levels of interoperability in Hadas: - interconnectivity infrastructure (in Java), reflective object model supporting mutability and mobility - integration : who can access whom? - configuration: dynamic agreemant between sites over use of comonents - coordination: control and dataflow between components, ISL Configuration: The operation to be called is link. What link does is: it copies a suitable ambassador objects to the other site. These ambassador objects then act like stubs. Ambassadors for the same siteobjects on various sites may have different dynamic parts in them. Each object supports methods like: add, remove (a method dynamically), invoke (a method with given parameters), describe (the offered methods). Ambassadors: - not just stubs, they have HADAS methods (install, update) - they have dynamic transformers (wrappers) and can evolve dynamically by interacting with hosting environment Reflective object model: - objects can answer questions about itself (given by Java) - object can change itself (addDataItem, addMethod, setMethod), trivial in Java - security specifications per method (probably all from Java) Wrappers: - dynamic linking to Java components - accessing C++ code with JNI - CORBA-HADAS, static wrapping - HTTP/CGI out and in transformer, dynamic wrapping Coordination, ISL: The language used is Scheme, implemented in Java. It supports weak typing and allows to encode higher-order procedures. http://www.dsg.technion.ac.il db lm wp ns gw Date[ May 27, 1998 ] Recordnr[ 1 ] Stored[ Composition Who[ Scott M. Lewandowski Title[ Frameworks for Component-Based Client/Server Computing Published[ ACM Computing Surveys, Vol.30, No.1, March 1998 Keywords[ CORBA, compound document, DCOM, JAVA, business object Comment[ Summary[ General impression: very pro CORBA, does not mention RMI, paper tries to cover a large area with doubtful success Middleware is defined to include the APIs used by clients to request a service from a server, the physical transmittion of the request to the network, and the rewulting transmission of data for the client back to the network. Middleware is run on both the client and server ends of a transaction. Three different kinds of middleware: - database middleware (ODBC, SQL, Oracle Glue) - groupware middleware (Lotus Notes, Microsoft Exchange) - inernet middleware (HTTP, secure socket layer) - object middleware (CORBA, DCOM) Furthermore: fundamental/generic middleware against domain-specific middleware. Fundamental: distributed file system, RPC, authentication... Various kind of systems: - fat servers versus fat clients: data on server, UI on client - is the application logic on the server or the client? - three-tier systems: application logic is separate ==> new level of autonomy for applicatino logic. Ex: web-applications with browser, applets or cgi-scripts, database - four-tiers: e.g. with additional second tier for unifying view of the data of the databases of first tier, (CHAIMS with new architecture would also be 4 tier system) CORBA is great!!!?? - "Technologies such as Java and object request brokers (ORBs) promise to provide seamless integration among all platforms within a few years." - "only CORBA and DCOM provide viable long-term solutions to the challenge of a standardized framework for object-based client/server systems, others do not have enough features or as great an installed base..." - yet CORBA is much better, because in DCOM e.g. no real objects (objects have no state, they are just procedures ==> handles to objects are arbitrary and only garuantee interface not object-state, no unique object identifier, no persistency supported) - also DCOM objects cannot automatically support multiple interfaces, - also clients cannot request for a specific given server, - also only using WindowsNT security model and no own universal security mechanism like CORBA - CORBA and Java are made for each other and together will win (???) ==> platform for universal network computing can be created using Java as mobile code systems and CORBA as integration technology Claims (not really true in my view): - java-interfaces and CORBA-IDL's are very similar (RMI transports code and methods, not just data!! ==> totally different kind of distributed programming) - CORBA allows parameters of any type (yes, it allows more than CGI, but not "any") Selfmanaging objects: - take responsibility for their own resources, work across networks, interact with other objects - smallest ones are components like activeX controls - ===> solid event model necessary that allows objects to broadcast specific messages and generate certain events (events = synchronisation objects) - ===> transparency of location and implementation is important (as offered by CORBA) BOMSIG (Business Object Model Special Interest Group), as example for framework on top of CORBA - no references given - promotes three-tier framework for buisness objects, consisting of business object logic, business proces objects, presenation object (differences not clear to me) Compound document framework (another example of a framework on top of CORBA) njs Date[ 11:31:04 ] Recordnr[ ] Stored[ Papers Composition Who[ J.R.Callahan, J.M Purtilo, University of Maryland Title[ A Packaging System for Heterogeneous Execution Environments Published[ IEEE Transactions on Software Engineering, vol.17, 1991, pp.626-635 Keywords[ MIL, Polygen, Polylith Comment[ more for small, on-one-site components, strenth is partitioning and automatic reasoning about possible configurations, yet automatic generation is limitied to certain environments Summary[ Polylith: TCP/IP-based communication systems for various languages. Polygen: Composotion and reasoning tool. What it is about: - generation of custom interface software for heterogeneous configurations. - in contrast to other approaches, not only stub generation, but inserting configuration methods needed to integrate an application (e.g. main, wrappers/dispachter program for LISP-procedures, byteswap functions for adjusting integers to various representations, rendezvous functions) - polygen changes source code and adds necessary lines and stubs so they can work over network - all is automatic, user just has to specify desired geometry - logical design is separated from the geometry Composition process: Starting point: several source files (C, Ada, Pascal, Lisp) that contain modules(procedure calls) to be composed. In the extraction phase, module specs are gained from the source files, or these module specs already exist. Module specs: are written in Polylith MIL (module interconnection language). It contains the interfaces a module offers and uses and the parameters of these procedure calls. In the composition phase, the user adds the design and annotated design (with geometric data) to the specs. The design says which modules are to be used, which communication system, where the modules are. Then in the generatin phase POLYGEN makes a package based on the configuration rules it has. Configuration rules are added by the Polygen system maintainer and say what kind of modules can be connected how. A package (valid configuration represented in an executable makefile and generated stubs and interfaces) is gained by an interference mechanism that uses partitioning. Module assertions are converted to prolog statements. Based on configuration rules, partitions are created.... Finally in the construction phase an executable is generated by running the makefile that polygen has created in the generation phase. Partitioning: Partitions are sets of compatible components. They can be represented by directed, acyclic graphs,whose internal nodes represent integration methods and temrinal nodes represent source components. Valid partitioning: has only a single root. Weaknesses: - source code must be changed and recompiled - right now only for Polylith-TCP/IP - data-conversion relies on underlying communication tool - good for putting together inhouse modules - rather targeted at smaller modules - no optimization, scheduling etc... Date[ August 21, 19] Recordnr[ ] Stored[ see library Who[ Charles W. Krueger Title[ Software Reuse Published[ ACM Computing Surveys, Vol. 24, No. 2, June 1992 Keywords[ reuse, abstraction Comment[ Summary[ Abstraction: Abstraction and reuse are two sides of the same coin. Many references given for that. Abstraction occurs in layers. In each layer we can distinguish between the abstraction specification, and the abstraction realization (contains hidden parts of the abstraction).Specification contains fixed part and variable part of the abstraction. 4 facets of software reuse are looked at in the paper, though all build on top of abstraction: - abstraction: what the abstraction is at all - selection: how users find abstractions, requires consice specifications - speciliations: choosing the abstraction realisations and the correct flexible parts - integration: interface of an abstraction, how are abstractions integrated in complete software system Reuse is being looked at in the following fields: 1) High-level languages: - reusable artifacts are the language elements, which abstract assembly language patterns. - variable parts are the statements and conditions we can fill in - integration is done by compilers, hidden parts (assembler language) are never visible - cognitive distance to a problem at hand is quite large (yet smaller than with pure assembler) 2) Design and Code scavenging - code scavenging: copying small code fragments without changing - design scavenging: copying larger code fragments containing a design pattern, and changing details yet keeping overall design; or making new code based on earlier experiences - very informal, not always worth while - no hidden parts of abstraction, specialization and integration require intimate knowledge of the code - if large pieces of good code can be reused without looking too much into it, the cognitive distance is small 3) Source Code Components Main contrast to code scavenging: components are build to reuse. The description here is a little bit outdated. He mentions mathematical analysis libraries and ADA-components. Nowadays, we would add JFC, MFC, RoqueWafe etc. Integration has been improved by todays OO-languages, specialization has been clearly "reduced" to parameters and inheritance. Selection is getting better by good browsers, web-pages etc.... 4) Software Schemas Quite outdated, the mentioned tools have not made it. Schemas seem to be quite similar to templates and design patterns. The foculs lies on higher level semantics descriptions of components, and of schemas how things work together (just design patterns). 5) Application generators Whole applications are generated, e.g. parser and compiler generator. Only certain rules, modules, elements, diagrams are written. The rest is generated. The abstractions come directly from the application domain. Cognitive distance is very small. 6) Very High-level Languages VHLL = executable specification languages Developing in a VHLL is similar to developing in a HLL (writing program that gets compiled). Like application generators, VHLL will generate the applications, yet VHLL are general purpose. VHLL want higher levels of specification without sacrificing computational generatily. - VHLLs are often very slow, yet execution efficiency is sacrificed for implementation and modification effencency - VHLLs are often based on some higher level mathematical model Examples for VHLLs: - SETL: based on set theory, good for easy use of abstract data types - PAISLey: functional programming, ..... - MODEL: declarative constraint language Main concern: execution speed. 7) Transformational systems 8) Architectural abstractions - come directly from application domain Date[ July 8, 1998 ] Recordnr[ ] Stored[ bookshelf? Who[ P. Bassett Title[ Managing for Flexible Software Manufacturing Published[ IEEE Computer, vol31, no7, July 1998 Keywords[ Comment[ Summary[ The article discusses reuse, the reason why it does not happen, and proposes some remedies. Reasons why reuse does not happen: - Old manufacturing culture: we only trust our own software, and distrust other software; "our software will be far better" - Management supports these habits Management strategies to overcome old culture: 1) Promoting reuse within same project, i.e. avoiding perfectionism and over-generalisation syndrom. 2) Own and manage multiproject assets centrally by central profit-centre that rents out component engineers (actual glue) that help individual projects to use these components fast and effectively. Architectures for reuse, two types: 1) Execution architectures: system is encapsulated into executable modules, e.g. many OO-architectures, CORBA, n-tiered client-server, ... Point of view is runtime. 2) Construction architectures: the executable modules are partitioned into reusable components according to the isolation of change. Point of view is construction time, the goal is to localize the effects of change, to reduce complexity and ensure as much independance between components as possible, so when making changes to API's, data structures etc, as view components as possible have to be touched. ==> reuse is enhanced. Infrastructure for reuse: We have infrastructures for execution architectures (e.g. ORB's), but not really for construction time. It is hard to access and find multiple sources of supply of components. With infrastructure also come basic metrics that would give information about the return of investment in components. Flexible Software Manufacturing - a new paradigm? What it means: components that have the capability to adapt/customize themselves to concrete requirements. How does CHAIMS relate to this? - we are not changing any megamodules in the composition process, we may only add mediator megamodules to complete certain suites of megamodules - yet the megamodule providers can provide more or less suitable megamodules ==> ideally they package the functionality in such a way that the megamodule can be used in as many different settings as possible (minimal interface yet still flexible enough for many uses). The article also mentions some books about reuse, e.g. McClure 1997, Jacobson 1997, Date[ June 18, 1998] Recordnr[ ] Stored[ Who[ Michael VanHilst (works now at HP-Labs), D. Notkin Title[ Using Role Components to Implement Collaboration-Based Designs Published[ OOPSLA 96 Keywords[ aspect-oriented programming, roles, collaborations, roles as code entities Comment[ nice idea, might become an additional implementation paradigm, compareable to model-view-controller Summary[ Problem statement: Collaborations are modelled in the design. They show interactions between different roles (not really between different classes)==> collaborations as collections of roles. A role specifies a part of a single object that participates in a particular collaboration. One class can play several roles in differing collaborations; the same role is not implemented by the same class throughout all applications using that collaboration pattern. How could the notion of roles brought over to the implementation? Code reuse, system evolution: Collaborations in the design are derived from use-case-like scenarios in the requirements analysis. By having role-entities in the code, these use-cases could be reflected directly in the code, preserving this complementary view to the static class view. How? Inheritance is a logical glue for composing roles into classes, but: - inheritance must be delayed until whole composition and order of composition is known (compile-time, not code-writing time) - bindings to types must be delayed as well, so that roles can be coded independant of the specific classes taking them on, and thus be reused ==> class template for each role that is parameterized by each of the collaborator and by the class taking on the role itself ==> class then extend these templates, replacing the collaborators by the actual classes ==> a class having several roles is extended several times, each time the higher level class becomes a parameter in the next template to be extended ==> inheritance chain (but only simple inheritance is used) In order to get the right order in the inheritance chain, a roles/responsibility matrix is made. It helps to determine which roles (object methods) extend each other, and thus should override each other by calling the original one in case not the extended one is used. Related concepts: subject-oriented programming mixins Date[ November 2, 1] Recordnr[ ] Stored[ Papers sonst Who[ Michael M. Gormann Title[ The Essential Paradigm for Successful Information Technology Standards Published[ http://www.wiscorp.com/p115.htm Keywords[ standards, NIST, Comment[ Good entry paper. Summary[ The author emphesizes that there exist three main factors that must be fulfilled in order for a standard to be sucessful: - significant market share vendor community - publically developed, available, and evolving standard - enforced conformance tests Successful means the standard is adopted by a wide range of vendors. The paper discusses these points taking the SQL-standard and NIST who has given up conformance tests. The paper also shows the consequences for individual clients as well as the industry as a whole when successful standards do not exist (locked into one vendor, disabling competition by market leaders, high prizes for non-competitive products). Lost of references. hullo! i'm a synopsis, NOT a synApsis! testing 1.. 2.. 3.. Date[ June 24, 1998] Recordnr[ ] Stored[ Composition papers Who[ M.-C. Shan, J.W.Davis, et al Title[ Business Process Flow Management and its Application in the Telecommunications Management Network Published[ HP-Journal, October 1996 Keywords[ workflow, composition, Comment[ Summary[ The paper describes HP OpenPM, now called changengine and used by several banks. It is advanced workflow technology based on a framework approach for reusability. Goals of changengine: - substantial evolution from traditional workflow technologies - for distributed heterogenous computing environment (several procotols via wrappers) - it is a middleware system for procedural automation of a business process by managing the sequence of process activities, including the invocation of appropriate human, instrument or computer resources. - content, structure of process can be preplanned or ad hoc Main elements: - Process engine: based on the business process definition (graphically, rules) the process engine determines when something takes place and triggers activities. - Resource executive: manages resources - BOW: business object wrappers Definition of process: Graph containing work nodes and rule nodes. Each work node can again be a process containing work nodes and rule nodes. Work nodes have status initial or fired. Forward arcs denote normal execution flow, and they form directed acylic graph. Each work node can only have incoming arc, whereas rule nodes can have several incoming arcs (they have rules to deal with that). Both kind of nodes can have several outgoing arcs. Backward arcs are reset arcs, i.e. when they fire, everything in their loop is reset, and started tasks are aborted. Nodes fire like in a petri-net. Rules: e.g. "if Customer.approval = TRUE then arc 5" Events: rule nodes can also raise evens, which themselves can fire rules nodes that have subscribed to that event. Events are modelled like specific kind of nodes, like a shortcut for not drawing to many arcs across the graph. This kind of graph allows to describe: - sequencing and timing and dependancy of business activities, - data and physical agent allocation of business activities - business rules and organization policies Mapping of process definition to execution: Work node -- process activity(task) -- invocation of an operation on business objects(resource) during execution of a process BOW: BOW's wrap business objects and interface to the process engine via CORBA. Towards business objects they interface with various protocols, e.g. also DCOM and DNA. Business objects are catalogued in a library. Interfaces: from process engine are CORBA and WfMC (Workflow Managmenet Coalition standard interface) Optimization: Data handler: allows seperation of application specific data and process-relevant data needed for rule nodes, thus reducing amount of data flow. Resource manager: for automatic workload balancing. Statistical data: bottleneck analysis, flow optimization. References: - paper gives further references (not very new) - Reed Letsinger and Michael VantHilst at HP labs - webpage: www.pwd.hp.com/cyc/af/50/ is behind firewall Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J.M.Voas Title[ The Challenges of Using COTS Software in Component-Based Development Published[ IEEE Computer, June 1998, Vol31 No6, Guest Editors introduction Keywords[ COTS Comment[ Summary[ Software we acquire elsewhere: - COTS: commercial of the shelf - CAS: commercially available software - NDI: nondevelopmental item ==> used as components or componentware to build component-based software or systems of systems Problems in using componentware: - Components may integrate perfectly during development, but not behave perfectly at rntime. - We have process models for developing software from requirements, but not yet for acquiring software. - COTS are delivered as black box ==> how to determine that they behave safely, securely, and reliably? - How to access the quality of COTS? How to access suitability? Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J.McDermid Title[ The Cost of COTS Published[ IEEE Computer, June 1998, Vol31 No6, an interview Keywords[ COTS Comment[ Quite quite an interesting interview discussing general cost issues of COTS in contrast to bespoke (custom solutions), especially for safety- and reliability-critical system. The article is very critical towards COTS, mainly talks from a viewpoint of critical systems (process control systems, not information systems). Summary[ Promises of COTS: eliminate sfotware development project that overrun time and cost, greater ability to interoperate diverse systems, quickly evolve large systems, lower costs COTS nowadays: GUIs, operations systems, databases ==> mainly large components (and what about CERN-libraries, statistic tools etc.?) Risk mitigation: Problem: COTS are often build without a strict process and documentation control, no clear QA, and are delivered without appropriate documentation of the process, and without e.g. complete test-suites etc. (solutions: certification, using an escrow i.e. depositing the documentation at a bank for the case the company disappears). How to access the quality? - retrospective assessment is more expensive than assessing the software when developing it, if possible at all (code analysis) - each upgrade has to be assessed anew - software has not been written with the goal to access it (whereas bespoke for critical systems is structured and written in order to be accessed) - accessing needs also been done for all unwanted functionality (additional effort not necessary for bespoke) How to demonstrate the desired level of reliability, availability, integrity? - unwanted functions with dangerous side-effects How to control future of a COTS-component? - component can go out of business - new releases with unwanted functions - cost of upgrading - wrappers do not solve any of above problems Cost-tradeoff between COTS and bespoke: - price of purchase versus development - price of assessing quality of COTS to desired quality level - price of integrating COTS - price for upgrades, price for accessing upgrades, price for integrating upgrades - risk of vendor going out of business and expected life-time of system COTS can offer historical data for its quality (e.g. OS but not things like Microsoftword which get updates too often), bespoke has not historical data but you know what you are developing and can assess that. Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J. M.. Voas Title[ Certifying Off-the-Shelf Software Components Published[ IEEE Computer, June 1998, Vol31 No6, an interview Keywords[ COTS Comment[ Summary[ Three questions must be answered positively before using/certifying a COTS-component for a specific environment: 1 Does component C fill the Developer's needs? 2 Is the quality of component C high enough? 3 What impact will component C have on system S? Ways to answer that is by: a Black-box testing (answers question 1) b System-level fault injection c Operational system testing a and b together answer 2 and 3. Black-box testing: - best to build own oracle that tests comonents against needs of user and not against vendors specification - can fail to exercise important/faulty portions of the code System-level fault injection: Instead of the component a fault injector is put into the system (just the minimum amount of surrounding components is used) that works nearly like the component but randomly makes wrong results. Can the system stand that? Operational system testing: Problem: enormous amount needed for components that rarely fail. Advantage voer system-level fault injection: tests the real wrong behaviour. Remedy if component is not save enough: wrappers. Problem: Wrapper may not catch all the behaviour of a component. Date[ July 29, 1998] Recordnr[ ] Stored[ file-cabinet, Papers Composition Who[ J. Magee, N. Dulay, J. Kramer Title[ Regis: A Constructive Development Environment for Distributed Programs Published[ IEE/IOP/BCS Distributed Systems Engineering, 1(5): 304-312, Sept 1994. Keywords[ Comment[ Other papers about Regis/Darwin: Ng, K. and Kramer, J.; Automated Support for Distributed Software Design, appeared in 7th International Workshop on Computer-aided Software Engineering (CASE 95) Mostly describes the Software Architect's Assistant, a visual tool to set up distributed systems. Magee, J. and Dulay, N. and Eisenbach, S. and Kramer, J.;Specifying Distributed Software Architectures, appeared in 5th European Software Engineering Conference (ESEC 95) Presents a formal model of Darwin in Robin Milner's Pi-Calculus. Magee, J. and Dulay, N. and Kramer, J.; Regis: A Constructive Development Environment for Distributed Programs; IEE/IOP/BCS Distributed Systems Engineering},Volume = {1},Number = {5},1994 Describes the most recent distributed execution environment for Darwin-structured applications. Summary[ Darwin is a configuration language, Regis is a system supporting Darwin and generating the distributed systems specified in Darwin. For each component an interface is specified that contains all incoming and outgoing links. These can be of different types (pipes, ports...). The communications are implemented by special C++ components. The components to be configured/assembled can be either composite components, consisting of a set of lower level components, or computation components. Latter are written in C++ and must inherit from a predefined class process. Darwin also allows to imbed directly program code in the component descriptions. Components are garbage collected after termination. Regis runs on a Unix environment, the components can run on different Unix-workstations. A mapping file defines on which processor of the multicomputer which component is run. My conclusions: Regis supports program generation for a homogeneous environment. The distribution seems only to be local - I do not know if it is suited for servers located outside the intranet. The components that are composed are controlled entirely by the configuration language and by Regis (automatic garbage collection) - no autonomous servers that exist and run independant of the client. No equivalents to "EXAMINE", "ESTIMATE". Legacy code probably could be brought in, but I have not seen this issue being specifically adressed. As far as I know, no commercial application. Notes of Louis: I looked at a bunch of papers from Imperial College, London. The head of that group is Jeff Kramer, the relevant URLs are: Regis: http://www-dse.doc.ic.ac.uk/~regis/ Darwin: http://www-dse.doc.ic.ac.uk/~jsc/research/darwin.html Some of their work is relevant for RapArch, Architecture, and RapNet (see below). Regis has been in use since 1992. Darwin/Regis ============ Regis is a programming environment aimed at supporting the development and execution of distributed program. A Regis program consists of loosely coupled components either directly written in C++ (primitive components) or constructed out of simpler subcomponents by using the Darwin language. As such, Darwin is an Architecture Description Language (ADL) remarkably similar to the RAPIDE ADL. The Regis environment lets you develop the individual C++ components and the composition using Darwin, then compiles everything into executables and runs it on distributed sites. Regis/Darwin is restricted to the design/implementation phase. Once the program is compiled, installed and running, it is on its own, there is no support for ongoing analysis. One '95 paper said they will do run-time monitoring and management, but that will probably be primitive (i.e. just monitoring if they still run) and may not even exist. They stress the fact that a Regis program can be distributed (a la mobile agents), but I don't think that is the exciting thing about it. The Darwin ADL -------------- Darwin boxes are called "components", action declaration are called "services", arrows are called "bindings". Like RAPIDE, Darwin specifies both provided as required services. Services are typed and type conformance is enforced. Darwin allows hierarchical composition of components as well as parametrization, a component can consist of n subcomponents, with n decided statically at run time or dynamically at runtime. The latter is what they call dynamic architectures. In both cases, all n components have the same type, bindings, etc. This is just simple instantiation of a class. In some aspects Darwin is more general than Rapide ADL. The communication mechanism is not restricted to events. Darwin supports any communication mechanism (events, streams, RPC, etc. In Regis, the mechanism is then implemented as a C++ class). Thus the type of an action denotes the C++ class that implements it. A Darwin filter on a stream of characters would look like component filter { provide output; require input; } A funny thing happens when one looks at services of type "port". A port is used to send messages through and is interpreted in a procedure call style. Thus, to send a message, a sensor *requires* a port, the "output" becomes "required". The following comes from their paper and seems wrong for a RAPIDE person (at least for me). component sensor { provide input; require output; } I guess they run into this problem because they support both push (stream, event) and pull (port) communication with others. Pi-calculus ----------- Darwin is also specified in Milner's \pi-calculus. This is an elementary calculus for describing and analyzing concurrent, independent processes that communicate via channels. A subset of the Pi-calculus (http://www.cwi.nl/~arie/picalc.html) seems to be a candidate for our RapNet composition language. Software Architect Assistant ---------------------------- Regis comes with a graphical architecting tool called Software Architect Assistant (SAA), similar to RapArch. In comparison to RapArch, SAA's focus is more on providing semantics and ease-of-use and less on providing fancy drawing capabilities. All "boxes" have the same size, and "arrows" are laid out automatically by the tool and cannot be changed. (See http://www-dse.doc.ic.ac.uk/sel/sereports/rj1/rj1.html for an evaluation.) On the other hand, boxes and arrow have full semantic meaning, and correctness is checked at data entry point. The graphical and the textual view are always consistent. I especially like the separation between connections and interfaces. The "arrow" is just a line, the ending points indicating in which direction it points are part of the "box". This makes sense, because when you define a box, it is already clear which "actions" are "required" and which are "provided". SAA also displays nicely how services are connected when components are hierarchically encapsulated in each other. SAA also supports libraries of components, that can be included as sub-components in other components and it can read Darwin (textual) code not written by SAA. The SAA exports RTF reports that can be directly imported into word processors. Date[ August 5, 199] Recordnr[ ] Stored[Composition, filecabinet Who[ I. Ben-Shaul, et.al. Title[ HADAS: A Network-Centric Framework for Interoperability Programming Published[ International Journal of Cooperative Informaion Systems, 1997 Keywords[ heterogeneity, RMI, HADAS, coordination language, Comment[ Very interesting approach. More focused on roaming agents. Summary[ Challenge: Compose, configure and execute network-centric applicatins made up of widely-distributed components. Major problem: global interoperability Examples: active, intelligent information agents; inter-organization collaborative workflow systems, e-commerce, large-scale concurrent computations Main ideas of HADAS (=heterogeneous autonomous distributed abstraction system): - autonomy of objects: administrative autonomy (==> evolving over time), design autonomy (heterogeneity) - network centric framework - no central agent like a broker, fully decentralized (==> possible by using RMI) - dynamic and programmable approach to interoperability, peer-to-peer configuration agreement - ISL as coordination lanague Approch: - a (reflective and mobile object model abstracting components - a Java-based framework in which components live and communicate - a higher-order interpreted coordination language that manipulates components Basic architecture: The comonponents are distributed object managers. These not only implement various ilities like security and unique id and persistence, they also contain or wrapp the effective behaviour offered by this component. These objects communicate with each other mainly over RMI. They could also use ftp, http or amp. The whole HADAS system is written in Java. Access to legacy components is by wrappers - these wrappers, written mainly in Java, e.g. access CORBA-components etc. If necessary, they also use native code. As all of HADAS is Java, data is communicated in Java format. For type- mismatches, peer-to-peer dynamic wrappers exist that transform data. Levels of interoperability in Hadas: - interconnectivity infrastructure (in Java), reflective object model supporting mutability and mobility - integration : who can access whom? - configuration: dynamic agreemant between sites over use of comonents - coordination: control and dataflow between components, ISL Configuration: The operation to be called is link. What link does is: it copies a suitable ambassador objects to the other site. These ambassador objects then act like stubs. Ambassadors for the same siteobjects on various sites may have different dynamic parts in them. Each object supports methods like: add, remove (a method dynamically), invoke (a method with given parameters), describe (the offered methods). Ambassadors: - not just stubs, they have HADAS methods (install, update) - they have dynamic transformers (wrappers) and can evolve dynamically by interacting with hosting environment Reflective object model: - objects can answer questions about itself (given by Java) - object can change itself (addDataItem, addMethod, setMethod), trivial in Java - security specifications per method (probably all from Java) Wrappers: - dynamic linking to Java components - accessing C++ code with JNI - CORBA-HADAS, static wrapping - HTTP/CGI out and in transformer, dynamic wrapping Coordination, ISL: The language used is Scheme, implemented in Java. It supports weak typing and allows to encode higher-order procedures. http://www.dsg.technion.ac.il db lm wp ns gw Date[ May 27, 1998 ] Recordnr[ 1 ] Stored[ Composition Who[ Scott M. Lewandowski Title[ Frameworks for Component-Based Client/Server Computing Published[ ACM Computing Surveys, Vol.30, No.1, March 1998 Keywords[ CORBA, compound document, DCOM, JAVA, business object Comment[ Summary[ General impression: very pro CORBA, does not mention RMI, paper tries to cover a large area with doubtful success Middleware is defined to include the APIs used by clients to request a service from a server, the physical transmittion of the request to the network, and the rewulting transmission of data for the client back to the network. Middleware is run on both the client and server ends of a transaction. Three different kinds of middleware: - database middleware (ODBC, SQL, Oracle Glue) - groupware middleware (Lotus Notes, Microsoft Exchange) - inernet middleware (HTTP, secure socket layer) - object middleware (CORBA, DCOM) Furthermore: fundamental/generic middleware against domain-specific middleware. Fundamental: distributed file system, RPC, authentication... Various kind of systems: - fat servers versus fat clients: data on server, UI on client - is the application logic on the server or the client? - three-tier systems: application logic is separate ==> new level of autonomy for applicatino logic. Ex: web-applications with browser, applets or cgi-scripts, database - four-tiers: e.g. with additional second tier for unifying view of the data of the databases of first tier, (CHAIMS with new architecture would also be 4 tier system) CORBA is great!!!?? - "Technologies such as Java and object request brokers (ORBs) promise to provide seamless integration among all platforms within a few years." - "only CORBA and DCOM provide viable long-term solutions to the challenge of a standardized framework for object-based client/server systems, others do not have enough features or as great an installed base..." - yet CORBA is much better, because in DCOM e.g. no real objects (objects have no state, they are just procedures ==> handles to objects are arbitrary and only garuantee interface not object-state, no unique object identifier, no persistency supported) - also DCOM objects cannot automatically support multiple interfaces, - also clients cannot request for a specific given server, - also only using WindowsNT security model and no own universal security mechanism like CORBA - CORBA and Java are made for each other and together will win (???) ==> platform for universal network computing can be created using Java as mobile code systems and CORBA as integration technology Claims (not really true in my view): - java-interfaces and CORBA-IDL's are very similar (RMI transports code and methods, not just data!! ==> totally different kind of distributed programming) - CORBA allows parameters of any type (yes, it allows more than CGI, but not "any") Selfmanaging objects: - take responsibility for their own resources, work across networks, interact with other objects - smallest ones are components like activeX controls - ===> solid event model necessary that allows objects to broadcast specific messages and generate certain events (events = synchronisation objects) - ===> transparency of location and implementation is important (as offered by CORBA) BOMSIG (Business Object Model Special Interest Group), as example for framework on top of CORBA - no references given - promotes three-tier framework for buisness objects, consisting of business object logic, business proces objects, presenation object (differences not clear to me) Compound document framework (another example of a framework on top of CORBA) njs Date[ 11:31:04 ] Recordnr[ ] Stored[ Papers Composition Who[ J.R.Callahan, J.M Purtilo, University of Maryland Title[ A Packaging System for Heterogeneous Execution Environments Published[ IEEE Transactions on Software Engineering, vol.17, 1991, pp.626-635 Keywords[ MIL, Polygen, Polylith Comment[ more for small, on-one-site components, strenth is partitioning and automatic reasoning about possible configurations, yet automatic generation is limitied to certain environments Summary[ Polylith: TCP/IP-based communication systems for various languages. Polygen: Composotion and reasoning tool. What it is about: - generation of custom interface software for heterogeneous configurations. - in contrast to other approaches, not only stub generation, but inserting configuration methods needed to integrate an application (e.g. main, wrappers/dispachter program for LISP-procedures, byteswap functions for adjusting integers to various representations, rendezvous functions) - polygen changes source code and adds necessary lines and stubs so they can work over network - all is automatic, user just has to specify desired geometry - logical design is separated from the geometry Composition process: Starting point: several source files (C, Ada, Pascal, Lisp) that contain modules(procedure calls) to be composed. In the extraction phase, module specs are gained from the source files, or these module specs already exist. Module specs: are written in Polylith MIL (module interconnection language). It contains the interfaces a module offers and uses and the parameters of these procedure calls. In the composition phase, the user adds the design and annotated design (with geometric data) to the specs. The design says which modules are to be used, which communication system, where the modules are. Then in the generatin phase POLYGEN makes a package based on the configuration rules it has. Configuration rules are added by the Polygen system maintainer and say what kind of modules can be connected how. A package (valid configuration represented in an executable makefile and generated stubs and interfaces) is gained by an interference mechanism that uses partitioning. Module assertions are converted to prolog statements. Based on configuration rules, partitions are created.... Finally in the construction phase an executable is generated by running the makefile that polygen has created in the generation phase. Partitioning: Partitions are sets of compatible components. They can be represented by directed, acyclic graphs,whose internal nodes represent integration methods and temrinal nodes represent source components. Valid partitioning: has only a single root. Weaknesses: - source code must be changed and recompiled - right now only for Polylith-TCP/IP - data-conversion relies on underlying communication tool - good for putting together inhouse modules - rather targeted at smaller modules - no optimization, scheduling etc... Date[ August 21, 19] Recordnr[ ] Stored[ see library Who[ Charles W. Krueger Title[ Software Reuse Published[ ACM Computing Surveys, Vol. 24, No. 2, June 1992 Keywords[ reuse, abstraction Comment[ Summary[ Abstraction: Abstraction and reuse are two sides of the same coin. Many references given for that. Abstraction occurs in layers. In each layer we can distinguish between the abstraction specification, and the abstraction realization (contains hidden parts of the abstraction).Specification contains fixed part and variable part of the abstraction. 4 facets of software reuse are looked at in the paper, though all build on top of abstraction: - abstraction: what the abstraction is at all - selection: how users find abstractions, requires consice specifications - speciliations: choosing the abstraction realisations and the correct flexible parts - integration: interface of an abstraction, how are abstractions integrated in complete software system Reuse is being looked at in the following fields: 1) High-level languages: - reusable artifacts are the language elements, which abstract assembly language patterns. - variable parts are the statements and conditions we can fill in - integration is done by compilers, hidden parts (assembler language) are never visible - cognitive distance to a problem at hand is quite large (yet smaller than with pure assembler) 2) Design and Code scavenging - code scavenging: copying small code fragments without changing - design scavenging: copying larger code fragments containing a design pattern, and changing details yet keeping overall design; or making new code based on earlier experiences - very informal, not always worth while - no hidden parts of abstraction, specialization and integration require intimate knowledge of the code - if large pieces of good code can be reused without looking too much into it, the cognitive distance is small 3) Source Code Components Main contrast to code scavenging: components are build to reuse. The description here is a little bit outdated. He mentions mathematical analysis libraries and ADA-components. Nowadays, we would add JFC, MFC, RoqueWafe etc. Integration has been improved by todays OO-languages, specialization has been clearly "reduced" to parameters and inheritance. Selection is getting better by good browsers, web-pages etc.... 4) Software Schemas Quite outdated, the mentioned tools have not made it. Schemas seem to be quite similar to templates and design patterns. The foculs lies on higher level semantics descriptions of components, and of schemas how things work together (just design patterns). 5) Application generators Whole applications are generated, e.g. parser and compiler generator. Only certain rules, modules, elements, diagrams are written. The rest is generated. The abstractions come directly from the application domain. Cognitive distance is very small. 6) Very High-level Languages VHLL = executable specification languages Developing in a VHLL is similar to developing in a HLL (writing program that gets compiled). Like application generators, VHLL will generate the applications, yet VHLL are general purpose. VHLL want higher levels of specification without sacrificing computational generatily. - VHLLs are often very slow, yet execution efficiency is sacrificed for implementation and modification effencency - VHLLs are often based on some higher level mathematical model Examples for VHLLs: - SETL: based on set theory, good for easy use of abstract data types - PAISLey: functional programming, ..... - MODEL: declarative constraint language Main concern: execution speed. 7) Transformational systems 8) Architectural abstractions - come directly from application domain Date[ July 8, 1998 ] Recordnr[ ] Stored[ bookshelf? Who[ P. Bassett Title[ Managing for Flexible Software Manufacturing Published[ IEEE Computer, vol31, no7, July 1998 Keywords[ Comment[ Summary[ The article discusses reuse, the reason why it does not happen, and proposes some remedies. Reasons why reuse does not happen: - Old manufacturing culture: we only trust our own software, and distrust other software; "our software will be far better" - Management supports these habits Management strategies to overcome old culture: 1) Promoting reuse within same project, i.e. avoiding perfectionism and over-generalisation syndrom. 2) Own and manage multiproject assets centrally by central profit-centre that rents out component engineers (actual glue) that help individual projects to use these components fast and effectively. Architectures for reuse, two types: 1) Execution architectures: system is encapsulated into executable modules, e.g. many OO-architectures, CORBA, n-tiered client-server, ... Point of view is runtime. 2) Construction architectures: the executable modules are partitioned into reusable components according to the isolation of change. Point of view is construction time, the goal is to localize the effects of change, to reduce complexity and ensure as much independance between components as possible, so when making changes to API's, data structures etc, as view components as possible have to be touched. ==> reuse is enhanced. Infrastructure for reuse: We have infrastructures for execution architectures (e.g. ORB's), but not really for construction time. It is hard to access and find multiple sources of supply of components. With infrastructure also come basic metrics that would give information about the return of investment in components. Flexible Software Manufacturing - a new paradigm? What it means: components that have the capability to adapt/customize themselves to concrete requirements. How does CHAIMS relate to this? - we are not changing any megamodules in the composition process, we may only add mediator megamodules to complete certain suites of megamodules - yet the megamodule providers can provide more or less suitable megamodules ==> ideally they package the functionality in such a way that the megamodule can be used in as many different settings as possible (minimal interface yet still flexible enough for many uses). The article also mentions some books about reuse, e.g. McClure 1997, Jacobson 1997, Date[ June 18, 1998] Recordnr[ ] Stored[ Who[ Michael VanHilst (works now at HP-Labs), D. Notkin Title[ Using Role Components to Implement Collaboration-Based Designs Published[ OOPSLA 96 Keywords[ aspect-oriented programming, roles, collaborations, roles as code entities Comment[ nice idea, might become an additional implementation paradigm, compareable to model-view-controller Summary[ Problem statement: Collaborations are modelled in the design. They show interactions between different roles (not really between different classes)==> collaborations as collections of roles. A role specifies a part of a single object that participates in a particular collaboration. One class can play several roles in differing collaborations; the same role is not implemented by the same class throughout all applications using that collaboration pattern. How could the notion of roles brought over to the implementation? Code reuse, system evolution: Collaborations in the design are derived from use-case-like scenarios in the requirements analysis. By having role-entities in the code, these use-cases could be reflected directly in the code, preserving this complementary view to the static class view. How? Inheritance is a logical glue for composing roles into classes, but: - inheritance must be delayed until whole composition and order of composition is known (compile-time, not code-writing time) - bindings to types must be delayed as well, so that roles can be coded independant of the specific classes taking them on, and thus be reused ==> class template for each role that is parameterized by each of the collaborator and by the class taking on the role itself ==> class then extend these templates, replacing the collaborators by the actual classes ==> a class having several roles is extended several times, each time the higher level class becomes a parameter in the next template to be extended ==> inheritance chain (but only simple inheritance is used) In order to get the right order in the inheritance chain, a roles/responsibility matrix is made. It helps to determine which roles (object methods) extend each other, and thus should override each other by calling the original one in case not the extended one is used. Related concepts: subject-oriented programming mixins Date[ November 2, 1] Recordnr[ ] Stored[ Papers sonst Who[ Michael M. Gormann Title[ The Essential Paradigm for Successful Information Technology Standards Published[ http://www.wiscorp.com/p115.htm Keywords[ standards, NIST, Comment[ Good entry paper. Summary[ The author emphesizes that there exist three main factors that must be fulfilled in order for a standard to be sucessful: - significant market share vendor community - publically developed, available, and evolving standard - enforced conformance tests Successful means the standard is adopted by a wide range of vendors. The paper discusses these points taking the SQL-standard and NIST who has given up conformance tests. The paper also shows the consequences for individual clients as well as the industry as a whole when successful standards do not exist (locked into one vendor, disabling competition by market leaders, high prizes for non-competitive products). Lost of references. hullo! i'm a synopsis, NOT a synApsis! testing 1.. 2.. 3.. Date[ June 24, 1998] Recordnr[ ] Stored[ Composition papers Who[ M.-C. Shan, J.W.Davis, et al Title[ Business Process Flow Management and its Application in the Telecommunications Management Network Published[ HP-Journal, October 1996 Keywords[ workflow, composition, Comment[ Summary[ The paper describes HP OpenPM, now called changengine and used by several banks. It is advanced workflow technology based on a framework approach for reusability. Goals of changengine: - substantial evolution from traditional workflow technologies - for distributed heterogenous computing environment (several procotols via wrappers) - it is a middleware system for procedural automation of a business process by managing the sequence of process activities, including the invocation of appropriate human, instrument or computer resources. - content, structure of process can be preplanned or ad hoc Main elements: - Process engine: based on the business process definition (graphically, rules) the process engine determines when something takes place and triggers activities. - Resource executive: manages resources - BOW: business object wrappers Definition of process: Graph containing work nodes and rule nodes. Each work node can again be a process containing work nodes and rule nodes. Work nodes have status initial or fired. Forward arcs denote normal execution flow, and they form directed acylic graph. Each work node can only have incoming arc, whereas rule nodes can have several incoming arcs (they have rules to deal with that). Both kind of nodes can have several outgoing arcs. Backward arcs are reset arcs, i.e. when they fire, everything in their loop is reset, and started tasks are aborted. Nodes fire like in a petri-net. Rules: e.g. "if Customer.approval = TRUE then arc 5" Events: rule nodes can also raise evens, which themselves can fire rules nodes that have subscribed to that event. Events are modelled like specific kind of nodes, like a shortcut for not drawing to many arcs across the graph. This kind of graph allows to describe: - sequencing and timing and dependancy of business activities, - data and physical agent allocation of business activities - business rules and organization policies Mapping of process definition to execution: Work node -- process activity(task) -- invocation of an operation on business objects(resource) during execution of a process BOW: BOW's wrap business objects and interface to the process engine via CORBA. Towards business objects they interface with various protocols, e.g. also DCOM and DNA. Business objects are catalogued in a library. Interfaces: from process engine are CORBA and WfMC (Workflow Managmenet Coalition standard interface) Optimization: Data handler: allows seperation of application specific data and process-relevant data needed for rule nodes, thus reducing amount of data flow. Resource manager: for automatic workload balancing. Statistical data: bottleneck analysis, flow optimization. References: - paper gives further references (not very new) - Reed Letsinger and Michael VantHilst at HP labs - webpage: www.pwd.hp.com/cyc/af/50/ is behind firewall Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J.M.Voas Title[ The Challenges of Using COTS Software in Component-Based Development Published[ IEEE Computer, June 1998, Vol31 No6, Guest Editors introduction Keywords[ COTS Comment[ Summary[ Software we acquire elsewhere: - COTS: commercial of the shelf - CAS: commercially available software - NDI: nondevelopmental item ==> used as components or componentware to build component-based software or systems of systems Problems in using componentware: - Components may integrate perfectly during development, but not behave perfectly at rntime. - We have process models for developing software from requirements, but not yet for acquiring software. - COTS are delivered as black box ==> how to determine that they behave safely, securely, and reliably? - How to access the quality of COTS? How to access suitability? Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J.McDermid Title[ The Cost of COTS Published[ IEEE Computer, June 1998, Vol31 No6, an interview Keywords[ COTS Comment[ Quite quite an interesting interview discussing general cost issues of COTS in contrast to bespoke (custom solutions), especially for safety- and reliability-critical system. The article is very critical towards COTS, mainly talks from a viewpoint of critical systems (process control systems, not information systems). Summary[ Promises of COTS: eliminate sfotware development project that overrun time and cost, greater ability to interoperate diverse systems, quickly evolve large systems, lower costs COTS nowadays: GUIs, operations systems, databases ==> mainly large components (and what about CERN-libraries, statistic tools etc.?) Risk mitigation: Problem: COTS are often build without a strict process and documentation control, no clear QA, and are delivered without appropriate documentation of the process, and without e.g. complete test-suites etc. (solutions: certification, using an escrow i.e. depositing the documentation at a bank for the case the company disappears). How to access the quality? - retrospective assessment is more expensive than assessing the software when developing it, if possible at all (code analysis) - each upgrade has to be assessed anew - software has not been written with the goal to access it (whereas bespoke for critical systems is structured and written in order to be accessed) - accessing needs also been done for all unwanted functionality (additional effort not necessary for bespoke) How to demonstrate the desired level of reliability, availability, integrity? - unwanted functions with dangerous side-effects How to control future of a COTS-component? - component can go out of business - new releases with unwanted functions - cost of upgrading - wrappers do not solve any of above problems Cost-tradeoff between COTS and bespoke: - price of purchase versus development - price of assessing quality of COTS to desired quality level - price of integrating COTS - price for upgrades, price for accessing upgrades, price for integrating upgrades - risk of vendor going out of business and expected life-time of system COTS can offer historical data for its quality (e.g. OS but not things like Microsoftword which get updates too often), bespoke has not historical data but you know what you are developing and can assess that. Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J. M.. Voas Title[ Certifying Off-the-Shelf Software Components Published[ IEEE Computer, June 1998, Vol31 No6, an interview Keywords[ COTS Comment[ Summary[ Three questions must be answered positively before using/certifying a COTS-component for a specific environment: 1 Does component C fill the Developer's needs? 2 Is the quality of component C high enough? 3 What impact will component C have on system S? Ways to answer that is by: a Black-box testing (answers question 1) b System-level fault injection c Operational system testing a and b together answer 2 and 3. Black-box testing: - best to build own oracle that tests comonents against needs of user and not against vendors specification - can fail to exercise important/faulty portions of the code System-level fault injection: Instead of the component a fault injector is put into the system (just the minimum amount of surrounding components is used) that works nearly like the component but randomly makes wrong results. Can the system stand that? Operational system testing: Problem: enormous amount needed for components that rarely fail. Advantage voer system-level fault injection: tests the real wrong behaviour. Remedy if component is not save enough: wrappers. Problem: Wrapper may not catch all the behaviour of a component. Date[ July 29, 1998] Recordnr[ ] Stored[ file-cabinet, Papers Composition Who[ J. Magee, N. Dulay, J. Kramer Title[ Regis: A Constructive Development Environment for Distributed Programs Published[ IEE/IOP/BCS Distributed Systems Engineering, 1(5): 304-312, Sept 1994. Keywords[ Comment[ Other papers about Regis/Darwin: Ng, K. and Kramer, J.; Automated Support for Distributed Software Design, appeared in 7th International Workshop on Computer-aided Software Engineering (CASE 95) Mostly describes the Software Architect's Assistant, a visual tool to set up distributed systems. Magee, J. and Dulay, N. and Eisenbach, S. and Kramer, J.;Specifying Distributed Software Architectures, appeared in 5th European Software Engineering Conference (ESEC 95) Presents a formal model of Darwin in Robin Milner's Pi-Calculus. Magee, J. and Dulay, N. and Kramer, J.; Regis: A Constructive Development Environment for Distributed Programs; IEE/IOP/BCS Distributed Systems Engineering},Volume = {1},Number = {5},1994 Describes the most recent distributed execution environment for Darwin-structured applications. Summary[ Darwin is a configuration language, Regis is a system supporting Darwin and generating the distributed systems specified in Darwin. For each component an interface is specified that contains all incoming and outgoing links. These can be of different types (pipes, ports...). The communications are implemented by special C++ components. The components to be configured/assembled can be either composite components, consisting of a set of lower level components, or computation components. Latter are written in C++ and must inherit from a predefined class process. Darwin also allows to imbed directly program code in the component descriptions. Components are garbage collected after termination. Regis runs on a Unix environment, the components can run on different Unix-workstations. A mapping file defines on which processor of the multicomputer which component is run. My conclusions: Regis supports program generation for a homogeneous environment. The distribution seems only to be local - I do not know if it is suited for servers located outside the intranet. The components that are composed are controlled entirely by the configuration language and by Regis (automatic garbage collection) - no autonomous servers that exist and run independant of the client. No equivalents to "EXAMINE", "ESTIMATE". Legacy code probably could be brought in, but I have not seen this issue being specifically adressed. As far as I know, no commercial application. Notes of Louis: I looked at a bunch of papers from Imperial College, London. The head of that group is Jeff Kramer, the relevant URLs are: Regis: http://www-dse.doc.ic.ac.uk/~regis/ Darwin: http://www-dse.doc.ic.ac.uk/~jsc/research/darwin.html Some of their work is relevant for RapArch, Architecture, and RapNet (see below). Regis has been in use since 1992. Darwin/Regis ============ Regis is a programming environment aimed at supporting the development and execution of distributed program. A Regis program consists of loosely coupled components either directly written in C++ (primitive components) or constructed out of simpler subcomponents by using the Darwin language. As such, Darwin is an Architecture Description Language (ADL) remarkably similar to the RAPIDE ADL. The Regis environment lets you develop the individual C++ components and the composition using Darwin, then compiles everything into executables and runs it on distributed sites. Regis/Darwin is restricted to the design/implementation phase. Once the program is compiled, installed and running, it is on its own, there is no support for ongoing analysis. One '95 paper said they will do run-time monitoring and management, but that will probably be primitive (i.e. just monitoring if they still run) and may not even exist. They stress the fact that a Regis program can be distributed (a la mobile agents), but I don't think that is the exciting thing about it. The Darwin ADL -------------- Darwin boxes are called "components", action declaration are called "services", arrows are called "bindings". Like RAPIDE, Darwin specifies both provided as required services. Services are typed and type conformance is enforced. Darwin allows hierarchical composition of components as well as parametrization, a component can consist of n subcomponents, with n decided statically at run time or dynamically at runtime. The latter is what they call dynamic architectures. In both cases, all n components have the same type, bindings, etc. This is just simple instantiation of a class. In some aspects Darwin is more general than Rapide ADL. The communication mechanism is not restricted to events. Darwin supports any communication mechanism (events, streams, RPC, etc. In Regis, the mechanism is then implemented as a C++ class). Thus the type of an action denotes the C++ class that implements it. A Darwin filter on a stream of characters would look like component filter { provide output; require input; } A funny thing happens when one looks at services of type "port". A port is used to send messages through and is interpreted in a procedure call style. Thus, to send a message, a sensor *requires* a port, the "output" becomes "required". The following comes from their paper and seems wrong for a RAPIDE person (at least for me). component sensor { provide input; require output; } I guess they run into this problem because they support both push (stream, event) and pull (port) communication with others. Pi-calculus ----------- Darwin is also specified in Milner's \pi-calculus. This is an elementary calculus for describing and analyzing concurrent, independent processes that communicate via channels. A subset of the Pi-calculus (http://www.cwi.nl/~arie/picalc.html) seems to be a candidate for our RapNet composition language. Software Architect Assistant ---------------------------- Regis comes with a graphical architecting tool called Software Architect Assistant (SAA), similar to RapArch. In comparison to RapArch, SAA's focus is more on providing semantics and ease-of-use and less on providing fancy drawing capabilities. All "boxes" have the same size, and "arrows" are laid out automatically by the tool and cannot be changed. (See http://www-dse.doc.ic.ac.uk/sel/sereports/rj1/rj1.html for an evaluation.) On the other hand, boxes and arrow have full semantic meaning, and correctness is checked at data entry point. The graphical and the textual view are always consistent. I especially like the separation between connections and interfaces. The "arrow" is just a line, the ending points indicating in which direction it points are part of the "box". This makes sense, because when you define a box, it is already clear which "actions" are "required" and which are "provided". SAA also displays nicely how services are connected when components are hierarchically encapsulated in each other. SAA also supports libraries of components, that can be included as sub-components in other components and it can read Darwin (textual) code not written by SAA. The SAA exports RTF reports that can be directly imported into word processors. Date[ August 5, 199] Recordnr[ ] Stored[Composition, filecabinet Who[ I. Ben-Shaul, et.al. Title[ HADAS: A Network-Centric Framework for Interoperability Programming Published[ International Journal of Cooperative Informaion Systems, 1997 Keywords[ heterogeneity, RMI, HADAS, coordination language, Comment[ Very interesting approach. More focused on roaming agents. Summary[ Challenge: Compose, configure and execute network-centric applicatins made up of widely-distributed components. Major problem: global interoperability Examples: active, intelligent information agents; inter-organization collaborative workflow systems, e-commerce, large-scale concurrent computations Main ideas of HADAS (=heterogeneous autonomous distributed abstraction system): - autonomy of objects: administrative autonomy (==> evolving over time), design autonomy (heterogeneity) - network centric framework - no central agent like a broker, fully decentralized (==> possible by using RMI) - dynamic and programmable approach to interoperability, peer-to-peer configuration agreement - ISL as coordination lanague Approch: - a (reflective and mobile object model abstracting components - a Java-based framework in which components live and communicate - a higher-order interpreted coordination language that manipulates components Basic architecture: The comonponents are distributed object managers. These not only implement various ilities like security and unique id and persistence, they also contain or wrapp the effective behaviour offered by this component. These objects communicate with each other mainly over RMI. They could also use ftp, http or amp. The whole HADAS system is written in Java. Access to legacy components is by wrappers - these wrappers, written mainly in Java, e.g. access CORBA-components etc. If necessary, they also use native code. As all of HADAS is Java, data is communicated in Java format. For type- mismatches, peer-to-peer dynamic wrappers exist that transform data. Levels of interoperability in Hadas: - interconnectivity infrastructure (in Java), reflective object model supporting mutability and mobility - integration : who can access whom? - configuration: dynamic agreemant between sites over use of comonents - coordination: control and dataflow between components, ISL Configuration: The operation to be called is link. What link does is: it copies a suitable ambassador objects to the other site. These ambassador objects then act like stubs. Ambassadors for the same siteobjects on various sites may have different dynamic parts in them. Each object supports methods like: add, remove (a method dynamically), invoke (a method with given parameters), describe (the offered methods). Ambassadors: - not just stubs, they have HADAS methods (install, update) - they have dynamic transformers (wrappers) and can evolve dynamically by interacting with hosting environment Reflective object model: - objects can answer questions about itself (given by Java) - object can change itself (addDataItem, addMethod, setMethod), trivial in Java - security specifications per method (probably all from Java) Wrappers: - dynamic linking to Java components - accessing C++ code with JNI - CORBA-HADAS, static wrapping - HTTP/CGI out and in transformer, dynamic wrapping Coordination, ISL: The language used is Scheme, implemented in Java. It supports weak typing and allows to encode higher-order procedures. http://www.dsg.technion.ac.il db lm wp ns gw Date[ May 27, 1998 ] Recordnr[ 1 ] Stored[ Composition Who[ Scott M. Lewandowski Title[ Frameworks for Component-Based Client/Server Computing Published[ ACM Computing Surveys, Vol.30, No.1, March 1998 Keywords[ CORBA, compound document, DCOM, JAVA, business object Comment[ Summary[ General impression: very pro CORBA, does not mention RMI, paper tries to cover a large area with doubtful success Middleware is defined to include the APIs used by clients to request a service from a server, the physical transmittion of the request to the network, and the rewulting transmission of data for the client back to the network. Middleware is run on both the client and server ends of a transaction. Three different kinds of middleware: - database middleware (ODBC, SQL, Oracle Glue) - groupware middleware (Lotus Notes, Microsoft Exchange) - inernet middleware (HTTP, secure socket layer) - object middleware (CORBA, DCOM) Furthermore: fundamental/generic middleware against domain-specific middleware. Fundamental: distributed file system, RPC, authentication... Various kind of systems: - fat servers versus fat clients: data on server, UI on client - is the application logic on the server or the client? - three-tier systems: application logic is separate ==> new level of autonomy for applicatino logic. Ex: web-applications with browser, applets or cgi-scripts, database - four-tiers: e.g. with additional second tier for unifying view of the data of the databases of first tier, (CHAIMS with new architecture would also be 4 tier system) CORBA is great!!!?? - "Technologies such as Java and object request brokers (ORBs) promise to provide seamless integration among all platforms within a few years." - "only CORBA and DCOM provide viable long-term solutions to the challenge of a standardized framework for object-based client/server systems, others do not have enough features or as great an installed base..." - yet CORBA is much better, because in DCOM e.g. no real objects (objects have no state, they are just procedures ==> handles to objects are arbitrary and only garuantee interface not object-state, no unique object identifier, no persistency supported) - also DCOM objects cannot automatically support multiple interfaces, - also clients cannot request for a specific given server, - also only using WindowsNT security model and no own universal security mechanism like CORBA - CORBA and Java are made for each other and together will win (???) ==> platform for universal network computing can be created using Java as mobile code systems and CORBA as integration technology Claims (not really true in my view): - java-interfaces and CORBA-IDL's are very similar (RMI transports code and methods, not just data!! ==> totally different kind of distributed programming) - CORBA allows parameters of any type (yes, it allows more than CGI, but not "any") Selfmanaging objects: - take responsibility for their own resources, work across networks, interact with other objects - smallest ones are components like activeX controls - ===> solid event model necessary that allows objects to broadcast specific messages and generate certain events (events = synchronisation objects) - ===> transparency of location and implementation is important (as offered by CORBA) BOMSIG (Business Object Model Special Interest Group), as example for framework on top of CORBA - no references given - promotes three-tier framework for buisness objects, consisting of business object logic, business proces objects, presenation object (differences not clear to me) Compound document framework (another example of a framework on top of CORBA) njs Date[ 11:31:04 ] Recordnr[ ] Stored[ Papers Composition Who[ J.R.Callahan, J.M Purtilo, University of Maryland Title[ A Packaging System for Heterogeneous Execution Environments Published[ IEEE Transactions on Software Engineering, vol.17, 1991, pp.626-635 Keywords[ MIL, Polygen, Polylith Comment[ more for small, on-one-site components, strenth is partitioning and automatic reasoning about possible configurations, yet automatic generation is limitied to certain environments Summary[ Polylith: TCP/IP-based communication systems for various languages. Polygen: Composotion and reasoning tool. What it is about: - generation of custom interface software for heterogeneous configurations. - in contrast to other approaches, not only stub generation, but inserting configuration methods needed to integrate an application (e.g. main, wrappers/dispachter program for LISP-procedures, byteswap functions for adjusting integers to various representations, rendezvous functions) - polygen changes source code and adds necessary lines and stubs so they can work over network - all is automatic, user just has to specify desired geometry - logical design is separated from the geometry Composition process: Starting point: several source files (C, Ada, Pascal, Lisp) that contain modules(procedure calls) to be composed. In the extraction phase, module specs are gained from the source files, or these module specs already exist. Module specs: are written in Polylith MIL (module interconnection language). It contains the interfaces a module offers and uses and the parameters of these procedure calls. In the composition phase, the user adds the design and annotated design (with geometric data) to the specs. The design says which modules are to be used, which communication system, where the modules are. Then in the generatin phase POLYGEN makes a package based on the configuration rules it has. Configuration rules are added by the Polygen system maintainer and say what kind of modules can be connected how. A package (valid configuration represented in an executable makefile and generated stubs and interfaces) is gained by an interference mechanism that uses partitioning. Module assertions are converted to prolog statements. Based on configuration rules, partitions are created.... Finally in the construction phase an executable is generated by running the makefile that polygen has created in the generation phase. Partitioning: Partitions are sets of compatible components. They can be represented by directed, acyclic graphs,whose internal nodes represent integration methods and temrinal nodes represent source components. Valid partitioning: has only a single root. Weaknesses: - source code must be changed and recompiled - right now only for Polylith-TCP/IP - data-conversion relies on underlying communication tool - good for putting together inhouse modules - rather targeted at smaller modules - no optimization, scheduling etc... Date[ August 21, 19] Recordnr[ ] Stored[ see library Who[ Charles W. Krueger Title[ Software Reuse Published[ ACM Computing Surveys, Vol. 24, No. 2, June 1992 Keywords[ reuse, abstraction Comment[ Summary[ Abstraction: Abstraction and reuse are two sides of the same coin. Many references given for that. Abstraction occurs in layers. In each layer we can distinguish between the abstraction specification, and the abstraction realization (contains hidden parts of the abstraction).Specification contains fixed part and variable part of the abstraction. 4 facets of software reuse are looked at in the paper, though all build on top of abstraction: - abstraction: what the abstraction is at all - selection: how users find abstractions, requires consice specifications - speciliations: choosing the abstraction realisations and the correct flexible parts - integration: interface of an abstraction, how are abstractions integrated in complete software system Reuse is being looked at in the following fields: 1) High-level languages: - reusable artifacts are the language elements, which abstract assembly language patterns. - variable parts are the statements and conditions we can fill in - integration is done by compilers, hidden parts (assembler language) are never visible - cognitive distance to a problem at hand is quite large (yet smaller than with pure assembler) 2) Design and Code scavenging - code scavenging: copying small code fragments without changing - design scavenging: copying larger code fragments containing a design pattern, and changing details yet keeping overall design; or making new code based on earlier experiences - very informal, not always worth while - no hidden parts of abstraction, specialization and integration require intimate knowledge of the code - if large pieces of good code can be reused without looking too much into it, the cognitive distance is small 3) Source Code Components Main contrast to code scavenging: components are build to reuse. The description here is a little bit outdated. He mentions mathematical analysis libraries and ADA-components. Nowadays, we would add JFC, MFC, RoqueWafe etc. Integration has been improved by todays OO-languages, specialization has been clearly "reduced" to parameters and inheritance. Selection is getting better by good browsers, web-pages etc.... 4) Software Schemas Quite outdated, the mentioned tools have not made it. Schemas seem to be quite similar to templates and design patterns. The foculs lies on higher level semantics descriptions of components, and of schemas how things work together (just design patterns). 5) Application generators Whole applications are generated, e.g. parser and compiler generator. Only certain rules, modules, elements, diagrams are written. The rest is generated. The abstractions come directly from the application domain. Cognitive distance is very small. 6) Very High-level Languages VHLL = executable specification languages Developing in a VHLL is similar to developing in a HLL (writing program that gets compiled). Like application generators, VHLL will generate the applications, yet VHLL are general purpose. VHLL want higher levels of specification without sacrificing computational generatily. - VHLLs are often very slow, yet execution efficiency is sacrificed for implementation and modification effencency - VHLLs are often based on some higher level mathematical model Examples for VHLLs: - SETL: based on set theory, good for easy use of abstract data types - PAISLey: functional programming, ..... - MODEL: declarative constraint language Main concern: execution speed. 7) Transformational systems 8) Architectural abstractions - come directly from application domain Date[ July 8, 1998 ] Recordnr[ ] Stored[ bookshelf? Who[ P. Bassett Title[ Managing for Flexible Software Manufacturing Published[ IEEE Computer, vol31, no7, July 1998 Keywords[ Comment[ Summary[ The article discusses reuse, the reason why it does not happen, and proposes some remedies. Reasons why reuse does not happen: - Old manufacturing culture: we only trust our own software, and distrust other software; "our software will be far better" - Management supports these habits Management strategies to overcome old culture: 1) Promoting reuse within same project, i.e. avoiding perfectionism and over-generalisation syndrom. 2) Own and manage multiproject assets centrally by central profit-centre that rents out component engineers (actual glue) that help individual projects to use these components fast and effectively. Architectures for reuse, two types: 1) Execution architectures: system is encapsulated into executable modules, e.g. many OO-architectures, CORBA, n-tiered client-server, ... Point of view is runtime. 2) Construction architectures: the executable modules are partitioned into reusable components according to the isolation of change. Point of view is construction time, the goal is to localize the effects of change, to reduce complexity and ensure as much independance between components as possible, so when making changes to API's, data structures etc, as view components as possible have to be touched. ==> reuse is enhanced. Infrastructure for reuse: We have infrastructures for execution architectures (e.g. ORB's), but not really for construction time. It is hard to access and find multiple sources of supply of components. With infrastructure also come basic metrics that would give information about the return of investment in components. Flexible Software Manufacturing - a new paradigm? What it means: components that have the capability to adapt/customize themselves to concrete requirements. How does CHAIMS relate to this? - we are not changing any megamodules in the composition process, we may only add mediator megamodules to complete certain suites of megamodules - yet the megamodule providers can provide more or less suitable megamodules ==> ideally they package the functionality in such a way that the megamodule can be used in as many different settings as possible (minimal interface yet still flexible enough for many uses). The article also mentions some books about reuse, e.g. McClure 1997, Jacobson 1997, Date[ June 18, 1998] Recordnr[ ] Stored[ Who[ Michael VanHilst (works now at HP-Labs), D. Notkin Title[ Using Role Components to Implement Collaboration-Based Designs Published[ OOPSLA 96 Keywords[ aspect-oriented programming, roles, collaborations, roles as code entities Comment[ nice idea, might become an additional implementation paradigm, compareable to model-view-controller Summary[ Problem statement: Collaborations are modelled in the design. They show interactions between different roles (not really between different classes)==> collaborations as collections of roles. A role specifies a part of a single object that participates in a particular collaboration. One class can play several roles in differing collaborations; the same role is not implemented by the same class throughout all applications using that collaboration pattern. How could the notion of roles brought over to the implementation? Code reuse, system evolution: Collaborations in the design are derived from use-case-like scenarios in the requirements analysis. By having role-entities in the code, these use-cases could be reflected directly in the code, preserving this complementary view to the static class view. How? Inheritance is a logical glue for composing roles into classes, but: - inheritance must be delayed until whole composition and order of composition is known (compile-time, not code-writing time) - bindings to types must be delayed as well, so that roles can be coded independant of the specific classes taking them on, and thus be reused ==> class template for each role that is parameterized by each of the collaborator and by the class taking on the role itself ==> class then extend these templates, replacing the collaborators by the actual classes ==> a class having several roles is extended several times, each time the higher level class becomes a parameter in the next template to be extended ==> inheritance chain (but only simple inheritance is used) In order to get the right order in the inheritance chain, a roles/responsibility matrix is made. It helps to determine which roles (object methods) extend each other, and thus should override each other by calling the original one in case not the extended one is used. Related concepts: subject-oriented programming mixins Date[ November 2, 1] Recordnr[ ] Stored[ Papers sonst Who[ Michael M. Gormann Title[ The Essential Paradigm for Successful Information Technology Standards Published[ http://www.wiscorp.com/p115.htm Keywords[ standards, NIST, Comment[ Good entry paper. Summary[ The author emphesizes that there exist three main factors that must be fulfilled in order for a standard to be sucessful: - significant market share vendor community - publically developed, available, and evolving standard - enforced conformance tests Successful means the standard is adopted by a wide range of vendors. The paper discusses these points taking the SQL-standard and NIST who has given up conformance tests. The paper also shows the consequences for individual clients as well as the industry as a whole when successful standards do not exist (locked into one vendor, disabling competition by market leaders, high prizes for non-competitive products). Lost of references. hullo! i'm a synopsis, NOT a synApsis! testing 1.. 2.. 3.. Date[ June 24, 1998] Recordnr[ ] Stored[ Composition papers Who[ M.-C. Shan, J.W.Davis, et al Title[ Business Process Flow Management and its Application in the Telecommunications Management Network Published[ HP-Journal, October 1996 Keywords[ workflow, composition, Comment[ Summary[ The paper describes HP OpenPM, now called changengine and used by several banks. It is advanced workflow technology based on a framework approach for reusability. Goals of changengine: - substantial evolution from traditional workflow technologies - for distributed heterogenous computing environment (several procotols via wrappers) - it is a middleware system for procedural automation of a business process by managing the sequence of process activities, including the invocation of appropriate human, instrument or computer resources. - content, structure of process can be preplanned or ad hoc Main elements: - Process engine: based on the business process definition (graphically, rules) the process engine determines when something takes place and triggers activities. - Resource executive: manages resources - BOW: business object wrappers Definition of process: Graph containing work nodes and rule nodes. Each work node can again be a process containing work nodes and rule nodes. Work nodes have status initial or fired. Forward arcs denote normal execution flow, and they form directed acylic graph. Each work node can only have incoming arc, whereas rule nodes can have several incoming arcs (they have rules to deal with that). Both kind of nodes can have several outgoing arcs. Backward arcs are reset arcs, i.e. when they fire, everything in their loop is reset, and started tasks are aborted. Nodes fire like in a petri-net. Rules: e.g. "if Customer.approval = TRUE then arc 5" Events: rule nodes can also raise evens, which themselves can fire rules nodes that have subscribed to that event. Events are modelled like specific kind of nodes, like a shortcut for not drawing to many arcs across the graph. This kind of graph allows to describe: - sequencing and timing and dependancy of business activities, - data and physical agent allocation of business activities - business rules and organization policies Mapping of process definition to execution: Work node -- process activity(task) -- invocation of an operation on business objects(resource) during execution of a process BOW: BOW's wrap business objects and interface to the process engine via CORBA. Towards business objects they interface with various protocols, e.g. also DCOM and DNA. Business objects are catalogued in a library. Interfaces: from process engine are CORBA and WfMC (Workflow Managmenet Coalition standard interface) Optimization: Data handler: allows seperation of application specific data and process-relevant data needed for rule nodes, thus reducing amount of data flow. Resource manager: for automatic workload balancing. Statistical data: bottleneck analysis, flow optimization. References: - paper gives further references (not very new) - Reed Letsinger and Michael VantHilst at HP labs - webpage: www.pwd.hp.com/cyc/af/50/ is behind firewall Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J.M.Voas Title[ The Challenges of Using COTS Software in Component-Based Development Published[ IEEE Computer, June 1998, Vol31 No6, Guest Editors introduction Keywords[ COTS Comment[ Summary[ Software we acquire elsewhere: - COTS: commercial of the shelf - CAS: commercially available software - NDI: nondevelopmental item ==> used as components or componentware to build component-based software or systems of systems Problems in using componentware: - Components may integrate perfectly during development, but not behave perfectly at rntime. - We have process models for developing software from requirements, but not yet for acquiring software. - COTS are delivered as black box ==> how to determine that they behave safely, securely, and reliably? - How to access the quality of COTS? How to access suitability? Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J.McDermid Title[ The Cost of COTS Published[ IEEE Computer, June 1998, Vol31 No6, an interview Keywords[ COTS Comment[ Quite quite an interesting interview discussing general cost issues of COTS in contrast to bespoke (custom solutions), especially for safety- and reliability-critical system. The article is very critical towards COTS, mainly talks from a viewpoint of critical systems (process control systems, not information systems). Summary[ Promises of COTS: eliminate sfotware development project that overrun time and cost, greater ability to interoperate diverse systems, quickly evolve large systems, lower costs COTS nowadays: GUIs, operations systems, databases ==> mainly large components (and what about CERN-libraries, statistic tools etc.?) Risk mitigation: Problem: COTS are often build without a strict process and documentation control, no clear QA, and are delivered without appropriate documentation of the process, and without e.g. complete test-suites etc. (solutions: certification, using an escrow i.e. depositing the documentation at a bank for the case the company disappears). How to access the quality? - retrospective assessment is more expensive than assessing the software when developing it, if possible at all (code analysis) - each upgrade has to be assessed anew - software has not been written with the goal to access it (whereas bespoke for critical systems is structured and written in order to be accessed) - accessing needs also been done for all unwanted functionality (additional effort not necessary for bespoke) How to demonstrate the desired level of reliability, availability, integrity? - unwanted functions with dangerous side-effects How to control future of a COTS-component? - component can go out of business - new releases with unwanted functions - cost of upgrading - wrappers do not solve any of above problems Cost-tradeoff between COTS and bespoke: - price of purchase versus development - price of assessing quality of COTS to desired quality level - price of integrating COTS - price for upgrades, price for accessing upgrades, price for integrating upgrades - risk of vendor going out of business and expected life-time of system COTS can offer historical data for its quality (e.g. OS but not things like Microsoftword which get updates too often), bespoke has not historical data but you know what you are developing and can assess that. Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J. M.. Voas Title[ Certifying Off-the-Shelf Software Components Published[ IEEE Computer, June 1998, Vol31 No6, an interview Keywords[ COTS Comment[ Summary[ Three questions must be answered positively before using/certifying a COTS-component for a specific environment: 1 Does component C fill the Developer's needs? 2 Is the quality of component C high enough? 3 What impact will component C have on system S? Ways to answer that is by: a Black-box testing (answers question 1) b System-level fault injection c Operational system testing a and b together answer 2 and 3. Black-box testing: - best to build own oracle that tests comonents against needs of user and not against vendors specification - can fail to exercise important/faulty portions of the code System-level fault injection: Instead of the component a fault injector is put into the system (just the minimum amount of surrounding components is used) that works nearly like the component but randomly makes wrong results. Can the system stand that? Operational system testing: Problem: enormous amount needed for components that rarely fail. Advantage voer system-level fault injection: tests the real wrong behaviour. Remedy if component is not save enough: wrappers. Problem: Wrapper may not catch all the behaviour of a component. Date[ July 29, 1998] Recordnr[ ] Stored[ file-cabinet, Papers Composition Who[ J. Magee, N. Dulay, J. Kramer Title[ Regis: A Constructive Development Environment for Distributed Programs Published[ IEE/IOP/BCS Distributed Systems Engineering, 1(5): 304-312, Sept 1994. Keywords[ Comment[ Other papers about Regis/Darwin: Ng, K. and Kramer, J.; Automated Support for Distributed Software Design, appeared in 7th International Workshop on Computer-aided Software Engineering (CASE 95) Mostly describes the Software Architect's Assistant, a visual tool to set up distributed systems. Magee, J. and Dulay, N. and Eisenbach, S. and Kramer, J.;Specifying Distributed Software Architectures, appeared in 5th European Software Engineering Conference (ESEC 95) Presents a formal model of Darwin in Robin Milner's Pi-Calculus. Magee, J. and Dulay, N. and Kramer, J.; Regis: A Constructive Development Environment for Distributed Programs; IEE/IOP/BCS Distributed Systems Engineering},Volume = {1},Number = {5},1994 Describes the most recent distributed execution environment for Darwin-structured applications. Summary[ Darwin is a configuration language, Regis is a system supporting Darwin and generating the distributed systems specified in Darwin. For each component an interface is specified that contains all incoming and outgoing links. These can be of different types (pipes, ports...). The communications are implemented by special C++ components. The components to be configured/assembled can be either composite components, consisting of a set of lower level components, or computation components. Latter are written in C++ and must inherit from a predefined class process. Darwin also allows to imbed directly program code in the component descriptions. Components are garbage collected after termination. Regis runs on a Unix environment, the components can run on different Unix-workstations. A mapping file defines on which processor of the multicomputer which component is run. My conclusions: Regis supports program generation for a homogeneous environment. The distribution seems only to be local - I do not know if it is suited for servers located outside the intranet. The components that are composed are controlled entirely by the configuration language and by Regis (automatic garbage collection) - no autonomous servers that exist and run independant of the client. No equivalents to "EXAMINE", "ESTIMATE". Legacy code probably could be brought in, but I have not seen this issue being specifically adressed. As far as I know, no commercial application. Notes of Louis: I looked at a bunch of papers from Imperial College, London. The head of that group is Jeff Kramer, the relevant URLs are: Regis: http://www-dse.doc.ic.ac.uk/~regis/ Darwin: http://www-dse.doc.ic.ac.uk/~jsc/research/darwin.html Some of their work is relevant for RapArch, Architecture, and RapNet (see below). Regis has been in use since 1992. Darwin/Regis ============ Regis is a programming environment aimed at supporting the development and execution of distributed program. A Regis program consists of loosely coupled components either directly written in C++ (primitive components) or constructed out of simpler subcomponents by using the Darwin language. As such, Darwin is an Architecture Description Language (ADL) remarkably similar to the RAPIDE ADL. The Regis environment lets you develop the individual C++ components and the composition using Darwin, then compiles everything into executables and runs it on distributed sites. Regis/Darwin is restricted to the design/implementation phase. Once the program is compiled, installed and running, it is on its own, there is no support for ongoing analysis. One '95 paper said they will do run-time monitoring and management, but that will probably be primitive (i.e. just monitoring if they still run) and may not even exist. They stress the fact that a Regis program can be distributed (a la mobile agents), but I don't think that is the exciting thing about it. The Darwin ADL -------------- Darwin boxes are called "components", action declaration are called "services", arrows are called "bindings". Like RAPIDE, Darwin specifies both provided as required services. Services are typed and type conformance is enforced. Darwin allows hierarchical composition of components as well as parametrization, a component can consist of n subcomponents, with n decided statically at run time or dynamically at runtime. The latter is what they call dynamic architectures. In both cases, all n components have the same type, bindings, etc. This is just simple instantiation of a class. In some aspects Darwin is more general than Rapide ADL. The communication mechanism is not restricted to events. Darwin supports any communication mechanism (events, streams, RPC, etc. In Regis, the mechanism is then implemented as a C++ class). Thus the type of an action denotes the C++ class that implements it. A Darwin filter on a stream of characters would look like component filter { provide output; require input; } A funny thing happens when one looks at services of type "port". A port is used to send messages through and is interpreted in a procedure call style. Thus, to send a message, a sensor *requires* a port, the "output" becomes "required". The following comes from their paper and seems wrong for a RAPIDE person (at least for me). component sensor { provide input; require output; } I guess they run into this problem because they support both push (stream, event) and pull (port) communication with others. Pi-calculus ----------- Darwin is also specified in Milner's \pi-calculus. This is an elementary calculus for describing and analyzing concurrent, independent processes that communicate via channels. A subset of the Pi-calculus (http://www.cwi.nl/~arie/picalc.html) seems to be a candidate for our RapNet composition language. Software Architect Assistant ---------------------------- Regis comes with a graphical architecting tool called Software Architect Assistant (SAA), similar to RapArch. In comparison to RapArch, SAA's focus is more on providing semantics and ease-of-use and less on providing fancy drawing capabilities. All "boxes" have the same size, and "arrows" are laid out automatically by the tool and cannot be changed. (See http://www-dse.doc.ic.ac.uk/sel/sereports/rj1/rj1.html for an evaluation.) On the other hand, boxes and arrow have full semantic meaning, and correctness is checked at data entry point. The graphical and the textual view are always consistent. I especially like the separation between connections and interfaces. The "arrow" is just a line, the ending points indicating in which direction it points are part of the "box". This makes sense, because when you define a box, it is already clear which "actions" are "required" and which are "provided". SAA also displays nicely how services are connected when components are hierarchically encapsulated in each other. SAA also supports libraries of components, that can be included as sub-components in other components and it can read Darwin (textual) code not written by SAA. The SAA exports RTF reports that can be directly imported into word processors. Date[ August 5, 199] Recordnr[ ] Stored[Composition, filecabinet Who[ I. Ben-Shaul, et.al. Title[ HADAS: A Network-Centric Framework for Interoperability Programming Published[ International Journal of Cooperative Informaion Systems, 1997 Keywords[ heterogeneity, RMI, HADAS, coordination language, Comment[ Very interesting approach. More focused on roaming agents. Summary[ Challenge: Compose, configure and execute network-centric applicatins made up of widely-distributed components. Major problem: global interoperability Examples: active, intelligent information agents; inter-organization collaborative workflow systems, e-commerce, large-scale concurrent computations Main ideas of HADAS (=heterogeneous autonomous distributed abstraction system): - autonomy of objects: administrative autonomy (==> evolving over time), design autonomy (heterogeneity) - network centric framework - no central agent like a broker, fully decentralized (==> possible by using RMI) - dynamic and programmable approach to interoperability, peer-to-peer configuration agreement - ISL as coordination lanague Approch: - a (reflective and mobile object model abstracting components - a Java-based framework in which components live and communicate - a higher-order interpreted coordination language that manipulates components Basic architecture: The comonponents are distributed object managers. These not only implement various ilities like security and unique id and persistence, they also contain or wrapp the effective behaviour offered by this component. These objects communicate with each other mainly over RMI. They could also use ftp, http or amp. The whole HADAS system is written in Java. Access to legacy components is by wrappers - these wrappers, written mainly in Java, e.g. access CORBA-components etc. If necessary, they also use native code. As all of HADAS is Java, data is communicated in Java format. For type- mismatches, peer-to-peer dynamic wrappers exist that transform data. Levels of interoperability in Hadas: - interconnectivity infrastructure (in Java), reflective object model supporting mutability and mobility - integration : who can access whom? - configuration: dynamic agreemant between sites over use of comonents - coordination: control and dataflow between components, ISL Configuration: The operation to be called is link. What link does is: it copies a suitable ambassador objects to the other site. These ambassador objects then act like stubs. Ambassadors for the same siteobjects on various sites may have different dynamic parts in them. Each object supports methods like: add, remove (a method dynamically), invoke (a method with given parameters), describe (the offered methods). Ambassadors: - not just stubs, they have HADAS methods (install, update) - they have dynamic transformers (wrappers) and can evolve dynamically by interacting with hosting environment Reflective object model: - objects can answer questions about itself (given by Java) - object can change itself (addDataItem, addMethod, setMethod), trivial in Java - security specifications per method (probably all from Java) Wrappers: - dynamic linking to Java components - accessing C++ code with JNI - CORBA-HADAS, static wrapping - HTTP/CGI out and in transformer, dynamic wrapping Coordination, ISL: The language used is Scheme, implemented in Java. It supports weak typing and allows to encode higher-order procedures. http://www.dsg.technion.ac.il db lm wp ns gw Date[ May 27, 1998 ] Recordnr[ 1 ] Stored[ Composition Who[ Scott M. Lewandowski Title[ Frameworks for Component-Based Client/Server Computing Published[ ACM Computing Surveys, Vol.30, No.1, March 1998 Keywords[ CORBA, compound document, DCOM, JAVA, business object Comment[ Summary[ General impression: very pro CORBA, does not mention RMI, paper tries to cover a large area with doubtful success Middleware is defined to include the APIs used by clients to request a service from a server, the physical transmittion of the request to the network, and the rewulting transmission of data for the client back to the network. Middleware is run on both the client and server ends of a transaction. Three different kinds of middleware: - database middleware (ODBC, SQL, Oracle Glue) - groupware middleware (Lotus Notes, Microsoft Exchange) - inernet middleware (HTTP, secure socket layer) - object middleware (CORBA, DCOM) Furthermore: fundamental/generic middleware against domain-specific middleware. Fundamental: distributed file system, RPC, authentication... Various kind of systems: - fat servers versus fat clients: data on server, UI on client - is the application logic on the server or the client? - three-tier systems: application logic is separate ==> new level of autonomy for applicatino logic. Ex: web-applications with browser, applets or cgi-scripts, database - four-tiers: e.g. with additional second tier for unifying view of the data of the databases of first tier, (CHAIMS with new architecture would also be 4 tier system) CORBA is great!!!?? - "Technologies such as Java and object request brokers (ORBs) promise to provide seamless integration among all platforms within a few years." - "only CORBA and DCOM provide viable long-term solutions to the challenge of a standardized framework for object-based client/server systems, others do not have enough features or as great an installed base..." - yet CORBA is much better, because in DCOM e.g. no real objects (objects have no state, they are just procedures ==> handles to objects are arbitrary and only garuantee interface not object-state, no unique object identifier, no persistency supported) - also DCOM objects cannot automatically support multiple interfaces, - also clients cannot request for a specific given server, - also only using WindowsNT security model and no own universal security mechanism like CORBA - CORBA and Java are made for each other and together will win (???) ==> platform for universal network computing can be created using Java as mobile code systems and CORBA as integration technology Claims (not really true in my view): - java-interfaces and CORBA-IDL's are very similar (RMI transports code and methods, not just data!! ==> totally different kind of distributed programming) - CORBA allows parameters of any type (yes, it allows more than CGI, but not "any") Selfmanaging objects: - take responsibility for their own resources, work across networks, interact with other objects - smallest ones are components like activeX controls - ===> solid event model necessary that allows objects to broadcast specific messages and generate certain events (events = synchronisation objects) - ===> transparency of location and implementation is important (as offered by CORBA) BOMSIG (Business Object Model Special Interest Group), as example for framework on top of CORBA - no references given - promotes three-tier framework for buisness objects, consisting of business object logic, business proces objects, presenation object (differences not clear to me) Compound document framework (another example of a framework on top of CORBA) njs Date[ 11:31:04 ] Recordnr[ ] Stored[ Papers Composition Who[ J.R.Callahan, J.M Purtilo, University of Maryland Title[ A Packaging System for Heterogeneous Execution Environments Published[ IEEE Transactions on Software Engineering, vol.17, 1991, pp.626-635 Keywords[ MIL, Polygen, Polylith Comment[ more for small, on-one-site components, strenth is partitioning and automatic reasoning about possible configurations, yet automatic generation is limitied to certain environments Summary[ Polylith: TCP/IP-based communication systems for various languages. Polygen: Composotion and reasoning tool. What it is about: - generation of custom interface software for heterogeneous configurations. - in contrast to other approaches, not only stub generation, but inserting configuration methods needed to integrate an application (e.g. main, wrappers/dispachter program for LISP-procedures, byteswap functions for adjusting integers to various representations, rendezvous functions) - polygen changes source code and adds necessary lines and stubs so they can work over network - all is automatic, user just has to specify desired geometry - logical design is separated from the geometry Composition process: Starting point: several source files (C, Ada, Pascal, Lisp) that contain modules(procedure calls) to be composed. In the extraction phase, module specs are gained from the source files, or these module specs already exist. Module specs: are written in Polylith MIL (module interconnection language). It contains the interfaces a module offers and uses and the parameters of these procedure calls. In the composition phase, the user adds the design and annotated design (with geometric data) to the specs. The design says which modules are to be used, which communication system, where the modules are. Then in the generatin phase POLYGEN makes a package based on the configuration rules it has. Configuration rules are added by the Polygen system maintainer and say what kind of modules can be connected how. A package (valid configuration represented in an executable makefile and generated stubs and interfaces) is gained by an interference mechanism that uses partitioning. Module assertions are converted to prolog statements. Based on configuration rules, partitions are created.... Finally in the construction phase an executable is generated by running the makefile that polygen has created in the generation phase. Partitioning: Partitions are sets of compatible components. They can be represented by directed, acyclic graphs,whose internal nodes represent integration methods and temrinal nodes represent source components. Valid partitioning: has only a single root. Weaknesses: - source code must be changed and recompiled - right now only for Polylith-TCP/IP - data-conversion relies on underlying communication tool - good for putting together inhouse modules - rather targeted at smaller modules - no optimization, scheduling etc... Date[ August 21, 19] Recordnr[ ] Stored[ see library Who[ Charles W. Krueger Title[ Software Reuse Published[ ACM Computing Surveys, Vol. 24, No. 2, June 1992 Keywords[ reuse, abstraction Comment[ Summary[ Abstraction: Abstraction and reuse are two sides of the same coin. Many references given for that. Abstraction occurs in layers. In each layer we can distinguish between the abstraction specification, and the abstraction realization (contains hidden parts of the abstraction).Specification contains fixed part and variable part of the abstraction. 4 facets of software reuse are looked at in the paper, though all build on top of abstraction: - abstraction: what the abstraction is at all - selection: how users find abstractions, requires consice specifications - speciliations: choosing the abstraction realisations and the correct flexible parts - integration: interface of an abstraction, how are abstractions integrated in complete software system Reuse is being looked at in the following fields: 1) High-level languages: - reusable artifacts are the language elements, which abstract assembly language patterns. - variable parts are the statements and conditions we can fill in - integration is done by compilers, hidden parts (assembler language) are never visible - cognitive distance to a problem at hand is quite large (yet smaller than with pure assembler) 2) Design and Code scavenging - code scavenging: copying small code fragments without changing - design scavenging: copying larger code fragments containing a design pattern, and changing details yet keeping overall design; or making new code based on earlier experiences - very informal, not always worth while - no hidden parts of abstraction, specialization and integration require intimate knowledge of the code - if large pieces of good code can be reused without looking too much into it, the cognitive distance is small 3) Source Code Components Main contrast to code scavenging: components are build to reuse. The description here is a little bit outdated. He mentions mathematical analysis libraries and ADA-components. Nowadays, we would add JFC, MFC, RoqueWafe etc. Integration has been improved by todays OO-languages, specialization has been clearly "reduced" to parameters and inheritance. Selection is getting better by good browsers, web-pages etc.... 4) Software Schemas Quite outdated, the mentioned tools have not made it. Schemas seem to be quite similar to templates and design patterns. The foculs lies on higher level semantics descriptions of components, and of schemas how things work together (just design patterns). 5) Application generators Whole applications are generated, e.g. parser and compiler generator. Only certain rules, modules, elements, diagrams are written. The rest is generated. The abstractions come directly from the application domain. Cognitive distance is very small. 6) Very High-level Languages VHLL = executable specification languages Developing in a VHLL is similar to developing in a HLL (writing program that gets compiled). Like application generators, VHLL will generate the applications, yet VHLL are general purpose. VHLL want higher levels of specification without sacrificing computational generatily. - VHLLs are often very slow, yet execution efficiency is sacrificed for implementation and modification effencency - VHLLs are often based on some higher level mathematical model Examples for VHLLs: - SETL: based on set theory, good for easy use of abstract data types - PAISLey: functional programming, ..... - MODEL: declarative constraint language Main concern: execution speed. 7) Transformational systems 8) Architectural abstractions - come directly from application domain Date[ July 8, 1998 ] Recordnr[ ] Stored[ bookshelf? Who[ P. Bassett Title[ Managing for Flexible Software Manufacturing Published[ IEEE Computer, vol31, no7, July 1998 Keywords[ Comment[ Summary[ The article discusses reuse, the reason why it does not happen, and proposes some remedies. Reasons why reuse does not happen: - Old manufacturing culture: we only trust our own software, and distrust other software; "our software will be far better" - Management supports these habits Management strategies to overcome old culture: 1) Promoting reuse within same project, i.e. avoiding perfectionism and over-generalisation syndrom. 2) Own and manage multiproject assets centrally by central profit-centre that rents out component engineers (actual glue) that help individual projects to use these components fast and effectively. Architectures for reuse, two types: 1) Execution architectures: system is encapsulated into executable modules, e.g. many OO-architectures, CORBA, n-tiered client-server, ... Point of view is runtime. 2) Construction architectures: the executable modules are partitioned into reusable components according to the isolation of change. Point of view is construction time, the goal is to localize the effects of change, to reduce complexity and ensure as much independance between components as possible, so when making changes to API's, data structures etc, as view components as possible have to be touched. ==> reuse is enhanced. Infrastructure for reuse: We have infrastructures for execution architectures (e.g. ORB's), but not really for construction time. It is hard to access and find multiple sources of supply of components. With infrastructure also come basic metrics that would give information about the return of investment in components. Flexible Software Manufacturing - a new paradigm? What it means: components that have the capability to adapt/customize themselves to concrete requirements. How does CHAIMS relate to this? - we are not changing any megamodules in the composition process, we may only add mediator megamodules to complete certain suites of megamodules - yet the megamodule providers can provide more or less suitable megamodules ==> ideally they package the functionality in such a way that the megamodule can be used in as many different settings as possible (minimal interface yet still flexible enough for many uses). The article also mentions some books about reuse, e.g. McClure 1997, Jacobson 1997, Date[ June 18, 1998] Recordnr[ ] Stored[ Who[ Michael VanHilst (works now at HP-Labs), D. Notkin Title[ Using Role Components to Implement Collaboration-Based Designs Published[ OOPSLA 96 Keywords[ aspect-oriented programming, roles, collaborations, roles as code entities Comment[ nice idea, might become an additional implementation paradigm, compareable to model-view-controller Summary[ Problem statement: Collaborations are modelled in the design. They show interactions between different roles (not really between different classes)==> collaborations as collections of roles. A role specifies a part of a single object that participates in a particular collaboration. One class can play several roles in differing collaborations; the same role is not implemented by the same class throughout all applications using that collaboration pattern. How could the notion of roles brought over to the implementation? Code reuse, system evolution: Collaborations in the design are derived from use-case-like scenarios in the requirements analysis. By having role-entities in the code, these use-cases could be reflected directly in the code, preserving this complementary view to the static class view. How? Inheritance is a logical glue for composing roles into classes, but: - inheritance must be delayed until whole composition and order of composition is known (compile-time, not code-writing time) - bindings to types must be delayed as well, so that roles can be coded independant of the specific classes taking them on, and thus be reused ==> class template for each role that is parameterized by each of the collaborator and by the class taking on the role itself ==> class then extend these templates, replacing the collaborators by the actual classes ==> a class having several roles is extended several times, each time the higher level class becomes a parameter in the next template to be extended ==> inheritance chain (but only simple inheritance is used) In order to get the right order in the inheritance chain, a roles/responsibility matrix is made. It helps to determine which roles (object methods) extend each other, and thus should override each other by calling the original one in case not the extended one is used. Related concepts: subject-oriented programming mixins Date[ November 2, 1] Recordnr[ ] Stored[ Papers sonst Who[ Michael M. Gormann Title[ The Essential Paradigm for Successful Information Technology Standards Published[ http://www.wiscorp.com/p115.htm Keywords[ standards, NIST, Comment[ Good entry paper. Summary[ The author emphesizes that there exist three main factors that must be fulfilled in order for a standard to be sucessful: - significant market share vendor community - publically developed, available, and evolving standard - enforced conformance tests Successful means the standard is adopted by a wide range of vendors. The paper discusses these points taking the SQL-standard and NIST who has given up conformance tests. The paper also shows the consequences for individual clients as well as the industry as a whole when successful standards do not exist (locked into one vendor, disabling competition by market leaders, high prizes for non-competitive products). Lost of references. hullo! i'm a synopsis, NOT a synApsis! testing 1.. 2.. 3.. Date[ June 24, 1998] Recordnr[ ] Stored[ Composition papers Who[ M.-C. Shan, J.W.Davis, et al Title[ Business Process Flow Management and its Application in the Telecommunications Management Network Published[ HP-Journal, October 1996 Keywords[ workflow, composition, Comment[ Summary[ The paper describes HP OpenPM, now called changengine and used by several banks. It is advanced workflow technology based on a framework approach for reusability. Goals of changengine: - substantial evolution from traditional workflow technologies - for distributed heterogenous computing environment (several procotols via wrappers) - it is a middleware system for procedural automation of a business process by managing the sequence of process activities, including the invocation of appropriate human, instrument or computer resources. - content, structure of process can be preplanned or ad hoc Main elements: - Process engine: based on the business process definition (graphically, rules) the process engine determines when something takes place and triggers activities. - Resource executive: manages resources - BOW: business object wrappers Definition of process: Graph containing work nodes and rule nodes. Each work node can again be a process containing work nodes and rule nodes. Work nodes have status initial or fired. Forward arcs denote normal execution flow, and they form directed acylic graph. Each work node can only have incoming arc, whereas rule nodes can have several incoming arcs (they have rules to deal with that). Both kind of nodes can have several outgoing arcs. Backward arcs are reset arcs, i.e. when they fire, everything in their loop is reset, and started tasks are aborted. Nodes fire like in a petri-net. Rules: e.g. "if Customer.approval = TRUE then arc 5" Events: rule nodes can also raise evens, which themselves can fire rules nodes that have subscribed to that event. Events are modelled like specific kind of nodes, like a shortcut for not drawing to many arcs across the graph. This kind of graph allows to describe: - sequencing and timing and dependancy of business activities, - data and physical agent allocation of business activities - business rules and organization policies Mapping of process definition to execution: Work node -- process activity(task) -- invocation of an operation on business objects(resource) during execution of a process BOW: BOW's wrap business objects and interface to the process engine via CORBA. Towards business objects they interface with various protocols, e.g. also DCOM and DNA. Business objects are catalogued in a library. Interfaces: from process engine are CORBA and WfMC (Workflow Managmenet Coalition standard interface) Optimization: Data handler: allows seperation of application specific data and process-relevant data needed for rule nodes, thus reducing amount of data flow. Resource manager: for automatic workload balancing. Statistical data: bottleneck analysis, flow optimization. References: - paper gives further references (not very new) - Reed Letsinger and Michael VantHilst at HP labs - webpage: www.pwd.hp.com/cyc/af/50/ is behind firewall Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J.M.Voas Title[ The Challenges of Using COTS Software in Component-Based Development Published[ IEEE Computer, June 1998, Vol31 No6, Guest Editors introduction Keywords[ COTS Comment[ Summary[ Software we acquire elsewhere: - COTS: commercial of the shelf - CAS: commercially available software - NDI: nondevelopmental item ==> used as components or componentware to build component-based software or systems of systems Problems in using componentware: - Components may integrate perfectly during development, but not behave perfectly at rntime. - We have process models for developing software from requirements, but not yet for acquiring software. - COTS are delivered as black box ==> how to determine that they behave safely, securely, and reliably? - How to access the quality of COTS? How to access suitability? Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J.McDermid Title[ The Cost of COTS Published[ IEEE Computer, June 1998, Vol31 No6, an interview Keywords[ COTS Comment[ Quite quite an interesting interview discussing general cost issues of COTS in contrast to bespoke (custom solutions), especially for safety- and reliability-critical system. The article is very critical towards COTS, mainly talks from a viewpoint of critical systems (process control systems, not information systems). Summary[ Promises of COTS: eliminate sfotware development project that overrun time and cost, greater ability to interoperate diverse systems, quickly evolve large systems, lower costs COTS nowadays: GUIs, operations systems, databases ==> mainly large components (and what about CERN-libraries, statistic tools etc.?) Risk mitigation: Problem: COTS are often build without a strict process and documentation control, no clear QA, and are delivered without appropriate documentation of the process, and without e.g. complete test-suites etc. (solutions: certification, using an escrow i.e. depositing the documentation at a bank for the case the company disappears). How to access the quality? - retrospective assessment is more expensive than assessing the software when developing it, if possible at all (code analysis) - each upgrade has to be assessed anew - software has not been written with the goal to access it (whereas bespoke for critical systems is structured and written in order to be accessed) - accessing needs also been done for all unwanted functionality (additional effort not necessary for bespoke) How to demonstrate the desired level of reliability, availability, integrity? - unwanted functions with dangerous side-effects How to control future of a COTS-component? - component can go out of business - new releases with unwanted functions - cost of upgrading - wrappers do not solve any of above problems Cost-tradeoff between COTS and bespoke: - price of purchase versus development - price of assessing quality of COTS to desired quality level - price of integrating COTS - price for upgrades, price for accessing upgrades, price for integrating upgrades - risk of vendor going out of business and expected life-time of system COTS can offer historical data for its quality (e.g. OS but not things like Microsoftword which get updates too often), bespoke has not historical data but you know what you are developing and can assess that. Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J. M.. Voas Title[ Certifying Off-the-Shelf Software Components Published[ IEEE Computer, June 1998, Vol31 No6, an interview Keywords[ COTS Comment[ Summary[ Three questions must be answered positively before using/certifying a COTS-component for a specific environment: 1 Does component C fill the Developer's needs? 2 Is the quality of component C high enough? 3 What impact will component C have on system S? Ways to answer that is by: a Black-box testing (answers question 1) b System-level fault injection c Operational system testing a and b together answer 2 and 3. Black-box testing: - best to build own oracle that tests comonents against needs of user and not against vendors specification - can fail to exercise important/faulty portions of the code System-level fault injection: Instead of the component a fault injector is put into the system (just the minimum amount of surrounding components is used) that works nearly like the component but randomly makes wrong results. Can the system stand that? Operational system testing: Problem: enormous amount needed for components that rarely fail. Advantage voer system-level fault injection: tests the real wrong behaviour. Remedy if component is not save enough: wrappers. Problem: Wrapper may not catch all the behaviour of a component. Date[ July 29, 1998] Recordnr[ ] Stored[ file-cabinet, Papers Composition Who[ J. Magee, N. Dulay, J. Kramer Title[ Regis: A Constructive Development Environment for Distributed Programs Published[ IEE/IOP/BCS Distributed Systems Engineering, 1(5): 304-312, Sept 1994. Keywords[ Comment[ Other papers about Regis/Darwin: Ng, K. and Kramer, J.; Automated Support for Distributed Software Design, appeared in 7th International Workshop on Computer-aided Software Engineering (CASE 95) Mostly describes the Software Architect's Assistant, a visual tool to set up distributed systems. Magee, J. and Dulay, N. and Eisenbach, S. and Kramer, J.;Specifying Distributed Software Architectures, appeared in 5th European Software Engineering Conference (ESEC 95) Presents a formal model of Darwin in Robin Milner's Pi-Calculus. Magee, J. and Dulay, N. and Kramer, J.; Regis: A Constructive Development Environment for Distributed Programs; IEE/IOP/BCS Distributed Systems Engineering},Volume = {1},Number = {5},1994 Describes the most recent distributed execution environment for Darwin-structured applications. Summary[ Darwin is a configuration language, Regis is a system supporting Darwin and generating the distributed systems specified in Darwin. For each component an interface is specified that contains all incoming and outgoing links. These can be of different types (pipes, ports...). The communications are implemented by special C++ components. The components to be configured/assembled can be either composite components, consisting of a set of lower level components, or computation components. Latter are written in C++ and must inherit from a predefined class process. Darwin also allows to imbed directly program code in the component descriptions. Components are garbage collected after termination. Regis runs on a Unix environment, the components can run on different Unix-workstations. A mapping file defines on which processor of the multicomputer which component is run. My conclusions: Regis supports program generation for a homogeneous environment. The distribution seems only to be local - I do not know if it is suited for servers located outside the intranet. The components that are composed are controlled entirely by the configuration language and by Regis (automatic garbage collection) - no autonomous servers that exist and run independant of the client. No equivalents to "EXAMINE", "ESTIMATE". Legacy code probably could be brought in, but I have not seen this issue being specifically adressed. As far as I know, no commercial application. Notes of Louis: I looked at a bunch of papers from Imperial College, London. The head of that group is Jeff Kramer, the relevant URLs are: Regis: http://www-dse.doc.ic.ac.uk/~regis/ Darwin: http://www-dse.doc.ic.ac.uk/~jsc/research/darwin.html Some of their work is relevant for RapArch, Architecture, and RapNet (see below). Regis has been in use since 1992. Darwin/Regis ============ Regis is a programming environment aimed at supporting the development and execution of distributed program. A Regis program consists of loosely coupled components either directly written in C++ (primitive components) or constructed out of simpler subcomponents by using the Darwin language. As such, Darwin is an Architecture Description Language (ADL) remarkably similar to the RAPIDE ADL. The Regis environment lets you develop the individual C++ components and the composition using Darwin, then compiles everything into executables and runs it on distributed sites. Regis/Darwin is restricted to the design/implementation phase. Once the program is compiled, installed and running, it is on its own, there is no support for ongoing analysis. One '95 paper said they will do run-time monitoring and management, but that will probably be primitive (i.e. just monitoring if they still run) and may not even exist. They stress the fact that a Regis program can be distributed (a la mobile agents), but I don't think that is the exciting thing about it. The Darwin ADL -------------- Darwin boxes are called "components", action declaration are called "services", arrows are called "bindings". Like RAPIDE, Darwin specifies both provided as required services. Services are typed and type conformance is enforced. Darwin allows hierarchical composition of components as well as parametrization, a component can consist of n subcomponents, with n decided statically at run time or dynamically at runtime. The latter is what they call dynamic architectures. In both cases, all n components have the same type, bindings, etc. This is just simple instantiation of a class. In some aspects Darwin is more general than Rapide ADL. The communication mechanism is not restricted to events. Darwin supports any communication mechanism (events, streams, RPC, etc. In Regis, the mechanism is then implemented as a C++ class). Thus the type of an action denotes the C++ class that implements it. A Darwin filter on a stream of characters would look like component filter { provide output; require input; } A funny thing happens when one looks at services of type "port". A port is used to send messages through and is interpreted in a procedure call style. Thus, to send a message, a sensor *requires* a port, the "output" becomes "required". The following comes from their paper and seems wrong for a RAPIDE person (at least for me). component sensor { provide input; require output; } I guess they run into this problem because they support both push (stream, event) and pull (port) communication with others. Pi-calculus ----------- Darwin is also specified in Milner's \pi-calculus. This is an elementary calculus for describing and analyzing concurrent, independent processes that communicate via channels. A subset of the Pi-calculus (http://www.cwi.nl/~arie/picalc.html) seems to be a candidate for our RapNet composition language. Software Architect Assistant ---------------------------- Regis comes with a graphical architecting tool called Software Architect Assistant (SAA), similar to RapArch. In comparison to RapArch, SAA's focus is more on providing semantics and ease-of-use and less on providing fancy drawing capabilities. All "boxes" have the same size, and "arrows" are laid out automatically by the tool and cannot be changed. (See http://www-dse.doc.ic.ac.uk/sel/sereports/rj1/rj1.html for an evaluation.) On the other hand, boxes and arrow have full semantic meaning, and correctness is checked at data entry point. The graphical and the textual view are always consistent. I especially like the separation between connections and interfaces. The "arrow" is just a line, the ending points indicating in which direction it points are part of the "box". This makes sense, because when you define a box, it is already clear which "actions" are "required" and which are "provided". SAA also displays nicely how services are connected when components are hierarchically encapsulated in each other. SAA also supports libraries of components, that can be included as sub-components in other components and it can read Darwin (textual) code not written by SAA. The SAA exports RTF reports that can be directly imported into word processors. Date[ August 5, 199] Recordnr[ ] Stored[Composition, filecabinet Who[ I. Ben-Shaul, et.al. Title[ HADAS: A Network-Centric Framework for Interoperability Programming Published[ International Journal of Cooperative Informaion Systems, 1997 Keywords[ heterogeneity, RMI, HADAS, coordination language, Comment[ Very interesting approach. More focused on roaming agents. Summary[ Challenge: Compose, configure and execute network-centric applicatins made up of widely-distributed components. Major problem: global interoperability Examples: active, intelligent information agents; inter-organization collaborative workflow systems, e-commerce, large-scale concurrent computations Main ideas of HADAS (=heterogeneous autonomous distributed abstraction system): - autonomy of objects: administrative autonomy (==> evolving over time), design autonomy (heterogeneity) - network centric framework - no central agent like a broker, fully decentralized (==> possible by using RMI) - dynamic and programmable approach to interoperability, peer-to-peer configuration agreement - ISL as coordination lanague Approch: - a (reflective and mobile object model abstracting components - a Java-based framework in which components live and communicate - a higher-order interpreted coordination language that manipulates components Basic architecture: The comonponents are distributed object managers. These not only implement various ilities like security and unique id and persistence, they also contain or wrapp the effective behaviour offered by this component. These objects communicate with each other mainly over RMI. They could also use ftp, http or amp. The whole HADAS system is written in Java. Access to legacy components is by wrappers - these wrappers, written mainly in Java, e.g. access CORBA-components etc. If necessary, they also use native code. As all of HADAS is Java, data is communicated in Java format. For type- mismatches, peer-to-peer dynamic wrappers exist that transform data. Levels of interoperability in Hadas: - interconnectivity infrastructure (in Java), reflective object model supporting mutability and mobility - integration : who can access whom? - configuration: dynamic agreemant between sites over use of comonents - coordination: control and dataflow between components, ISL Configuration: The operation to be called is link. What link does is: it copies a suitable ambassador objects to the other site. These ambassador objects then act like stubs. Ambassadors for the same siteobjects on various sites may have different dynamic parts in them. Each object supports methods like: add, remove (a method dynamically), invoke (a method with given parameters), describe (the offered methods). Ambassadors: - not just stubs, they have HADAS methods (install, update) - they have dynamic transformers (wrappers) and can evolve dynamically by interacting with hosting environment Reflective object model: - objects can answer questions about itself (given by Java) - object can change itself (addDataItem, addMethod, setMethod), trivial in Java - security specifications per method (probably all from Java) Wrappers: - dynamic linking to Java components - accessing C++ code with JNI - CORBA-HADAS, static wrapping - HTTP/CGI out and in transformer, dynamic wrapping Coordination, ISL: The language used is Scheme, implemented in Java. It supports weak typing and allows to encode higher-order procedures. http://www.dsg.technion.ac.il Date[ May 27, 1998 ] Recordnr[ 1 ] Stored[ Composition Who[ Scott M. Lewandowski Title[ Frameworks for Component-Based Client/Server Computing Published[ ACM Computing Surveys, Vol.30, No.1, March 1998 Keywords[ CORBA, compound document, DCOM, JAVA, business object Comment[ Summary[ General impression: very pro CORBA, does not mention RMI, paper tries to cover a large area with doubtful success Middleware is defined to include the APIs used by clients to request a service from a server, the physical transmittion of the request to the network, and the rewulting transmission of data for the client back to the network. Middleware is run on both the client and server ends of a transaction. Three different kinds of middleware: - database middleware (ODBC, SQL, Oracle Glue) - groupware middleware (Lotus Notes, Microsoft Exchange) - inernet middleware (HTTP, secure socket layer) - object middleware (CORBA, DCOM) Furthermore: fundamental/generic middleware against domain-specific middleware. Fundamental: distributed file system, RPC, authentication... Various kind of systems: - fat servers versus fat clients: data on server, UI on client - is the application logic on the server or the client? - three-tier systems: application logic is separate ==> new level of autonomy for applicatino logic. Ex: web-applications with browser, applets or cgi-scripts, database - four-tiers: e.g. with additional second tier for unifying view of the data of the databases of first tier, (CHAIMS with new architecture would also be 4 tier system) CORBA is great!!!?? - "Technologies such as Java and object request brokers (ORBs) promise to provide seamless integration among all platforms within a few years." - "only CORBA and DCOM provide viable long-term solutions to the challenge of a standardized framework for object-based client/server systems, others do not have enough features or as great an installed base..." - yet CORBA is much better, because in DCOM e.g. no real objects (objects have no state, they are just procedures ==> handles to objects are arbitrary and only garuantee interface not object-state, no unique object identifier, no persistency supported) - also DCOM objects cannot automatically support multiple interfaces, - also clients cannot request for a specific given server, - also only using WindowsNT security model and no own universal security mechanism like CORBA - CORBA and Java are made for each other and together will win (???) ==> platform for universal network computing can be created using Java as mobile code systems and CORBA as integration technology Claims (not really true in my view): - java-interfaces and CORBA-IDL's are very similar (RMI transports code and methods, not just data!! ==> totally different kind of distributed programming) - CORBA allows parameters of any type (yes, it allows more than CGI, but not "any") Selfmanaging objects: - take responsibility for their own resources, work across networks, interact with other objects - smallest ones are components like activeX controls - ===> solid event model necessary that allows objects to broadcast specific messages and generate certain events (events = synchronisation objects) - ===> transparency of location and implementation is important (as offered by CORBA) BOMSIG (Business Object Model Special Interest Group), as example for framework on top of CORBA - no references given - promotes three-tier framework for buisness objects, consisting of business object logic, business proces objects, presenation object (differences not clear to me) Compound document framework (another example of a framework on top of CORBA) Date[ 11:31:04 ] Recordnr[ ] Stored[ Papers Composition Who[ J.R.Callahan, J.M Purtilo, University of Maryland Title[ A Packaging System for Heterogeneous Execution Environments Published[ IEEE Transactions on Software Engineering, vol.17, 1991, pp.626-635 Keywords[ MIL, Polygen, Polylith Comment[ more for small, on-one-site components, strenth is partitioning and automatic reasoning about possible configurations, yet automatic generation is limitied to certain environments Summary[ Polylith: TCP/IP-based communication systems for various languages. Polygen: Composotion and reasoning tool. What it is about: - generation of custom interface software for heterogeneous configurations. - in contrast to other approaches, not only stub generation, but inserting configuration methods needed to integrate an application (e.g. main, wrappers/dispachter program for LISP-procedures, byteswap functions for adjusting integers to various representations, rendezvous functions) - polygen changes source code and adds necessary lines and stubs so they can work over network - all is automatic, user just has to specify desired geometry - logical design is separated from the geometry Composition process: Starting point: several source files (C, Ada, Pascal, Lisp) that contain modules(procedure calls) to be composed. In the extraction phase, module specs are gained from the source files, or these module specs already exist. Module specs: are written in Polylith MIL (module interconnection language). It contains the interfaces a module offers and uses and the parameters of these procedure calls. In the composition phase, the user adds the design and annotated design (with geometric data) to the specs. The design says which modules are to be used, which communication system, where the modules are. Then in the generatin phase POLYGEN makes a package based on the configuration rules it has. Configuration rules are added by the Polygen system maintainer and say what kind of modules can be connected how. A package (valid configuration represented in an executable makefile and generated stubs and interfaces) is gained by an interference mechanism that uses partitioning. Module assertions are converted to prolog statements. Based on configuration rules, partitions are created.... Finally in the construction phase an executable is generated by running the makefile that polygen has created in the generation phase. Partitioning: Partitions are sets of compatible components. They can be represented by directed, acyclic graphs,whose internal nodes represent integration methods and temrinal nodes represent source components. Valid partitioning: has only a single root. Weaknesses: - source code must be changed and recompiled - right now only for Polylith-TCP/IP - data-conversion relies on underlying communication tool - good for putting together inhouse modules - rather targeted at smaller modules - no optimization, scheduling etc... Date[ August 21, 19] Recordnr[ ] Stored[ see library Who[ Charles W. Krueger Title[ Software Reuse Published[ ACM Computing Surveys, Vol. 24, No. 2, June 1992 Keywords[ reuse, abstraction Comment[ Summary[ Abstraction: Abstraction and reuse are two sides of the same coin. Many references given for that. Abstraction occurs in layers. In each layer we can distinguish between the abstraction specification, and the abstraction realization (contains hidden parts of the abstraction).Specification contains fixed part and variable part of the abstraction. 4 facets of software reuse are looked at in the paper, though all build on top of abstraction: - abstraction: what the abstraction is at all - selection: how users find abstractions, requires consice specifications - speciliations: choosing the abstraction realisations and the correct flexible parts - integration: interface of an abstraction, how are abstractions integrated in complete software system Reuse is being looked at in the following fields: 1) High-level languages: - reusable artifacts are the language elements, which abstract assembly language patterns. - variable parts are the statements and conditions we can fill in - integration is done by compilers, hidden parts (assembler language) are never visible - cognitive distance to a problem at hand is quite large (yet smaller than with pure assembler) 2) Design and Code scavenging - code scavenging: copying small code fragments without changing - design scavenging: copying larger code fragments containing a design pattern, and changing details yet keeping overall design; or making new code based on earlier experiences - very informal, not always worth while - no hidden parts of abstraction, specialization and integration require intimate knowledge of the code - if large pieces of good code can be reused without looking too much into it, the cognitive distance is small 3) Source Code Components Main contrast to code scavenging: components are build to reuse. The description here is a little bit outdated. He mentions mathematical analysis libraries and ADA-components. Nowadays, we would add JFC, MFC, RoqueWafe etc. Integration has been improved by todays OO-languages, specialization has been clearly "reduced" to parameters and inheritance. Selection is getting better by good browsers, web-pages etc.... 4) Software Schemas Quite outdated, the mentioned tools have not made it. Schemas seem to be quite similar to templates and design patterns. The foculs lies on higher level semantics descriptions of components, and of schemas how things work together (just design patterns). 5) Application generators Whole applications are generated, e.g. parser and compiler generator. Only certain rules, modules, elements, diagrams are written. The rest is generated. The abstractions come directly from the application domain. Cognitive distance is very small. 6) Very High-level Languages VHLL = executable specification languages Developing in a VHLL is similar to developing in a HLL (writing program that gets compiled). Like application generators, VHLL will generate the applications, yet VHLL are general purpose. VHLL want higher levels of specification without sacrificing computational generatily. - VHLLs are often very slow, yet execution efficiency is sacrificed for implementation and modification effencency - VHLLs are often based on some higher level mathematical model Examples for VHLLs: - SETL: based on set theory, good for easy use of abstract data types - PAISLey: functional programming, ..... - MODEL: declarative constraint language Main concern: execution speed. 7) Transformational systems 8) Architectural abstractions - come directly from application domain Date[ July 8, 1998 ] Recordnr[ ] Stored[ bookshelf? Who[ P. Bassett Title[ Managing for Flexible Software Manufacturing Published[ IEEE Computer, vol31, no7, July 1998 Keywords[ Comment[ Summary[ The article discusses reuse, the reason why it does not happen, and proposes some remedies. Reasons why reuse does not happen: - Old manufacturing culture: we only trust our own software, and distrust other software; "our software will be far better" - Management supports these habits Management strategies to overcome old culture: 1) Promoting reuse within same project, i.e. avoiding perfectionism and over-generalisation syndrom. 2) Own and manage multiproject assets centrally by central profit-centre that rents out component engineers (actual glue) that help individual projects to use these components fast and effectively. Architectures for reuse, two types: 1) Execution architectures: system is encapsulated into executable modules, e.g. many OO-architectures, CORBA, n-tiered client-server, ... Point of view is runtime. 2) Construction architectures: the executable modules are partitioned into reusable components according to the isolation of change. Point of view is construction time, the goal is to localize the effects of change, to reduce complexity and ensure as much independance between components as possible, so when making changes to API's, data structures etc, as view components as possible have to be touched. ==> reuse is enhanced. Infrastructure for reuse: We have infrastructures for execution architectures (e.g. ORB's), but not really for construction time. It is hard to access and find multiple sources of supply of components. With infrastructure also come basic metrics that would give information about the return of investment in components. Flexible Software Manufacturing - a new paradigm? What it means: components that have the capability to adapt/customize themselves to concrete requirements. How does CHAIMS relate to this? - we are not changing any megamodules in the composition process, we may only add mediator megamodules to complete certain suites of megamodules - yet the megamodule providers can provide more or less suitable megamodules ==> ideally they package the functionality in such a way that the megamodule can be used in as many different settings as possible (minimal interface yet still flexible enough for many uses). The article also mentions some books about reuse, e.g. McClure 1997, Jacobson 1997, Date[ June 18, 1998] Recordnr[ ] Stored[ Who[ Michael VanHilst (works now at HP-Labs), D. Notkin Title[ Using Role Components to Implement Collaboration-Based Designs Published[ OOPSLA 96 Keywords[ aspect-oriented programming, roles, collaborations, roles as code entities Comment[ nice idea, might become an additional implementation paradigm, compareable to model-view-controller Summary[ Problem statement: Collaborations are modelled in the design. They show interactions between different roles (not really between different classes)==> collaborations as collections of roles. A role specifies a part of a single object that participates in a particular collaboration. One class can play several roles in differing collaborations; the same role is not implemented by the same class throughout all applications using that collaboration pattern. How could the notion of roles brought over to the implementation? Code reuse, system evolution: Collaborations in the design are derived from use-case-like scenarios in the requirements analysis. By having role-entities in the code, these use-cases could be reflected directly in the code, preserving this complementary view to the static class view. How? Inheritance is a logical glue for composing roles into classes, but: - inheritance must be delayed until whole composition and order of composition is known (compile-time, not code-writing time) - bindings to types must be delayed as well, so that roles can be coded independant of the specific classes taking them on, and thus be reused ==> class template for each role that is parameterized by each of the collaborator and by the class taking on the role itself ==> class then extend these templates, replacing the collaborators by the actual classes ==> a class having several roles is extended several times, each time the higher level class becomes a parameter in the next template to be extended ==> inheritance chain (but only simple inheritance is used) In order to get the right order in the inheritance chain, a roles/responsibility matrix is made. It helps to determine which roles (object methods) extend each other, and thus should override each other by calling the original one in case not the extended one is used. Related concepts: subject-oriented programming mixins Date[ November 2, 1] Recordnr[ ] Stored[ Papers sonst Who[ Michael M. Gormann Title[ The Essential Paradigm for Successful Information Technology Standards Published[ http://www.wiscorp.com/p115.htm Keywords[ standards, NIST, Comment[ Good entry paper. Summary[ The author emphesizes that there exist three main factors that must be fulfilled in order for a standard to be sucessful: - significant market share vendor community - publically developed, available, and evolving standard - enforced conformance tests Successful means the standard is adopted by a wide range of vendors. The paper discusses these points taking the SQL-standard and NIST who has given up conformance tests. The paper also shows the consequences for individual clients as well as the industry as a whole when successful standards do not exist (locked into one vendor, disabling competition by market leaders, high prizes for non-competitive products). Lost of references. Date[ June 24, 1998] Recordnr[ ] Stored[ Composition papers Who[ M.-C. Shan, J.W.Davis, et al Title[ Business Process Flow Management and its Application in the Telecommunications Management Network Published[ HP-Journal, October 1996 Keywords[ workflow, composition, Comment[ Summary[ The paper describes HP OpenPM, now called changengine and used by several banks. It is advanced workflow technology based on a framework approach for reusability. Goals of changengine: - substantial evolution from traditional workflow technologies - for distributed heterogenous computing environment (several procotols via wrappers) - it is a middleware system for procedural automation of a business process by managing the sequence of process activities, including the invocation of appropriate human, instrument or computer resources. - content, structure of process can be preplanned or ad hoc Main elements: - Process engine: based on the business process definition (graphically, rules) the process engine determines when something takes place and triggers activities. - Resource executive: manages resources - BOW: business object wrappers Definition of process: Graph containing work nodes and rule nodes. Each work node can again be a process containing work nodes and rule nodes. Work nodes have status initial or fired. Forward arcs denote normal execution flow, and they form directed acylic graph. Each work node can only have incoming arc, whereas rule nodes can have several incoming arcs (they have rules to deal with that). Both kind of nodes can have several outgoing arcs. Backward arcs are reset arcs, i.e. when they fire, everything in their loop is reset, and started tasks are aborted. Nodes fire like in a petri-net. Rules: e.g. "if Customer.approval = TRUE then arc 5" Events: rule nodes can also raise evens, which themselves can fire rules nodes that have subscribed to that event. Events are modelled like specific kind of nodes, like a shortcut for not drawing to many arcs across the graph. This kind of graph allows to describe: - sequencing and timing and dependancy of business activities, - data and physical agent allocation of business activities - business rules and organization policies Mapping of process definition to execution: Work node -- process activity(task) -- invocation of an operation on business objects(resource) during execution of a process BOW: BOW's wrap business objects and interface to the process engine via CORBA. Towards business objects they interface with various protocols, e.g. also DCOM and DNA. Business objects are catalogued in a library. Interfaces: from process engine are CORBA and WfMC (Workflow Managmenet Coalition standard interface) Optimization: Data handler: allows seperation of application specific data and process-relevant data needed for rule nodes, thus reducing amount of data flow. Resource manager: for automatic workload balancing. Statistical data: bottleneck analysis, flow optimization. References: - paper gives further references (not very new) - Reed Letsinger and Michael VantHilst at HP labs - webpage: www.pwd.hp.com/cyc/af/50/ is behind firewall Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J.M.Voas Title[ The Challenges of Using COTS Software in Component-Based Development Published[ IEEE Computer, June 1998, Vol31 No6, Guest Editors introduction Keywords[ COTS Comment[ Summary[ Software we acquire elsewhere: - COTS: commercial of the shelf - CAS: commercially available software - NDI: nondevelopmental item ==> used as components or componentware to build component-based software or systems of systems Problems in using componentware: - Components may integrate perfectly during development, but not behave perfectly at rntime. - We have process models for developing software from requirements, but not yet for acquiring software. - COTS are delivered as black box ==> how to determine that they behave safely, securely, and reliably? - How to access the quality of COTS? How to access suitability? Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J.McDermid Title[ The Cost of COTS Published[ IEEE Computer, June 1998, Vol31 No6, an interview Keywords[ COTS Comment[ Quite quite an interesting interview discussing general cost issues of COTS in contrast to bespoke (custom solutions), especially for safety- and reliability-critical system. The article is very critical towards COTS, mainly talks from a viewpoint of critical systems (process control systems, not information systems). Summary[ Promises of COTS: eliminate sfotware development project that overrun time and cost, greater ability to interoperate diverse systems, quickly evolve large systems, lower costs COTS nowadays: GUIs, operations systems, databases ==> mainly large components (and what about CERN-libraries, statistic tools etc.?) Risk mitigation: Problem: COTS are often build without a strict process and documentation control, no clear QA, and are delivered without appropriate documentation of the process, and without e.g. complete test-suites etc. (solutions: certification, using an escrow i.e. depositing the documentation at a bank for the case the company disappears). How to access the quality? - retrospective assessment is more expensive than assessing the software when developing it, if possible at all (code analysis) - each upgrade has to be assessed anew - software has not been written with the goal to access it (whereas bespoke for critical systems is structured and written in order to be accessed) - accessing needs also been done for all unwanted functionality (additional effort not necessary for bespoke) How to demonstrate the desired level of reliability, availability, integrity? - unwanted functions with dangerous side-effects How to control future of a COTS-component? - component can go out of business - new releases with unwanted functions - cost of upgrading - wrappers do not solve any of above problems Cost-tradeoff between COTS and bespoke: - price of purchase versus development - price of assessing quality of COTS to desired quality level - price of integrating COTS - price for upgrades, price for accessing upgrades, price for integrating upgrades - risk of vendor going out of business and expected life-time of system COTS can offer historical data for its quality (e.g. OS but not things like Microsoftword which get updates too often), bespoke has not historical data but you know what you are developing and can assess that. Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J. M.. Voas Title[ Certifying Off-the-Shelf Software Components Published[ IEEE Computer, June 1998, Vol31 No6, an interview Keywords[ COTS Comment[ Summary[ Three questions must be answered positively before using/certifying a COTS-component for a specific environment: 1 Does component C fill the Developer's needs? 2 Is the quality of component C high enough? 3 What impact will component C have on system S? Ways to answer that is by: a Black-box testing (answers question 1) b System-level fault injection c Operational system testing a and b together answer 2 and 3. Black-box testing: - best to build own oracle that tests comonents against needs of user and not against vendors specification - can fail to exercise important/faulty portions of the code System-level fault injection: Instead of the component a fault injector is put into the system (just the minimum amount of surrounding components is used) that works nearly like the component but randomly makes wrong results. Can the system stand that? Operational system testing: Problem: enormous amount needed for components that rarely fail. Advantage voer system-level fault injection: tests the real wrong behaviour. Remedy if component is not save enough: wrappers. Problem: Wrapper may not catch all the behaviour of a component. Date[ July 29, 1998] Recordnr[ ] Stored[ file-cabinet, Papers Composition Who[ J. Magee, N. Dulay, J. Kramer Title[ Regis: A Constructive Development Environment for Distributed Programs Published[ IEE/IOP/BCS Distributed Systems Engineering, 1(5): 304-312, Sept 1994. Keywords[ Comment[ Other papers about Regis/Darwin: Ng, K. and Kramer, J.; Automated Support for Distributed Software Design, appeared in 7th International Workshop on Computer-aided Software Engineering (CASE 95) Mostly describes the Software Architect's Assistant, a visual tool to set up distributed systems. Magee, J. and Dulay, N. and Eisenbach, S. and Kramer, J.;Specifying Distributed Software Architectures, appeared in 5th European Software Engineering Conference (ESEC 95) Presents a formal model of Darwin in Robin Milner's Pi-Calculus. Magee, J. and Dulay, N. and Kramer, J.; Regis: A Constructive Development Environment for Distributed Programs; IEE/IOP/BCS Distributed Systems Engineering},Volume = {1},Number = {5},1994 Describes the most recent distributed execution environment for Darwin-structured applications. Summary[ Darwin is a configuration language, Regis is a system supporting Darwin and generating the distributed systems specified in Darwin. For each component an interface is specified that contains all incoming and outgoing links. These can be of different types (pipes, ports...). The communications are implemented by special C++ components. The components to be configured/assembled can be either composite components, consisting of a set of lower level components, or computation components. Latter are written in C++ and must inherit from a predefined class process. Darwin also allows to imbed directly program code in the component descriptions. Components are garbage collected after termination. Regis runs on a Unix environment, the components can run on different Unix-workstations. A mapping file defines on which processor of the multicomputer which component is run. My conclusions: Regis supports program generation for a homogeneous environment. The distribution seems only to be local - I do not know if it is suited for servers located outside the intranet. The components that are composed are controlled entirely by the configuration language and by Regis (automatic garbage collection) - no autonomous servers that exist and run independant of the client. No equivalents to "EXAMINE", "ESTIMATE". Legacy code probably could be brought in, but I have not seen this issue being specifically adressed. As far as I know, no commercial application. Notes of Louis: I looked at a bunch of papers from Imperial College, London. The head of that group is Jeff Kramer, the relevant URLs are: Regis: http://www-dse.doc.ic.ac.uk/~regis/ Darwin: http://www-dse.doc.ic.ac.uk/~jsc/research/darwin.html Some of their work is relevant for RapArch, Architecture, and RapNet (see below). Regis has been in use since 1992. Darwin/Regis ============ Regis is a programming environment aimed at supporting the development and execution of distributed program. A Regis program consists of loosely coupled components either directly written in C++ (primitive components) or constructed out of simpler subcomponents by using the Darwin language. As such, Darwin is an Architecture Description Language (ADL) remarkably similar to the RAPIDE ADL. The Regis environment lets you develop the individual C++ components and the composition using Darwin, then compiles everything into executables and runs it on distributed sites. Regis/Darwin is restricted to the design/implementation phase. Once the program is compiled, installed and running, it is on its own, there is no support for ongoing analysis. One '95 paper said they will do run-time monitoring and management, but that will probably be primitive (i.e. just monitoring if they still run) and may not even exist. They stress the fact that a Regis program can be distributed (a la mobile agents), but I don't think that is the exciting thing about it. The Darwin ADL -------------- Darwin boxes are called "components", action declaration are called "services", arrows are called "bindings". Like RAPIDE, Darwin specifies both provided as required services. Services are typed and type conformance is enforced. Darwin allows hierarchical composition of components as well as parametrization, a component can consist of n subcomponents, with n decided statically at run time or dynamically at runtime. The latter is what they call dynamic architectures. In both cases, all n components have the same type, bindings, etc. This is just simple instantiation of a class. In some aspects Darwin is more general than Rapide ADL. The communication mechanism is not restricted to events. Darwin supports any communication mechanism (events, streams, RPC, etc. In Regis, the mechanism is then implemented as a C++ class). Thus the type of an action denotes the C++ class that implements it. A Darwin filter on a stream of characters would look like component filter { provide output; require input; } A funny thing happens when one looks at services of type "port". A port is used to send messages through and is interpreted in a procedure call style. Thus, to send a message, a sensor *requires* a port, the "output" becomes "required". The following comes from their paper and seems wrong for a RAPIDE person (at least for me). component sensor { provide input; require output; } I guess they run into this problem because they support both push (stream, event) and pull (port) communication with others. Pi-calculus ----------- Darwin is also specified in Milner's \pi-calculus. This is an elementary calculus for describing and analyzing concurrent, independent processes that communicate via channels. A subset of the Pi-calculus (http://www.cwi.nl/~arie/picalc.html) seems to be a candidate for our RapNet composition language. Software Architect Assistant ---------------------------- Regis comes with a graphical architecting tool called Software Architect Assistant (SAA), similar to RapArch. In comparison to RapArch, SAA's focus is more on providing semantics and ease-of-use and less on providing fancy drawing capabilities. All "boxes" have the same size, and "arrows" are laid out automatically by the tool and cannot be changed. (See http://www-dse.doc.ic.ac.uk/sel/sereports/rj1/rj1.html for an evaluation.) On the other hand, boxes and arrow have full semantic meaning, and correctness is checked at data entry point. The graphical and the textual view are always consistent. I especially like the separation between connections and interfaces. The "arrow" is just a line, the ending points indicating in which direction it points are part of the "box". This makes sense, because when you define a box, it is already clear which "actions" are "required" and which are "provided". SAA also displays nicely how services are connected when components are hierarchically encapsulated in each other. SAA also supports libraries of components, that can be included as sub-components in other components and it can read Darwin (textual) code not written by SAA. The SAA exports RTF reports that can be directly imported into word processors. Date[ August 5, 199] Recordnr[ ] Stored[Composition, filecabinet Who[ I. Ben-Shaul, et.al. Title[ HADAS: A Network-Centric Framework for Interoperability Programming Published[ International Journal of Cooperative Informaion Systems, 1997 Keywords[ heterogeneity, RMI, HADAS, coordination language, Comment[ Very interesting approach. More focused on roaming agents. Summary[ Challenge: Compose, configure and execute network-centric applicatins made up of widely-distributed components. Major problem: global interoperability Examples: active, intelligent information agents; inter-organization collaborative workflow systems, e-commerce, large-scale concurrent computations Main ideas of HADAS (=heterogeneous autonomous distributed abstraction system): - autonomy of objects: administrative autonomy (==> evolving over time), design autonomy (heterogeneity) - network centric framework - no central agent like a broker, fully decentralized (==> possible by using RMI) - dynamic and programmable approach to interoperability, peer-to-peer configuration agreement - ISL as coordination lanague Approch: - a (reflective and mobile object model abstracting components - a Java-based framework in which components live and communicate - a higher-order interpreted coordination language that manipulates components Basic architecture: The comonponents are distributed object managers. These not only implement various ilities like security and unique id and persistence, they also contain or wrapp the effective behaviour offered by this component. These objects communicate with each other mainly over RMI. They could also use ftp, http or amp. The whole HADAS system is written in Java. Access to legacy components is by wrappers - these wrappers, written mainly in Java, e.g. access CORBA-components etc. If necessary, they also use native code. As all of HADAS is Java, data is communicated in Java format. For type- mismatches, peer-to-peer dynamic wrappers exist that transform data. Levels of interoperability in Hadas: - interconnectivity infrastructure (in Java), reflective object model supporting mutability and mobility - integration : who can access whom? - configuration: dynamic agreemant between sites over use of comonents - coordination: control and dataflow between components, ISL Configuration: The operation to be called is link. What link does is: it copies a suitable ambassador objects to the other site. These ambassador objects then act like stubs. Ambassadors for the same siteobjects on various sites may have different dynamic parts in them. Each object supports methods like: add, remove (a method dynamically), invoke (a method with given parameters), describe (the offered methods). Ambassadors: - not just stubs, they have HADAS methods (install, update) - they have dynamic transformers (wrappers) and can evolve dynamically by interacting with hosting environment Reflective object model: - objects can answer questions about itself (given by Java) - object can change itself (addDataItem, addMethod, setMethod), trivial in Java - security specifications per method (probably all from Java) Wrappers: - dynamic linking to Java components - accessing C++ code with JNI - CORBA-HADAS, static wrapping - HTTP/CGI out and in transformer, dynamic wrapping Coordination, ISL: The language used is Scheme, implemented in Java. It supports weak typing and allows to encode higher-order procedures. http://www.dsg.technion.ac.il Date[ May 27, 1998 ] Recordnr[ 1 ] Stored[ Composition Who[ Scott M. Lewandowski Title[ Frameworks for Component-Based Client/Server Computing Published[ ACM Computing Surveys, Vol.30, No.1, March 1998 Keywords[ CORBA, compound document, DCOM, JAVA, business object Comment[ Summary[ General impression: very pro CORBA, does not mention RMI, paper tries to cover a large area with doubtful success Middleware is defined to include the APIs used by clients to request a service from a server, the physical transmittion of the request to the network, and the rewulting transmission of data for the client back to the network. Middleware is run on both the client and server ends of a transaction. Three different kinds of middleware: - database middleware (ODBC, SQL, Oracle Glue) - groupware middleware (Lotus Notes, Microsoft Exchange) - inernet middleware (HTTP, secure socket layer) - object middleware (CORBA, DCOM) Furthermore: fundamental/generic middleware against domain-specific middleware. Fundamental: distributed file system, RPC, authentication... Various kind of systems: - fat servers versus fat clients: data on server, UI on client - is the application logic on the server or the client? - three-tier systems: application logic is separate ==> new level of autonomy for applicatino logic. Ex: web-applications with browser, applets or cgi-scripts, database - four-tiers: e.g. with additional second tier for unifying view of the data of the databases of first tier, (CHAIMS with new architecture would also be 4 tier system) CORBA is great!!!?? - "Technologies such as Java and object request brokers (ORBs) promise to provide seamless integration among all platforms within a few years." - "only CORBA and DCOM provide viable long-term solutions to the challenge of a standardized framework for object-based client/server systems, others do not have enough features or as great an installed base..." - yet CORBA is much better, because in DCOM e.g. no real objects (objects have no state, they are just procedures ==> handles to objects are arbitrary and only garuantee interface not object-state, no unique object identifier, no persistency supported) - also DCOM objects cannot automatically support multiple interfaces, - also clients cannot request for a specific given server, - also only using WindowsNT security model and no own universal security mechanism like CORBA - CORBA and Java are made for each other and together will win (???) ==> platform for universal network computing can be created using Java as mobile code systems and CORBA as integration technology Claims (not really true in my view): - java-interfaces and CORBA-IDL's are very similar (RMI transports code and methods, not just data!! ==> totally different kind of distributed programming) - CORBA allows parameters of any type (yes, it allows more than CGI, but not "any") Selfmanaging objects: - take responsibility for their own resources, work across networks, interact with other objects - smallest ones are components like activeX controls - ===> solid event model necessary that allows objects to broadcast specific messages and generate certain events (events = synchronisation objects) - ===> transparency of location and implementation is important (as offered by CORBA) BOMSIG (Business Object Model Special Interest Group), as example for framework on top of CORBA - no references given - promotes three-tier framework for buisness objects, consisting of business object logic, business proces objects, presenation object (differences not clear to me) Compound document framework (another example of a framework on top of CORBA) Date[ 11:31:04 ] Recordnr[ ] Stored[ Papers Composition Who[ J.R.Callahan, J.M Purtilo, University of Maryland Title[ A Packaging System for Heterogeneous Execution Environments Published[ IEEE Transactions on Software Engineering, vol.17, 1991, pp.626-635 Keywords[ MIL, Polygen, Polylith Comment[ more for small, on-one-site components, strenth is partitioning and automatic reasoning about possible configurations, yet automatic generation is limitied to certain environments Summary[ Polylith: TCP/IP-based communication systems for various languages. Polygen: Composotion and reasoning tool. What it is about: - generation of custom interface software for heterogeneous configurations. - in contrast to other approaches, not only stub generation, but inserting configuration methods needed to integrate an application (e.g. main, wrappers/dispachter program for LISP-procedures, byteswap functions for adjusting integers to various representations, rendezvous functions) - polygen changes source code and adds necessary lines and stubs so they can work over network - all is automatic, user just has to specify desired geometry - logical design is separated from the geometry Composition process: Starting point: several source files (C, Ada, Pascal, Lisp) that contain modules(procedure calls) to be composed. In the extraction phase, module specs are gained from the source files, or these module specs already exist. Module specs: are written in Polylith MIL (module interconnection language). It contains the interfaces a module offers and uses and the parameters of these procedure calls. In the composition phase, the user adds the design and annotated design (with geometric data) to the specs. The design says which modules are to be used, which communication system, where the modules are. Then in the generatin phase POLYGEN makes a package based on the configuration rules it has. Configuration rules are added by the Polygen system maintainer and say what kind of modules can be connected how. A package (valid configuration represented in an executable makefile and generated stubs and interfaces) is gained by an interference mechanism that uses partitioning. Module assertions are converted to prolog statements. Based on configuration rules, partitions are created.... Finally in the construction phase an executable is generated by running the makefile that polygen has created in the generation phase. Partitioning: Partitions are sets of compatible components. They can be represented by directed, acyclic graphs,whose internal nodes represent integration methods and temrinal nodes represent source components. Valid partitioning: has only a single root. Weaknesses: - source code must be changed and recompiled - right now only for Polylith-TCP/IP - data-conversion relies on underlying communication tool - good for putting together inhouse modules - rather targeted at smaller modules - no optimization, scheduling etc... Date[ August 21, 19] Recordnr[ ] Stored[ see library Who[ Charles W. Krueger Title[ Software Reuse Published[ ACM Computing Surveys, Vol. 24, No. 2, June 1992 Keywords[ reuse, abstraction Comment[ Summary[ Abstraction: Abstraction and reuse are two sides of the same coin. Many references given for that. Abstraction occurs in layers. In each layer we can distinguish between the abstraction specification, and the abstraction realization (contains hidden parts of the abstraction).Specification contains fixed part and variable part of the abstraction. 4 facets of software reuse are looked at in the paper, though all build on top of abstraction: - abstraction: what the abstraction is at all - selection: how users find abstractions, requires consice specifications - speciliations: choosing the abstraction realisations and the correct flexible parts - integration: interface of an abstraction, how are abstractions integrated in complete software system Reuse is being looked at in the following fields: 1) High-level languages: - reusable artifacts are the language elements, which abstract assembly language patterns. - variable parts are the statements and conditions we can fill in - integration is done by compilers, hidden parts (assembler language) are never visible - cognitive distance to a problem at hand is quite large (yet smaller than with pure assembler) 2) Design and Code scavenging - code scavenging: copying small code fragments without changing - design scavenging: copying larger code fragments containing a design pattern, and changing details yet keeping overall design; or making new code based on earlier experiences - very informal, not always worth while - no hidden parts of abstraction, specialization and integration require intimate knowledge of the code - if large pieces of good code can be reused without looking too much into it, the cognitive distance is small 3) Source Code Components Main contrast to code scavenging: components are build to reuse. The description here is a little bit outdated. He mentions mathematical analysis libraries and ADA-components. Nowadays, we would add JFC, MFC, RoqueWafe etc. Integration has been improved by todays OO-languages, specialization has been clearly "reduced" to parameters and inheritance. Selection is getting better by good browsers, web-pages etc.... 4) Software Schemas Quite outdated, the mentioned tools have not made it. Schemas seem to be quite similar to templates and design patterns. The foculs lies on higher level semantics descriptions of components, and of schemas how things work together (just design patterns). 5) Application generators Whole applications are generated, e.g. parser and compiler generator. Only certain rules, modules, elements, diagrams are written. The rest is generated. The abstractions come directly from the application domain. Cognitive distance is very small. 6) Very High-level Languages VHLL = executable specification languages Developing in a VHLL is similar to developing in a HLL (writing program that gets compiled). Like application generators, VHLL will generate the applications, yet VHLL are general purpose. VHLL want higher levels of specification without sacrificing computational generatily. - VHLLs are often very slow, yet execution efficiency is sacrificed for implementation and modification effencency - VHLLs are often based on some higher level mathematical model Examples for VHLLs: - SETL: based on set theory, good for easy use of abstract data types - PAISLey: functional programming, ..... - MODEL: declarative constraint language Main concern: execution speed. 7) Transformational systems 8) Architectural abstractions - come directly from application domain Date[ July 8, 1998 ] Recordnr[ ] Stored[ bookshelf? Who[ P. Bassett Title[ Managing for Flexible Software Manufacturing Published[ IEEE Computer, vol31, no7, July 1998 Keywords[ Comment[ Summary[ The article discusses reuse, the reason why it does not happen, and proposes some remedies. Reasons why reuse does not happen: - Old manufacturing culture: we only trust our own software, and distrust other software; "our software will be far better" - Management supports these habits Management strategies to overcome old culture: 1) Promoting reuse within same project, i.e. avoiding perfectionism and over-generalisation syndrom. 2) Own and manage multiproject assets centrally by central profit-centre that rents out component engineers (actual glue) that help individual projects to use these components fast and effectively. Architectures for reuse, two types: 1) Execution architectures: system is encapsulated into executable modules, e.g. many OO-architectures, CORBA, n-tiered client-server, ... Point of view is runtime. 2) Construction architectures: the executable modules are partitioned into reusable components according to the isolation of change. Point of view is construction time, the goal is to localize the effects of change, to reduce complexity and ensure as much independance between components as possible, so when making changes to API's, data structures etc, as view components as possible have to be touched. ==> reuse is enhanced. Infrastructure for reuse: We have infrastructures for execution architectures (e.g. ORB's), but not really for construction time. It is hard to access and find multiple sources of supply of components. With infrastructure also come basic metrics that would give information about the return of investment in components. Flexible Software Manufacturing - a new paradigm? What it means: components that have the capability to adapt/customize themselves to concrete requirements. How does CHAIMS relate to this? - we are not changing any megamodules in the composition process, we may only add mediator megamodules to complete certain suites of megamodules - yet the megamodule providers can provide more or less suitable megamodules ==> ideally they package the functionality in such a way that the megamodule can be used in as many different settings as possible (minimal interface yet still flexible enough for many uses). The article also mentions some books about reuse, e.g. McClure 1997, Jacobson 1997, Date[ June 18, 1998] Recordnr[ ] Stored[ Who[ Michael VanHilst (works now at HP-Labs), D. Notkin Title[ Using Role Components to Implement Collaboration-Based Designs Published[ OOPSLA 96 Keywords[ aspect-oriented programming, roles, collaborations, roles as code entities Comment[ nice idea, might become an additional implementation paradigm, compareable to model-view-controller Summary[ Problem statement: Collaborations are modelled in the design. They show interactions between different roles (not really between different classes)==> collaborations as collections of roles. A role specifies a part of a single object that participates in a particular collaboration. One class can play several roles in differing collaborations; the same role is not implemented by the same class throughout all applications using that collaboration pattern. How could the notion of roles brought over to the implementation? Code reuse, system evolution: Collaborations in the design are derived from use-case-like scenarios in the requirements analysis. By having role-entities in the code, these use-cases could be reflected directly in the code, preserving this complementary view to the static class view. How? Inheritance is a logical glue for composing roles into classes, but: - inheritance must be delayed until whole composition and order of composition is known (compile-time, not code-writing time) - bindings to types must be delayed as well, so that roles can be coded independant of the specific classes taking them on, and thus be reused ==> class template for each role that is parameterized by each of the collaborator and by the class taking on the role itself ==> class then extend these templates, replacing the collaborators by the actual classes ==> a class having several roles is extended several times, each time the higher level class becomes a parameter in the next template to be extended ==> inheritance chain (but only simple inheritance is used) In order to get the right order in the inheritance chain, a roles/responsibility matrix is made. It helps to determine which roles (object methods) extend each other, and thus should override each other by calling the original one in case not the extended one is used. Related concepts: subject-oriented programming mixins Date[ November 2, 1] Recordnr[ ] Stored[ Papers sonst Who[ Michael M. Gormann Title[ The Essential Paradigm for Successful Information Technology Standards Published[ http://www.wiscorp.com/p115.htm Keywords[ standards, NIST, Comment[ Good entry paper. Summary[ The author emphesizes that there exist three main factors that must be fulfilled in order for a standard to be sucessful: - significant market share vendor community - publically developed, available, and evolving standard - enforced conformance tests Successful means the standard is adopted by a wide range of vendors. The paper discusses these points taking the SQL-standard and NIST who has given up conformance tests. The paper also shows the consequences for individual clients as well as the industry as a whole when successful standards do not exist (locked into one vendor, disabling competition by market leaders, high prizes for non-competitive products). Lost of references. Date[ June 24, 1998] Recordnr[ ] Stored[ Composition papers Who[ M.-C. Shan, J.W.Davis, et al Title[ Business Process Flow Management and its Application in the Telecommunications Management Network Published[ HP-Journal, October 1996 Keywords[ workflow, composition, Comment[ Summary[ The paper describes HP OpenPM, now called changengine and used by several banks. It is advanced workflow technology based on a framework approach for reusability. Goals of changengine: - substantial evolution from traditional workflow technologies - for distributed heterogenous computing environment (several procotols via wrappers) - it is a middleware system for procedural automation of a business process by managing the sequence of process activities, including the invocation of appropriate human, instrument or computer resources. - content, structure of process can be preplanned or ad hoc Main elements: - Process engine: based on the business process definition (graphically, rules) the process engine determines when something takes place and triggers activities. - Resource executive: manages resources - BOW: business object wrappers Definition of process: Graph containing work nodes and rule nodes. Each work node can again be a process containing work nodes and rule nodes. Work nodes have status initial or fired. Forward arcs denote normal execution flow, and they form directed acylic graph. Each work node can only have incoming arc, whereas rule nodes can have several incoming arcs (they have rules to deal with that). Both kind of nodes can have several outgoing arcs. Backward arcs are reset arcs, i.e. when they fire, everything in their loop is reset, and started tasks are aborted. Nodes fire like in a petri-net. Rules: e.g. "if Customer.approval = TRUE then arc 5" Events: rule nodes can also raise evens, which themselves can fire rules nodes that have subscribed to that event. Events are modelled like specific kind of nodes, like a shortcut for not drawing to many arcs across the graph. This kind of graph allows to describe: - sequencing and timing and dependancy of business activities, - data and physical agent allocation of business activities - business rules and organization policies Mapping of process definition to execution: Work node -- process activity(task) -- invocation of an operation on business objects(resource) during execution of a process BOW: BOW's wrap business objects and interface to the process engine via CORBA. Towards business objects they interface with various protocols, e.g. also DCOM and DNA. Business objects are catalogued in a library. Interfaces: from process engine are CORBA and WfMC (Workflow Managmenet Coalition standard interface) Optimization: Data handler: allows seperation of application specific data and process-relevant data needed for rule nodes, thus reducing amount of data flow. Resource manager: for automatic workload balancing. Statistical data: bottleneck analysis, flow optimization. References: - paper gives further references (not very new) - Reed Letsinger and Michael VantHilst at HP labs - webpage: www.pwd.hp.com/cyc/af/50/ is behind firewall Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J.M.Voas Title[ The Challenges of Using COTS Software in Component-Based Development Published[ IEEE Computer, June 1998, Vol31 No6, Guest Editors introduction Keywords[ COTS Comment[ Summary[ Software we acquire elsewhere: - COTS: commercial of the shelf - CAS: commercially available software - NDI: nondevelopmental item ==> used as components or componentware to build component-based software or systems of systems Problems in using componentware: - Components may integrate perfectly during development, but not behave perfectly at rntime. - We have process models for developing software from requirements, but not yet for acquiring software. - COTS are delivered as black box ==> how to determine that they behave safely, securely, and reliably? - How to access the quality of COTS? How to access suitability? Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J.McDermid Title[ The Cost of COTS Published[ IEEE Computer, June 1998, Vol31 No6, an interview Keywords[ COTS Comment[ Quite quite an interesting interview discussing general cost issues of COTS in contrast to bespoke (custom solutions), especially for safety- and reliability-critical system. The article is very critical towards COTS, mainly talks from a viewpoint of critical systems (process control systems, not information systems). Summary[ Promises of COTS: eliminate sfotware development project that overrun time and cost, greater ability to interoperate diverse systems, quickly evolve large systems, lower costs COTS nowadays: GUIs, operations systems, databases ==> mainly large components (and what about CERN-libraries, statistic tools etc.?) Risk mitigation: Problem: COTS are often build without a strict process and documentation control, no clear QA, and are delivered without appropriate documentation of the process, and without e.g. complete test-suites etc. (solutions: certification, using an escrow i.e. depositing the documentation at a bank for the case the company disappears). How to access the quality? - retrospective assessment is more expensive than assessing the software when developing it, if possible at all (code analysis) - each upgrade has to be assessed anew - software has not been written with the goal to access it (whereas bespoke for critical systems is structured and written in order to be accessed) - accessing needs also been done for all unwanted functionality (additional effort not necessary for bespoke) How to demonstrate the desired level of reliability, availability, integrity? - unwanted functions with dangerous side-effects How to control future of a COTS-component? - component can go out of business - new releases with unwanted functions - cost of upgrading - wrappers do not solve any of above problems Cost-tradeoff between COTS and bespoke: - price of purchase versus development - price of assessing quality of COTS to desired quality level - price of integrating COTS - price for upgrades, price for accessing upgrades, price for integrating upgrades - risk of vendor going out of business and expected life-time of system COTS can offer historical data for its quality (e.g. OS but not things like Microsoftword which get updates too often), bespoke has not historical data but you know what you are developing and can assess that. Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J. M.. Voas Title[ Certifying Off-the-Shelf Software Components Published[ IEEE Computer, June 1998, Vol31 No6, an interview Keywords[ COTS Comment[ Summary[ Three questions must be answered positively before using/certifying a COTS-component for a specific environment: 1 Does component C fill the Developer's needs? 2 Is the quality of component C high enough? 3 What impact will component C have on system S? Ways to answer that is by: a Black-box testing (answers question 1) b System-level fault injection c Operational system testing a and b together answer 2 and 3. Black-box testing: - best to build own oracle that tests comonents against needs of user and not against vendors specification - can fail to exercise important/faulty portions of the code System-level fault injection: Instead of the component a fault injector is put into the system (just the minimum amount of surrounding components is used) that works nearly like the component but randomly makes wrong results. Can the system stand that? Operational system testing: Problem: enormous amount needed for components that rarely fail. Advantage voer system-level fault injection: tests the real wrong behaviour. Remedy if component is not save enough: wrappers. Problem: Wrapper may not catch all the behaviour of a component. Date[ July 29, 1998] Recordnr[ ] Stored[ file-cabinet, Papers Composition Who[ J. Magee, N. Dulay, J. Kramer Title[ Regis: A Constructive Development Environment for Distributed Programs Published[ IEE/IOP/BCS Distributed Systems Engineering, 1(5): 304-312, Sept 1994. Keywords[ Comment[ Other papers about Regis/Darwin: Ng, K. and Kramer, J.; Automated Support for Distributed Software Design, appeared in 7th International Workshop on Computer-aided Software Engineering (CASE 95) Mostly describes the Software Architect's Assistant, a visual tool to set up distributed systems. Magee, J. and Dulay, N. and Eisenbach, S. and Kramer, J.;Specifying Distributed Software Architectures, appeared in 5th European Software Engineering Conference (ESEC 95) Presents a formal model of Darwin in Robin Milner's Pi-Calculus. Magee, J. and Dulay, N. and Kramer, J.; Regis: A Constructive Development Environment for Distributed Programs; IEE/IOP/BCS Distributed Systems Engineering},Volume = {1},Number = {5},1994 Describes the most recent distributed execution environment for Darwin-structured applications. Summary[ Darwin is a configuration language, Regis is a system supporting Darwin and generating the distributed systems specified in Darwin. For each component an interface is specified that contains all incoming and outgoing links. These can be of different types (pipes, ports...). The communications are implemented by special C++ components. The components to be configured/assembled can be either composite components, consisting of a set of lower level components, or computation components. Latter are written in C++ and must inherit from a predefined class process. Darwin also allows to imbed directly program code in the component descriptions. Components are garbage collected after termination. Regis runs on a Unix environment, the components can run on different Unix-workstations. A mapping file defines on which processor of the multicomputer which component is run. My conclusions: Regis supports program generation for a homogeneous environment. The distribution seems only to be local - I do not know if it is suited for servers located outside the intranet. The components that are composed are controlled entirely by the configuration language and by Regis (automatic garbage collection) - no autonomous servers that exist and run independant of the client. No equivalents to "EXAMINE", "ESTIMATE". Legacy code probably could be brought in, but I have not seen this issue being specifically adressed. As far as I know, no commercial application. Notes of Louis: I looked at a bunch of papers from Imperial College, London. The head of that group is Jeff Kramer, the relevant URLs are: Regis: http://www-dse.doc.ic.ac.uk/~regis/ Darwin: http://www-dse.doc.ic.ac.uk/~jsc/research/darwin.html Some of their work is relevant for RapArch, Architecture, and RapNet (see below). Regis has been in use since 1992. Darwin/Regis ============ Regis is a programming environment aimed at supporting the development and execution of distributed program. A Regis program consists of loosely coupled components either directly written in C++ (primitive components) or constructed out of simpler subcomponents by using the Darwin language. As such, Darwin is an Architecture Description Language (ADL) remarkably similar to the RAPIDE ADL. The Regis environment lets you develop the individual C++ components and the composition using Darwin, then compiles everything into executables and runs it on distributed sites. Regis/Darwin is restricted to the design/implementation phase. Once the program is compiled, installed and running, it is on its own, there is no support for ongoing analysis. One '95 paper said they will do run-time monitoring and management, but that will probably be primitive (i.e. just monitoring if they still run) and may not even exist. They stress the fact that a Regis program can be distributed (a la mobile agents), but I don't think that is the exciting thing about it. The Darwin ADL -------------- Darwin boxes are called "components", action declaration are called "services", arrows are called "bindings". Like RAPIDE, Darwin specifies both provided as required services. Services are typed and type conformance is enforced. Darwin allows hierarchical composition of components as well as parametrization, a component can consist of n subcomponents, with n decided statically at run time or dynamically at runtime. The latter is what they call dynamic architectures. In both cases, all n components have the same type, bindings, etc. This is just simple instantiation of a class. In some aspects Darwin is more general than Rapide ADL. The communication mechanism is not restricted to events. Darwin supports any communication mechanism (events, streams, RPC, etc. In Regis, the mechanism is then implemented as a C++ class). Thus the type of an action denotes the C++ class that implements it. A Darwin filter on a stream of characters would look like component filter { provide output; require input; } A funny thing happens when one looks at services of type "port". A port is used to send messages through and is interpreted in a procedure call style. Thus, to send a message, a sensor *requires* a port, the "output" becomes "required". The following comes from their paper and seems wrong for a RAPIDE person (at least for me). component sensor { provide input; require output; } I guess they run into this problem because they support both push (stream, event) and pull (port) communication with others. Pi-calculus ----------- Darwin is also specified in Milner's \pi-calculus. This is an elementary calculus for describing and analyzing concurrent, independent processes that communicate via channels. A subset of the Pi-calculus (http://www.cwi.nl/~arie/picalc.html) seems to be a candidate for our RapNet composition language. Software Architect Assistant ---------------------------- Regis comes with a graphical architecting tool called Software Architect Assistant (SAA), similar to RapArch. In comparison to RapArch, SAA's focus is more on providing semantics and ease-of-use and less on providing fancy drawing capabilities. All "boxes" have the same size, and "arrows" are laid out automatically by the tool and cannot be changed. (See http://www-dse.doc.ic.ac.uk/sel/sereports/rj1/rj1.html for an evaluation.) On the other hand, boxes and arrow have full semantic meaning, and correctness is checked at data entry point. The graphical and the textual view are always consistent. I especially like the separation between connections and interfaces. The "arrow" is just a line, the ending points indicating in which direction it points are part of the "box". This makes sense, because when you define a box, it is already clear which "actions" are "required" and which are "provided". SAA also displays nicely how services are connected when components are hierarchically encapsulated in each other. SAA also supports libraries of components, that can be included as sub-components in other components and it can read Darwin (textual) code not written by SAA. The SAA exports RTF reports that can be directly imported into word processors. Date[ August 5, 199] Recordnr[ ] Stored[Composition, filecabinet Who[ I. Ben-Shaul, et.al. Title[ HADAS: A Network-Centric Framework for Interoperability Programming Published[ International Journal of Cooperative Informaion Systems, 1997 Keywords[ heterogeneity, RMI, HADAS, coordination language, Comment[ Very interesting approach. More focused on roaming agents. Summary[ Challenge: Compose, configure and execute network-centric applicatins made up of widely-distributed components. Major problem: global interoperability Examples: active, intelligent information agents; inter-organization collaborative workflow systems, e-commerce, large-scale concurrent computations Main ideas of HADAS (=heterogeneous autonomous distributed abstraction system): - autonomy of objects: administrative autonomy (==> evolving over time), design autonomy (heterogeneity) - network centric framework - no central agent like a broker, fully decentralized (==> possible by using RMI) - dynamic and programmable approach to interoperability, peer-to-peer configuration agreement - ISL as coordination lanague Approch: - a (reflective and mobile object model abstracting components - a Java-based framework in which components live and communicate - a higher-order interpreted coordination language that manipulates components Basic architecture: The comonponents are distributed object managers. These not only implement various ilities like security and unique id and persistence, they also contain or wrapp the effective behaviour offered by this component. These objects communicate with each other mainly over RMI. They could also use ftp, http or amp. The whole HADAS system is written in Java. Access to legacy components is by wrappers - these wrappers, written mainly in Java, e.g. access CORBA-components etc. If necessary, they also use native code. As all of HADAS is Java, data is communicated in Java format. For type- mismatches, peer-to-peer dynamic wrappers exist that transform data. Levels of interoperability in Hadas: - interconnectivity infrastructure (in Java), reflective object model supporting mutability and mobility - integration : who can access whom? - configuration: dynamic agreemant between sites over use of comonents - coordination: control and dataflow between components, ISL Configuration: The operation to be called is link. What link does is: it copies a suitable ambassador objects to the other site. These ambassador objects then act like stubs. Ambassadors for the same siteobjects on various sites may have different dynamic parts in them. Each object supports methods like: add, remove (a method dynamically), invoke (a method with given parameters), describe (the offered methods). Ambassadors: - not just stubs, they have HADAS methods (install, update) - they have dynamic transformers (wrappers) and can evolve dynamically by interacting with hosting environment Reflective object model: - objects can answer questions about itself (given by Java) - object can change itself (addDataItem, addMethod, setMethod), trivial in Java - security specifications per method (probably all from Java) Wrappers: - dynamic linking to Java components - accessing C++ code with JNI - CORBA-HADAS, static wrapping - HTTP/CGI out and in transformer, dynamic wrapping Coordination, ISL: The language used is Scheme, implemented in Java. It supports weak typing and allows to encode higher-order procedures. http://www.dsg.technion.ac.il Date[ May 27, 1998 ] Recordnr[ 1 ] Stored[ Composition Who[ Scott M. Lewandowski Title[ Frameworks for Component-Based Client/Server Computing Published[ ACM Computing Surveys, Vol.30, No.1, March 1998 Keywords[ CORBA, compound document, DCOM, JAVA, business object Comment[ Summary[ General impression: very pro CORBA, does not mention RMI, paper tries to cover a large area with doubtful success Middleware is defined to include the APIs used by clients to request a service from a server, the physical transmittion of the request to the network, and the rewulting transmission of data for the client back to the network. Middleware is run on both the client and server ends of a transaction. Three different kinds of middleware: - database middleware (ODBC, SQL, Oracle Glue) - groupware middleware (Lotus Notes, Microsoft Exchange) - inernet middleware (HTTP, secure socket layer) - object middleware (CORBA, DCOM) Furthermore: fundamental/generic middleware against domain-specific middleware. Fundamental: distributed file system, RPC, authentication... Various kind of systems: - fat servers versus fat clients: data on server, UI on client - is the application logic on the server or the client? - three-tier systems: application logic is separate ==> new level of autonomy for applicatino logic. Ex: web-applications with browser, applets or cgi-scripts, database - four-tiers: e.g. with additional second tier for unifying view of the data of the databases of first tier, (CHAIMS with new architecture would also be 4 tier system) CORBA is great!!!?? - "Technologies such as Java and object request brokers (ORBs) promise to provide seamless integration among all platforms within a few years." - "only CORBA and DCOM provide viable long-term solutions to the challenge of a standardized framework for object-based client/server systems, others do not have enough features or as great an installed base..." - yet CORBA is much better, because in DCOM e.g. no real objects (objects have no state, they are just procedures ==> handles to objects are arbitrary and only garuantee interface not object-state, no unique object identifier, no persistency supported) - also DCOM objects cannot automatically support multiple interfaces, - also clients cannot request for a specific given server, - also only using WindowsNT security model and no own universal security mechanism like CORBA - CORBA and Java are made for each other and together will win (???) ==> platform for universal network computing can be created using Java as mobile code systems and CORBA as integration technology Claims (not really true in my view): - java-interfaces and CORBA-IDL's are very similar (RMI transports code and methods, not just data!! ==> totally different kind of distributed programming) - CORBA allows parameters of any type (yes, it allows more than CGI, but not "any") Selfmanaging objects: - take responsibility for their own resources, work across networks, interact with other objects - smallest ones are components like activeX controls - ===> solid event model necessary that allows objects to broadcast specific messages and generate certain events (events = synchronisation objects) - ===> transparency of location and implementation is important (as offered by CORBA) BOMSIG (Business Object Model Special Interest Group), as example for framework on top of CORBA - no references given - promotes three-tier framework for buisness objects, consisting of business object logic, business proces objects, presenation object (differences not clear to me) Compound document framework (another example of a framework on top of CORBA) Date[ 11:31:04 ] Recordnr[ ] Stored[ Papers Composition Who[ J.R.Callahan, J.M Purtilo, University of Maryland Title[ A Packaging System for Heterogeneous Execution Environments Published[ IEEE Transactions on Software Engineering, vol.17, 1991, pp.626-635 Keywords[ MIL, Polygen, Polylith Comment[ more for small, on-one-site components, strenth is partitioning and automatic reasoning about possible configurations, yet automatic generation is limitied to certain environments Summary[ Polylith: TCP/IP-based communication systems for various languages. Polygen: Composotion and reasoning tool. What it is about: - generation of custom interface software for heterogeneous configurations. - in contrast to other approaches, not only stub generation, but inserting configuration methods needed to integrate an application (e.g. main, wrappers/dispachter program for LISP-procedures, byteswap functions for adjusting integers to various representations, rendezvous functions) - polygen changes source code and adds necessary lines and stubs so they can work over network - all is automatic, user just has to specify desired geometry - logical design is separated from the geometry Composition process: Starting point: several source files (C, Ada, Pascal, Lisp) that contain modules(procedure calls) to be composed. In the extraction phase, module specs are gained from the source files, or these module specs already exist. Module specs: are written in Polylith MIL (module interconnection language). It contains the interfaces a module offers and uses and the parameters of these procedure calls. In the composition phase, the user adds the design and annotated design (with geometric data) to the specs. The design says which modules are to be used, which communication system, where the modules are. Then in the generatin phase POLYGEN makes a package based on the configuration rules it has. Configuration rules are added by the Polygen system maintainer and say what kind of modules can be connected how. A package (valid configuration represented in an executable makefile and generated stubs and interfaces) is gained by an interference mechanism that uses partitioning. Module assertions are converted to prolog statements. Based on configuration rules, partitions are created.... Finally in the construction phase an executable is generated by running the makefile that polygen has created in the generation phase. Partitioning: Partitions are sets of compatible components. They can be represented by directed, acyclic graphs,whose internal nodes represent integration methods and temrinal nodes represent source components. Valid partitioning: has only a single root. Weaknesses: - source code must be changed and recompiled - right now only for Polylith-TCP/IP - data-conversion relies on underlying communication tool - good for putting together inhouse modules - rather targeted at smaller modules - no optimization, scheduling etc... Date[ August 21, 19] Recordnr[ ] Stored[ see library Who[ Charles W. Krueger Title[ Software Reuse Published[ ACM Computing Surveys, Vol. 24, No. 2, June 1992 Keywords[ reuse, abstraction Comment[ Summary[ Abstraction: Abstraction and reuse are two sides of the same coin. Many references given for that. Abstraction occurs in layers. In each layer we can distinguish between the abstraction specification, and the abstraction realization (contains hidden parts of the abstraction).Specification contains fixed part and variable part of the abstraction. 4 facets of software reuse are looked at in the paper, though all build on top of abstraction: - abstraction: what the abstraction is at all - selection: how users find abstractions, requires consice specifications - speciliations: choosing the abstraction realisations and the correct flexible parts - integration: interface of an abstraction, how are abstractions integrated in complete software system Reuse is being looked at in the following fields: 1) High-level languages: - reusable artifacts are the language elements, which abstract assembly language patterns. - variable parts are the statements and conditions we can fill in - integration is done by compilers, hidden parts (assembler language) are never visible - cognitive distance to a problem at hand is quite large (yet smaller than with pure assembler) 2) Design and Code scavenging - code scavenging: copying small code fragments without changing - design scavenging: copying larger code fragments containing a design pattern, and changing details yet keeping overall design; or making new code based on earlier experiences - very informal, not always worth while - no hidden parts of abstraction, specialization and integration require intimate knowledge of the code - if large pieces of good code can be reused without looking too much into it, the cognitive distance is small 3) Source Code Components Main contrast to code scavenging: components are build to reuse. The description here is a little bit outdated. He mentions mathematical analysis libraries and ADA-components. Nowadays, we would add JFC, MFC, RoqueWafe etc. Integration has been improved by todays OO-languages, specialization has been clearly "reduced" to parameters and inheritance. Selection is getting better by good browsers, web-pages etc.... 4) Software Schemas Quite outdated, the mentioned tools have not made it. Schemas seem to be quite similar to templates and design patterns. The foculs lies on higher level semantics descriptions of components, and of schemas how things work together (just design patterns). 5) Application generators Whole applications are generated, e.g. parser and compiler generator. Only certain rules, modules, elements, diagrams are written. The rest is generated. The abstractions come directly from the application domain. Cognitive distance is very small. 6) Very High-level Languages VHLL = executable specification languages Developing in a VHLL is similar to developing in a HLL (writing program that gets compiled). Like application generators, VHLL will generate the applications, yet VHLL are general purpose. VHLL want higher levels of specification without sacrificing computational generatily. - VHLLs are often very slow, yet execution efficiency is sacrificed for implementation and modification effencency - VHLLs are often based on some higher level mathematical model Examples for VHLLs: - SETL: based on set theory, good for easy use of abstract data types - PAISLey: functional programming, ..... - MODEL: declarative constraint language Main concern: execution speed. 7) Transformational systems 8) Architectural abstractions - come directly from application domain Date[ July 8, 1998 ] Recordnr[ ] Stored[ bookshelf? Who[ P. Bassett Title[ Managing for Flexible Software Manufacturing Published[ IEEE Computer, vol31, no7, July 1998 Keywords[ Comment[ Summary[ The article discusses reuse, the reason why it does not happen, and proposes some remedies. Reasons why reuse does not happen: - Old manufacturing culture: we only trust our own software, and distrust other software; "our software will be far better" - Management supports these habits Management strategies to overcome old culture: 1) Promoting reuse within same project, i.e. avoiding perfectionism and over-generalisation syndrom. 2) Own and manage multiproject assets centrally by central profit-centre that rents out component engineers (actual glue) that help individual projects to use these components fast and effectively. Architectures for reuse, two types: 1) Execution architectures: system is encapsulated into executable modules, e.g. many OO-architectures, CORBA, n-tiered client-server, ... Point of view is runtime. 2) Construction architectures: the executable modules are partitioned into reusable components according to the isolation of change. Point of view is construction time, the goal is to localize the effects of change, to reduce complexity and ensure as much independance between components as possible, so when making changes to API's, data structures etc, as view components as possible have to be touched. ==> reuse is enhanced. Infrastructure for reuse: We have infrastructures for execution architectures (e.g. ORB's), but not really for construction time. It is hard to access and find multiple sources of supply of components. With infrastructure also come basic metrics that would give information about the return of investment in components. Flexible Software Manufacturing - a new paradigm? What it means: components that have the capability to adapt/customize themselves to concrete requirements. How does CHAIMS relate to this? - we are not changing any megamodules in the composition process, we may only add mediator megamodules to complete certain suites of megamodules - yet the megamodule providers can provide more or less suitable megamodules ==> ideally they package the functionality in such a way that the megamodule can be used in as many different settings as possible (minimal interface yet still flexible enough for many uses). The article also mentions some books about reuse, e.g. McClure 1997, Jacobson 1997, Date[ June 18, 1998] Recordnr[ ] Stored[ Who[ Michael VanHilst (works now at HP-Labs), D. Notkin Title[ Using Role Components to Implement Collaboration-Based Designs Published[ OOPSLA 96 Keywords[ aspect-oriented programming, roles, collaborations, roles as code entities Comment[ nice idea, might become an additional implementation paradigm, compareable to model-view-controller Summary[ Problem statement: Collaborations are modelled in the design. They show interactions between different roles (not really between different classes)==> collaborations as collections of roles. A role specifies a part of a single object that participates in a particular collaboration. One class can play several roles in differing collaborations; the same role is not implemented by the same class throughout all applications using that collaboration pattern. How could the notion of roles brought over to the implementation? Code reuse, system evolution: Collaborations in the design are derived from use-case-like scenarios in the requirements analysis. By having role-entities in the code, these use-cases could be reflected directly in the code, preserving this complementary view to the static class view. How? Inheritance is a logical glue for composing roles into classes, but: - inheritance must be delayed until whole composition and order of composition is known (compile-time, not code-writing time) - bindings to types must be delayed as well, so that roles can be coded independant of the specific classes taking them on, and thus be reused ==> class template for each role that is parameterized by each of the collaborator and by the class taking on the role itself ==> class then extend these templates, replacing the collaborators by the actual classes ==> a class having several roles is extended several times, each time the higher level class becomes a parameter in the next template to be extended ==> inheritance chain (but only simple inheritance is used) In order to get the right order in the inheritance chain, a roles/responsibility matrix is made. It helps to determine which roles (object methods) extend each other, and thus should override each other by calling the original one in case not the extended one is used. Related concepts: subject-oriented programming mixins Date[ November 2, 1] Recordnr[ ] Stored[ Papers sonst Who[ Michael M. Gormann Title[ The Essential Paradigm for Successful Information Technology Standards Published[ http://www.wiscorp.com/p115.htm Keywords[ standards, NIST, Comment[ Good entry paper. Summary[ The author emphesizes that there exist three main factors that must be fulfilled in order for a standard to be sucessful: - significant market share vendor community - publically developed, available, and evolving standard - enforced conformance tests Successful means the standard is adopted by a wide range of vendors. The paper discusses these points taking the SQL-standard and NIST who has given up conformance tests. The paper also shows the consequences for individual clients as well as the industry as a whole when successful standards do not exist (locked into one vendor, disabling competition by market leaders, high prizes for non-competitive products). Lost of references. Date[ June 24, 1998] Recordnr[ ] Stored[ Composition papers Who[ M.-C. Shan, J.W.Davis, et al Title[ Business Process Flow Management and its Application in the Telecommunications Management Network Published[ HP-Journal, October 1996 Keywords[ workflow, composition, Comment[ Summary[ The paper describes HP OpenPM, now called changengine and used by several banks. It is advanced workflow technology based on a framework approach for reusability. Goals of changengine: - substantial evolution from traditional workflow technologies - for distributed heterogenous computing environment (several procotols via wrappers) - it is a middleware system for procedural automation of a business process by managing the sequence of process activities, including the invocation of appropriate human, instrument or computer resources. - content, structure of process can be preplanned or ad hoc Main elements: - Process engine: based on the business process definition (graphically, rules) the process engine determines when something takes place and triggers activities. - Resource executive: manages resources - BOW: business object wrappers Definition of process: Graph containing work nodes and rule nodes. Each work node can again be a process containing work nodes and rule nodes. Work nodes have status initial or fired. Forward arcs denote normal execution flow, and they form directed acylic graph. Each work node can only have incoming arc, whereas rule nodes can have several incoming arcs (they have rules to deal with that). Both kind of nodes can have several outgoing arcs. Backward arcs are reset arcs, i.e. when they fire, everything in their loop is reset, and started tasks are aborted. Nodes fire like in a petri-net. Rules: e.g. "if Customer.approval = TRUE then arc 5" Events: rule nodes can also raise evens, which themselves can fire rules nodes that have subscribed to that event. Events are modelled like specific kind of nodes, like a shortcut for not drawing to many arcs across the graph. This kind of graph allows to describe: - sequencing and timing and dependancy of business activities, - data and physical agent allocation of business activities - business rules and organization policies Mapping of process definition to execution: Work node -- process activity(task) -- invocation of an operation on business objects(resource) during execution of a process BOW: BOW's wrap business objects and interface to the process engine via CORBA. Towards business objects they interface with various protocols, e.g. also DCOM and DNA. Business objects are catalogued in a library. Interfaces: from process engine are CORBA and WfMC (Workflow Managmenet Coalition standard interface) Optimization: Data handler: allows seperation of application specific data and process-relevant data needed for rule nodes, thus reducing amount of data flow. Resource manager: for automatic workload balancing. Statistical data: bottleneck analysis, flow optimization. References: - paper gives further references (not very new) - Reed Letsinger and Michael VantHilst at HP labs - webpage: www.pwd.hp.com/cyc/af/50/ is behind firewall Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J.M.Voas Title[ The Challenges of Using COTS Software in Component-Based Development Published[ IEEE Computer, June 1998, Vol31 No6, Guest Editors introduction Keywords[ COTS Comment[ Summary[ Software we acquire elsewhere: - COTS: commercial of the shelf - CAS: commercially available software - NDI: nondevelopmental item ==> used as components or componentware to build component-based software or systems of systems Problems in using componentware: - Components may integrate perfectly during development, but not behave perfectly at rntime. - We have process models for developing software from requirements, but not yet for acquiring software. - COTS are delivered as black box ==> how to determine that they behave safely, securely, and reliably? - How to access the quality of COTS? How to access suitability? Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J.McDermid Title[ The Cost of COTS Published[ IEEE Computer, June 1998, Vol31 No6, an interview Keywords[ COTS Comment[ Quite quite an interesting interview discussing general cost issues of COTS in contrast to bespoke (custom solutions), especially for safety- and reliability-critical system. The article is very critical towards COTS, mainly talks from a viewpoint of critical systems (process control systems, not information systems). Summary[ Promises of COTS: eliminate sfotware development project that overrun time and cost, greater ability to interoperate diverse systems, quickly evolve large systems, lower costs COTS nowadays: GUIs, operations systems, databases ==> mainly large components (and what about CERN-libraries, statistic tools etc.?) Risk mitigation: Problem: COTS are often build without a strict process and documentation control, no clear QA, and are delivered without appropriate documentation of the process, and without e.g. complete test-suites etc. (solutions: certification, using an escrow i.e. depositing the documentation at a bank for the case the company disappears). How to access the quality? - retrospective assessment is more expensive than assessing the software when developing it, if possible at all (code analysis) - each upgrade has to be assessed anew - software has not been written with the goal to access it (whereas bespoke for critical systems is structured and written in order to be accessed) - accessing needs also been done for all unwanted functionality (additional effort not necessary for bespoke) How to demonstrate the desired level of reliability, availability, integrity? - unwanted functions with dangerous side-effects How to control future of a COTS-component? - component can go out of business - new releases with unwanted functions - cost of upgrading - wrappers do not solve any of above problems Cost-tradeoff between COTS and bespoke: - price of purchase versus development - price of assessing quality of COTS to desired quality level - price of integrating COTS - price for upgrades, price for accessing upgrades, price for integrating upgrades - risk of vendor going out of business and expected life-time of system COTS can offer historical data for its quality (e.g. OS but not things like Microsoftword which get updates too often), bespoke has not historical data but you know what you are developing and can assess that. Date[ June 17, 1998] Recordnr[ ] Stored[ magazine, file- cabinet, composition Who[ J. M.. Voas Title[ Certifying Off-the-Shelf Software Components Published[ IEEE Computer, June 1998, Vol31 No6, an interview Keywords[ COTS Comment[ Summary[ Three questions must be answered positively before using/certifying a COTS-component for a specific environment: 1 Does component C fill the Developer's needs? 2 Is the quality of component C high enough? 3 What impact will component C have on system S? Ways to answer that is by: a Black-box testing (answers question 1) b System-level fault injection c Operational system testing a and b together answer 2 and 3. Black-box testing: - best to build own oracle that tests comonents against needs of user and not against vendors specification - can fail to exercise important/faulty portions of the code System-level fault injection: Instead of the component a fault injector is put into the system (just the minimum amount of surrounding components is used) that works nearly like the component but randomly makes wrong results. Can the system stand that? Operational system testing: Problem: enormous amount needed for components that rarely fail. Advantage voer system-level fault injection: tests the real wrong behaviour. Remedy if component is not save enough: wrappers. Problem: Wrapper may not catch all the behaviour of a component. Date[ July 29, 1998] Recordnr[ ] Stored[ file-cabinet, Papers Composition Who[ J. Magee, N. Dulay, J. Kramer Title[ Regis: A Constructive Development Environment for Distributed Programs Published[ IEE/IOP/BCS Distributed Systems Engineering, 1(5): 304-312, Sept 1994. Keywords[ Comment[ Other papers about Regis/Darwin: Ng, K. and Kramer, J.; Automated Support for Distributed Software Design, appeared in 7th International Workshop on Computer-aided Software Engineering (CASE 95) Mostly describes the Software Architect's Assistant, a visual tool to set up distributed systems. Magee, J. and Dulay, N. and Eisenbach, S. and Kramer, J.;Specifying Distributed Software Architectures, appeared in 5th European Software Engineering Conference (ESEC 95) Presents a formal model of Darwin in Robin Milner's Pi-Calculus. Magee, J. and Dulay, N. and Kramer, J.; Regis: A Constructive Development Environment for Distributed Programs; IEE/IOP/BCS Distributed Systems Engineering},Volume = {1},Number = {5},1994 Describes the most recent distributed execution environment for Darwin-structured applications. Summary[ Darwin is a configuration language, Regis is a system supporting Darwin and generating the distributed systems specified in Darwin. For each component an interface is specified that contains all incoming and outgoing links. These can be of different types (pipes, ports...). The communications are implemented by special C++ components. The components to be configured/assembled can be either composite components, consisting of a set of lower level components, or computation components. Latter are written in C++ and must inherit from a predefined class process. Darwin also allows to imbed directly program code in the component descriptions. Components are garbage collected after termination. Regis runs on a Unix environment, the components can run on different Unix-workstations. A mapping file defines on which processor of the multicomputer which component is run. My conclusions: Regis supports program generation for a homogeneous environment. The distribution seems only to be local - I do not know if it is suited for servers located outside the intranet. The components that are composed are controlled entirely by the configuration language and by Regis (automatic garbage collection) - no autonomous servers that exist and run independant of the client. No equivalents to "EXAMINE", "ESTIMATE". Legacy code probably could be brought in, but I have not seen this issue being specifically adressed. As far as I know, no commercial application. Notes of Louis: I looked at a bunch of papers from Imperial College, London. The head of that group is Jeff Kramer, the relevant URLs are: Regis: http://www-dse.doc.ic.ac.uk/~regis/ Darwin: http://www-dse.doc.ic.ac.uk/~jsc/research/darwin.html Some of their work is relevant for RapArch, Architecture, and RapNet (see below). Regis has been in use since 1992. Darwin/Regis ============ Regis is a programming environment aimed at supporting the development and execution of distributed program. A Regis program consists of loosely coupled components either directly written in C++ (primitive components) or constructed out of simpler subcomponents by using the Darwin language. As such, Darwin is an Architecture Description Language (ADL) remarkably similar to the RAPIDE ADL. The Regis environment lets you develop the individual C++ components and the composition using Darwin, then compiles everything into executables and runs it on distributed sites. Regis/Darwin is restricted to the design/implementation phase. Once the program is compiled, installed and running, it is on its own, there is no support for ongoing analysis. One '95 paper said they will do run-time monitoring and management, but that will probably be primitive (i.e. just monitoring if they still run) and may not even exist. They stress the fact that a Regis program can be distributed (a la mobile agents), but I don't think that is the exciting thing about it. The Darwin ADL -------------- Darwin boxes are called "components", action declaration are called "services", arrows are called "bindings". Like RAPIDE, Darwin specifies both provided as required services. Services are typed and type conformance is enforced. Darwin allows hierarchical composition of components as well as parametrization, a component can consist of n subcomponents, with n decided statically at run time or dynamically at runtime. The latter is what they call dynamic architectures. In both cases, all n components have the same type, bindings, etc. This is just simple instantiation of a class. In some aspects Darwin is more general than Rapide ADL. The communication mechanism is not restricted to events. Darwin supports any communication mechanism (events, streams, RPC, etc. In Regis, the mechanism is then implemented as a C++ class). Thus the type of an action denotes the C++ class that implements it. A Darwin filter on a stream of characters would look like component filter { provide output; require input; } A funny thing happens when one looks at services of type "port". A port is used to send messages through and is interpreted in a procedure call style. Thus, to send a message, a sensor *requires* a port, the "output" becomes "required". The following comes from their paper and seems wrong for a RAPIDE person (at least for me). component sensor { provide input; require output; } I guess they run into this problem because they support both push (stream, event) and pull (port) communication with others. Pi-calculus ----------- Darwin is also specified in Milner's \pi-calculus. This is an elementary calculus for describing and analyzing concurrent, independent processes that communicate via channels. A subset of the Pi-calculus (http://www.cwi.nl/~arie/picalc.html) seems to be a candidate for our RapNet composition language. Software Architect Assistant ---------------------------- Regis comes with a graphical architecting tool called Software Architect Assistant (SAA), similar to RapArch. In comparison to RapArch, SAA's focus is more on providing semantics and ease-of-use and less on providing fancy drawing capabilities. All "boxes" have the same size, and "arrows" are laid out automatically by the tool and cannot be changed. (See http://www-dse.doc.ic.ac.uk/sel/sereports/rj1/rj1.html for an evaluation.) On the other hand, boxes and arrow have full semantic meaning, and correctness is checked at data entry point. The graphical and the textual view are always consistent. I especially like the separation between connections and interfaces. The "arrow" is just a line, the ending points indicating in which direction it points are part of the "box". This makes sense, because when you define a box, it is already clear which "actions" are "required" and which are "provided". SAA also displays nicely how services are connected when components are hierarchically encapsulated in each other. SAA also supports libraries of components, that can be included as sub-components in other components and it can read Darwin (textual) code not written by SAA. The SAA exports RTF reports that can be directly imported into word processors. Date[ August 5, 199] Recordnr[ ] Stored[Composition, filecabinet Who[ I. Ben-Shaul, et.al. Title[ HADAS: A Network-Centric Framework for Interoperability Programming Published[ International Journal of Cooperative Informaion Systems, 1997 Keywords[ heterogeneity, RMI, HADAS, coordination language, Comment[ Very interesting approach. More focused on roaming agents. Summary[ Challenge: Compose, configure and execute network-centric applicatins made up of widely-distributed components. Major problem: global interoperability Examples: active, intelligent information agents; inter-organization collaborative workflow systems, e-commerce, large-scale concurrent computations Main ideas of HADAS (=heterogeneous autonomous distributed abstraction system): - autonomy of objects: administrative autonomy (==> evolving over time), design autonomy (heterogeneity) - network centric framework - no central agent like a broker, fully decentralized (==> possible by using RMI) - dynamic and programmable approach to interoperability, peer-to-peer configuration agreement - ISL as coordination lanague Approch: - a (reflective and mobile object model abstracting components - a Java-based framework in which components live and communicate - a higher-order interpreted coordination language that manipulates components Basic architecture: The comonponents are distributed object managers. These not only implement various ilities like security and unique id and persistence, they also contain or wrapp the effective behaviour offered by this component. These objects communicate with each other mainly over RMI. They could also use ftp, http or amp. The whole HADAS system is written in Java. Access to legacy components is by wrappers - these wrappers, written mainly in Java, e.g. access CORBA-components etc. If necessary, they also use native code. As all of HADAS is Java, data is communicated in Java format. For type- mismatches, peer-to-peer dynamic wrappers exist that transform data. Levels of interoperability in Hadas: - interconnectivity infrastructure (in Java), reflective object model supporting mutability and mobility - integration : who can access whom? - configuration: dynamic agreemant between sites over use of comonents - coordination: control and dataflow between components, ISL Configuration: The operation to be called is link. What link does is: it copies a suitable ambassador objects to the other site. These ambassador objects then act like stubs. Ambassadors for the same siteobjects on various sites may have different dynamic parts in them. Each object supports methods like: add, remove (a method dynamically), invoke (a method with given parameters), describe (the offered methods). Ambassadors: - not just stubs, they have HADAS methods (install, update) - they have dynamic transformers (wrappers) and can evolve dynamically by interacting with hosting environment Reflective object model: - objects can answer questions about itself (given by Java) - object can change itself (addDataItem, addMethod, setMethod), trivial in Java - security specifications per method (probably all from Java) Wrappers: - dynamic linking to Java components - accessing C++ code with JNI - CORBA-HADAS, static wrapping - HTTP/CGI out and in transformer, dynamic wrapping Coordination, ISL: The language used is Scheme, implemented in Java. It supports weak typing and allows to encode higher-order procedures. http://www.dsg.technion.ac.il Date[ May 27, 1998 ] Recordnr[ 1 ] Stored[ Composition Who[ Scott M. Lewandowski Title[ Frameworks for Component-Based Client/Server Computing Published[ ACM Computing Surveys, Vol.30, No.1, March 1998 Keywords[ CORBA, compound document, DCOM, JAVA, business object Comment[ Summary[ General impression: very pro CORBA, does not mention RMI, paper tries to cover a large area with doubtful success Middleware is defined to include the APIs used by clients to request a service from a server, the physical transmittion of the request to the network, and the rewulting transmission of data for the client back to the network. Middleware is run on both the client and server ends of a transaction. Three different kinds of middleware: - database middleware (ODBC, SQL, Oracle Glue) - groupware middleware (Lotus Notes, Microsoft Exchange) - inernet middleware (HTTP, secure socket layer) - object middleware (CORBA, DCOM) Furthermore: fundamental/generic middleware against domain-specific middleware. Fundamental: distributed file system, RPC, authentication... Various kind of systems: - fat servers versus fat clients: data on server, UI on client - is the application logic on the server or the client? - three-tier systems: application logic is separate ==> new level of autonomy for applicatino logic. Ex: web-applications with browser, applets or cgi-scripts, database - four-tiers: e.g. with additional second tier for unifying view of the data of the databases of first tier, (CHAIMS with new architecture would also be 4 tier system) CORBA is great!!!?? - "Technologies such as Java and object request brokers (ORBs) promise to provide seamless integration among all platforms within a few years." - "only CORBA and DCOM provide viable long-term solutions to the challenge of a standardized framework for object-based client/server systems, others do not have enough features or as great an installed base..." - yet CORBA is much better, because in DCOM e.g. no real objects (objects have no state, they are just procedures ==> handles to objects are arbitrary and only garuantee interface not object-state, no unique object identifier, no persistency supported) - also DCOM objects cannot automatically support multiple interfaces, - also clients cannot request for a specific given server, - also only using WindowsNT security model and no own universal security mechanism like CORBA - CORBA and Java are made for each other and together will win (???) ==> platform for universal network computing can be created using Java as mobile code systems and CORBA as integration technology Claims (not really true in my view): - java-interfaces and CORBA-IDL's are very similar (RMI transports code and methods, not just data!! ==> totally different kind of distributed programming) - CORBA allows parameters of any type (yes, it allows more than CGI, but not "any") Selfmanaging objects: - take responsibility for their own resources, work across networks, interact with other objects - smallest ones are components like activeX controls - ===> solid event model necessary that allows objects to broadcast specific messages and generate certain events (events = synchronisation objects) - ===> transparency of location and implementation is important (as offered by CORBA) BOMSIG (Business Object Model Special Interest Group), as example for framework on top of CORBA - no references given - promotes three-tier framework for buisness objects, consisting of business object logic, business proces objects, presenation object (differences not clear to me) Compound document framework (another example of a framework on top of CORBA) Date[ 11:31:04 ] Recordnr[ ] Stored[ Papers Composition Who[ J.R.Callahan, J.M Purtilo, University of Maryland Title[ A Packaging System for Heterogeneous Execution Environments Published[ IEEE Transactions on Software Engineering, vol.17, 1991, pp.626-635 Keywords[ MIL, Polygen, Polylith Comment[ more for small, on-one-site components, strenth is partitioning and automatic reasoning about possible configurations, yet automatic generation is limitied to certain environments Summary[ Polylith: TCP/IP-based communication systems for various languages. Polygen: Composotion and reasoning tool. What it is about: - generation of custom interface software for heterogeneous configurations. - in contrast to other approaches, not only stub generation, but inserting configuration methods needed to integrate an application (e.g. main, wrappers/dispachter program for LISP-procedures, byteswap functions for adjusting integers to various representations, rendezvous functions) - polygen changes source code and adds necessary lines and stubs so they can work over network - all is automatic, user just has to specify desired geometry - logical design is separated from the geometry Composition process: Starting point: several source files (C, Ada, Pascal, Lisp) that contain modules(procedure calls) to be composed. In the extraction phase, module specs are gained from the source files, or these module specs already exist. Module specs: are written in Polylith MIL (module interconnection language). It contains the interfaces a module offers and uses and the parameters of these procedure calls. In the composition phase, the user adds the design and annotated design (with geometric data) to the specs. The design says which modules are to be used, which communication system, where the modules are. Then in the generatin phase POLYGEN makes a package based on the configuration rules it has. Configuration rules are added by the Polygen system maintainer and say what kind of modules can be connected how. A package (valid configuration represented in an executable makefile and generated stubs and interfaces) is gained by an interference mechanism that uses partitioning. Module assertions are converted to prolog statements. Based on configuration rules, partitions are created.... Finally in the construction phase an executable is generated by running the makefile that polygen has created in the generation phase. Partitioning: Partitions are sets of compatible components. They can be represented by directed, acyclic graphs,whose internal nodes represent integration methods and temrinal nodes represent source components. Valid partitioning: has only a single root. Weaknesses: - source code must be changed and recompiled - right now only for Polylith-TCP/IP - data-conversion relies on underlying communication tool - good for putting together inhouse modules - rather targeted at smaller modules - no optimization, scheduling etc... Date[ August 21, 19] Recordnr[ ] Stored[ see library Who[ Charles W. Krueger Title[ Software Reuse Published[ ACM Computing Surveys, Vol. 24, No. 2, June 1992 Keywords[ reuse, abstraction Comment[ Summary[ Abstraction: Abstraction and reuse are two sides of the same coin. Many references given for that. Abstraction occurs in layers. In each layer we can distinguish between the abstraction specification, and the abstraction realization (contains hidden parts of the abstraction).Specification contains fixed part and variable part of the abstraction. 4 facets of software reuse are looked at in the paper, though all build on top of abstraction: - abstraction: what the abstraction is at all - selection: how users find abstractions, requires consice specifications - speciliations: choosing the abstraction realisations and the correct flexible parts - integration: interface of an abstraction, how are abstractions integrated in complete software system Reuse is being looked at in the following fields: 1) High-level languages: - reusable artifacts are the language elements, which abstract assembly language patterns. - variable parts are the statements and conditions we can fill in - integration is done by compilers, hidden parts (assembler language) are never visible - cognitive distance to a problem at hand is quite large (yet smaller than with pure assembler) 2) Design and Code scavenging - code scavenging: copying small code fragments without changing - design scavenging: copying larger code fragments containing a design pattern, and changing details yet keeping overall design; or making new code based on earlier experiences - very informal, not always worth while - no hidden parts of abstraction, specialization and integration require intimate knowledge of the code - if large pieces of good code can be reused without looking too much into it, the cognitive distance is small 3) Source Code Components Main contrast to code scavenging: components are build to reuse. The description here is a little bit outdated. He mentions mathematical analysis libraries and ADA-components. Nowadays, we would add JFC, MFC, RoqueWafe etc. Integration has been improved by todays OO-languages, specialization has been clearly "reduced" to parameters and inheritance. Selection is getting better by good browsers, web-pages etc.... 4) Software Schemas Quite outdated, the mentioned tools have not made it. Schemas seem to be quite similar to templates and design patterns. The foculs lies on higher level semantics descriptions of components, and of schemas how things work together (just design patterns). 5) Application generators Whole applications are generated, e.g. parser and compiler generator. Only certain rules, modules, elements, diagrams are written. The rest is generated. The abstractions come directly from the application domain. Cognitive distance is very small. 6) Very High-level Languages VHLL = executable specification languages Developing in a VHLL is similar to developing in a HLL (writing program that gets compiled). Like application generators, VHLL will generate the applications, yet VHLL are general purpose. VHLL want higher levels of specification without sacrificing computational generatily. - VHLLs are often very slow, yet execution efficiency is sacrificed for implementation and modification effencency - VHLLs are often based on some higher level mathematical model Examples for VHLLs: - SETL: based on set theory, good for easy use of abstract data types - PAISLey: functional programming, ..... - MODEL: declarative constraint language Main concern: execution speed. 7) Transformational systems 8) Architectural abstractions - come directly from application domain Date[ July 8, 1998 ] Recordnr[ ] Stored[ bookshelf? Who[ P. Bassett Title[ Managing for Flexible Software Manufacturing Published[ IEEE Computer, vol31, no7, July 1998 Keywords[ Comment[ Summary[ The article discusses reuse, the reason why it does not happen, and proposes some remedies. Reasons why reuse does not happen: - Old manufacturing culture: we only trust our own software, and distrust other software; "our software will be far better" - Management supports these habits Management strategies to overcome old culture: 1) Promoting reuse within same project, i.e. avoiding perfectionism and over-generalisation syndrom. 2) Own and manage multiproject assets centrally by central profit-centre that rents out component engineers (actual glue) that help individual projects to use these components fast and effectively. Architectures for reuse, two types: 1) Execution architectures: system is encapsulated into executable modules, e.g. many OO-architectures, CORBA, n-tiered client-server, ... Point of view is runtime. 2) Construction architectures: the executable modules are partitioned into reusable components according to the isolation of change. Point of view is construction time, the goal is to localize the effects of change, to reduce complexity and ensure as much independance between components as possible, so when making changes to API's, data structures etc, as view components as possible have to be touched. ==> reuse is enhanced. Infrastructure for reuse: We have infrastructures for execution architectures (e.g. ORB's), but not really for construction time. It is hard to access and find multiple sources of supply of components. With infrastructure also come basic metrics that would give information about the return of investment in components. Flexible Software Manufacturing - a new paradigm? What it means: components that have the capability to adapt/customize themselves to concrete requirements. How does CHAIMS relate to this? - we are not changing any megamodules in the composition process, we may only add mediator megamodules to complete certain suites of megamodules - yet the megamodule providers can provide more or less suitable megamodules ==> ideally they package the functionality in such a way that the megamodule can be used in as many different settings as possible (minimal interface yet still flexible enough for many uses). The article also mentions some books about reuse, e.g. McClure 1997, Jacobson 1997, Date[ June 18, 1998] Recordnr[ ] Stored[ Who[ Michael VanHilst (works now at HP-Labs), D. Notkin Title[ Using Role Components to Implement Collaboration-Based Designs Published[ OOPSLA 96 Keywords[ aspect-oriented programming, roles, collaborations, roles as code entities Comment[ nice idea, might become an additional implementation paradigm, compareable to model-view-controller Summary[ Problem statement: Collaborations are modelled in the design. They show interactions between different roles (not really between different classes)==> collaborations as collections of roles. A role specifies a part of a single object that participates in a particular collaboration. One class can play several roles in differing collaborations; the same role is not implemented by the same class throughout all applications using that collaboration pattern. How could the notion of roles brought over to the implementation? Code reuse, system evolution: Collaborations in the design are derived from use-case-like scenarios in the requirements analysis. By having role-entities in the code, these use-cases could be reflected directly in the code, preserving this complementary view to the static class view. How? Inheritance is a logical glue for composing roles into classes, but: - inheritance must be delayed until whole composition and order of composition is known (compile-time, not code-writing time) - bindings to types must be delayed as well, so that roles can be coded independant of the specific classes taking them on, and thus be reused ==> class template for each role that is parameterized by each of the collaborator and by the class taking on the role itself ==> class then extend these templates, replacing the collaborators by the actual classes ==> a class having several roles is extended several times, each time the higher level class becomes a parameter in the next template to be extended ==> inheritance chain (but only simple inheritance is used) In order to get the right order in the inheritance chain, a roles/responsibility matrix is made. It helps to determine which roles (object methods) extend each other, and thus should override each other by calling the original one in case not the extended one is used. Related concepts: subject-oriented programming mixins Date[ November 2, 1] Recordnr[ ] Stored[ Papers sonst Who[ Michael M. Gormann Title[ The Essential Paradigm for Successful Information Technology Standards Published[ http://www.wiscorp.com/p115.htm Keywords[ standards, NIST, Comment[ Good entry paper. Summary[ The author emphesizes that there exist three main factors that must be fulfilled in order for a standard to be sucessful: - significant market share vendor community - publically developed, available, and evolving standard - enforced conformance tests Successful means the standard is adopted by a wide range of vendors. The paper discusses these points taking the SQL-standard and NIST who has given up conformance tests. The paper also shows the consequences for individual clients as well as the industry as a whole when successful standards do not exist (locked into one vendor, disabling competition by market leaders, high prizes for non-competitive products). Lost of references.