Modeling Service Integration in Web Applications

16  Download (0)

Full text


Modeling Service Integration in Web


Cristina Cachero1, Jaime G´omez1, and Oscar Pastor2 1

Departamento de Lenguajes y Sistemas Inform´aticos Universidad de Alicante. SPAIN



Departamento de Sistemas Inform´aticos y Computaci´on Universidad Polit´ecnica de Valencia. SPAIN

Abstract In the last years integration of service invocation in the con-text 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 pro-posal for the seamless integration of both single and multi-step service calls in the context of a cohesive user interface. The notation and seman-tics 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 inde-pendence of the interface models from both business logic and interface target technologies.



In the last few years we have witnessed how existing and to come Web tech-nologies have induced much more flexible distributed environments where new business opportunities have appeared, but also new risks related to software de-velopment [18]. Although the scientific community agrees in that, in order to keep the possibility of failure to a minimum, the development process for en-terprise applications should evolve in a Web Engineering manner, there is no agreement at how the core activities behind a sound Web Application devel-opment 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 infor-mation 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 idiosyn-crasy 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 De-scription, 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 nu-ances 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 spe-cific 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 In-ternet. 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 ac-cessed. 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, mak-ing 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.


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 de-velopment of web based interfaces, and its connection with previously existing application logic modules2.

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

Man-agement andBooking 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 corre-sponds 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.


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.


add Booking RECEPT. view Bookings given a date update Booking delete Booking manage payment types print invoice manage rooms manage service types manage room types add charge to room register Client Entrance add Client Client Management Booking Management

Hotel Data 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 (itsclass orinstance scope, its associated

is-Querytagged 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 aBookingList, 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 correspondingBooking. 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 ofPayment 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, material-ized in a Navigation Access Diagram (NAD). In this diagram, the designer must define the (possibly restricted) views each user type has over the different con-ceptual 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 require-ment. Also, the NAD provides a package mechanism (known as Navigational


Client idClient newclient destroyClient name email company discount sendMail Room roomNumber newRoom destroyRoom floor people RoomTypes idType newRoom_type destroyRoom_type description roomPrice Booking arrivalDate newBooking modifyBooking departureDate customizedPrice destroyBooking Charge date newCharge destroyCharge units quantity Service idService newService destroyService description unitPrice Invoice invoiceNumber newInvoice destroyInvoice total state * * * 1..1 1..1 * * 1..1 1..1 * Payment paymentType newPayment destroyPayment description 1..1 * BookingList /nBookings isVIP 1..1 * newBookingSet

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.

Hotel System DN1 Booking Management DN4 Client Management DN5 Hotel Data Management Lr: "Entry point"


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 NCBooking 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.

Client Info: Client

Room Info: Room Booking Info: Booking

arrivalDate(V) departureDate(V) customizedPrice(V) name(V) email(V) company(V) roomNumber(V) floor(V) people(V) newBooking S DN4

Room Search Client SearchDN5


Li Ls: "Do New Booking"

Lres:"newBooking OK"

Lr:"View Booking Info" [arrivalDate>=$ and departureDate<=$]

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 labeledView Bookings, that points at theBooking Info NC (which is a partial view of theBooking domain class, see Fig. 2).

– Internal links (Li) connect information constructs inside a given NT. In Fig. 4 we observe how theBooking 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

newBook-ing() service, which belongs to the Booking Info NC. The dotted arrows

departing from such Ls imply that the service depends for its interface defi-nition on the contents of theClient Searh andRoom 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 LrView Bookings, which provides access to theBooking Info

view. In this case, the associated filterarrivalDate>=$ 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.


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. {overlapping} < InParams->includesAll(steps->inParams) Methods InParams nullable OCLdefault introductionMode Params name type CompoundMRP-SL CompoundSRP-SL Simple-SL 1..1 1..N Steps order * * AtomsMRP AtomsSRP cardinality cardinality mandatory mandatory order order 2..N transaction transaction provider OutParams visible resultVisualizationContext SelectionParams IntroductionModes<<enumeration>> NavigationParams VisualizationContext<<enumeration>> oclFormula oclFormula orgLink targetLink hidden constant immediate selection navigation origin destination ServiceLink 1..1 * MultiStepCollection 0..1 1..1 ... ParamsSteps cardinality ncView

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 toMethods. Such methods have, among other characteristics, an as-sociated 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

intro-duced 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 Com-pound Single Resource Provider Service Links (CompoundSRP-SL) or Com-pound Multiple Resource Provider Service Links (CompoundMRP-SL)3. In both SRP and MRP Compound Services, itsAtomsdo 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 theAtomSRP must be greater than 1)4.

Last, atoms inside compound Services may be related to each other follow-ing 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.


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

ofIntroduction Modes (see Fig. 5):

– Hidden parameters are not showed in the interface, and so acquire the

de-fault value if provided (see attributeOCLDefault in Fig. 5), or a null value otherwise5.


In OO-H, Compound Services that involve more than one method and have an associated execution strategie are also known asService Chains


This constraint is expressed in OO-H by means of the OCL formula

self.compundSRP-SL.methods->size()=1 implies self.cardinality>1


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 thenewBooking()service requires the ex-plicitly 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 room6. 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 andRoom 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 setintroductionMode=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

theClient Search andRoom SearchNT. In Fig. 6 we observe the contents of the

Room Search NT. This NT includes a set of alternative paths, namelySearch by

Type, Search by Room Number and Search among all rooms that can be used to

select the value of theRoom 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 theFind Room as the initial link for the pa-rameter input, andRoom 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 acti-vated the service, namelySearch 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 to the metamodel attributeOCLDefault.


Find a Room

Room Types: RoomType

Available Rooms: Room

roomNumber(V) floor(V) people(V) description(V) roomPrice(V) ExP:"Room Selected" Li:"allRoomsOfType" Li:"byType" Li:"allAvailableRooms" Li:"byRoomNumber" [roomNumber=$] Lr:"findRoom"

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 naviga-tion paths designed inside the boundaries of our system.

However, this mechanism on its own is not enough to model some very com-mon situations of web service interfaces: the division of the input process into more than oneservice step(see Fig. 5), which is a must for complex service inter-faces. 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

newBook-ingSet(), 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.


MULTI STEP Booking: Booking C Lr:"Multi Booking" Li:"STEP 1 [1..1] [Client]" Li:"STEP 2 [1..N] [Room]"

Li:"STEP 3 [1..1] [arrivalDate, departureDate]"


Ls: "Save all Bookings"

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 thecardinality attribute associated to theAtomSimpleSLmetaclass (see Fig. 5). Each one of the steps also have an associatedcardinality, 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 it-erations, 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 CompoundnewBookingSet()method implies that theAtomSRP.cardinality associated to thenewBooking()(only) atom is set toN.

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 attributeParamsSteps.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 de-pendency: the sharing of a value among different calls to the same service. How-ever, 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 ap-plication. 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 ac-tual 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 ref-erenced (resultVisualizationContext=origin/destination). Also, if the results in-volve 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 desti-nation of the service link (in our example labeled asnewBookingOK, see Fig. 4) determines the point from which the user is allowed to continue the navigation through the system.


Invocation Process: the service model footprint

Finally, and once the Navigation Model has been defined, OO-H includes a pre-sentation design model that captures interface architecture and prepre-sentation. 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 (possi-bly) multi-page input of parameters: type, cardinality, default values, associated interface step and so on. As an example, we present the XML specification cor-responding to the well know servicenewBooking().

<?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>


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 pa-rameters; <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 assump-tions 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="" 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, theendpoint tag provides the string to perform the ac-tual connection. Note also how the acac-tual 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

in-cluded as a ref value attribute associated to the corresponding parameter) or (3) be directly introduced by means of avalue attribute (see theprice parame-ter). 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.



Conclusions and further work

This paper has presented an extension to the OO-H conceptual modeling ap-proach 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 invoca-tion (tLogic) semantics.

– A set of modeling constructs that abstract the definition of Multi-Step in-terfaces.

At this moment efforts are being made towards the support of Compound Services that involve Internet Transactions. Also, we are working on the evolu-tion of the OO-H XML template specificaevolu-tion to achieve fully compliance with other well known XML specifications such as the XForms[8] or WSUI[28]. Fur-thermore, intensive work is being performed on the OO-H Case tool to provide full support to the method.


[1] M. Bieber, H. Oinas-Kukkonen, and V. Balasubramanian. Hypertext Functional-ity. ACM Computing Surveys, 31(4), 12 1999.

[2] D. Billard. Transactional Services for the Internet. InInternational Workshop on

the Web and Databases (WebDB), 1998.

[3] C. Cachero, J. G´omez, A. P´arraga, and O. Pastor. Conference Review System: a Case of Study. InProceedings of First International Workshop on Web-Oriented Software Technology IWWOST’01, pages 195–227. Valencia University of Tech-nology, 06 2001.

[4] S. Ceri, P. Fraternali, and A. Bongio. Web Modeling Language (WebML): a

modeling language for designing Web sites. InProceedings of the 9th International

WWW Conference, 05 2000.

[5] J. Conallen. Modeling Web Application Architectures with UML. CACM:

Com-munications of the ACM., 42(10):63–70, 10 1999.

[6] Microsoft Corporation. Web Services for Business Process Design.


[7] Directory Services Markup Language. [8] eXtensible Markup Language (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´omez, C. Cachero, and O. Pastor. Extending a Conceptual Modelling

Ap-proach to Web Application Design. In 12thInternational Conference on Advanced

Information Systems (CAiSE’00), volume 1789, pages 79–93. Springer-Verlag. Lec-ture Notes in Computer Science, 06 2000.

[12] J. G´omez, C. Cachero, and O. Pastor. Conceptual Modelling of

Device-Independent Web Applications. IEEE Multimedia Special Issue on Web

Engi-neering, pages 26–39, 04 2001.

[13] F. Leymann. Web Services Flow Language., 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. InProceedings of First ICSE Workshop on Web Engineering, 05 1999.

[19] Standard Proposal. Transaction Authority Markup Language., 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

Develop-ment EnvironDevelop-ment. In Proceedings of the 8th International WWW Conference,


[22] Simple Object Access Protocol.

[23] Universal Description, Discovery and Integration. [24] User Interface Modeling Language. 16. UIML

[25] UML Specification. V1.3., 06 1999. [26] OMG Unified Modelling Language Specification.,

06 1999.

[27] Web Services Description Language. [28] WSUI Specification. Working Draft. V1.0., 10 2001.