WWW/Internet - Portal do Software Público Brasileiro

ISBN: 978-972-8939-25-0 © 2010 IADISmanagement and distribution of abstract UI component interface definitions that can be referenced byproviders of compatible UI component implementations. It thereby allows providers of UI componentimplementations as well as developers that integrate UI Services to ensure compatibility on a global scale.UISDL-C is used to define abstract UI component interfaces: properties, operations, events, and datatypes in an implementation- and programming language independent way similar to WSDL. It fully reflectsour UI component model. Syntax details are presented in sect. 3.4. Applications that use UI Services areprogrammed against the abstract interfaces defined with UISDL-C.UISDL-C also adopts the data type definition based on XML Schema as an abstraction concept fromWSDL. XML Schema was chosen due to its programming language independence. Like in WSDL, XMLSchema definitions are utilized to specify the data types required for the abstract interface definition, i.e.properties, invocation and result parameters of operations, and events. Furthermore, instances of XMLSchema data types can easily be serialized in XML. We have therefore decided to use XML as a commonand implementation-independent data exchange format between UI component implementations to maintainimplementation independence at runtime. This is the prerequisite that UI component implementations mustfulfill to be distributable as UI Services. It is the responsibility of each component implementation to convertbetween the XML representation and internal data representations. Since the data exchange with webservices via SOAP uses the same strategy, our approach also simplifies the integration between UI Servicesand web services, since UI component data can be directly wrapped in SOAP messages.With UISDL-B, implementation bindings for concrete UI component implementations are specified anddistributed. They are created by UI component providers and bind the abstract interface defined in UISDL-Cto implementation-specific component operations for life cycle management (constructor, destructor), forshowing and hiding the UI component, accessors for properties, component operations, and for(un)registering event handlers. Analogous to WSDL, references from UISDL-B to constituents of the abstractinterface being bound are based on names. Also, UISDL-B includes elements to specify the libraries to beincluded before the component can be instantiated. Syntax details and realizations for bindings are presentedin sect. 3.5. The abstract interface implemented by a UISDL-B description is denoted by a reference thecorresponding UISDL-C. Inverse references from UISDL-C descriptions to UISDL-B implementationbindings are avoided since the number of component providers that can vary over time, which imposes therisk of invalid references and would require frequent updates of UISDL-C descriptions. Instead, the UIService repository (sect. 4) stores and updates these references.The possibility to dynamically select, bind, and even exchange component implementations delivered byUI Services does not require them to be compatible on the technical interface level, which is ensured by theabstract interface definitions. However, interface compatibility alone does mean that all implementationsprovide the same functionality. Therefore, also the functional equivalence of different componentimplementations for one abstract interface must additionally be considered. Since this is hardly possible toguarantee from a technical point of view, UISDL-C supports an organizational model based on a functionalclassification which allows component providers to express functional equivalence. A detailed discussion ofour functional classification approach and their definition goes beyond the focus of this paper. Briefly, wedefine one class per abstract interface definition, i.e. UISDL-C document that specifies the functionality to beprovided by its implementations. UISDL-C supports this classification through a mandatory reference to itsclass. For the same reason, the name of the abstract part of UISDL was chosen to be UISDL-Class.As motivated in the requirements, it is also necessary to provide means to declare functional extensionrelationships between two abstract interfaces as part of UISDL-C descriptions. In the drag-and-dropextension example, it is obvious that the Google Map implementation (which supports drag-and-drop), isfunctionally equivalent to the Yahoo Map (which does not feature drag-and-drop support) in applicationsimplemented against the abstract Map UI interface. The presence of a functional extension is based on twocriteria: interface compatibility and functional equivalence of the extending interface's class to the class ofthe extended interface. Informally, by declaring an abstract component interface B to be a functionalextension of an abstract UI component interface A, it is expressed that B adds at least one element to the setI A of operations, properties, events, or data types defined in A, without redefining other elements in I A . I.e. Btechnically remains interface compatible with A. The second criterion of functional extension requiresimplementations of B to implement equivalent functionality for all elements in I A , i.e. to adhere to A's class,its superclass. Through this concept, we can specify that any implementation of B can be used as analternative for an implementation of A, thereby increasing the number of alternatives for the dynamicbinding. UISDL-C therefore features an optional superclass reference.178