Session:Components--Discussions
From WICSA Conference Wiki
Please use this page to capture ideas, thoughts, reactions, opinions and so on about the content of this working session.
Key ideas
(key ideas, how papers relate to each other and support the session theme)
- 10 minute discussion + 5 minute questions
Discussion questions
Based on Nov 9 Discussions
- What are the characteristics of SOA and Web-Services for Mobile and Distributed devices?
- How do we extend the principles (functional and non-functional aspects) of components to embedded systems?
- How to predict the consequences of 3-party component integration at the system level?
- What are the implications of connectors on the system properties?
- How do we generate an initial component configuration for Dynamic behaviour?
- Related question - How do we get a software architecture that guarentees certain properties of a dynamic behaviour?
- What are the similarities and differences in a Service Oriented and Component bases approaches? - (Already discussed - you can add to Wiki)
- How is software evolution affected in component based systems?
- How are the binding mechanisms in software architecture and component implementatons related?
- How to translate legacy systems to Component Based System?
Pre-session Discussions
Session Minutes (1st day: Nov 9: 3:15PM)
Venue: Panther Hall
Michael Jiang: Service-Oriented Architecture for Deploying and Integrating Enterprise Applications
Not present for presentation
Rikard Land :Architectural Concerns When Selecting an In-House Integration Strategy Experiences from Industry
- Different software systems developed in house
- Organizations undergo mergers and systems need to merge
- Two systems that overalap.
- We can have 4 strategies
- use one retire other: choose 1 strategy
- retire both: build over experience to build new system, migration plan
- some functionality from both
- no integration
- In short: SFS, CO (choose one), EM (Evolutonary Merge), IM
- Different case sudies (9 of them)
- Which strategies to choose in each instance
- We need to resolve at architectural level, at lower level too time consuming
- Arch compatibility, and Retirability
- Exclusion criterion 1: Arch. Compatibility
- High level arch. factors (like client-server..etc.)
- framework level compatibility
- Exclusion criterion 2: Retirability
- matter of tradeoff
- Have to ask various stakeholders
- Stragtegy Exclusion indicated in paper
- In conclusion, merge is really difficult
- In future, looking into what is required to resuse as much as possible
- Questions
- What does it mean to retire?
Stop using it or stop supporting it? Ans: We have to see that.
- How did you come up with this survey or criterion?
Ans: My own, born out of experience and intution
- System that started from scratch, how did they do it?
Ans: In some cases they change language, in other case translation, In one case there was physics cal, they had to change major.
- Who actually made the decision to choose or not? Was it influenced by their desire to say to hold on to assets? Was it architects or managers?
Ans: Different case, eg. managers asked and Architects said 'no' it is difficult.
- Remark: In the end everything is a management decision.
Frank Luders: Software Component Services for Embedded Real-Time Systems
- In embedded systems we haven't seen much use of components
- Research focused on:
- Source code components
- Static configuration
- Narrow application domain
- Efficiency motivated
- Our approach
- Binary comoponents
- Wider application domains
- Inspired by COM like components and Component services
- Component services for ERTS (Embedded real time systems)
- COM way: service implement common functionality and use proxy object
- Proxy objects are generated off-line on the development host
- Examples of services:
- Timing
- Synchronization
- Monitoring
- Asynchronous invocation
- Expected benefits
- Useful services make it attractive
- error-prone func. outside component makes it simpler and more reliable
- More reusable components
- Can be implemented by vendors
- Prototype done: initial results
- Two prototypes developed, tools generate proxy for logging service
- At conceptual prototype level
- Future
- continue development
- Evaluate feasibility, usefulness
- Evaluate and etend the set of services
- Concluding
- Approach differes from main research trend
- COM and COM+ influenced, so easy adaptibility
- Will require some resource overhead
- Emperical evaluation is needed (feasibility and usefulness)
- Questions
- Question: Really interesting idea, but does using proxy change the interface thing. now make changes like sync-and asynch.
Ans: Would be interesting to look at proxies that retain semantics
- Question: Also about proxies; in real time systems, choosing solution which uses proxies imposes overhead. So what was the exact motivation to choose?
Ans: It is one of the things that has been proven to work. so logging etc. actually justify its use
- Ques: Capability based access control. Can you ensure that?
Ans: components will have less talkin to do with core. services should provide that
- Ques: Do you depend on operating system to provide that:
Ans: We are implementing it on top of operating system. But good idea would be to integrate it into the operation system. e.g. COM+ did it
- Ques: Any example of embedded systems using Window CE?
Ans: I don't have example at present...thank you.
Michelle:Connectors as Integration Services
- SOA integration with Non-service compoents
- Protocol, integration
- Vendors advocated wrappers
- Connectors: Our choice
- Elementable, composable
- Guidlines for Integrating service design
- Avoid over integration
- Avoid redundancy: share when appropriate
- Consistency: avoid creating artificial relationships
- Example: Overseas Inventory managent system, Domestic Inventory System
- Ques:In example, systems look similar, what if they are different?
Ans: If they are sharing similar data, data just needs to be translated, and then it should work. create integration service that has minimal integration first and then other integration functionality can be outside that principal integrator component
- Ques:In figure, Translator is it outside?
Ans: Yes
- Ques: You say redundancy is problem? But should it be?
Ans: If you services use the functionality, you should not use it in integratin service????
Massimo Tavolli: Adaptor Synthesis for Protocol Enhanced Compoent Based Architecture
- Basic idea is to avoid failures in the system
- e.g. Deadlock
- Their idea is to build the connector directly from the specification and then avoid failure avoid failure behaviour
- Prototyping done using COM, DCOM
- Future work:
- use more user-friendly specs.
- Generate connectors that improve behaviour.
Post discussions
- Khalid: Discuss SOA or Web-services for mobile devices and distributed
- Johan: How do we extend the principles of components to embedded systems? How do we take care of non-functional aspects in embedded sytems?
- Christine: 3rd party components - integration and control? side-effects of the component intearactions:
- Yan: Using connector to encapsulate communication between components. Mapping to runnable code - what are the performance implications?
- Alexei: Self-management systems? My interest is in dynamisms in comp bses sytems.
- Yijun Yu:Dynamic behaviour, how to generate intial configuration to affect quality attributes? How to support parallel development of components? Maintainability?
- Oliver: Main difference between Service. and Component bases systems
- Salah: Maintenance of software and software evolution? Defining arch. choice and find some rules that control the development so that bad decisions are reflected upon and caught?
- John : SOA, asynh. communications., how to deal with third party components, differnent systems built at differnt times - interested in integrations
- Alan: Adaptive systems, Distributed services and integration
- Rikard: How can older legacy systems can be matched to new techniques
- Laurens: Was involved in case studies with Rikard. How do you deal with compatibility particulary in comonent sense.
- Michelle: Web services, security, interaction with components?
- Frank: Components: a promising approach to software architecture, how can component models play a role in rearchitecting existing systems
- Ivica: What is the difference between SOA, and Comp. based approach.
- Some references:
- R. Sessions, "Fuzzy Boundaries: Objects, Components, and Web Services", ACM Queue, Dec/Jan 2004, pg. 40.
- W. Vogels, "Web Services are not distributed objects", IEEE Internet Computing, Nov/Dec 2003, and at http://weblogs.cs.cornell.edu/AllThingsDistributed/archives/2003_11.html
- K. Birman, "Like it or not, web services are distributed objects", CACM, Dec 2004, p. 60, and at http://www.cs.cornell.edu/Info/Projects/Spinglass/public_pdfs/Whither%20WS.pdf.
- Definitons vary - business driven to soft/computer science driven.
- Difference of concerns
- Service does not lend itself to easy architecture, decompostion, information hiding or decoupling.
- Does web-service lend to function decompostion well?
- Components do with implementation, services provide a service
- Services how do they integrate with components?
- Grouping of web-service to create new services or components.
- Services always related to distributed sytems (transpaent)
- WebService has been WSI standardized (e.g. follows SOA protocol).
- WebService's implication on software architecture: e.g. it constraints your solution. (in the same way perhaps the components do)
- Common concerns with components and the ideas that can be carried over.
- Binding mechanisms in components (different meaning the way it is used in software architecture and the way it is used in real-world)
- Some references:
Post-session Summary
- Exercise
- Participants pick two questions they consider most relevant to them.
Qestion - Requests:
1 - 0, 2 - 3, 3 - 2, 4 - 1, 5 - 2, 6 - 2, 7 - 0, 8 - 2, 9 - 3, 10 - 3
Picked for first discussion, 2, 9, 10 and 5-6
- Subquestions to 2
Salah: How can we redefine aspects of embedded systems to fit those of components?
AC: How do we include components with known functional and non-functional properties in embedded systems.
LB: Hoes does the component functinal overhead influence performance and predictability of embedded systems?
Iv: How can we ensure some properties with dynamically uploading components?
RL: How much dynamism can we allow while not loosing too much of predictability?
RL: How much dynamism(which types)can be implemented with acceptable runtime overhead?
Oliver:Could we use aspect oriented programming to separate functional and non-functional properties in case of embedded systems.
Did we need to be able to ad and remove dynamicaly non -functional services in case of RTES.
MH: define what princples of component-based systems are most desirable but missing in embedded systems What impact does the variay of platforms for mobile devices have and how components can be used in those ES?
FL: How to balance the flexibility of CBSE with the dependability in ERTS?
JM: How do we use CB principles in combination with existing approach that target NF aspect?
- Discussion
Tradeoffs - dynamism - predictability DAI faces similar problem in multi-agents. Similar in web-based-services; but in web-services it is more or less standardized. in multi-agent systems number of ways you can communicate is enormous and non-standardized.
Nowadays, overhead cost in hardware is more acceptable. so how is it very different from desktop environments? predictability is more important than efficiency.
Overhead of component tech. is not more, but people are not using it properly and blame goes to technology unjusfiably.
There are component models that are predictable.e.g. COM is quite predictable but the system it sits on is not so many a times.
What dynamism to use that allows good enough predictability? Start from something that is predictable and build more and more dynamism. This way it might be easier task.
How do take knowledge from other systems and extend them to embedded component systems? ... General quality aspects can be applied to ES. Given the constraint on resources we need to do that quality evaluation / tradeoff analysis. Other aspect is resusability.
What techniques in other dynamic system can be extended or applied here (e.g. in agent systems)? The openness of communication in e.g. say multi-agents, where the forces are combined a very unpreditable manner. Formalization of interaction protocols and goal-oriented approaches can provide the clue perhaps.
From experience of one (nuclear) dynamic system: Restricting the type of interaction or simplifying them. Sequence of component replacement to be planned ahead.
Replacment: continue the operation of old component until you are ready for smooth transition.
Putting test interface and monitoring interface in a component.
Self-management systems (e.g. from IBM research) View: autonomic systems are similar to multi-agent systems. system is hierarchically organized. [monitoring- ?- planning and execution]. How do you globally optimize?
If we need component systems that are employed on large systems then we need inputs from software engineering community.
- Discussion on relation between system and component properties
We want all dependencies to be known and we want to mantain black-box nature of component.
Statically it is difficult. But we can observe dynamic behaviour. Component models specify for a component - what is required and what it delivers(provided). Perhaps prohibiting certain behaviour would be a good thing, but would it decrease dynamisms.
One possible way it to list all interactions and then provide some sort of contracts. Component based representation might not be the right view for all kind of useful analysis. We also need to construct a view for analysis.
- Discussion on Component Binding
In software architecture, it means connecting one component to another and has one non-ambiguous meaning here. Binding in known component systems is used more in sense of picking up the requisite component. The use of term 'binding' is not very clear and not very often used. We perhaps use the term 'attach' more often. In component models it is much more permissive than that is allowed in architectural models.
Can we have run-time architectures?
What would be interesting is to look at extension of present component models like com to include the architectural elements. We may need serveral component models for different domains. Some commercial systems like COM have done a very good lower level jobs like component life-cycles.
Different postion: Basic concepts in component models are and should be same. Only extensions are required for different domains.
We mostly cannot start from a blank piece of paper. We have to take into account the component models avaialabe and that places some constraints on us to start with and hence cannot be ignored.
The discussion can only get more interesting...but we have to stop. It was great having you on board. Thank you!
- Vikram
Kindly feel free to edit and add to this document. It was great listening to your interesting ideas and discussions.
