Creating Service-based Interactive Applications by using Annotated Web Services

Posted on by : admin Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,


The central idea behind Web services is the reuse of functionality. In most development methodologies for building interactive applications upon a service infrastructure, reusability is still reduced to the functional core encapsulated within the services. The concept of Web service annotations aims to include further reusable information fragments that are not covered by the functional interface description and thus – when applied to the apropriate methodology – to profit from faster and simplyfied application development.

The mechanism for service annotations has been build upon the approach used within the Dynvoker project. In this approach a service annotation file contains UI related information that is associated to operations and parameters within the service’s functional interface description by using XPath expressions. Due to the fact that the annotation language used in Dynvoker (GUIDD) only offers basic UI related information, it has been extended. In order to find apropriate annotations, several service-based interactive applications have been analysed to detect reusable patterns.

During our investigations more then 25 different reusable types of information fragments and thus of annotations have been identified. The annotations introduced by our approach are categorized into UI related annotations and annotations describing preand postconditions of a service operation. The UI related annotations semselfs are classified into annotations describing the layout and structure of the UI and annotations describing the behavior of the UI. In general, each operation of a service can be associated with one input dialog for collecting the input parameters and several output dialogs which are presented depending on the result value returned by the operation.

The UI related annotations are used to give a reusable description of these dialogs. Due to the fact that the annotations are created on the level of Abstract User Interfaces, these description can be reused for developing applications for different platforms and devices. Thus for example the layout and structure definitions do not cover concrete position or size specifications but the capability to group input fields or determine their order. Fig. 1 shows a simple example of a login service operation. The login service has got an input dialog to request credentials and depending on their validity one of two possible output dialogs is displayed. The dialog for requesting the credentials can not be derived completely from the functional interface description of the service operation. It can be determined only that two input parameters for values of type String are necessary.

Annotations for data type definitions are used in the example to specify that the first parameter should only include characters and that the second one is of the semantic type password. Furthermore a button with the label Login is associated with the operation. A ordering definition that is one of several layouting definitions is used to indicate that this button should be displayed after the two input fields. The return value of the service operation is annotated by return value dependend output dialogs. Both dialogs contain a text indicating the result of the login operation. In the case of a failed login two buttons are indicated within the annotations.

The button with the label Retry contains a navigation definition pointing to the login operation thus resulting in a further invocation of the first dialog when the button is pressed. Based on the described information within the annotations a valid UI can be created automatically. The annotations within the behavior definition are mainly intended to increase the usability of the created UI. A very often applied annotation is the ”validation annotation” that provides a rule expressed by a regular expression or by the Object Constraints Language (OCL). They can be used to provide direct feedback to a user if the input does not conform to one of these given rules. The decision to use OCL rules has been made to also describe dependencies between parameters.

Thus it is for example possible to point out that the value of a variable ”Date dateFlightTo” has to be smaller then a second variable’s value ”Date dateFlightBack” – and thus the first date input has to be before the second date. A further example for a behavior annotation is the ”suggestion” information. It enables to associate an input parameter of a Web service with another service that returns a concrete proposal for an input value. It is obvious that such a suggestion service is only available in rare cases. Thus our research also aims to provide guidlines for extending Web service infrastructures to improve the development of interactive applications based on such infrastructures.

Besides the annotations used in the example to describe UIs for single services, annotations have been identified to define relations between parameters or return values of different operations. The usefulness of these annotations is explained in the next two sections that discuss how the UI related annotations and the annotations describing pre- and postconditions of a service operation can be used to derive a task-model and associated UIs (semi-)automatically. In order to attach service annotations in a simple manner to their associated service, a specific editor for creating them is currently under development. It offers the possibility to import a functional interface description of a Web service and to assign values for the various annotations to the interface description itself, to the service operations, operation parameters and defined data types.

The values can be assigned on one hand via a simple key-value mechanism and on the other hand in a visual mode. After parsing the functional interface description all UI interactors (e.g. text fields) are displayed and offer the possibility to instantiate associated annotations such as labels, validation information (e.g. by an regular expression), default values or MIME type information. For expressing the vocabulary of the annotations, an Ecore model has been introduced.