WWW/Internet - Portal do Software Público Brasileiro

IADIS International Conference WWW/Internet 2010interaction. In the electronic map, a centerChange event is triggered in response to the respective action ofthe user. The functionality of a UI component is represented by operations that consume input parametersand produce at most one return parameter. A sample operation of the electronic map is addSimpleMarker. Itadds a Point-of-Interest marker at the geo-coordinate supplied as an input parameter.3.2 RequirementsThe purpose of UISDL is to define an XML-based description language for UI Services. UISDL thereforehas to provide means to describe the interfaces of UI components that follow the UI component modelpresented in section 3.1, including the data types they use to communicate with the application that integratesthem in an abstract, i.e. implementation- and programming language independent, way.To distribute component implementations, UISDL must support the binding of componentimplementations to an abstract interface description. Implementation bindings must (a) enable the life cyclemanagement of UI components, (b) provide access to properties, (c) enable the invocation of componentoperations, and (d) allow the (de-)registration of event listeners. Furthermore, libraries that must be includedto use the component implementation must be specified as part of the implementation binding.To fully exploit the flexibility offered by UI Services, it must be possible to implement runtimemechanisms on top of the implementation bindings that support a dynamic binding of UI Services. Dynamicbinding enables the selection and exchange of a concrete UI service implementation at runtime, for examplebased on the context of use, including user preferences and platform properties. For the same reason, abstractinterface definitions and implementation bindings must be separated since multiple UI componentimplementations, e.g. Google Map, Yahoo Map, OpenStreetMap, offered by different providers can exist forone abstract Map interface. It is clear that their common abstract interface can only cover the common set offunctionalities offered by the implementations. However, we have found that existing componentimplementations often extend this common set with additional functionalities. For example, some existingimplementations of the abstract Map interface, like Google Maps, allow to drag-and-drop of Point-of-Interestmarkers and produce a corresponding event in response. This requires the specification of an abstractinterface specifically for these implementations that extends the Map interface with the additional event.Otherwise, the additional functionality would either not be accessible or applications using the Map UIService could not detect the compatibility of the extended interface with Map UI. UISDL must thereforesupport the declaration of functional extensions between abstract interfaces.Finally, we have found inline metadata in the form of keywords, screenshots of UI componentimplementations, license information, pricing, suitability, and human-readable documentation to be necessaryfor the management of UISDL descriptions in a UI Service repository (see sect. 4) and their integration incomposition tools.3.3 Language Concepts and Design DecisionsThe language concepts and design decisions for UISDL are guided by the requirements in sect. 3.2.Interestingly, the requirements that have to be fulfilled by UISDL regarding abstraction, binding andintegration into applications are quite similar to those addressed by WSDL. The major difference seems to bethat web services are executed remotely on a server, while UI components provided by UI Services areexecuted locally in the scope of the application that integrates them. For UI Services, the need to provide anexecution environment on the client that manages the UI components' life-cycle replaces the need for remoteservice invocation mechanisms required for web service integration. As we will show in the following,concepts developed for classical web services that have shown to be reusable for our approach.WSDL is structured into an abstract part and a concrete part. Its abstract part specifies the web serviceinterface, i.e. the operations offered by the service, and the data type definitions they use in a platform-,protocol- and programming language independent way against which applications can be developed. Itsconcrete part contains protocol binding information and endpoint definitions that allow applications to invokea specific implementation of the web service. UISDL adopts these abstraction and structuring concepts bydefining two different document types, namely UISDL-Class (UISDL-C) for the abstract part and UISDL-Binding (UISDL-B) for the concrete part. By defining two different document types for both parts, we go onestep beyond WSDL. Their physical separation was chosen to provide the organizational means for a central177