WWW/Internet - Portal do Software Público Brasileiro

ISBN: 978-972-8939-25-0 © 2010 IADISsuitability attribute to support the selection process for dynamic binding at runtime, keywords, licenseinformation, and pricing. The interface binding element (lines 19-49) specifies information necessary tointegrate, access, and manage the component life cycle at runtime for the specific implementation beingbound. The language attribute holds the programming language of the component implementation. Thebinding type attribute denotes the type of implementation binding used.The dependencies element (lines 20-23) specifies the libraries that must be included to use thecomponent. The elements constructor and destructor are utilized for component life-cycle management, therendering element specfies how the component is set visible. An accessor element exists for each componentproperty specified in the UISDL-C and specifies read and write access. For each event element in UISDL-C,the eventsink element specifies how event listeners are registered and unregistered. For each operation in theUISDL-C, the invocation element specifies how the operation is invoked. The attributes property, event, andoperation are references from UISDL-B to UISDL-C. They are generally based on the interface elementnames specified in the corresponding UISDL-C. Therefore, applications can be implemented against theabstract interface specification.By now, we have identified the two binding types code template and convention as being suitable forUISDL-B. The example in listing 2 uses code templates, which are applicable for script languages likeJavascript that support execution of code generated at runtime. Briefly, in the code templates, placeholdersenclosed by '@' symbols represent application-specific parts that must be replaced with application-specificvalues (constants, variables, pointers) before the code can be executed. Placeholder types to refer to events,properties, and parameters specified in the UISDL-C (e.g. @paramater:center@), or to the componentinstance (@:instance@) have been defined. This enables an application to pass these values to a codetemplate processor using the names in the UISDL-C. We have found these placeholder types to be sufficient.Code templates are enclosed in code elements (cp. fig. 2). The convention binding type directly maps theabstract interface specified in UISDL-C to a concrete implementation skeleton, e.g. through XSLT. Thecomponent implementation can in this case be managed and accessed with knowledge about the mappingrules. The mapping rules used must therefore be identifiable from the interface binding's binding typeattribute.4. RUNTIME ENVIRONMENT AND IMPLEMENTATIONA client-side thin server runtime (TSR) that provides the runtime mechanisms required to support integrationand dynamic binding of UI Services has been implemented for web browsers (Pietschmann et al. 2010). Itprovides RIAs with the necessary runtime mechanisms to dynamically bind UI component implementationsdescribed in UISDL-B, to manage their life-cycle, and to access them from client-side business logic. TheTSR supports the binding types code templates and convention. Furthermore, we realized a repository toregister, manage and retrieve UI components and to enable their global distribution.For UI component implementations described in UISDL-B, the TSR provides means to create, render,and destroy UI component instances, to access their properties, to add and remove event handlers, and toinvoke their operations in a uniform way. The selection of the UI Service to be bound is either done bypassing a UISDL-C class name or the URL of a UISDL-B to the TSR. It queries the repository to retrieve aUISDL-B document using AJAX. If a class name is used, the selection of an appropriate UISDL-B isdelegated to the repository and performed based on information about requesting device that is passed withthe query, including an option to preselect a concrete component implementation. Upon receiving theUISDL-B, the TSR creates the UI component instance.Application-specific information required by the Integration Manager, i.e. variables, constants, andpointers to event handler functions, are passed from the business logic via API calls programmed against theabstract UISDL-C interface specification, e.g. the name of the property to be set together with the new value,and an identifier by which the component instance is registered by the Integration Manager.To conveniently integrate and initialize UI component implementations, we have defined UI componentplaceholders that allow service selection information together with application-specific information bespecified as part of HTML documents which we term composition documents. The TSR is able to processcomposition documents, making the integration of UI Services without programming particularly easy.Details of the composition document are beyond the scope of this paper.180