Modeling Service Integration in Web Applications

Modeling Service Integration in Web Applications Cristina Cachero 1, Jaime Gómez 1, and Oscar Pastor 2 1 Departamento de Lenguajes y Sistemas Informáticos Universidad de Alicante. SPAIN {ccachero,jgomez}@dlsi.ua.es 2 Departamento de Sistemas Informáticos y Computación Universidad Politécnica de Valencia. SPAIN opastor@dsic.upv.es Abstract In the last years integration of service invocation in the context of dynamic, personalized interfaces has become a must for web applications. However, existing conceptual modeling methods pay little attention to the different ways the user may need to interact with such services, which usually involve concepts far more complex than those related to text field input. This paper presents the OO-H modeling proposal for the seamless integration of both single and multi-step service calls in the context of a cohesive user interface. The notation and semantics provided by OO-H allow the reuse of context information and/or navigation paths for the assignment of values to service parameters and the visualization of service results. Furthermore, the OO-H invocation philosophy, based on the Web Services platform, guarantees the independence of the interface models from both business logic and interface target technologies. 1 Introduction In the last few years we have witnessed how existing and to come Web technologies have induced much more flexible distributed environments where new business opportunities have appeared, but also new risks related to software development [18]. Although the scientific community agrees in that, in order to keep the possibility of failure to a minimum, the development process for enterprise applications should evolve in a Web Engineering manner, there is no agreement at how the core activities behind a sound Web Application development process should be addressed, nor at how and to which degree system functionality should be supported. In this sense, some approaches, most of them coming from the hypermedia community, consider Web Applications as information delivery systems, where only trivial functionality is offered [17, 21, 4]. Others, coming from the Software Engineering field, regard Web Applications as traditional distributed applications, and propose service modeling approaches that make exclusive use of standard models and methods to capture the idiosyncrasy of functionality[5]. These approaches pay little or no attention to interface

characteristics (navigation, integration and rendering), which are aspects that make a difference in web environments. Still other approaches consider the Web as a Dynamic Business Web [9] where the application development consists on a process of communication and integration of Web Services disseminated over the net and offered via (often) collaborating technologies such as Universal Description, Discovery and Integration (UDDI [23]), Directory Services Markup Language [7], Simple Object Access Protocol [22] or Web Services Description Language (WSDL [27]), and thus disregard the informational part that is also present in actual web applications. We agree with [15] in that each of these trends partially addresses the nuances Web Applications involve, and so a fusion of their respective points of view is needed in order to provide a cohesive solution to web service interface modeling. On one hand hypermedia modeling methods center on web navigation and interaction issues, which provide the basic semantics for a web application to succeed, but only if those concepts are seamlessly integrated with the (often complex) functionality users require. On the other hand, traditional software engineering methods, although proven successful for the modeling of complex functionality, do not provide the mechanisms and constructs to capture the specific interface navigation and rendering semantics. Furthermore, cost reduction and time-to-market speed of sophisticated web applications can only be achieved by means of a leverage of services from partners and other third parties over Internet. It is here where the concept of Dynamic Business Web pays an important role: proposed models should be capable of abstracting the implementation issues far beyond the concept of client-server applications: simplicity and ubiquity must be maintained regardless of the complexity of services provided in the context of web applications, which in turn requires the use of new integration methods and constructs that materialize this new service-oriented architecture [24, 10]. In our proposal, known as the Object-Oriented Hypermedia method (OO- H[11, 12]), we have gathered and enriched the relevant aspects of each trend in order to provide a unified definition of service interfaces. In this sense, on one hand OO-H incorporates a set of Object Oriented UML-compliant [25] models that provide the means to reflect the method interface description, including input and output parameters. On the other hand, OO-H provides, at navigation level, the semantics needed to express how and when these methods may be accessed. Furthermore, the navigation semantics and constructs are also useful to reflect both the parameter input process and the (often required) visualization of results. Last, but not least, the actual invocation of the method is performed taking into account the need for a service-agnostic request handling that, making use of high level protocols and languages such as XML, HTTP, SOAP and WSDL, transforms the information gathered in the OO-H models into a calling

message that is sent to the underlying business modules. 1. The remaining of the article is structured as follows: section 2 provides, by means of an example, a brief overview of the main OO-H models and constructs that gather the interface semantics. Section 3 describes in detail the service interface modeling framework for both single and multi-step services. Section 4 centers on the treatment of both in and out service parameters. Section 5 sketches the process followed to actually invoke the underlying business services. Last, conclusions and further work are sketched in section 6. 2 OO-H: an overview The OO-H method is a generic approach, based on the Object Oriented paradigm, that provides the designer with the semantics and notation necessary for the development of web based interfaces, and its connection with previously existing application logic modules 2. In order to illustrate the main OO-H concepts, a small example is going to be employed all along the paper: a hotel reservation system. In this system, and as a basic explanation (for reasons of brevity) let s assume there is a single actor (a receptionist) and three hotel subsystems: Client Management, Hotel Data Management and Booking Management, each of which includes a subset of the user functional requirements. The receptionist is allowed, inside the boundaries of the Client Management subsystem, to add a new client, register the entrance of a client, add charges to rooms and print invoices. On the other hand, as part of the Hotel Data Management subsystem, s/he can manage the number, type and characteristics of rooms offered by the hotel, types of services offered to clients and the payment methods. Last, inside the Booking Management subsystem, s/he can manage the room bookings, which includes adding, updating, deleting and/or viewing booking reports. OO-H reflects all this information, which corresponds to the functional requirements of the only actor identified in the system, in the Use Case Diagram that can be seen in Fig. 1. 2.1 Domain phase: method capture in OO-H We have already mentioned that OO-H includes a set of UML-compliant models, namely the Business Class Diagram and the Use Case Diagram, that together give support to the Domain Analysis phase of the method. The Class Diagram 1 In this paper the term service refers to component services that others might use to build web applications. In OO-H, these services are modeled inside the boundaries of either business or utility classes, and are treated as any other class method. For this reason, the terms service and method will be used as synonyms all along the paper. 2 A whole definition of the OO-H approach is out of the scope of this paper: interested readers are referred to [11, 12] for a extended explanation.

Client Management register Client Entrance add charge to room print invoice add Client RECEPT. manage rooms manage service types manage payment types manage room types Hotel Data Management update Booking view Bookings given a date add Booking delete Booking Booking Management Figure1. Hotel Reservation System Use Case Diagram includes the definition of both static (classes, attributes and relationships) and dynamic (methods) aspects. As far as methods are concerned, its UML definition includes both general information (its class or instance scope, its associated is- Query tagged value etc.) and information regarding each of its parameters: type, whether they are input, output or both input and output parameters, default value if available, mandatory/non mandatory character, etc. Back to our example, in Fig. 2 we observe the class diagram corresponding to the hotel reservation system. This diagram models the fact that the hotel has a set of Rooms (of different Types), that can be booked by a Client. All Bookings are contained in a BookingList, one for each combination of room and client. Once the client has arrived in the hotel, and for each room, the system keeps track of the Services provided to that room (laundry, drinks, etc). Also, it Charges the due amount of money to the corresponding Booking. When the client leaves the hotel, an Invoice, which may include more than one Booking (for example, if the client has occupied more than one room) is generated and the method of Payment is registered. 2.2 Navigation phase: access to methods Once the Domain Analysis (Business Class Diagram) has been defined, the next OO-H modeling phase involves the construction of a navigation view, materialized in a Navigation Access Diagram (NAD). In this diagram, the designer must define the (possibly restricted) views each user type has over the different conceptual classes. These views, known as Navigational Classes (NC), may include both attributes and methods, and are connected by means of Navigational Links (NL), which make up the navigation paths needed to fulfill each user requirement. Also, the NAD provides a package mechanism (known as Navigational

Client idclient name email company discount newclient destroyclient sendmail Payment paymenttype description newpayment destroypayment 1..1 Room roomnumber floor * * people * BookingList /nbookings isvip 1..1 * * newroom destroyroom Booking arrivaldate departuredate customizedprice newbooking modifybooking destroybooking newbookingset * 1..1 Invoice invoicenumber total state newinvoice destroyinvoice 1..1 * Charge date units quantity newcharge destroycharge 1..1 RoomTypes idtype description roomprice newroom_type destroyroom_type * 1..1 Service idservice description unitprice newservice destroyservice Figure2. Hotel Reservation System Class Diagram Target, NT) that allows the designer to define different levels of abstraction. In Fig. 3 we can observe the first level of the NAD diagram corresponding to the receptionist user type, where each subsystem detected in the Use Case Diagram (see Fig. 1) corresponds to a NT. The different NT are accessed via a Collection (C), which is depicted as an inverted triangle, and which represents an access structure that, in this case, gathers the entry points to each NT. Lr: "Entry point" Hotel System Client DN4 Management Hotel Data DN5 Management Booking DN1 Management Figure3. Level 0 NAD Diagram (derived from the Use Case Diagram)

Inside the Booking Management NT (see Fig. 4), we observe how the interface modeled at this level contains the NC and NL necessary to fulfill the Use Cases previously defined for that NT. As an example, the NC Booking info provides access to the arrival dates, departure dates and the price the client pays for the room, as well as to the newbooking() method, which allows the receptionist to introduce new room reservations. Lr:"View Booking Info" [arrivaldate>=$ and departuredate<=$] Client Info: Client name(v) email(v) company(v) Booking Info: Booking arrivaldate(v) departuredate(v) customizedprice(v) Lres:"newBooking OK" S newbooking Ls: "Do New Booking" Li Li Room Info: Room roomnumber(v) floor(v) people(v) Room DN4 Search Client DN5 Search Figure4. NAD corresponding to the Bookings NT Also in Fig. 4 we observe how navigation paths are depicted by means of link constructs, which in OO-H are further categorized according to its purpose. In our example, three types are especially relevant: Requirement Links (Lr) establishes the point from where the user begins to navigate inside each NT. In our example it is depicted by means of an arrow labeled View Bookings, that points at the Booking Info NC (which is a partial view of the Booking domain class, see Fig. 2). Internal links (Li) connect information constructs inside a given NT. In Fig. 4 we observe how the Booking Info NC is the source of two Internal Links that relate the general information regarding each booking with information regarding the specific room and client involved in that booking instance. Last, Service Links (Ls), whose detailed description will be provided in next section, provide the interface to the services the actor is allowed to invoke. In our example, we can observe how the receptionist can access the newbooking() service, which belongs to the Booking Info NC. The dotted arrows departing from such Ls imply that the service depends for its interface definition on the contents of the Client Searh and Room Search NT. Furthermore, Link constructs may have one or more Filters associated. Filters are OCL formulae [26] that constrain navigation. An example of such formulae

can be seen in the Lr View Bookings, which provides access to the Booking Info view. In this case, the associated filter arrivaldate >= $ and departuredate <= $, where the $ symbol stands for user input, restricts the set of target objects to those bookings that are inside the boundaries of a given period. 3 Service Modeling in OO-H We have already mentioned that Service Links (Ls) provide OO-H with the necessary semantics to model the Service Interface. The reason for choosing a navigation construct to define the service interface model is that we agree with [1] in that service invocation and, more precisely, (1) introduction of service parameters, (2) actual invocation of the service and (3) visualization of results, which are the main service interface concerns, always imply user navigation. Next we are presenting the concepts that directly influence the definition of such service links, and that can be seen in the OO-H metamodel depicted in Fig. 5. <<enumeration>> IntroductionModes hidden constant immediate selection navigation Params name type Methods provider 2..N 1..1 1..N CompoundSRP-SL Simple-SL <<enumeration>> VisualizationContext origin destination AtomsMRP cardinality mandatory order CompoundMRP-SL transaction AtomsSRP cardinality mandatory order transaction {overlapping} OutParams visible resultvisualizationcontext ncview SelectionParams oclformula InParams NavigationParams oclformula orglink targetlink nullable OCLdefault introductionmode * < InParams->includesAll(steps->inParams) ParamsSteps cardinality * Steps order * 1..1 ServiceLink 1..1 0..1 MultiStepCollection... Figure5. Service Metamodel 3.1 Categorization of Service Links In Fig. 5 we can observe how, as we stated in section 2.2, ServiceLinks are associated to Methods. Such methods have, among other characteristics, an associated provider, which determines the actual location of the method, and a

set of parameters (Params), which can be further divided into InParams and OutParams. Note how this hierarchy is overlapping: parameters can be introduced to the method and then returned on method completion, possibly with a modified value. Methods can be directly accessed by means of Simple Service Links (Simple- SL), or be an atom of a more general Compound Service. Depending on the provider of each method, Compound Services can be further divided into Compound Single Resource Provider Service Links (CompoundSRP-SL) or Compound Multiple Resource Provider Service Links (CompoundMRP-SL) 3. In both SRP and MRP Compound Services, its Atoms do not necessary know each other and may not be simultaneously accessed again by another application, or even by another user type inside the same application. A special case of Compound Service occurs when there is a single method that is called more than once (with different parameters). That is the reason why, in Fig. 5, CompoundSRP-SL can be associated with just one method (although, if it is the case, the cardinality attribute associated to the AtomSRP must be greater than 1) 4. Last, atoms inside compound Services may be related to each other following a well defined strategy, and may include any kind of data dependency. In this sense, there are specific proposals [20, 13] that tackle both the composition strategies and the data dependencies that may harness the set of methods that make up the Compound Service. These aspects are out of the scope of this article. Next, we are introducing each of the tasks involved in defining a sound web interface to service invocation. 4 Parameter input and result visualization process Going back to Fig. 5, we observe how each service link, regardless of its type, has an associated set of input parameters that, in case of Compound Services, will be made up of the union of the parameters corresponding to each of its atoms. In order to model the user input, OO-H Method distinguishes among five types of Introduction Modes (see Fig. 5): Hidden parameters are not showed in the interface, and so acquire the default value if provided (see attribute OCLDefault in Fig. 5), or a null value otherwise 5. 3 In OO-H, Compound Services that involve more than one method and have an associated execution strategie are also known as Service Chains 4 This constraint is expressed in OO-H by means of the OCL formula self.compundsrp-sl.methods->size()=1 implies self.cardinality>1 5 Of course, if the parameter cannot contain a null value (nullable=false) then a default value is mandatory.

Constant parameters only differ from hidden parameters in that their value is considered to provide relevant information for the user task, and so they appear in the interface, although they cannot be edited. Immediate parameters adopt the value typed by the user by means of any kind of textbox. Selection parameters are given a value by means of a user selection among a set of prefixed values. User Navigation Parameters imply a navigation activity through the model in order to get the desired value. In order to illustrate these introduction modes and how they are stored in the metamodel of Fig. 5, let s suppose the newbooking() service requires the explicitly introduction of four parameters (arrivaldate, departuredate, Client and Room) and that it has another attribute, the customizedprice, that is optional and, if not provided, adopts the value roomprice, which depends on the type of room 6. Let s also suppose that the designer has decide that departuredate, arrivaldate and customizedprice are introduced by means of a textbox, which is modeled by setting the property introductionmode=immediate. However, in order to introduce the Client and Room involved in the booking, let s suppose the designer wants the user to choose an instance from the population of the corresponding classes. In this case, s/he must set introductionmode=navigation, and define the actual navigation path that needs to be followed in order to get the parameter value. In our example there are no navigation paths that can be reused for such purpose, and so new navigation paths have been defined inside the Client Search and Room Search NT. In Fig. 6 we observe the contents of the Room Search NT. This NT includes a set of alternative paths, namely Search by Type, Search by Room Number and Search among all rooms that can be used to select the value of the Room parameter. Once the desired navigation paths have been designed, the association of such paths to a given input parameter can be performed in two ways: Definition of the initial and final link of the navigation path. Introduction, by means of OCL expressions, of the whole navigation path. This mechanism is useful when the NAD has many navigation forks, and we are interested in the user to be offered just one (or a small set) of them. Back to our example, if we set the Find Room as the initial link for the parameter input, and Room Selected as the final link, all possible paths in between will be available for the user to enter the parameter value once s/he has activated the service, namely Search by Type, Search by Room Number and Search among all rooms. If, on the contrary, the designer introduces a given path such as findroom->allrooms, the user will only be offered the possibility to choose among a list of rooms, while the rest of alternatives remain hidden. Note how 6 This default value is modeled by means of the assignment of the OCL formula bookinglist.room.roomtypes.roomprice to the metamodel attribute OCLDefault.

Lr:"findRoom" Find a Room Li:"byType" Li:"byRoomNumber" [roomnumber=$] Room Types: RoomType description(v) roomprice(v) Li:"allAvailableRooms" Li:"allRoomsOfType" Available Rooms: Room roomnumber(v) floor(v) people(v) ExP:"Room Selected" Figure6. NAD for the Search Room NT associated with the newbooking() service this mechanism provides a very simple yet powerful way of reuse of the navigation paths designed inside the boundaries of our system. However, this mechanism on its own is not enough to model some very common situations of web service interfaces: the division of the input process into more than one service step (see Fig. 5), which is a must for complex service interfaces. OO-H specifically tackles such situations, and extends such introduction modes with a new construct, which is showed next. 4.1 Multi-step service interfaces Multi-step interfaces can be associated either to simple or compound services. They involve the division of the attributes that must be introduced among a set of abstract pages, with the peculiarity that the user may go back and forth until s/he decides to activate the service. In order to model such situation, OO- H defines a Multi-Step Collection (MC). MC collections share with traditional collections the grouping role. However, associations departing from MC s are sorted, what provides an order to the steps. In our example (see Fig. 7), and in order to illustrate the use of Multi-step Collections, let s suppose we have introduced a new method called newbookingset(), which provides the receptionist with the possibility of booking more than one room at a time for a given client and dates, in order to speed the booking task.

Lr:"Multi Booking" MULTI STEP Li:"STEP 1 [1..1] [Client]" Li:"STEP 3 [1..1] [arrivaldate, departuredate]" Booking: Booking Li:"STEP 2 [1..N] [Room]" newbookingset Ls: "Save all Bookings" C Figure7. MultiStep Service Modeling This new Compound Service involves a loop on the method newbooking(), once for each room selected. The iteration on the method is captured by means of the cardinality attribute associated to the AtomSimpleSL metaclass (see Fig. 5). Each one of the steps also have an associated cardinality, which can be either one (meaning that only the last value introduced is stored and reused for each iteration of the given method) or the value corresponding to the number of iterations, in which case the system keeps a list with the set of values introduced by the user, and it provides one of such values each time the method is invoked (what, furthermore, causes the consuption of that value and its deletion from the list). Back to our example, the Compound newbookingset() method implies that the AtomSRP.cardinality associated to the newbooking() (only) atom is set to N. On the other hand, in Fig 7 we can observe how the separation of parameters in different interface steps is modeled in OO-H. In our example, user input has been divided into three steps: first (STEP 1) the user must choose the client (first parameter of the compound service). The attribute ParamsSteps.cardinality=1..1 (see Fig. 5) means that this value will be reused in every iteration on the method. Then (STEP 2) the user enters the set of desired rooms. Note how this time the attribute ParamsSteps.cardinality=1..N implies that more than one room can be selected (one for each time the method is invoked). Last (STEP 3), the user must introduce the arrival and departure dates for all the bookings involved in the newbookingset() service. The receptionist can go back and forth as many times as desired, until s/he decides every data is correct. Then, s/he activates the service, and gathers the results. The previous example already introduces some very simple way of data dependency: the sharing of a value among different calls to the same service. However, more complex dependencies between services and/or service data inside these compound services is better modeled by means of activity diagrams. Some recent approaches (see e.g. [20]) develop these ideas in depth, and center on the definition of workflow and data dependencies of services that are invoked

independently during the life of the user session or even the life of the whole application. OO-H tackles such problem by means of Activity Diagrams associated to Compound Services, whose description remains, due to space constraints, out of the scope of this article. 4.2 Visualization of results The visualization of return values once the service is completed (be them actual out parameters or error messages), follows the same philosophy than that of parameter input. Each output parameter (see Fig. 5) has three associated attributes: on one hand the designer must specify whether this result value must be presented to the user or not (visible=true/false) and, on the other hand, whether such result must be presented in the result abstract page or just referenced (resultvisualizationcontext=origin/destination). Also, if the results involve instances of a given class, the attribute NCView allows the designer to reuse the navigation information and determine the visualization structure of each object returned. Once the desired results have been presented, the destination of the service link (in our example labeled as newbookingok, see Fig. 4) determines the point from which the user is allowed to continue the navigation through the system. 5 Invocation Process: the service model footprint Finally, and once the Navigation Model has been defined, OO-H includes a presentation design model that captures interface architecture and presentation. Although the definition of such model is out of the scope of this article, it is important to note how the interface description is formalized in a taxonomy of XML templates, where each template gives a different interface perspective. The result is a graph of XML abstract pages whose interrelations are showed in a diagram called Abstract Presentation Diagram (APD). Inside this taxonomy, the templates that gathers the footprint of the service model are, namely: tform: it reflects parameter-related information. tlogic: it associates interface values to service parameters, and provides the necessary information to generate the calling message. TForm documents include, for a given service, information regarding (possibly) multi-page input of parameters: type, cardinality, default values, associated interface step and so on. As an example, we present the XML specification corresponding to the well know service newbooking(). <?xml version="1.0" standalone="no"?> <!DOCTYPE tform SYSTEM "C:\Archivos de programa\les Objects 1.0a\XMLLib\tForm.dtd"> <tform id="donewbooking_form" tlogicid="donewbooking_logic"> <!-- Client parameter-->

<param id="donewbooking.aclient" type="client" validate="no"> <input mode="navigation" begin="findclient" end="clientfound" default=""/> <label id="donewbooking.aclient_label"/> <step id="1" minoccurs="1" maxoccurs="1"> </param> <!-- Room parameter --> <param id="donewbooking.aroom" type="room" validate="no"> <input mode="navigation" begin="findroom" end="roomfound" default=""/> <label id="donewbooking.aroom_label"/> <step id="1" minoccurs="1" maxoccurs="1"> </param> <!-- ArrivalDate parameter --> <param id="donewbooking.anarrivaldate" type="string" validate="no"> <input mode="immediate" default=""/> <label id="donewbooking.arrivaldate_label"/> <step id="1" minoccurs="1" maxoccurs="1"> </param> <!-- departuredate parameter --> <param id="donewbooking.adeparturedate" type="string" validate="no"> <input mode="immediate" default=""/> <label id="donewbooking.departuredate_label"/> <step id="3" minoccurs="1" maxoccurs="1"> </param> </TForm> In this example, self-explanatory, we can observe how all the characteristics modeled at NAD level are preserved in this textual description. Inside the tform document, only visible parameters (that is, those whose introduction mode is not hidden) are shown, and each param element maintains its related information. Also, in this document the in/out/in-out categorization of parameters is reflected by means of the set of tags associated: <input> tags are associated to in parameters; <output> tags are associated to out parameters, and both tags are associated to in-out parameters. TForm documents contain, as part of its header, an attribute that associates it to an instance of the TLogic template. This template is being introduced in next section. 5.1 OO-H Service Invocation: implementation issues Documents falling in the tlogic category contain the needed information to allow the generation of the actual call to the underlying services. At this point of development, the OO-H solution architecture realizes a set of key assumptions about service providers, the most important being that a service provider exposes the functionality as SOAP services. The main reason for this restriction is that SOAP overcomes many of the problems encountered over heterogeneous

architectures and platforms [16], as for example the problem of firewall filtering of non-http requests, and which have not been totally solved by well-known middleware platforms such as CORBA, RMI or DCOM. As an example, the tlogic document corresponding to our new Booking() service call instance, is presented next: <TLogic id="donewbooking_logic"> <service id="newbooking" method="newbooking" type="soap-service" endpoint="http://www.gplsi.ua.es/soap/demo/servlet/servicerouter" minoccurs="1" maxoccurs="1"> <provider id="es.myhotel.bookings"/> <parameter id="aclient" param_value="donewbooking.aclient"/> <parameter id="aroom" param_value="donewbooking.aroom"/> <parameter id="anarrivaldate" param_value="donewbooking.anarrivaldate"/> <parameter id="adeparturedate" param_value="donewbooking.adeparturedate"/> <parameter id="price" ref_value=""/> </service> </TLogic> In this specification, the endpoint tag provides the string to perform the actual connection. Note also how the actual provider of the method must have a globally unique identifier associated, and the service id be also unique inside such provider context. Inside the tlogic documents, each method parameter has an associated value, which may be provided (1) by the corresponding tform document (see the param value attribute of the parameters aclient, aroom, anarrivaldate or adeparturedate), (2) by an expression (which would be included as a ref value attribute associated to the corresponding parameter) or (3) be directly introduced by means of a value attribute (see the price parameter). Note how, were we dealing with Compound Services, we could have more than one instance of the service tag, and/or an associated cardinality greater than one. Also, we would like to stress the fact that both SRP and MRP Compound Services may involve a user internet transaction, and that in such case concerns such as Privacy, Loyalty or maintenance of ACID properties (also known as PLACID concerns [2]) must be preserved when designing the actual invocation policy. The specification of internet transactions has already been tackled at different levels of abstraction in several proposals (see e.g. the characterization of I-Transactions presented in [2], the XML transactional languages such as [6, 19] or the proposed Transaction Internet Protocol[14]).These concepts, although critical for the correct implementation of such services, fall out the scope of this paper, which just aims at providing a mechanism for the interface definition of services, be them transactional or not.

6 Conclusions and further work This paper has presented an extension to the OO-H conceptual modeling approach for the specification of user-service interaction (feeding of parameters, invocation of services, either simple or compound, and view of service results). This approach increases the level of abstraction at which web applications have been traditionally developed and integrated. Furthermore, OO-H is supported by a CASE tool that, at this stage of development, already provides a model compiler for the automatic generation of interface prototypes. The main contributions of this paper can be summarized as follows: An integration process that, departing from traditional software engineering techniques, extend the views provided by such approaches with a set of new complementary hypermedia views that include server interface definition. A set of interaction modes that define the way the user can introduce the values for the set of parameters involved in the service invocation. The formalization of the service invocation constructs by means of two XML templates that gather the abstract interaction (tform) and invocation (tlogic) semantics. A set of modeling constructs that abstract the definition of Multi-Step interfaces. At this moment efforts are being made towards the support of Compound Services that involve Internet Transactions. Also, we are working on the evolution of the OO-H XML template specification to achieve fully compliance with other well known XML specifications such as the XForms[8] or WSUI[28]. Furthermore, intensive work is being performed on the OO-H Case tool to provide full support to the method. References [1] M. Bieber, H. Oinas-Kukkonen, and V. Balasubramanian. Hypertext Functionality. ACM Computing Surveys, 31(4), 12 1999. [2] D. Billard. Transactional Services for the Internet. In International Workshop on the Web and Databases (WebDB), 1998. [3] C. Cachero, J. Gómez, A. Párraga, and O. Pastor. Conference Review System: a Case of Study. In Proceedings of First International Workshop on Web-Oriented Software Technology IWWOST 01, pages 195 227. Valencia University of Technology, 06 2001. [4] S. Ceri, P. Fraternali, and A. Bongio. Web Modeling Language (WebML): a modeling language for designing Web sites. In Proceedings of the 9th International WWW Conference, 05 2000. [5] J. Conallen. Modeling Web Application Architectures with UML. CACM: Communications of the ACM., 42(10):63 70, 10 1999. [6] Microsoft Corporation. Web Services for Business Process Design. www.gotdotnet.com/team/xml wsspecs/xlang c/default.html, 2001.

[7] Directory Services Markup Language. http://www.dsml.org/. [8] extensible Markup Language (XML). http://www.w3.org/xml/. [9] Inc. Gartner Group. The Future of Web Services: Dynamic Business Webs. Market Analysis, 02 2001. [10] H.W. Gellersen and M. Gaedke. Object-Oriented Web Application Development. IEEE Internet Computing, pages 60 68, 01 1999. [11] J. Gómez, C. Cachero, and O. Pastor. Extending a Conceptual Modelling Approach to Web Application Design. In 12 th International Conference on Advanced Information Systems (CAiSE 00), volume 1789, pages 79 93. Springer-Verlag. Lecture Notes in Computer Science, 06 2000. [12] J. Gómez, C. Cachero, and O. Pastor. Conceptual Modelling of Device- Independent Web Applications. IEEE Multimedia Special Issue on Web Engineering, pages 26 39, 04 2001. [13] F. Leymann. Web Services Flow Language. www- 4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf, 05 2001. [14] J. Lyon, K. Evans, and J. Klein. Transaction Internet Protocol (TIP). Technical Report, 02 1999. [15] F. Manola. Technologies for a Web Object Model. IEEE Internet Computing, pages 38 47, 01 1999. [16] D. Martin, M. Birbeck, and et al. Professional XML. WROX, 01 2000. [17] G. Mecca, P. Merialdo, and P. Atzeni. Araneus in the era of XML. IEEE Data Engineering Bulletin, 42(10):63 70, 10 1999. [18] S. Murugesan, Y. Deshpande, S. Hansen, and A. Ginige. Web Engineering: A New Discipline for Development of Web-based Systems. In Proceedings of First ICSE Workshop on Web Engineering, 05 1999. [19] Standard Proposal. Transaction Authority Markup Language. www.xaml.org, 2001. [20] J. Rodríguez and O. Díaz. Moving Service Dependencies at the Presentation Layer. In International Conference on Software Engineering (ICSE 02) (To be published). ACM, 2002. [21] D. Schwabe and R. Almeida Pontes. A Method-based Web Application Development Environment. In Proceedings of the 8th International WWW Conference, 1999. [22] Simple Object Access Protocol. http://www.develop.com/soap/. [23] Universal Description, Discovery and Integration. http://uddi.microsoft.com/. [24] User Interface Modeling Language. 16. UIML http://www.uiml.org. [25] UML Specification. V1.3. http://www.rational.com/uml/index.jsp, 06 1999. [26] OMG Unified Modelling Language Specification. http://www.rational.com/uml/, 06 1999. [27] Web Services Description Language. http://msdn.microsoft.com/xml/general/wsdl.asp. [28] WSUI Specification. Working Draft. V1.0. http://www.wsui.org, 10 2001.