The emerge of web services in Service-Oriented Architectures (SOA) within companies or at the global internet oers new ways for the creation of web applications. Even though the composition of services via business processes are covered by existing tools and solutions, concepts for a lightweight service consumption are still in a preliminary phase. The complexity of state-of-the-art SOA technology prevents users with limited IT skills getting easy access to web services and their oered functionalities. This paper presents a user-centric design approach to model and create simple service-based applications in a graphical way without being necessary to write any code.
The introduction of Web 2.0 oers users the capability to take part in the
development of the WWW. Non-technical users are able to create web pages in form
of blogs or customize web pages such as iGoogle [
The concepts presented in this paper follow the approach of service
composition at the presentation layer enhanced by user interface (UI) related service
annotations [
We propose a graphical lightweight service composition approach in order to model data- and control ows at the UI level. The modeling of data-ows will be done by the graphical connection of single UI elements of the frontends. In addition, the paper presents two ways of dening a control ow to create multi-page applications (see Sec. 4).
We integrate the mentioned concepts into our authoring environment and evaluate their usability and acceptance in form of a user study (see Sec. 5). 2
The general approach of service composition at the presentation layer has the
goal to support non-programmers in the design and creation of simple
servicebased applications. The target user group refers to end users in general and to
knowledge workers and skilled web users in particular. The composition process
is fully integrated in a three step development methodology presented in [
The composition is based on annotated services that act as the foundation for the designed applications. The annotations are reusable information fragments attached to the service description (like WSDL or WADL), which are typically not available for an application developer or service composer. They are created by the service developer and stored in an annotation model based on a formally dened meta-model. Annotations provide extensive additional information covering the visual appearance of a service, the behavior of UI-elements and relations between services to further improve the visual appearance of resulting composite applications. The following examples explain the use of annotations:
Visual Property: This annotation adds information about the designated visual appearance of a service element; e.g. if a parameter is a string that represents a password, this parameter should be displayed obscured. Unit and Conversion: This annotation assigns a unit to a specic service parameter. In addition, with a set of conversion rules it is possible to oer one value in dierent units and convert between them.
Annotations dening the behavior of UI-elements:
Suggestion: This annotation assigns an external suggestion service to a specic service element to provide a list of suggested values while typing. Validation: To proof the correctness of entered data, this annotation denes rules entered data is checked up on.
Annotations dening the relations between services
Bundle: A set of disjunct services or service operations that benecially work together, can be dened with this annotation. In general the 21 currently available annotations should thus be seen as a kind of knowledge transfer from the service developer to the service composer, facilitate the understanding and simplify the composition of web services.
During the design time the information gained from the service description and the annotations are used to create a service front-end, which is a UI for a specic service operation (detailed description in Sec. 3). The user, in his role as a service composer and application designer, interacts with these front-ends only to create the desired application in a kind of WYSIWYG (What you see is what you get) principle. No technical knowledge about service composition is required to build an application, so the user can model and layout his application in a graphical way without being necessary to write any code. An application consists of several pages that can be connected with each other to dene a navigation ow through the nal application. Each page acts as a container for the front-ends and represents a dialog visible on the screen. The complete design process including the integration and composition of the front-ends (detailed description in Sec. 4) is supported by a web-based authoring tool, the ServFace Builder. Figure 1 shows a screenshot of the current prototype. The ServFace Builder supports the user in the design of multi-page applications and the composition of the service front-ends. An internal object model represents the current modeling state and supports the generation of executable applications for dierent target platforms. This application model is constantly updated according to user changes and its serialization serves as input to the model-to-code generation process.
As mentioned above services and in particular the operations of those services are represented by generated service front-ends. Number 1 and 2 of gure 1 are examples of service front-ends for service operations from a service called "ight booking service". A service front-end representing a service operation comprises of a nested container structure including a root operation container and an interaction container for the input and output parameters of a web service. Those interaction containers comprehend the visualization of the operation parameters that are the key elements to later invoke the service when using the nal composite application. Figure 2 illustrates the ve step generation process:
Since a remote service repository manages the services, all available information about a service need to be retrieved from the repository at rst. To avoid extensively communication aords the information about a service are stored in a local data model. This model represents all information necessary for the front-end generation process. All available services including their operations are presented to the user within the Building Blocks browser (Fig. 1 No. 4).
To infer the structure and the elements of a service operation, an Inference Engine parses the model that represents the service and analyses the particular service operation. It generates UI elements for each service element that needs to be displayed within this service-front-end. To infer which UI element should be used for a specic service element the inference engine considers the following: parameter type (input or output) base data type data type enhancements and restrictions occurrence denitions Complex data types need special consideration because they can be arbitrarily nested or can contain recursions. The inference engine does not follow recursions arbitrarily to avoid innite loops, but rather aborts further inspection after a certain number of loops. For input parameters complex data types are represented by a nested structure, dividing the complex type into its child elements. For output parameters complex data types are presented by tables as standard output format or lists. Depending on the depth of a nested complex type, the table could contain a expand mode to show complex child elements. Minimum and maximum occurrences are taken into consideration by redundantly displaying the data type element or allowing multi-selection in the range of the occurrence. As a result the inference engine creates model commands (4) that are executed by the API of the underlying application model. The execution aects the current state of the application model (5), e.g. by integrating new elements or changing existing ones. The following example explains this process:
A simple ight search operation needs two inputs to search available ights. A destination (data type: string) and a departure date (data type: date). The return value is a complex type containing the data type elements "FlightNo.", "Airline", "Price" that all are dened as string data types. Firstly, the inference engine creates the container structure including an operation root group, an input group and an output group. Secondly, both input parameters are inferred. Because the destination parameter is dened as string a textbox is chosen, whereas the departure date is a date type and therefore it is visualized by a calendar widget. Thirdly, for the output parameter as a complex type a structured output e.g. a table is chosen to display the results. Finally, an execution button is created to invoke the web service in the resulting composite application.
The particularity of this generation process is the consideration of additional
information provided by the ServFace service annotations. Furthermore, a
consolidation of several HCI guidelines (e.g. provided by Apple or Microsoft) or
perceptions of usability experts like [
A continuation of the ight search example above explains this process: The parameter of the destination input eld is dened as string. Without the inuence of annotations it is displayed as a standard textbox handling arbitrary phrases. The addition of an Enumeration annotation denes a collection of valid values e.g. a selection of all available destination airports. To avoid false inputs the inference engine would not choose a textbox as representing UI element, but rather a combobox to restrain the input possibilities. In addition a Feedback annotation is added to all parameters dening a name readable for humans. This causes the inference engine to not determine the parameter name from the service description that does not necessarily provide an understandable name for its elements, but to use the name provided by the Feedback annotation. The service inference engine as well as the annotation eect determination take the formerly mentioned UI design recommendations into consideration. These recommendations inuence the choice which UI element is used to represent a service parameter, or change the conguration of those UI elements. The following example lists the consolidated UI recommendations for the Enumeration annotation:
Use a Radio-Button-Group whenever there is a choice between 2 or 3 values. Use a Drop-Down-List whenever there are more than three but under 20 valid values.
Use a ComboBox (Drop-Down-List with search capability) whenever there are more than 20 but under 200 valid values.
Use a Textbox when there are more than 200 valid values.
Show at least 8 items at the same time before a scrollbar appears whenever a Drop-Down-List or ComboBox is used.
Sort the items alphabetically whenever there are more than 12 items.
The generation of UIs for web services were also analyzed in former research
projects like WSGUI [
Nowadays, there are already many mashup-editors available like Yahoo Pipes
[
The common visualizations of data ows in mashups are ports (often
displayed by little circles) for each variable and arrows from the source to the
target port. The activity of connecting those ports is called "Wiring" [
For the denition of the order of execution we have two views oering dierent levels of expressiveness. Both use pages, which can contain front-ends for service operations. The transition from one page to another will cause the invocation of the corresponding web services. The rst approach is intended for users who are new to the tool and want to create applications simply and quickly. Therefore, thumbnails of the pages are listed (Fig. 3 a) similar to the well-known slide listing in Microsoft Powerpoint. The order of execution is dened by the order of the pages in the list view. For example moving a page B before another page A, means that the service operations associated with page B are executed before the ones of page A. With this approach you can only dene a sequential order without branches in the execution ow, but this is suitable for many simple processes and easy to use. The user has not to consider the details of the process ow. For an experienced user who wants to dene more complex processes we (a) Sequential Page View (b) Page Flow View provide a detailed ow view showing the transitions between the pages (Fig. 3 b). In this view he is able to create his own transitions and to dene alternative ows for an application. We do not only use nodes in this view as it is known from process diagrams, but also the thumbnails of the pages. The user can click on a thumbnail and open it, to see the service front-ends contained by this page, integrate new ones or connect UI elements as described above. 5
To evaluate the presented approaches a user study was accomplished. While for
the rst study [
Since the aspired end user should not necessarily have advanced IT-experience, we ensured that the background knowledge of all participants was not related to computer science. The main scope of the evaluation was divided into two parts. The rst part was an exploratory evaluation of the ServFace Builder with a duration of approx. 15 minutes. The participants had the chance to try out the tool without further tasks or guidance. They have not received extensive information beforehand either. However the observers stood by to assist or answer questions whenever necessary. As shown in gure 4 most users stated that the bench of the ServFace Builder is very clearly structured (92%) and the functionality is self-explanatory (67%). This means that the usage of the tool should be easily understandable even without a previous tutorial or extensive explanations. However many user (67%) had problems getting started right after they reached the rst tool screen. This leaves room for further optimizations regarding the start-up process and the user guidance coordinating the rst steps.
In the second part of the evaluation the users got the task to adopt the role of a company worker who tries to ease the business travel booking process. They had to create a composition that satises the requirements of the given scenario description. A selection of the results of the second part is presented in gure 5. As expected, the participants had less trouble to get started with the composition process now (92%). Both, the participants and the observers had the impression that in most cases the design process came more naturally to the participants. This impression was conrmed by the comments of the participants: 92% stated that the design process of a multi-page composite application is straightforward and all participants declared that the front-ends are self-explanatory (75%) or at least understandable (25%). This points out that the users of the tool are able to handle the composition process quite well with little familiarization. The 15 minutes exploratory try-out was sucient to enable the participants to design the required application without further diculty. Therefore the period of vocational adjustment is rather short even for users without IT-background. In contrast many users (67%) criticized the lack of guidance provided by the ServFace Builder. In addition, the drag&drop concept to add the service operations to the canvas was rated neither intuitive nor comfortable.
The ow view (Fig. 3 b) was used as the central view showing the pages during the user study. But only 25% of the participants asked for the possibility to inuence the order or to dene alternative ows. The observers noticed that most participants just added new pages and integrated service front-ends in the linear order they had created the pages before. This motivates the modication of the ServFace Builder, the simple sequential view should be the standard view on start-up and the ow view should be available on demand. 6
The paper presented two concepts supporting the approach of service composition at the presentation layer. The generation and composition of service frontends oers new ways in designing service-based applications for non-programmers. An evaluation with a working prototype showed that most users handled the tool without extensive diculties after a short familiarization period. Most concepts pointed out to be understood and accepted by the users. However there are further elds of improvement. An extended guidance and a better way to get the composition process started are two important examples. In addition the visualization process of the service front-ends could be enhanced by an extended support for dierent platforms. An expert-based evaluation as well as a third iteration of the user study are planned to estimate the recommended changes gained from the presented evaluation. 7
This work is supported by the EU Research Project (FP7) ServFace. In addition, we would like to thank the participants of the user study and the supervisors of our theses Marius Feldmann (L. Dannecker) and Gerald Hbsch (A. Pursche).