Unit I Introduction

Unit I
H ok ma
Introduction
UNIT I
INTRODUCTION
Software Components $ ob(ects $ fundamental properties of Component technology $ modules $ interfaces $ callbac!s $ directory services $ component architecture $ components and middleware 1.1 INTRODUCTION Component Based Development claims to offer a radically new approach to the design, construction, implementation and evolution of software applications. Software applications are assembled from components from a variety of sources; the components themselves may be written in several different programming languages and run on several different platforms. A Component is an executable unit of functionality. ne can buy or download it, deploy it, and it wor!s. "t is a software blac! box, i.e. a binary unit of deployment. Components are Self#contained elements of software that can be assembled to form applications. Components may exist as either binary code or source code A software component is code that implements a set of well defined interfaces. "t is manageable, discrete chun! of logic. Components are not entire applications $ they cannot run alone. Components # program modules that are designed to interoperate with each other at runtime. A component is a unit of software that conforms to a component model and can be deployed and composed independently without modification according to a composition standard. Software entities interact with a component using the component%s clearly defined interfaces; an interaction standard defines the elements of the interface. "n computer programming, third party software component is a reusable software component developed to be either freely distributed or sold by an entity other than the original vendor of the development platform. &he third party software component mar!et thrives because component oriented development improves the efficiency and 'uality of developing custom applications.
IT1401 Component Based Technology
Dept. of IT/RMKEC
Unit I
Introduction
)icrosoft *isual Basic Spawned the first commercially viable mar!et for reusable software components. *isual Basic%s first extensibility mechanism was the specification for *isual Basic +xtensions, commonly !nown as ,custom controls,. "n version -.. of *isual Basic, the C/ 0 b(ect 1in!ing and +mbedding C/ was 0 1+2 Control +xtension2 custom control was introduced to replace *B/.
later renamed Active/ and then C ). "n version 3.. of *isual Basic, also !nown as *B.4+&, )icrosoft introduced the .4+& Component to replace both *B/ and Active/. "t was still possible to use many Active/ components in *B.4+& by wrapping them in a .4+& layer. An individual component is a software pac!age or a module that encapsulates a set of related functions 0or data2. All system processes are placed into separate components so that all of the data and functions inside each component are semantically related 0(ust as with the contents of classes2. Because of this principle, it is often said that components are modular and cohesive. 5ith regard to system#wide co#ordination, components communicate with each other via interfaces. 5hen a component offers services to the rest of the system, it adopts a provided interface which specifies the services that can be utili6ed by other components and how. &his interface can be seen as a signature of the component # the client does not need to !now about the inner wor!ings of the component 0implementation2 in order to ma!e use of it. 7owever when a component needs to use another component in order to function, it adopts a used interface which specifies the services that it needs. Another important attribute of components is that they are substitutable, so that a component can replace another 0at design time or run#time2, if the successor component meets the re'uirements of the initial component 0expressed via the interfaces2. Conse'uently, components can be replaced with either an updated version or an alternative for example, without brea!ing the system in which the component operates. As a general rule of thumb for engineers substituting components, component B can immediately replace component A, if component B provides at least what component A provided, and uses no more than what component A used.
IT1401 Component Based Technology 2 Dept. of IT/RMKEC
Unit I
Introduction
Software components often ta!e the form of ob(ects or collections of ob(ects 0from ob(ect#oriented programming2, in some binary or textual form, adhering to some interface description language 0"D12 so that the component may exist autonomously from other components in a computer. 5hen a component is to be accessed or shared across execution contexts or networ! lin!s, techni'ues such as seriali6ation or marshalling are often employed to deliver the component to its destination.
In the 89:.s, programmers built scientific subroutine libraries that were
reusable in a broad array of engineering and scientific applications. &hough these subroutine libraries reused well#defined algorithms in an effective manner, they had a limited domain of application. Commercial sites routinely created application programs from reusable modules written in Assembler, C B 1, ;1<8 and other second# and third#generation languages using both System and user application libraries. As of =.8., modern reusable components encapsulate both data structures and the algorithms that are applied to the data structures. "t builds on prior theories of software ob(ects, software architectures, software framewor!s and software design patterns, and the extensive theory of ob(ect#oriented programming and the ob(ect oriented design of all these. "t claims that software components, li!e the idea of hardware components, used for example in telecommunications, can ultimately be made interchangeable and reliable.
1.2 SOFTWARE COMPONENT >A software component is a physical pac!aging of executable software with a well#defined and published interface?# @rady Booch.
Unit I
Introduction
>A software component is a coherent pac!age of software artifacts that can be independently developed and delivered as a unit and that can be composed, to build a larger unit.? # Desmon DASou6a >A software component is a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition? # Councill and 7einmann..
A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties . defined by Clemens Szyperski. A piece of software offering 0via an interface2 a predefined service and which is able to communicate with other components. A component is an ob(ect having a graphical representation that can be displayed on the screen and that can interact with the user. Examples of soft a!e "ompo#e#ts Beusable software components can be simple li!e familiar push buttons, text fields list boxes, scrollbars, dialogs of a graphical user interface, calendar, etc,. 1.2.1 C$a!a"te!%st%" p!ope!t%es of a "ompo#e#t &he characteristic properties of a component are that itC is a unit of independent deployment is a unit of third#party composition has no 0externally2 observable state Impl%"at%o#s& o Dor a component to be independently deployable, it needs to be well separated from its environment and other components. A component, therefore,
Unit I
Introduction
encapsulates its constituent features. Also, as it is a unit of deployment, a component will never be deployed partially. o A third party cannot be expected to have access to the construction details of all the components involved. Dor a component to be composable with other components by such a third party, it needs to be sufficiently self-contained. Also, it needs to come with clear specifications of what it re'uires and provides. "n other words, a component needs to encapsulate its implementation and interact with its environment by means of well#defined interfaces. o A component should not have any 0externally2 observable state $ it is re'uired that the component cannot be distinguished from copies of its own in any given process 0or other loading context2, there will be at most one copy of a particular component. C!%te!%a fo! soft a!e "ompo#e#ts& (defined by Clemens Szyperski and David Messerschmitt) )ultiple#use EF parallel execution 4on#context#specific EF exchangeable Composable with other components +ncapsulated i.e., non#investigable through its interfaces A unit of independent deployment and versioning 1.2.2 Compo#e#t as a se!'%"e p!o'%(e! &he component is an independent, executable entity that can be made up of one or more executable ob(ects. "t does not have to be compiled before it is used with other components. &he services offered by a component are made available through an interface and is published. All component interactions ta!e place through that interface. Components provide a service without regard to where the component is executing or its programming language. Reusability is an important characteristic of a high#'uality software component. A software component should be designed and implemented so that it can
Unit I
Introduction
be reused in many different programs. "t ta!es significant effort and awareness to write a software component that is effectively reusable. &he component needs to beC fully documented thoroughly tested robust # with comprehensive input#validity chec!ing able to pass bac! appropriate error messages or return codes designed with an awareness that it will be put to unforeseen uses Reaso#s to )se Compo#e#ts @rowing number of 0freely2 available libraries and programs worth to be re#used +xchangeable software units Support of distributed parallel run time systems Avoids lin!age of may be incompatible libraries 1onger lifetime of implementations 1.* O+,ECTS &he notions of instantiation, identity, and encapsulation lead to the notion of ob(ects. "n contrast to the properties characteri6ing components, the characteristic properties of an ob(ect are that itC is a unit of instantiation, it has a uni'ue identity; may have state and this can be externally observable; +ncapsulates its state and behavior. Impl%"at%o#s&
o Because an ob(ect is a unit of instantiation, it cannot be partially instantiated.
Since an ob(ect has individual state, it also has a uni'ue identity that suffices to identify the ob(ect despite state changes for its entire lifetime. Consider the apocryphal story about @eorge 5ashingtonAs axe. "t had five new handles and four new axe heads, but was still @eorge 5ashingtonAs axe. &his is a good example of a real life ob(ect of which nothing but its abstract identity remained stable over time.
Unit I
Introduction
o As ob(ects are instantiated, there needs to be a construction plan that describes the state space, initial state, and behavior of a new ob(ect. Also, that plan needs to exist before the ob(ect can come into existence. Such a plan may be explicitly available and is then called a class. Alternatively, it may be implicitly available in the form of an ob(ect that already exists $ that is, sufficiently close to the ob(ect to be created, and can be cloned. Such a pre#existing ob(ect is called a prototype object 01ieberman, 89G:; Hngar and Smith, 89G3; Blasche!, 899-2. o 5hether using classes or prototype ob(ects, the newly instantiated ob(ect needs to be set to an initial state. &he initial state needs to be a valid state of the constructed ob(ect, but it may also depend on parameters specified by the client as!ing for the new ob(ect. &he code re'uired to control ob(ect creation and initiali6ation can be a static procedure $ usually called a constructor if it is part of the ob(ectAs class. Alternatively, it can be an ob(ect of its own $ usually called a factory object, or factory for short if it is dedicated to this purpose. )ethods on ob(ects that return freshly created other ob(ects are another variation $ usually called factory methods. 1.*.1 Compo#e#ts a#( o-.e"ts bviously, a component is li!ely to act through ob(ects and therefore would normally consist of one or more classes or immutable prototype ob(ects. An ob(ect is considered immutable if its state cannot change after it is constructed. "n addition, it might contain a set of immutable ob(ects that capture default initial state and other component resources. 7owever, there is no need for a component to contain classes only, or even to contain classes at all. "nstead, a component could contain traditional procedures and even have global 0static2 variables 0as long as the resulting state remains unobservable2, or it may be reali6ed in its entirety using a functional programming approach, or using assembly language, or any other approach. b(ects created in a component $ more precisely, references to such ob(ects $ can leave the component and become visible to the componentAs clients, usually other components. "f only ob(ects become visible to clients, there is no way to tell whether or not a component is >all ob(ect#oriented? inside.
Unit I
Introduction
The difference bet een state maintained by !b"ects created by a c!mp!nent and state maintained by a c!mp!nent#
State maintained by an ob(ect is abstracted by that ob(ectAs reference. A component that does not maintain observable state cannot 0observably2 maintain references even to the ob(ects it created. A reference to the component itself 0the componentAs fully 'ualified name2 cannot be used to retrieve any ob(ects. "nterestingly, this property can be achieved in a non#ob(ect#oriented setting. A functional component can create closures and a procedural component can maintain tables of stateful records that are only manipulated in table indices, which themselves are not !ept by the component. 5hether or not any such state 0in ob(ects, closures, or tables2 is persistent across component activations is a separate 'uestion, the correct answer to which depends on the intended use of a particular component. A component may contain multiple classes, but a class is necessarily confined to being part of a single component. ;artial deployment of a class would not normally ma!e sense. f course, (ust as classes can depend on other classes using inheritance, components can depend on other components $ this is an import relation. &he superclasses of a class do not necessarily need to reside in the same component as the class itself. 5here a class has a superclass in another component, the inheritance relation between these two classes crosses component boundaries, forcing a corresponding import relationship between the two underlying components. "nheritance of specifications is an essential techni'ue for establishing correctness, as, by referring to the same specification, two components establish a common basis.
D%ffe!e#"e -et ee# "ompo#e#t a#( o-.e"t& b(ects focus on conceptual entities whereas components are based on more physical things. b(ect describes real world entities, whereas Component describes services of real world entities.
Unit I
Introduction
b(ects and components are both language dependent and separate interface from implementation, but components depend on context too.
Components are more pragmatic and impose a less rigorous discipline on the developer. b(ects were typically smaller than components b(ects wor!ed within the boundaries of one programming language rather than several. Components could include their own metadata while ob(ects relied on separate metadata. b(ects stated what they provided in their specification whereas components also had to specify the services that they re'uired in order to wor!. 1./ FUNDAMENTA0 PROPERTIES OF COMPONENET TECHNO0O12 i) Technological feasibility +stablishing component mar!ets rests on technological feasibility. Although many of the re'uired !ey technologies are finally available, a solid overall understanding of component software is still lac!ing. &here are several deep technical issues that need to be addressed before mission#critical systems can responsibly be built on component technology. ii) Integration and Testing Components come from independent sources and are integrated by third parties. "n the absence of countermeasures, a component system is only as strong as its wea!est component. Dault isolation is thus an essential theme, as is safety of individual components. "n traditional software engineering processes, module development and testing is followed by systems integration and testing. &his approach leaves room for errors that are merely a result of composition and which are not apparent at the level of individual components, but which should be detected during systems integration and testing. 5ith third#party integration, the situation becomes
Unit I
Introduction
more difficult, as integration testing of modules from different sources needs to be addressed. ;art of the potential of software components $ and a reason for the failure of the "C analogy $ is the possibility of late integration. Iava applets are an example of the extreme !ind, as, until a web page is re'uested by a browser, the applet code will not be integrated into the re'uesting browser. 5hen late integration is used, integration testing is no longer feasible. Dor most integration tests, a negative result would come too late in the process as the components will have already been ac'uired and deployed. *ersion chec!s are among the few tests that are useful and essential at the stage of late integration. A load#time complaint about incompatible versions of locally available components is a reasonable diagnosis. +ven if late sanity chec!s are performed, they can at most come to the rescue of the user, but cannot directly help to improve the 'uality of the components involved. A component vendor faces a combinatorial explosion of possible system configurations against which to test a component. "n an open mar!et of independent component developers, the set of possible combinations is not even !nown to any one of the involved parties. Durthermore, the number of combinations continues to grow even after deployment of a system, as new components can be integrated as they become available. "nstead of full integration testing, testing against a few possible configurations is the best that can be done. )ore fundamentally, components need to be built in ways that allow for modular chec!ing $ that is, the analysis of component properties based only on the component and the interfaces it builds on. &herefore, component vendors need to strengthen the per component process. "n many cases, this re'uires conservative engineering 0defensive programming2. iii) afety measurements &he notion of component safety is important as, even if a component fails to function, it must not violate system#wide rules. Safety is the foremost reason to discriminate among otherwise e'ual methods of component construction.
IT1401 Component Based Technology 10
ne of the
critical decisions to be made is the proper choice of programming languages and tools.
Dept. of IT/RMKEC
Unit I
Introduction
"f a language and its implementation guarantee important safety properties, proof obligations can be ta!en off developers and costly safeguarding runtime measures can be eliminated. Software development processes that do not depend on testing naturally gain importance, though they have yet to ma!e significant inroads into the practice of software development. iv) !unctionality and performance nce safety properties are in place, functionality and performance have to follow. Broad classes of safety re'uirements can be covered by the choice of methodology and tools. &here is no such magic bullet to achieve functionality, and the effects of independent composition on overall functionality are not fully understood. Conservatism again seems to be the only advisable strategy. Dor example, b(ect )anagement @roup 0 )@2 recommends mixing and matching its various ob(ect services, claiming orthogonality and interoperability. Although these services were designed with this goal in mind, studies show that actual mixing is not easy and, in some situations, even impossible. +ven where functionality and safety are firmly in place, performance remains a formidable problem. ;erformance of a component system is affected in nontrivial ways by the actual composition. ;erformance is primarily addressing the 'uestion >"s it fast enoughJ? 7owever, problems of economical resource utili6ation are closely related, including demands for processing capacity, primary and secondary storage, or networ! bandwidth.
1.3 MODU0ES Components are rather close to modules, as introduced by modular languages #)odula#= and Ada. "n Ada, modules are called pac!ages, but the concepts are almost identical. An important hallmar! of truly modular approaches is the support of separate compilation, including the ability to type chec! across module boundaries properly. 5ith the introduction of the language +iffel, it was claimed that a class is a
Unit I
Introduction
better module. &his seemed to be (ustified, based on the early ideas that modules would each implement one abstract data type 0AD&2. After all, a class can be seen as implementing an AD&, with the additional properties of inheritance and polymorphism. 7owever, modules can be used to pac!age multiple entities, such as AD&s or, indeed, classes, into one unit. Also, modules do not have a concept of instantiation, whereas classes do. 0"n module#less languages, this fre'uently leads to the introduction of >static? classes that essentially serve as simple modules.2 "n more recent language designs $ such as beron, )odula# K, Component ;ascal, and CL $ the notions of modules 0or assemblies in CL2 and classes are !ept separate. "n all cases, a module can contain multiple classes. 0"n languages such as Iava that do not have a separate module concept, modules can be emulated to a degree by using nested classes.2 5here classes inherit from each other, they can do so across module boundaries. As an aside, it should be mentioned that in Smalltal! systems, it was traditionally acceptable to modify existing classes to build an application. Hnli!e classes, modules can indeed be used to form minimal components. +ven modules that do not contain any classes can function as components. A good example is traditional math libraries that can be pac!aged into modules and are of a functional rather than ob(ect#oriented nature. 4evertheless, one aspect of fully#fledged components is not normally supported by module concepts. &here are no persistent immutable resources that come with a module, beyond what has been hardwired as constants in the code. Besources parameteri6e a component. Beplacing these resources allows the component to be configured without the need to rebuild its code. Dor example, resource configuration can be used for locali6ation. &he configuration of resources seems to assign mutable state to a component. 7owever, as components are not supposed to modify their own resources, resources fall into the same category as the compiled code that also forms part of a component. "ndeed, it is useful to regard a locali6ed version of a component as a different 0but related2 component. &rac!ing the relationship between a component and its derived locali6ed versions is similar to trac!ing the relationship between different release versions of a component.
Unit I
Introduction
"t is instructive to explore cases where modules do not 'ualify as components. Hnder the definition used here, components do not permit observable state, while modules can clearly be built to use global 0static2 variables to expose observable state. Durthermore, modules tend to depend statically on implementations in other modules by importing direct interfaces from other modules. Dor components, such static dependencies on component#external implementations are allowed but not recommended. Static dependencies should be limited to contractual elements, including types and constants. Dependencies on implementations should be relegated to the ob(ect level by preferring indirect over direct interfaces in module dependencies to enable flexible compositions using multiple implementations of the same interface. &o summari6e, modularity is a prere'uisite for component technology, but rules beyond the traditional modularity criteria are needed to form components rather than (ust modules. )any modularity criteria go bac! to ;arnas 0893=2 and include the principle of maximi6ing cohesion of modules while minimi6ing dependencies between modules. )odularity is thus certainly not a new concept. Hnfortunately, the vast ma(ority of software solutions today are not even modular. Dor example, it is common practice for huge enterprise solutions to operate on a single database, allowing any part of the system to depend on any part of the data model. Adopting component technology re'uires adoption of principles of independence and controlled explicit dependencies. Component technology unavoidably leads to modular solutions. &he software engineering benefits can be sufficient to (ustify initial investment into component technology, even when component mar!ets are not foreseen in the mid#term. 1.4 INTERFACES "nterface of a component can be defined as the componentAs access points. &hese points allow clients of a component, usually components themselves, to access the services provided by the component. 4ormally, a component will have multiple interfaces corresponding to different access points. +ach access point may provide a different service, catering for different client needs. +mphasi6ing the contractual
Unit I
Introduction
nature of the interface specifications is important because the component and its clients are developed in mutual ignorance, so it is the contract that forms a common middle ground for successful interaction. &o be successful, interfaces have to obey the following non#technical aspectsC 8. &he economy of scale has to be !ept in mind. A component can have multiple interfaces, each representing a service that the component offers. Some of the offered services may be less popular than others, but if none is popular and the particular combination of offered services is not popular either, the component has no mar!et. "n such a case, the overheads involved in casting the particular solutions into a component form may not be (ustified. 4otice, however, that individual adaptations of component systems may well lead to the development of components that themselves have no mar!et. "n this situation, extensions to the component system should build on what the system provides, and the easiest way of achieving this may well be the development of the extension in component form. "n this case, the economic argument applies indirectly in that the extending component itself is not viable, but the resulting combination with the extended component system is. =. Second, undue fragmentation of the mar"et has to be avoided as it threatens the viability of components. Bedundant introductions of similar interfaces have thus to be minimi6ed. "n a mar!et economy, such a minimi6ation is usually the result of either early standardi6ation efforts among the main players in a mar!et segment or fierce eliminating competition. "n the former case, the danger is sub optimality due to >committee design? and, in the latter case, it is sub optimality due to the non#technical nature of mar!et forces. K. &hird, to maximi#e the reach of an interface specification and components implementing this interface, there need to be common media to publici#e and advertise interfaces and components. "f nothing else, this re'uires a small number of widely accepted uni'ue naming schemes. Iust as "SB4 0"nternational Standard Boo! 4umber2 is a worldwide and uni'ue naming scheme to identify any published boo!, a similar scheme is needed to refer abstractly to interfaces >by name.? Iust as with an "SB4, an interface identifier
Unit I
Introduction
is not re'uired to carry any meaning. An "SB4 consists of a country code, a publisher code, a publisher#assigned serial number, and a chec!ing digit. Although it reveals the boo!As publisher, it does not code the boo!As contents. )eaning may be hinted at by the boo!As title, but titles are not guaranteed to be uni'ue. An interesting variation on the theme of interface standardi6ation is the standardi6ation of message formats, schemas and protocols. "nstead of formali6ing interfaces as collections of parametric operations, the focus is on what is passed bac! and forth. &his viewpoint is sometimes described as the >viewpoint of the wire? or as >wire formats,? alluding to the importance of standardi6ing message schemas, formats, and protocols when interconnecting machines in a networ!. Standardi6ation of message formats, schemas and protocols is indeed the main approach of "nternet 0";, HD;, &C;, S4);, and so on2 and web 07&&;, 7&)1, and so on2 standards. &o achieve broader semantic coverage, it is useful to standardi6e message schemas in the context of a single generic message format. &his is the rationale behind /)1, a single generic format, the large number of related standards 0including S A; MSimple b(ect Access ;rotocolN and several /)1 web services standards2, and the growing number of /)1 schema standardi6ation efforts.
Requires interface
Defines the services from the components environment that it uses
Provides interface
Defines the services that are provided by the component to other component
Component
$xport interface% &rovides interface An interface that defines the services provided by the component to other components. A component may provide many export interfaces. Import interfaces
Unit I
Introduction
An interface that the component conforms to build on. "t defines the services that must be made available for the component to execute as specified. 1.4.1 Compo#e#ts a#( %#te!fa"es "nterfaces are the means by which components connect. &echnically, an interface is a set of named operations that can be invo!ed by clients. +ach operationAs semantics is specified, and this specification plays a dual role as it serves both providers implementing the interface and clients using the interface. As, in a component setting, providers and clients are ignorant of each other, the specification of the interface becomes the mediating middle that lets the two parties wor! together. "t is therefore important to view interfaces and their specifications in isolation of any specific component that may implement or use such interfaces. A component may either directly provide an interface or implement ob(ects that, if made available to clients, provide interfaces. "nterfaces directly provided by a component correspond to procedural interfaces of traditional libraries. &here can be interfaces provided indirectly by ob(ects that are made available by the component. Such indirectly implemented interfaces correspond to ob(ect interfaces. Components can be specified separate from interfaces and their specifications. A component specification names all interfaces that a component should adhere to and adds component#specific properties. "t is also possible to focus on the interaction between components using certain interfaces. &his is done by writing specifications that constrain data flows through a given set of interfaces. 1.4.2 D%!e"t a#( %#(%!e"t %#te!fa"es 'irect (procedural) and indirect (object) interfaces can be unified into a single concept. +ssentially, the idea is to use static ob(ects that can be part of a component. A procedural interface to a component is modeled as an ob(ect interface of a static ob(ect within the component. )ost component implementations can be made to have their interfaces loo! li!e ob(ect interfaces. &his is the traditional >wor!around? of pure ob(ect#oriented languages, including Iava. )odeling all component interfaces as ob(ect interfaces, in which a single component may provide multiple ob(ect interfaces, helps simplify the grounds for
Unit I
Introduction
discussion of semantics. 7owever, it is important to remember the conse'uences of using a true ob(ect interface rather than a procedural interface. An !b"ect interface introduces an indirection called method dispatch or, sometimes, dynamic method loo"up. Dor a given ob(ect, its class determines the implementation of its interface. At runtime, a method invocation is resolved by retrieving the target ob(ectAs class and directing the call to the method implementation in that class. )ethod dispatch can lead to the involvement of a third party. "n particular, it can involve a third party of which both the calling client and the interface#introducing component are unaware. &his is the case when the ob(ect implementing an interface belongs to a component different from the component with which the client seems to interact through the interface. &raditional procedural interfaces are always direct as the definition of the procedural interface and its implementation belong to the same component. f course, explicit procedural indirection is possible by means of procedure variables 0also called function pointers2. An example will ma!e these things clearer. Consider a component &extServices that offers an interface "Chec!@rammar. &extServices also offers a mediator that can be used to select a default grammar chec!er. A default grammar chec!er is selected by passing an ob(ect that implements the "Chec!@rammar interface to the &extServices mediator. &his installed third#party chec!er may then be used by other services implemented in &extServices, but also indirectly by clients of &extServices. 7ence, a client that as!s for a grammar chec!er might get one that is implemented outside &extServices. &his is possible even though the client may only !now about &extServices and &extServices itself may !now nothing about the actual implementer of the grammar chec!er.
17
Dept. of IT/RMKEC
Unit I
Introduction
F%5)!e 1.1 Example of (%!e"t a#( %#(%!e"t %#te!fa"es.
Digure 8.8 illustrates this scenario, the numbers indicating in which order ob(ects are ac'uired. 82 &he grammar chec!er !nows about the text service mediator. =2 &he grammar chec!er registered itself as the default chec!er with the mediator $ the mediator !nows only about the abstract chec!er interface. K2 &he word processor !nows about the mediator. -2 &he word processor ac'uires a reference to the current default chec!er from the mediator $ (ust as the mediator, the word processor, !nows only the abstract chec!er interface. &he effective coupling of two dynamically selected parties via a well#defined interface is a powerful concept called late binding and is right at the heart of ob(ect# oriented programming. "n a component system, the situation is the same but the proper wor!ing of the resulting dynamic configurations is harder to control. 5ith components, not only are the two connected parties unaware of each other, but also it is li!ely that even the designers do not !now each other. &hus, it is only the 'uality of the interface specification that holds things together. 1.4.* I#te!fa"e as "o#t!a"ts "nterface specifications can be viewed as contracts between a client of an interface and a provider of an implementation of the interface. &he contract states,
Unit I
Introduction
Client C $eeds t! d! t! %se the interface. ;rovider C &as t! implement t! meet the services pr!mised by the interface . &he contract also specifies pre#condition and post#condition for the operation. &re-condition C +stablished by client before calling an operation. &ost-condition C Set by provider before returning to the client. 1.4./ 6e!s%o#s "n a component world, versions of components can be prolific. Dor example, many vendors may provide various >upwards#compatible,? enhanced versions of a successful component. &raditional version management $ often based on the assignment of ma(or and minor version numbers $ assumes that the versions of a component evolve at a single source. "n a free mar!et, the evolution of versions is more complex and management of version numbers can become a problem in its own right. A subtle aspect of versioning arises when moving from direct to indirect interfaces $ that is, to ob(ect interfaces. 5ith direct interfaces it suffices to chec! versions at bind time, which is when a service is first re'uested. "ndirect interfaces couple arbitrary third parties. "n a versioned system, care must be ta!en to avoid indirect coupling of parties that are of incompatible versions. Dor example, a client originally re'uesting a service may be capable of wor!ing with version 8 of that service. nce it holds an ob(ect reference, it may pass the reference on to another component. 7owever, the latter component might re'uire version = of the service. Hnless versions are chec!ed in every place where an ob(ect reference crosses component boundaries, version chec!ing is not sound. &he goal is to ensure that older and newer components are either compatible or clearly detected as incompatible. ne possible approach is to insist on immutable interface specifications. "nstead of trying to maintain the complex compatibility relationship among various versions of interfaces, each interface, once published, is fro6en and never changed again. Supporting multiple versions is then e'uivalent to supporting multiple interfaces. An outdated interface is simply no longer supported. ;assing a reference of a particular interface version to other components is not a problem. &he receiving
Unit I
Introduction
component either accepts the reference because it can handle this particular interface or it expects a different version and thus a different interface and then it will not accept the reference. )sing immutable interfaces is essentially the *+, (*omponent +bject ,odel) approach. A more refined, but also more complex, approach is to allow mutation of definitions from one version to the next. Bules need to define precisely what changes are valid to retain bac!wards compatibility. 5here such compatibility cannot be maintained, relevant parts of a definition should be deprecated. &his way, outdated clients of such a definition can be isolated by analy6ing their dependencies against what is provided. "n general, interfaces and components can be used >side#by#side? $ that is, multiple versions of a component can be loaded and instantiated in the same space. "t is useful to distinguish components that should be used in the latest version from components that should always be used in the version that some client was built and tested against. So, 'istinguishing components is essentially the *-R (*ommon -anguage Runtime) approach.
1.7 CA00+AC8 A callbac" is a reference to executable code, or a piece of executable code, that is passed as an argument to other code. &his allows a lower#level software layer to call a subroutine 0or function2 defined in a higher#level layer. A callbac! is a procedure that is passed to a library at one point, and the callbac! is said to be registered with the library. At some later point, the library then calls the callbac!. Digure 8.= illustrates the call graph as it occurs in a system using callbac!s. "n a layered architecture, normal calls always originate in higher, more abstract, layers and then stay in their layer or move downwards.
Unit I
Introduction
F%5)!e 1.2 Call se9)e#"e -et ee# l%-!a!: a#( "l%e#t %# t$e p!ese#"e of "all-a"ks.
A callbac! usually reverses the direction of the flow of control, so a lower layer calls a procedure in a higher layer. Dor this reason, callbac! invocations are sometimes called upcalls. Callbac!s are a common feature in procedural libraries that have to handle asynchronous events. Dor example, some windowing libraries use a callbac! to notify a particular windowAs client code when the user resi6ed the window. Alternatively, the client could poll the library for events continuously, a model that is also 'uite common. 'hat is s! special ab!%t callback pr!ced%res( "n a strict procedural library model, it is always the client calling the library. &he libraryAs operations always run to completion before returning control. &hus, the client never observes any intermediate states that the library might go through. &he only relevant library states, as far as the client is concerned, are those (ust before and (ust after a call to the library. 5hile the library procedure proceeds, the clientAs state does not change. As the client has full control over its own state when calling a library procedure, the library call can be understood simply from the clientAs state (ust before the call and the library procedureAs pre# and post# conditions. "n the presence of callbac!s, the situation changes. &he intermediate library state at the point of calling the callbac! may be revealed to clients. A library thus has to be careful to establish a >valid? state, as far as observable by the client, before invo!ing any callbac!s. Durthermore, a callbac! may cause the libraryAs state to
Unit I
Introduction
change through direct or indirect calls to the library. 7ence, the observable state of the library has to remain >valid? for as long as any callbac!s are active. "n Digure 8.=, this critical region in the library has been mar!ed. *alidity of the library state is again specified as part of a contract. &he library defines the callbac! interface. 7ence, the contract comes with the library and specifies what a callbac! can expect and, to a lesser extent, what it has to do. ;rocedural code can generally observe state and state changes. A library can ma!e part of its state observable by exporting variables or inspection functions. A libraryAs client can thus observe the relative order in which callbac!s are performed and in which the observable library state is changed. 7owever, such ordering is not specified by normal pre# and post#conditions, is not part of a normal procedural contract, and is therefore implementation dependent. A callbac! procedureAs role is all about state and state change. )ost non#empty callbac!s 'uery the library and the client for further information $ that is, observe more state, before ta!ing appropriate action.
1.; DIRECTOR2 SER6ICES A directory service is simply the software system that stores, organi6es and provides access to information in a directory. "t allows the loo!up of values given a name, similar to a dictionary. Directories may be very narrow in scope, supporting only a small set of node types and data types, or they may be very broad, supporting an arbitrary or extensible set of types. "n a telephone directory, the nodes are names and the data items are telephone numbers. Consider a system that provides a basic directory service as part of a simple file system. &he directory service supports callbac!s to notify clients of changes in the
Unit I
Introduction
managed directory. Such a notification service is useful, for instance, to !eep a visual representation of the directory up to date. Although this is only an example, it already represents an advance on the status 'uo of most current systems. &he notification mechanism is exactly what would be needed to implement a file#and#folder metaphor on top of a file system in a reasonable way. &he example is s!etched in Component ;ascal notation.
&he simple directory service interface is grouped into two parts.
&he first part supports file loo!up and addition or removal of named files, modeling a single flat directory for the sa!e of simplicity. &he second part supports registration and unregistration of callbac!s.
Begistered callbac!s are invo!ed on addition or removal of a name. +ach operation of the interface is specified using simple pre# and post#conditions. State that is observable through a given interface but which is not mentioned in a post#condition is guaranteed to remain unchanged.
23
Dept. of IT/RMKEC
Unit I
Introduction
&o be useful in practice, this convention needs to be modified. "t is often ambiguous as to which variables may change to establish a post#condition. Also, insisting that unmentioned variables remain unchanged can be too sharp. A common approach to resolving these issues is to introduce model variables $ also called specificati!n variables $ that capture the abstract state relevant to a specification fragment. &hen, pre# and post#conditions on operations are augmented by modifies clauses. A modifies clause simply states which model variables may be changed by an implementation of the so#specified operation. 1.;.1 A "l%e#t of t$e (%!e"to!: se!'%"e 4ow consider a simple client that uses directory callbac!s to maintain some visual display of the directoryAs contents.
MODULE DirectoryDisplay; ( most details deleted ! IM"O#$ Directory; "#OCEDU#E %otifier (I% n& Directory'%ame!; (E)I% I* Directory'$his*ile(n! + %IL $,E% ( entry under name n has been removed delete n in display ! EL-E ( entry has been added under name n include n in display ! E%D E%D %otifier; (E)I% Directory'#e.ister%otifier(%otifier! E%D DirectoryDisplay'
&he clientAs callbac! procedure involves first chec!ing with the directory service to find out what change happened to the entry under the given name. A callbac! recursively invo!es operations on the calling service. Dor example, on redefinition of an entry, is the notifier called at all, called once, or called twiceJ 4ot calling the notifier would be (ustified because the list of registered names did not change. ne call would reflect the fact that the binding of the
Unit I
Introduction
name has changed. &wo calls would correspond to the implicit removal of the old entry, followed by the addition of the new entry. &he design of the notifier with (ust the name as a parameter forces any useful callbac! to en'uire for further information from the directory. 7ence, the only sensible thing to do is call the notifier in implementations of Add+ntry and Bemove+ntry (ust before returning. Although in a sense obvious, this really ought to be added to the contract. Again, it is li!ely that such a clause would form part of the informal conditions in a contract. 1.;.2 Same "l%e#t< Next !elease "n a next stage, consider a variation of DirectoryDisplay that, on screen, uses a pseudo name >Hntitled.? &his name is used for anonymous files that have not been registered with the directory, but have been announced to the display service. &he assumption is that no registered file will ever be called >Hntitled.? bviously, users would be confused if the directory ever contained an entry for a file named >Hntitled.? Assume that the implementer of DirectoryDisplay had a brilliant idea. 5hy not remove such an entry from the directory again as soon as the notification call arrivesJ
MODULE DirectoryDisplay; (* Version 1 ! 1 *" #M$O%& Directory; $%O'EDU%E (oti)ier (#( n* Directory (ame"; +E,#( #- Directory &his-ile(n" . (#L &/E( (* entry under name n has been removed delete n in display *" EL0E #- n . 1Untitled2 &/E( (* oops you shouldn3t do that Directory %emoveEntry(n" (* EL0E (* entry has been added under name n include n in display *" E(D E(D E(D (oti)ier; +E,#( Directory %e4ister((oti)ier" E(D DirectoryDisplay *" 4otcha5 *"
25
Dept. of IT/RMKEC
Unit I
Introduction
Digure 8.K shows the flow of control in detail as it occurs when a client tries to insert a file named >Hntitled? into a directory $ an attempt undercut by the display notifier. &he notifier is actually called recursively as a conse'uence of removing the entry from within the first notifier call.
F%5)!e 1.* Call se9)e#"e -et ee# a "l%e#t< t$e (%!e"to!:< a#( t$e (%!e"to!: (%spla: = 'e!s%o# 1.>.1.
"t is li!ely that this subtle interaction as!ed for some serious debugging. Dor example, a first attempt 0version 8...8#alpha2 might have been to catch and delete >Hntitled? first thing in the notifier $ that is, even before chec!ing that the entry has actually been added rather than removed. *ersion 8...8#alpha terminated abnormally, reporting a stac! overflow during a test insertion of an entry >Hntitled.? 1.? COMPONENT ARCHITECTURE System architecture is the pivotal basis of any large#scale software technology and is of utmost importance for component based system. &he benefits of component architecture are, i. ii. "nteraction between components and their environment is regulated. &he roles of the components are defined.
26 Dept. of IT/RMKEC
Unit I
Introduction
iii. iv.
&ool interfaces are standardi6ed. Hser interface aspects both for end users and for assemblers are regulari6ed.
1.?.1 Roles of a# A!"$%te"t)!e An architecture is needed when as!ing for guidelines and rules for complex system design and implementation. An architecture needs to create simultaneously the basis for independence and cooperation. "ndependence of system is re'uired to enable multiple sources of solution parts. Architecture is about a holistic view of the system, often one that is yet to be developed. Architecture defines the properties that characteri6e any system built following this particular architecture. +xampleC perating system. An operating system partilally defines the architecture for overall system resources resting on it by defineing how in dependent processes compete for resources. An architecture prescribes proper framewor!s for all involved mechanisms, limiting the degree of freedom to curb variations and enable cooperation. An architecture includes all policy decisions re'uired to enable interoperation across independent uses of the mechanisms, ;olicy decisions includes the roles of the component. An architecture needs to be based on the principal considerations of overall functionality, performance, reliability and security. 1.?.2 8e: Te!ms %# Compo#e#t A!"$%te"t)!e ) c!mp!nent system architect%re c!nsists !f a set !f platf!rm decisi!ns* a set !f c!mp!nent frame !rks* and an inter!perati!n desi+n f!r the c!mp!nent frame !rks. A platform is the substrate that allows for installation of components and component framewor!s, such that these can be instantiated and activated. A platform can be concrete or virtual. *oncrete platforms provide direct physical support $ that is, implement their services in hardware.
Unit I
Introduction
.irtual platforms $ also called platform abstractions or platform shields $ emulate a platform on top of another, introducing a cost$flexibility tradeoff. ) c!mp!nent frame !rk is a dedicated and f!c%sed architect%re* %s%ally ar!%nd a fe key mechanisms* and a fi,ed set !f p!licies f!r mechanisms at the c!mp!nent level. Component framewor!s often implement protocols to connect participating components and enforce some of the policies set by the framewor!. &he policies governing the use of the mechanisms that are used by the framewor! itself are not necessarily fixed. "nstead, they can be left to higher#level architecture. )n inter!perati!n desi+n f!r c!mp!nent frame !rks c!mprises the r%les !f inter!perati!n am!n+ all the frame !rks "!ined by the system architect%re. Such a design can be seen as a second#order component framewor!, with the 0first#order2 component framewor!s as its plugin 0second#order2 components. "t is 'uite clearly established by now that this second level is re'uired $ a single# component framewor! for everything is illusory. "t is less clear if a third or even higher level will be needed, but the meta#architecture model hinted at here is scalable, allowing for growth. ) c!mp!nent is a set !f n!rmally sim%ltane!%sly depl!yed at!mic c!mp!nents. &his distinction between components and atomic components caters for the fact that most atomic components will never be deployed individually, although they could. "nstead, most atomic components belong to a family of components and a typical deployment will cover the entire family. )n at!mic c!mp!nent is a m!d%le and a set !f res!%rces. Atomic components are the elementary units of deployment, versioning and replacement. Although usually deployed in groups, individual deployment is possible. A module is thus an atomic component with no separate resources. 0Iava pac!ages are not modules in this strict sense $ the atomic units of deployment in Iava are class files. A single pac!age is compiled into many class files $ one per public class.2
Unit I
Introduction
) m!d%le is a set !f classes and p!ssibly n!n-!b"ect-!riented c!nstr%cts* s%ch as pr!ced%res !r f%ncti!ns. bviously, a module may statically re'uire the presence of other modules to function. 7ence, a module can only be deployed if all modules that it depends on are also available. ) res!%rce is a fr!zen c!llecti!n !f typed items. &he resource concept could include code resources to subsume modules. &he point is that there are resources besides those generated by a compiler compiling a module or pac!age. "n a >pure ob(ects? approach, resources are externali6ed immutable ob(ects $ immutable because components have no persistent identity and duplicates cannot be distinguished 0component instances have identity, of course2. ) C!mm!n C!mp!nent )rchitect%re is a c!mp!nent architect%re definin+ standards necessary f!r the inter!perati!n !f c!mp!nents devel!ped in the c!nte,t !f different frame !rks.
1.?.1 A t%e!e( "ompo#e#t a!"$%te"t)!e A fundamental notion of traditional software architectures is that of layers. 1ayers and hierarchical decomposition remain very useful in component systems. +ach part of a component system, including the components themselves, can be layered, as components may be located within particular layers of a larger architecture. &o master the complexity of larger component systems, the architecture itself needs to be layered. "t is important to distinguish clearly between the layers formed by architecture and those formed by a meta#architecture. &he layers formed by a meta#architecture are thus called tiers. )ulti tier client$server applications are an example of tiered architecture. 7owever, the tiers proposed in the following differ from the tiers found in client$ server architecture. Component system architecture arranges an open set of
Unit I
Introduction
component framewor!s. &his is a second-tier architecture, in which each of the component framewor!s introduces a first#tier architecture. "t is important to notice the radical difference between tiers and traditional layers. T!a(%t%o#al 0a:e!s &raditional layers seen from the bottom up Different T%e!s tiers focus on different
approach. &his approach is abstract and degrees of integration, but all are of application specific nature. similar application relevance. "n a well balanced layered system, all layers &iers are of decreasing performance in have their performance and resource resource relevance, but of increasing structural relevance. implication.
F%5)!e 1./ A m)lt%@la:e! a!"$%te"t)!e %t$ t$!ee t%e!s = "ompo#e#ts< "ompo#e#t f!ame o!ks< a#( a "ompo#e#t s:stem.
Digure 8.- illustrates the interplay of layers and tiers in a multi#layer three#tier architecture. As depicted, 7igher tiers provide shared lower layers to accept lower tiers.
&iers are depicted beside each other, whereas layers sit on top of each other .
Digure 8.O shows how component instances communicate with each other either directly 0for example, by using C ) connectable ob(ects, C ) messaging service messages, C BBA events, or IavaBeans events2 or indirectly via a component framewor" that mediates and regulates component interaction. &he same choice recurs when component framewor! instances interact $ the mediator in this case being a tier three instance. C" stands for "ompo#e#t %#sta#"e, CD" for "ompo#e#t f!ame o!k %#sta#"e, and CDD" for "ompo#e#t s:stem Ao! "ompo#e#t f!ame o!k f!ame o!kB %#sta#"e.
Unit I
Introduction
Figure 1.5 Free versus mediated interaction in a tiered architecture
"n a world still largely dominated by monolithic software, not even first#tier architecture is commonplace. 4ote that !b"ects and class frame !rks d! n!t f!rm the l! est tier. &he tier structure starts with deployable entities / components P &raditional class framewor!s merely structure individual components, independent of the placement in a tiered architecture. b(ects and class framewor!s can be found within components. &here, depending on the componentsA complexity, they can readily form their own layering and hierarchies, such as )DC 0)icrosoft Doundation Classes2 in 1+. -ightweight architecture enables the construction of lightweight components. Such components can be constructed with restrictive assumptions in mind. 1ightweight components are most economical if their guiding architecture opens an important degree of extensibility while fixing other decisions. &he ability to have lightweight components is important $ it creates richness in a mar!et in which heavier weights can also blossom. Dor example, the many Active/ >heavyweights? become truly useful when combined with the many more lightweight ob(ects, including controls in the original sense. 1ightweight components can be made possible in two ways. By using multiple speciali6ed component framewor!s.
31
Dept. of IT/RMKEC
Unit I
Introduction
By allowing components to leave unimplemented those features that they do not re'uire. "n the first case, the 'uestion of interoperation among component framewor!s arises and, thus, the concept of tiered architecture. "n the second case, it becomes very difficult to compose components, as it is never clear which aspects are implemented. "ndeed, most systems following the second approach simply do not even have a guiding first#tier architecture $ there is no component framewor! at all.
1.1> COMPONENTS AND MIDD0EWARE Middle are is a name f!r the set !f s!ft are that sits bet een vari!%s !peratin+ systems and a hi+her* distrib%ted pr!+rammin+ platf!rm. )iddleware is sometimes categori6ed into, )essage# riented )iddleware 0) )2 b(ect# riented )iddleware 0 )2.
7owever, most modern middleware blends both approaches. Also, there is a tendency for traditional operating systems to incorporate direct support. perating systems have always included support for some communication protocols. &he push for web services and its >inversion? of the programming world from a program# to a protocol#centric one ma!es much of the middleware value proposition split into two halves $ support for suitable protocols and support structure that eases the local construction of services. "solated middleware products, such as message 'ueuing systems, transaction processing monitors, or concentrators are slowly disappearing. "nstead, speciali6ed servers are emerging that combine middleware functions with specific component framewor!s. &hey are application servers, "ntegration servers and wor!flow and orchestration server. %. Appl%"at%o# se!'e!s
32
Dept. of IT/RMKEC
Unit I
Introduction
&hese servers combine application management, data transaction, load balancing, and other functions. &he application server mar!et is served by almost O. I=++ server implementations as well as by .4+&<C )Q servers. %%. I#te5!at%o# se!'e!s &hese servers combine protocol conversion, data translation, routing, and other functions. &he integration server mar!et is perhaps the most fragmented, with products of many shapes and forms from many vendors, including Cross5orlds, "B) 05ebSphere B=B "ntegrator2, )icrosoft 0Bi6&al! Server2, racle 0/)1 "ntegration Server2, SeeBeyond 0eBusiness "ntegration Suite2, Sun 0Sun 4+ "ntegration Server2, Sybase 0"ntegrator2, &ibco 0Active+nterprise2, *itria 0Business5are2, web)ethods 0+nterprise2, and 5BR 0*erastream2. %%%. Wo!k flo a#( o!"$est!at%o# se!'e!s "t combine event routing, decision ma!ing, and other functions. &he wor! flow and orchestration server mar!et sees 'uite a variety of products, including "B)As )R Series 5or!flow and )icrosoftAs Bi6&al! Server. All these server categories introduce their own component framewor! $ usually built on top of one of the leading component platforms, which are I=++ or .4+& 0incl. C )Q2. "n early =..=, the most successful example is +IB for I=++ application servers. &his trend can be seen as a progressive replacement of middleware $ which often too! the form of traditional procedural or ob(ect#oriented libraries $ by component framewor!s. )iddleware services provide a more functional set of application programming interfaces to allow an application toC
1ocate transparently across the networ!, thus providing interaction with another service or application Be independent from networ! services Be reliable and always available 0urwit#1s classification system organi6es the many types of middleware that
when compared to the operating system and networ! services. are currently available. &hese classifications are based on scalability and recoverabilityC
Unit I
Introduction
.em!te /r!ced%re Call S Client ma!es calls to procedures running on remote systems. Can be asynchronous or synchronous. Messa+e 0riented Middle are S )essages sent to the client are collected and stored until they are acted upon, while the client continues with other processing. 0b"ect .e1%est 2r!ker S &his type of middleware ma!es it possible for applications to send ob(ects and re'uest services in an ob(ect#oriented system. S34-!riented Data )ccess S middleware between applications and database servers. 5mbedded Middle are S communication services and integration interface software<firmware that operates between embedded applications and the real time operating system. ther sources include these additional classificationsC Transacti!n pr!cessin+ m!nit!rs S ;rovides tools and an environment to develop and deploy distributed applications. )pplicati!n servers S software installed on a computer to facilitate the serving 0running2 of other applications.
R.M.8 EN1INEERIN1 CO00E1E

DEPARTMENT OF INFORMATION TECHNOLOGY
IT1/>1 = COMPONENT +ASED TECHNO0O12
!E"TION #AN$
!NIT%I Introduction
T&O MAR$ !E"TION"'
8. Define software component. A software component is a system element offering a predefined serviceable to communicate with other components. =. Specify the characteristics of ob(ect
Unit I
Introduction
b(ect is a unit of instantiation, it has a uni'ue identity. "t may have state and this can be externally observable. K. 5hat is prototype ob(ectJ &he ob(ect may be implicitly available in the form of an ob(ect that already exists. Such a preexisting ob(ect is called a prototype ob(ect. -. 5hat is factory ob(ect and methodsJ Dactory ob(ectsC "t can be an ob(ect of its own.Dactory methodsC )ethods on ob(ects that return freshly created other ob(ects are another variation. O. 5hat are modulesJ )odules do not have a concept of instantiation whereas classes do. )odules can be used and always and have been used to pac!age multiple entities. :. Specify the non#technical aspects that are need in interfaces. T A component have multiple interfaces, each representing a service that the component offers. T Bedundant introductions of similar interfaces need to be minimi6ed. T Be'uires a small number of widely accepted uni'ue naming schemes. 3. Define callbac!. Callbac!s are a common feature in procedural libraries that has to handle asynchronous events. G. 5hat is component architectureJ Component architecture is the pivotal basis of any large#scale software technology and is of utmost importance for component based systems. 9. Specify some cornerstones of a component architecture. T "nteraction between components and their environment is regulated. T &he roles of components are defined. T &ool interfaces are standardi6ed. 8.. Specify the roles of an architecture.
Unit I
Introduction
T Architecture needs to create simultaneously the basis for independence and cooperation. T An Architecture defines overall invariants. T "t needs to be based on the principal considerations of overall functionality T "t prescribes proper framewor!s for all involved mechanisms. 88. 5hat is the use of conceptual levelJ A component framewor! is a dedicated and focused architecture usually around a few !ey mechanisms and a fixed set of policies for mechanisms at the component level.
8=. Define component framewor!. A component framewor! is a dedicated and focused architecture usually around afew !ey mechanisms and a fixed set of policies for mechanisms at the component level. 8K. 5hat is a resourceJ A resource is a fro6en collection of typed items. 8-. Define middleware. )iddleware is a name for the set of software that sits between various operating systems and a higher distributed programming platform. 8O. Categori6e the middleware. T )essage oriented middleware0) )2. T b(ect oriented middleware0 8:. 5hat is generative programmingJ @enerative programming aims at transformations approach to the construction of software. 83. Specify the areas used in generative approaches. T Hsed to produce individual components. T Hsed to enhance composed systems.
)2.
Unit I
Introduction
8G. Specify the criteria that is used to fulfill the software definition. T )ultiple use T 4on#context specific. T Composable with other component. T +ncapsulated. 89. Specify the fundamental properties of component technology. T "f a component fails to function it must not violate system#wide rules. T Software development processes that do not depending on testing T ;erformance of a component system is affected in non#trivial ways by the actual composition =.. 5hat is enhance composed systems and give example. &hey need to be positioned in such a way that they do not interfere with the unit of deployment characteristic of components. +gCI"& techni'ue.
() MAR$
!E"TION"'
8.+xplain the fundamental properties of component technology. T &echnological feasibility T &echnical problems T "ntegration and testing T ;otential of software components
=. +xplain briefly about component architecture. T Bole of architecture T A &iered component architecture T Components and middleware
Unit I
Introduction
K. +xplain briefly about callbac!s with example T Definition T Diagram T +xplanation T +gC Directory service
-. 5rite short notes on modules, interfaces. T )odules T "nterfaces "nterface $ types, "nterface with &extService example "nterface as contracts *ersion
O. 5rite short notes on ob(ects and software components. T Software components $ definition, characteristic properties and implications. T b(ects # definition, characteristic properties and implications.
38
Dept. of IT/RMKEC

Unit I Introduction

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Unit I Introduction

Încărcat de

Drepturi de autor:

Formate disponibile

Unit I

IT1401 Component Based Technology

IT1401 Component Based Technology

F%5)!e 1.1 Example of (%!e"t a#( %#(%!e"t %#te!fa"es.

&he simple directory service interface is grouped into two parts.

IT1401 Component Based Technology

IT1401 Component Based Technology

IT1401 Component Based Technology

Figure 1.5 Free versus mediated interaction in a tiered architecture

IT1401 Component Based Technology

IT1401 Component Based Technology

R.M.8 EN1INEERIN1 CO00E1E

IT1401 Component Based Technology

S-ar putea să vă placă și