Component frameworks Roy Kensmil

1. Component frameworks • Roy Kensmil

2. Historical trens in software development. ABSTRACT INTERACTIONS COMPONENT BUS COMPONENT GLUE THIRD-PARTY BINDING

3. ABSTRACT INTERACTIONS • defining interaction protocols • Specify these interactions in terms of • abstract interfaces, and implement components to communicate with each other through them.

4. COMPONENT BUS • Bind components to an information bus that manages the routing of information between • communicating components to remove explicit dependencies from the components themselves.

5. Glue Code • Create to act as an adapter for incompatible components, or as a mediator betweenpeers.

6. THIRD-PARTY BINDING • Remove connections established in the implementation of a component by having a third • component bind two interacting components together.

7. What is a component framework? • A component framework defines a set of abstract interactions that define protocols by which components communicate. • Is also defines the packiging for components so that they can be instantiated and composed into legal configurations by third-party binding.

8. Three most used types of component frameworks on the market today: • Second tire component framework • Contextual component framework • Visual component frameworks

9. Tiered component architectures • Hierarchal decomposition • Layering • Key terms • Component • Atomic Component • Module • Resource

10. Importance of Layers and hierarchal decomposition on today’s component system

11. Layers of components • Layers can contain components needed perform a certain service. • All the layers stacked on top of each other form an architecture.

12. Mastering complexity • Mastering the complexity of a layered architecture by adding the layered architecture on top of another layered architecture. • Meta-architecture

13. Layers and Tiers • A meta-architecture is forms a layer beneath the component architecture • In this case layers are called tiers • First tier is the component architecture • Second Tier is the meta-architecture (component framework)

14. Definition of a component framework • A component framework is a dedicated and focused architecture usually around a few key mechanisms, and a fixed set of policies for mechanisms at the component level.

15. Third Tier • The need for a third tier. (another meta-architecture) • A component framework can become an Island (can communicate only with instances of specified components)

16. Model a component framework as a component. • Can then be plugged into another architecture. • The third tier can enable these component framework to communicate

17. Contextual Component Frameworks • Component frameworks where components describe at runtime the properties component instances need to satisfy in order to execute properly

18. Power of contextual component frameworks • Elements declare their constraints on acceptable contexts but do not construct these contexts. • Composition assumes well-formed contexts minimizing the burden of describing and handling exceptional conditions. • Composites have certain properties by construction, as long as they have been formed using one of the valid components.

19. Usage of Contexts • Declarative attribution is used to achieve runtime construction and placement of object instances in the appropriate contexts. • Description of context requirement is done by associating attributes to components.

20. In COM this is done by registry entries per COM Class and in EJB by a XML document called the deployment descriptor.

21. COM+ • Apartments/Domains • Registries request at runtime if instance must be placed in a single or multithreaded apartment. • MTS added transactional context to COM+ classes.

22. EJB • Deployment Descriptor • It refers to the XML file that controls a J2EEEJB deployment. It tells the EJB server which classes make up the bean implementation, the home interface and the remote interface. If there is more than one EJB in the package, it indicates also how the EJBs interact with one another.

23. EJB uses the concept of containers. It's pattern is almost the same as that of MTS but classes can be given attributes so that their instances can explicitly call on transaction API to explicitly begin commit or abort a transaction by themselves. • Containers in EJB support persistent objects by distinguishing between session and entity beans. • In session beans state is lost once enclosing transaction terminates. • In entity beans is transferred to a persistent store if a transaction has committed.

24. Visual component frameworks (explained using the blackBox frame work) • How blackbox is composed: • Framework consist of a core set of layered models and open set of subsystems. • Each subsystem itself is a set of layered modules. • The component builder is the framework extended with a development subsystem. • The development subsystem contains (compilation, debugging, browsing and repository services) • left part are the standard programming interfaces and on the right are the optional interfaces.

25. Cornerstone of visual components: • -visual appearance • -interaction with their containing and contained components. • Views in blackbox provide visual presentation of data and can be context sensitive, active, and interactive. • Function as an anchor for arbitrary objects under the hood.

26. (MVC) • A view has a (separate) model. • A model represents and manages data a view can present. • A view is connected to a controller to enable a user to specify how the data must be represented. • MVC are modeled as persistent objects in blackbox. • Their state is stored as part of the containing document. • persistence is expected for models. • For views and controllers there are extra requirements for their persistence. • Eg. Each view can display models differently meaning that it's controller supports a different style. • A view can be set to display a specific part of a model. (Eg.)

27. Container Modes. • In traditional VCF the distinction is made between using preassembled component instances and the assembly of component instances. • In blackbox their is a unique concept to take advantage of the unification of build and use time. • Container modes. • Using a special editor containers on every level of a document can be set to different modes. • blackbox examples. • modes in blackbox can be set for each container in a document. • a programmer can fully determine degree of flexibility a user of a document has. • Rules blackbox enforces to stop misbehaving components from executing and displaying trash on screen or making document inconsistent: • 1) A model cannot send a message while another message sent by a model is still on it's way • 2)A view cannot send a message while another message sent by a view is still on it's way

28. Eg. • Scenario 1 • Solution: • Messages are allocated on the sender's stack frame and sent in natural recursive order (depth first). • But the framework can prohibit the sending with overlapping semantics. • Eg. • If a view tries to change a model while a change request is still in progress it will be delayed and registered • by the component framework and executed after a termination notification by the preceding message.

29. Cascaded message multicasting services. • In blackbox components do not need to be connected explicitly. • Connections can be made or maintained by frameworks. • Changes to components are done by message or event multicasting. • A problem in with this service is that messages can arrive out of order.

30. cascaded multicasting • For each of the three level a separate multicasting message mechanism with separate recursive barrier is implemented. • Send a controller message along a focused path. A view consuming this message (focus view) can then request a model change. • This change by a focus view to a model causes a message by a model to be multicast to all views using the model • Each view can then multicast a view message to the frame which display the data of a view.