Separating Business Process from User Interaction in Web-Based ...

Electronic Commerce Research, 3: 83–111 (2003)  2003 Kluwer Academic Publishers. Manufactured in the Netherlands.

Separating Business Process from User Interaction in Web-Based Information Commerce ∗ KARL ABERER ∗∗ , ANWITAMAN DATTA and ZORAN DESPOTOVIC {karl.aberer, anwitaman.datta,zoran.despotovic}@epfl.ch Swiss Federal Institute of Technology (EPFL), Switzerland ANDREAS WOMBACHER Fraunhofer IPSI, Germany

[email protected]

Abstract In Web-based information commerce it is diffcult to disentangle presentation from process logic, and sometimes even data is not separate from the presentation. Consequently, it becomes crucial to define an abstract model for business processes and their mapping into an active user interface presentation, using the principle of separation of concern. We endeavor to extend XSLT to accommodate the separation of process information from the data structure and presentation. We support declarative design further by a language designed to concisely specify information commerce processes. The isolation of the aspects of data, process and presentation makes it easier for developers to work independently and to focus on their primary responsibility. Keywords: web-based information systems, e-commerce systems, user interface, XSLT, workflow management, information commerce

0. Introduction and motivation As modern markets move rapidly onto electronic platforms, e-commerce and e-business are becoming key terms in todays economy. E-commerce addresses the trading of physical goods, such as books, food, computers and appliances. Information commerce, i.e., trading information goods, like news, software, or reports, is even more attractive over electronic channels, since goods can be distributed through the same infrastructure. We find nowadays many popular examples of information commerce on the Internet. This ranges from commercial services originating in the old economy, like digital libraries provided by scientific publishers, over new economy applications, like auction market places or information portals, to information exchange communities, like Napster or Gnutella [Oram, 13]. Models and infrastructures for reliable information commerce constitute an area of active research and development with many technical challenges, such as delivery mecha∗ The work presented in this paper was supported (in part) by the National Competence Center in Research on

Mobile Information and Communication Systems (NCCR-MICS), a center supported by the Swiss National Science Foundation under Grant number 5005-67322. ∗∗ Corresponding author.

84

ABERER ET AL.

nisms, copyright issues, tamper-resistance, adequate payment facilities, non-repudiation and information quality. We envisage an infrastructure for information vendors who sell specific pieces of information, information mediators, who buy, recombine and resell information, and information brokers who provide directories of information vendors together with added-value information. We assume that information has an associated value, that requires controlled access in an individualized manner and guarantees concerning the quality and authenticity of the information. In such a setting the different properties associated with an information product as well as the corresponding interaction between buyers and sellers need to be specified in a highly configurable yet unambigous way. This is an adequate assumption for many application types, like portal sites, electronic news services, stock market information services, software evaluation services, or directory services. This setting is our motivation to develop a framework for the implementation of information commerce applications. The framework takes into account the requirements both of process management and user interaction. It consists of a process language specifically tailored to the needs of information commerce and is using a light-weight infrastructure built on the XML standard family, in particular XSLT. Though the framework is specifically designed for information commerce it is nevertheless applicable to other types of service-oriented Web applications. One of the main reasons for the success of XML as a basic infrastructure for the Web is the separation of document structure from document layout, which constitutes a major factor in developing content-oriented applications in a more modular and efficient fashion. The logical structure of the document content or the document data is represented in a layout-independent format. The generation of the user interface layout, e.g., in HTML, is performed by specialized document processing languages, like XSLT [Kay, 7]. This approach has the well-known advantages of separation of concerns: development and processing of the data can make use of application-specific data schemas (“application markup”). Thus changes in the presentation do not affect the logical structure of the documents, which realizes a form of logical data independence. Multiple layouts for different media can be generated from the same logical documents. Considering the function of a service-oriented Web site, such as an information commerce site, we must be aware that it’s purpose goes beyond the presentation of document content and data. In fact it represents an active document supporting interactions among users and backend systems. There exist nowadays various implementation approaches for dynamic Web pages, like CGI scripts, active server pages, servlets and JSP. The business processes that are implemented using these techniques are hidden in the application code (and often the logical data structures as well). On the other hand the area of workflow management systems has demonstrated that an abstract representation of complex business processes is extremely beneficial in their development, maintenance and implementation. Also here we find an independence principle realized, namely the independence of the process structure, usually expressed in terms of an abstract process model, like Petri nets or state charts, from the implementation of the processes, by associating various system and user resources with the activities to be performed. This brings us to the question, whether the independence of the implementation of the active parts of a Web page, in terms of what interactions a user may perform within a

SEPARATING BUSINESS PROCESS FROM USER INTERACTION

85

business process, from the actual abstract specification of the process structure would not be a valuable goal to achieve and if yes, how it may be reached. This is a problem that we intend to address. We will show that such a separation of concerns is indeed possible and that it can be achieved in a Web context, with minimally invasive extensions of existing approaches, in particular the one of XSLT [Kay, 7]. In other words, we will extend XSLT in a way, such that both process and data structure can be transformed into active Web pages. Doing so, we also intend to maintain the declarative nature of XSLT, allowing a rule-oriented specification of the layout-oriented transformations. We will achieve, following the principle of orthogonality, a separation of concerns along two dimensions: • Content and process. Web applications consist of the content presented and the process underlying the interaction with the user. Only the ensemble of the two allows to fully characterize a service-oriented Web site. • Structure and presentation. Structure provides a logical view of the application, whereas presentation is concerned with the user interaction. For both, content and process, we want to achieve independence of structure and presentation. Separation of concerns facilitates the development of service-oriented Web sites by making it more modular. Changes that affect one concern do not affect the other ones. Examples would be: • Changes to the user interface do not affect the logical representation of the data as well as the processes. • Changes to the process logic (e.g., the control flow) can be made independently of the specifications of the layout transformations, and even can be done without affecting existing transformations (and similarly for the data structures, as it is known for XSLT). • Control of the process flow (workflow logic) and generation of user interface layout can be independently distributed as required (client, server). • Developers can concentrate on the aspects they are interested in (process structure, data structures, layout). When developing the process and data structures, layout aspects can be ignored, and when developing the layout only a partial understanding of the structured specification is required (e.g., only activity types but not their detailed dependencies). Also using more abstract models for specifying the structural models facilitates their understanding. Declarative specifications increase the modularity of specifications and allow for increased ease of the evolution in applications. Thus we follow the XSLT paradigm for layout specification. Declarativity is also one of our design goals for process specification. Though there exist a plethora of approaches to specify and analyse business processes for electronic commerce, we found that none of them are both of declarative nature and support the specific characteristics of information commerce processes sufficiently. Therefore we will introduce a declarative modelling language that we have specifically designed to capture the essential concepts of information commerce processes. We identified the following important constituents for information commerce process languages:

86

ABERER ET AL.

• Direct representation of the communication acts occurring in a business process: we view information commerce processes as interdependent communications among the participants in which information goods are exchanged. The communication actions are based on the information good specifications and trading roles, and are the elementary constitutent of the model. • Rule-based process specification. The process specifications are composed from these communication acts by means of condition-action-rules. From the highly declarative process specification all the message exchanges that are required in an information commerce process are derived. The process specification defines which actions are possible to execute. • Obligation semantics. By associating with certain combinations of communication acts obligations we can distinguish admissible execution of actions from obligatory execution. This allows to make actions interdependent in a way that all participants are driven toward the completion of a business process in order to achieve certain execution goals. Having such an information commerce language makes it easier to develop, analyze and adapt the specifications of information commerce processes. Combining a declarative framework for layout specification and process specification results in a highly flexible and easy to use infrastructure for specifying Web-based applications that strictly separates layout, process and content. With respect to implementation we pay attention to avoid any dependencies on heavyweight infrastructure, like application servers. Our architecture will consist mainly of an XSLT interpreter that is extended by a process control component. It will be light-weight, making implementation of complete applications, like C2C business processes, which are purely client-based, perceivable. Hence our approach will also be an ideal platform to implement business processes in P2P environments. The rest of the paper is organized as follows. In Section 1 we discuss related work, then in Section 2 we provide a generic overview of basic abstractions we devised. Section 3 contains the description of the information commerce process language we use. Section 4 introduces details of the implementation architecture of the specific worfklow model aware style sheet extensions, followed by an application example illustrating several methodological aspects of the approach in Section 5. Section 6 concludes the paper with a summary.

1. Related work After it started as a network-based information system offering only static content (pure HTML), the Web has now become a platform for highly sophisticated applications delivering dynamic content to its users. In this section we discuss different solutions that enable dynamic behavior of the Web—both commercial solutions as well as some of the latest research on that issue. We can identify two main categories of related work: approaches that are aiming at the integration of business processes with components for user interaction and approaches for modelling of business processes on the Web.

SEPARATING BUSINESS PROCESS FROM USER INTERACTION

87

With respect to integration of business processes with user interaction components, we are interested in the separation of concern principles that we have addressed in the introduction. With respect to business processes modelling we will concentrate our evaluation on the aspect of declarativity and flexibility of use.

1.1. Business processes and their presentation The separation of the content from the presentation does not seem to be a major problem nowadays. The appearance of XML is usually (and wrongly) tied with solving this problem. Essentially, any Web-DBPL integrator tool (such as Microsoft’s Internet Database Connector (IDC) or Allaire’s Cold Fusion Web Database Construction Kit) or any Web database publishing tool (Microsoft Access is a typical example) provide a solution for this problem. No matter what kind of database connectivity they use (proprietary or not) they can be looked at as belonging to a large group of scripting (or programming) language based HTML extensions, main representatives of which are ASP or JSP as well as Java servlet based solutions. Also a number of research efforts were directed to support the design of data-intensive Web sites. However user interaction is considered there for the purpose of data navigation only (see, for example, [Fraternali, 4] for a comprehensive overview). But the real problems start when it comes to the separation of the business processes from the presentation. The first group of solutions—CGI scripts and servlets1 —does not offer anything to help developers separate the business processes from the presentation. With servlets, for example, the entire page must be composed in a servlet. More precisely, HTML tags and presentation code are embedded within Java code. The most important consequence is that if a developer wanted to make any change in the appearance of the page he would have to edit and recompile the servlet, which obviously presents not only a development but also maintenance and evolution nightmare. A considerable improvement was brought by server side scripting solutions—ASP and JSP in the first place. Essentially, JSP [Geary, 5] offers a possibility to encapsulate the application logic into software components (JavaBeans) with well-defined interfaces expressed in XML (tag libraries) that can be easily used by the page designers. Thus, application logic is separated from the presentation and both application logic and presentation can be changed without affecting each other. But there is still one problem. JSP does not support process definition on a high abstraction level which makes it difficult (if not impossible) to specify process-aware UI mapping with JSP. Client-side scripting can help here but such solutions become cumbersome even for simple business processes. Another evolving approach from Apache’s Cocoon project, namely XSP [McLaughlin, 10] provides means to add programming logic to XML documents. The XSP document can also be generated from ordinary XML document using XSLT transformation, thereby introducing the XSP related programming logic. This is an improvement to XML, since XML in itself has only structured data/content, and no means for scripting, however such programming scripts too do not help in separating the process logic from content (just like JSP). Such initiatives, on the other hand are complementary to our work, and XSP or other XML-

88

ABERER ET AL.

oriented extensions, in conjunction with our approach of separating the three dimensions of process logic, content and presentation can revolutionize the emerging workflow and Web service related research and technology. Another interesting approach that bears some similarity to ours is the WSUI initiative [Anuf, Chaston and Moses, 2]. WSUI defines a Web component model that couples network services with interaction and presentation. The presentation of a component is defined as a set of XSLT stylesheets that work independently of the business logic of the component. This essentially means that, as with JSP, the second of our two objectives is achieved. But there are some unnatural limitations of the approach taken there. Namely, the layout of the components is not defined in terms of the state the component can be in, but in terms of events that it can respond to. Rodriguez and Diaz [14] present an interesting approach that advocates the same principles as ours. They essentially provide a possibility to define a process of WSUI components. Compared to our approach, the main difference is the fact that they start in the design from active HTML pages and bind to those the process logic explicitly, whereas we intend to generate those pages from a rule-based specification. Thus our approach is more flexible and efficient in particular when generating multiple layouts for different platforms. 1.2. Business process modelling Mechanisms for the specification of interaction processes in electronic commerce are described in many different contexts, both in standardization and research. We summarize in the following some of the important approaches, namely EDI protocols, Web standardization intitatives, crossorganizational information systems, and agent communication languages. Web-based EDI is gaining substantial momentum with the growing importance of the Web as a B2B e-commerce infrastructure. Many initiatives are currently under way for defining—or redefining—EDI standards for the Web architecture using XML as the underlying data exchange language. Examples are ebXML, RosettaNet, or the Internet Open Trading Protocol, just to name a few. These standards are based on predefined process models that capture common, standard business processes for electronic commerce. In this way they provide elaborate but static specifications of e-commerce processes as well as their corresponding domain models and message formats. In the context of Web standardization a number of standards have evolved that address different aspects of information commerce. A representative example is the Information and Content Exchange Protocol ICE [Wombacher and Aberer, 16]. ICE is a protocol that supports the exchange of content, like catalog data or news items, in B2B applications. It provides a negotiation protocol to determine the delivery modalities and an exchange protocol to perform the information exchange itself. As for Web-based EDI this standard provides a static process models. Crossorganizational information systems are addressed in standardization initiatives (e.g., OMG), middleware products (e.g., BEA Systems), and research projects [Grefen et al., 6; Klingemann, Wäsch, and Aberer, 9; Merz et al., 11]. In crossorganizational information systems existing autonomous information systems of different companies are

SEPARATING BUSINESS PROCESS FROM USER INTERACTION

89

directly connected in order to support crossorganizational business processes. In order to deal with the autonomity of the involved information systems, contracts are specified, that specify a common view of the shared data and processes for the crossorganizational business process. The models used to specify contracts are standard non-declarative process models, like flowcharts or Petri nets. Agent communication languages, like KQML [Finin et al., 3] focus on the problem of communication among autonomous software agents. These languages correlate in a declarative manner the agents’ internal states with the messages that are intended to change these states, called performatives. They also specify the interaction languages and interaction protocols that can be used to establish agent communication. There exist approaches to use agent communication languages in order to model electronic commerce business processes, like FLBC [Kimbrough, 8]. The semantics of agent communication languages can be given through logical models, that extend standard predicate logic with concepts to capture dynamics of processes (dynamic logic), modalities, like obligation (deontic logic) [Meyer, Wieringa, and Dignum, 12] and intention (illocutionary logic) [Weigand, Verharen, and Dignum, 15]. The language for modelling information commerce processes that we will propose belongs to this class of approaches, but focuses in contrast to the existing proposals specifically on the characteristics of information commerce.

2. Separating user interaction from process logic The separation of the business process logic from the implementation of the activities is usually considered as the main contribution of the workflow management technology. The business process is specified at a high level of abstraction, using either GUI tools or workflow definition languages. The main result of this step is the definition of control and data flow dependencies among activities. Activities themselves are defined separately and their definition is not a part of the process definition. In runtime a workflow engine invokes the activity implementations according to the dependencies defined in the process specification. The workflow management approach ascertains that process definition and the implementation of the activities can be maintained and changed independently.

2.1. The role of interactive Web documents in workflow implementation One possibility to implement a workflow activity, that is performed interactively by a human, is to provide an interactive Web document (a “Web page”). The document allows a user to provide workflow-relevant data and thus decide on the further process execution. Interactions of the user initiate the return of workflow-relevant data to the workflow engine and indicate the completion of activities. On the other hand interactive Web documents serve the purpose of data presentation to an interactive user. If the interactive Web document is implementing a workflow, activity data is typically related to the purpose of this activity, e.g., by presenting data relevant for making decisions. Users can also interact with the interactive Web document in order to

90

ABERER ET AL.

navigate through the data as it is presented. By using a mechanism for layout generation (like XSLT) data structure is separated from layout for presentation and navigation. Thus an interactive Web document clearly plays two roles in the implementation of workflow activities: with respect to separating content from presentation it serves as presentation medium, and with respect to separating activity implementation from workflow structure it serves as activity implementation. This double role should also be reflected in the mechanisms used to generate interactive Web documents. XSLT addresses only generation of presentation format from structured data. We intend to extend XSLT to also generate interaction capabilities for activity implementation, in order to separate process structure from activity implementation. 2.2. Implementing workflow activitites using interactive Web documents The way data is presented to a user within an e-commerce application depends on the current state of the workflow process. Therefore we have to provide for the UI developer using XSLT a means to express this dependency in the stylesheets he is developing. On the other hand when implementing a workflow activity an interactive Web document must be enabled to interact with the workflow engine. Therefore we have to extend XSLT also to include interactions with the workflow engine. It may seem that, with such an extension of the stylesheet functionality, we are sacrificing the ease of the UI creation process and putting more burdens on the UI designer. However, we do not think that this is the case if we provide the UI developer with clear and simple abstractions of the workflow and use simple constructs for interacting with the workflow engine. We can identify two main ingredients of a workflow: activities (with dependencies among them, control flow) and the data passed between the actions (data flow). Additional concepts such as participants (whether human beings or IT applications) are used to further determine the concept of activities. Thus, the UI designer needs first of all to understand about the workflow, the type of activities occuring and the workflow-relevant data. For the activities this requires knowledge of the activity names and invocation parameters. This gives a set B = {b(x1, x2 , . . . , xk ) | b is a business activity}. For the workflow relevant data this requires the knowledge of workflow-relevant data objects D = {d1 , d2 , . . . , dn }. What a UI designer does not need to bother about are the details of the process definitions, i.e., the different data and control flow dependencies. Based on this knowledge he must be able to interact with the workflow engine at least in the following ways. 1. Initiate the performance of business activities in B. For doing that he must in particular be able to provide values for the invocation parameters of the activities from set B derived from the earlier interactions with the user or the WF engine. 2. Obtain and manipulate the values of workflow relevant data in D. This data is required for the implementation of activities. 3. The evaluation of conditions on the process state. These are predicates C = {p(x1 , x2 , . . . , xk )} where p are (Boolean combinations of) predicates on the activity execution state. The most basic predicate on the activity execution state is to determine whether

SEPARATING BUSINESS PROCESS FROM USER INTERACTION

91

an activity has been executed or not. Depending on the activity state model of the WF model this can be refined to take into account more activity states. For a more fine-grained interaction of the interactive Web document with the workflow engine additional functionality can be provided, for example, functions for analysis of workflow history. The specific instantiation of these interactions depends on the underlying workflow model and the capabilities of the workflow interpreter used. More on this will be given in Section 4, when we describe the specific workflow model that we use and its semantics.

2.3. Process-aware XSLT style sheets We give now a pattern of how to extend the XSLT style sheet mechanism in order to make it interacting with a workflow process. It covers the interaction possibilities a UI designer needs that have been mentioned before. This pattern should be applicable for most kinds of workflow models and interpreters. We will present a concrete instantiation of this pattern by applying it to our information commerce language in Section 3. Conditional sections of style sheets depending on the workflow process and data state. This enables the UI designer to make the document rendition dependent on the workflow execution. Syntactically we represent this as a new element type ... 2 The representation of a predicate p(x1 , . . . , xk ), determined by the function Rep, depends on the specific implementation. We will give later an example, where we use an XPathoriented representation for the sake of compatibility with XSLT. The important point is that a predicate may be true for multiple instantiations of the parameters x1 , . . . , xk . In such a case, as for ordinary XSLT templates, the content of is instantiated for every instantiation of the parameters once. The order of these instantiations is implementation-dependent. We may also just test whether a predicate is satisfied for specific parameters by using ... The subelements of are then included when there exist parameters, for which the predicate evaluates true. In contrast to the use of and the use of in ordinary XSL we will also allow a template rule to be contained within an element, such that the rule becomes only applicable if the test predicate is satisfied in the workflow state. Retrieval of data from workflow state. When processing an element the processing clearly will depend on the values of x1 , . . . , xk . Therefore we provide within the scope of the element these values as implicitly defined XSLT variables

92

ABERER ET AL.

with name Rep(xi ), i.e., it is available as if it were defined as and takes the value of the parameter for which the template condition is evaluated to true. For retrieval of other data from the workflow state we also may explicitly retrieve these values into variables by or inline it directly into the resulting document by . In both cases the expressiveness of expressions query and their representation in XSLT by Rep(query) depends on the concrete implementation of the mechanism. Natural examples of languages for Rep(query) are the use of XPath and XQuery. Execution of a workflow action as part of a user interaction. This enables the UI designer to couple active elements of the user interface (like forms and links) with workflow actions. Syntactically we represent this by introducing a new element type: ... The submit element binds the execution of the action b to an HTML form element that is identified by identifier ID and that is contained within the element. We make use of the XML ID/IDREF mechanism for linking. The variable values x1 , . . . , xk are either taken from the referenced action element (e.g., HTML form) or from an XSLT variable. Such an XSLT variable is either explicitly defined or implicitly defined, e.g., by the element.

3. Business Offer Language (BOL) We use the Business Offer Language, BOL [Aberer and Wombacher, 1], to encode our process description. BOL is a flexible rule-based abstraction to specify business processes. It is particularly well suited for information commerce as it’s main abstraction primitive is the exchange of an information good. The business offer language has been developed by following a number of key principles that we recognized as essential for the specification of information commerce processes. A more detailed discussion of these design motivations, and in particular why the resulting process specifications are more compact, are better understandable and evolve more easily, is given in [Aberer and Wombacher, 1]. 1. The main primitive of the language is the action of exchanging an information good. We subsume under the notion of information good all goods that are exchanged electronically in an information commerce process, including payments and certificates.

SEPARATING BUSINESS PROCESS FROM USER INTERACTION

93

2. In order to specify such an exchange action we need to provide the description of the information good itself as well as the description of the provider and receiver of the information good. 3. To express the business logic we have to be able to constrain the execution of actions by conditions on the information good, the process state and time. This allows to express which actions are valid within the agreement in a certain process state. 4. Since the provider and receiver are autonomous we require a minimal mechanism in order to establish an agreement on an information good exchange action. At least we have to give both parties the opportunity to express their agreement to the exchange. This allows to identify which actions become obligatory in a certain process state. 5. We explicitly differentiate state changes that result directly from communication actions from those that result from implicit state changes. Thus the model allows to determine all possible communications from the specification.

3.1. BOL overview Four notions are central to the BOL—goods, roles, actions, and rules. The notion of information good includes all goods that are exchanged electronically in a given information commerce business process. Possible examples range from registrations or newsletters, to payments and certificates. Each information good is generally characterized by a set of attributes or parameters: G(p1 : T1 , . . . , pn : Tn ), where their domains Ti include all standard primitive data types as well as domain specific types. For example, the good registration(n : Name) has one parameter drawn from the set of all valid (human) names. In order to specify such an information good exchange action, we need to describe the provider and receiver of the information goods. Thus all the participants of such exchanges are modelled by roles. In a typical portal example, we may consider “Website” and “Visitor” as the roles. Having defined the roles R1 and R2 we can give the full specification of the information goods by associating with them the direction of exchange, for delivering the good. We denote this as G(p1 : T1 , . . . , pn : Tn ) : R1 → R2 . The declaration of all information goods is then a finite set of good declarations of this form, denoted as goods : G1 , . . . , Gn . Since the provider and receiver of an information good are autonomous, a minimal mechanism is required in order to establish an agreement on information good exchanges. This is done using the actions request, promise, and deliver on information goods, where a request + promise pair on any particular information good implies the obligation to deliver the same. The state transition diagram shown in Figure 1 associates with every information good an elementary business process. In this process all information goods are first by default in an initial state (“init”) and can move by different transition sequences to the final delivered state. Note that not for all paths necessarily an obligation occurs. Obligation is only a conceptual notion. Adherence to the obligation in the real life transactions, and any legal actions in the event of breach of obligation by real life participants playing the role of BOL

94

ABERER ET AL.

Figure 1. BOL state transition diagram.

role(s) are beyond the scope of BOL, and are case specific. However, the BOL contract and history log may be used as evidence in any legal proceeding. The actions are defined in a way such that they exactly correspond to message exchanges. Thus the only possible actions in the model are the communication actions promise, request and delivery and they are implicitly defined by means of the specification of the information goods. For each of the actions we introduce a state predicate, expressing the fact that the corresponding action has occured: promised(R1, R2 , G(p1 : T1 , . . . , pn : Tn ), t) requested(R1, R2 , G(p1 : T1 , . . . , pn : Tn ), t) delivered(R1, R2 , G(p1 : T1 , . . . , pn : Tn ), t). The state predicates are parametrized by the time t of the occurrence of the action since this is frequently an important criterion for the further flow of actions. In order to create processes with dependencies among different information goods we must have a possibility to create dependencies among executions of different actions. For that purpose there exist two types of rules. • Actions that correspond to an explicit communciation of the participants, i.e., a message exchange, are enabled by rules of the form state → [action]

SEPARATING BUSINESS PROCESS FROM USER INTERACTION

95

where the state expression is a Boolean combination on the state predicates promised, requested and delivered, on relations that are defined on the parameter domains of the information goods and on the temporal parameters that occur in the state predicates. An empty predicate state evaluates to true. • Implicit actions are state changes that are not connected to a communciation but result from the business logic. They are described by so-called substitution rules: state => impliedState Normally an interaction starts in some initial state, which needs not to be reached first by performing the necessary actions. This initial state is specified in an initialization clause: init: state We illustrate the BOL and in particular the use and interplay of actions, substitution rules and initial state by the following example. Example scenario. A website offers electronic books to its members. Membership is free, and the visitors get K electronic books for free. However, free access to books expires after a period of one month since registration. After accessing K books, or expiry of the first month, whichever occurs earlier, the visitor needs to provide valid credit card information to the website. Then the visitor may request as many books he likes. The corresponding BOL specification is given in Figure 2. We comment it in detail. There are two roles involved, the website and its visitors (line 1). Since visitors have to register before they can obtain a book and they also have to pay for the books we have three types of goods exchanged, namely registrations, payments and books (lines 2–4). In the initial state the website has by default already promised the delivery of the first book, such 1 roles: Visitor, Website; 2 goods: Registration (MemberID: STRING, Email: EMAIL): Visitor -> Website, 3 Payment (CreditCardInformation: INTEGER): Visitor -> Website, 4 Book (Title: STRING, Number: INTEGER): Website -> Visitor; 5 init: promised(Website, Visitor, Book(Title, 1), START); 6 rules: -> [deliver(Visitor, Website, Registration(MemberID, Email))], 7 delivered(Visitor, Website, Registration(MemberID, Email), t) 8 -> [deliver(Visitor, Website, Payment(CreditCardInformation))], 9 promised(Website, Visitor, Book(Title, Number), t) 10 -> [request(Visitor, Website, Book(Title, Number))], 11 requested(Visitor, Website, Book(Title, Number), t) 12 -> [deliver(Website, Visitor, Book(Title, Number))]; 13 substitution: 14 delivered(Visitor, Website, Registration(MemberID, Email), t) 15 => requested(Website, Visitor, Payment(CreditCardInformation), t), 16 requested(Visitor, Website, Payment(CreditCardInformation), t) 17 and delivered(Website, Visitor, Book(Title, Number), NOW) 18 and Number < K and NOW < t+1 month 19 => promised(Website, Visitor, Book(Title, Number+1), t), 20 delivered(Visitor, Website, Payment(CreditCardInformation), t) 21 => promised(Website, Visitor, Book(Title, Number), t);

Figure 2. Sample business process specified in BOL.

96

ABERER ET AL.

that no specific action is required in order to reach the corresponding state (line 5). Note that the time value in the predicate is set to a predefined value START, which corresponds to the time the interaction starts. Note also that the variable Title of the good Book is free, which amounts to the fact that all potentially deliverable books are offered. The selection of a specific book has to be performed by mechanisms provided through the user interface, that are outside the scope of this process specification. Only four different interactions can occur, as specified in rules (lines 6–12). The first rule (line 6) expresses that a visitor can register at any time. The second rule (lines 7, 8) expresses that after registration the visitor is enabled to deliver a payment. The third rule (lines 9, 10) expresses that when a book has been promised by the website, the visitor is enabled to request a book. The fourth rule (lines 11, 12) expresses that books that have been requested can be delivered. The explicit communication actions among the participants specified in the rules part will be of particular importance in the implementation of the user interfaces. Most of the business logic of this particular example is encoded into the substitution rules (lines 13–21). These specifications are mostly relevant for the interpreter of the process specification. The first substitution rule (lines 14, 15) expresses that, once a registration is delivered, implicitly a payment is expected (requested) by the Web site. The second and third substitution rules capture the delivery conditions. Substitution rule 2 (lines 16–19) expresses that, when a payment is requested from the visitor and a book is delivered, that then the next book is promised, unless the number of books delivered exceeds K and the registration does not date back more than one month. NOW is a built-in function evaluating to the time at which the rule is applied. The third substitution rule (lines 20, 21) expresses that once a payment is received any number of books is promised. In this specification there exists one case where an obligation occurs: whenever the Website has promised to deliver a book and the Visitor requests a book, the delivery of the book becomes obligatory. Since promising of books is however conditioned in the substitution rules, this obligation only occurs after the visitor has provided the necessary registration and payment. A BOL specification is used to derive the following relevant information on the process: 1. The message exchanges, as they are directly linked to the actions. 2. The process definition by means of the conditions for the execution of actions. 3. The obligations as they are directly derived from the promise and request actions occuring. This demonstrates that information commerce processes can be specified in the BOL both concisely and declaratively. The expressions and rules are interpreted by a BOL interpreter, which will be described in more detail in Section 4.1. It checks for the validity of incoming actions, maintains present workflow state and the workflow history, and determines potential actions (from the rules and workflow history). The instantiation of the potential actions with semantically useful parameters is task of an application or the user interacting with the interpreter

SEPARATING BUSINESS PROCESS FROM USER INTERACTION

97

through the user interface. The checking of the instantiated actions can be performed by again calculating the potential actions and comparing the calculated actions with the ones fed in from outside. The most challenging tasks of the interpreter are the checking of the constraints and the handling and the definition of the different states of the BOL instance.

3.2. BOL-aware XSLT extensions In Section 2.3 we described the basic XSLT extensions enabling workflow-aware XSLT stylesheets. In this section we describe BOL specific instantiations related to the constructs introduced. The workflow relevant data objects correspond to the goods that have been defined. For each good type multiple instances of the good can be instantiated at the same time. Therefore the states of the goods are given as relations on the good attribute domains.

 D = RG | G(x1 , . . . , xnG ) ∈ Goods , RG = (x1 , . . . , xnG ) . Note that tuples in these relations may contain null values if the corresponding good parameters have not been set in the course of the execution of the process corresponding to one good. The set of actions is given by    
 B = request G(x1 , . . . , xnG ) , promise G(x1 , . . . , xnG ) , G(x1 ,...,xnG )∈Goods

    deliver G(x1 , . . . , xnG ) , set G(x1 , . . . , xnG ) .

The semantics of the actions request, promise, and deliver is the execution of the corresponding BOL action on the good G. The set action inserts (or updates) a data tuple into the corresponding tuple relation RG . This allows to specify action parameters in a stepwise, interactive manner before actually submitting an action. Different types of atomic predicates can be used to check the workflow execution state. First, we have predicates to check whether a specific action has been performed for a good. These have the good parameters and the execution time as parameters: 
    C1 = requested G(x1 , . . . , xnG ), t , promised G(x1 , . . . , xnG ), t , G∈Goods

  delivered G(x1 , . . . , xnG ), t .

Second, we have predicates that check whether the execution of actions on certain good types is enabled according to the BOL rules. These predicates have no parameters: 
      enabled promise(G) , enabled request(G) , enabled deliver(G) . C2 = G∈Goods

Third, we have a predicate to check the status of the workflow execution with one free parameter returning the error status value:
 C3 = error(x) .

98

ABERER ET AL.

As far as the representation function Rep for predicates is concerned we use the following XPath-like notation. For a predicate in C1 we have    Rep requested G(x1 , . . . , xnG ), t = ’/requested/G’. The parameters are uniquely determined and need therefore not to be explicitly mentioned. Within the scope of the element, where the predicate is introduced, we may access the parameters through variables with default name $G.name, where name is the name of the good parameter used in the BOL good specification. For obtaining the value of time parameter we use the expression ’$requested.G’. For a predicate in C2 we have    Rep enabled request(G) = ’/enabled/request/G’ and for C3 we have Rep(error(x)) = ’/error’. We may also construct Boolean combinations of these predicates in element conditions, as with ordinary XSL. For obtaining explicitly data values using or we use also XPath expressions assuming a proper XML encoding of the additional state information made available by the BOL interpreter is given. As far as the XSLT representation is concerned namespace xslt-wf is replaced by xslt-bol. We give now a few examples for the use of the XSLT extensions interfacing with the BOL workflow engine. Example. The first example is on the evaluation of a condition within a element and is shown in Figure 3. The nesting determines of how the interleaving of the processing of registrations and payments is ordered. Within the scope of the element the value of $Registration.Email is available for processing and we can use it like an XSLT variable. Using these variables in the condition has the same effect as including, for example, ... You will be billed in Swiss Francs // xslt-bol:submit example as shown next. ... Figure 3. Condition evaluation.

SEPARATING BUSINESS PROCESS FROM USER INTERACTION

99

where [email protected] is the value of the workflow variable. In order to check whether the workflow variable has been set we can check whether its value equals the NULL value represented as empty string ”. Example. xslt-bol:submit elements provide an abstraction to the UI designer to create active elements in a desired look-and-feel manner for BOL actions and to pass the user’s inputs to the BOL interpreter. We give an example in Figure 4. The action attribute specifies a complete BOL action that is to be performed. The type of action and the BOL goods along with the parameter passing specifications must be provided. Parameter passing specifications bind actual parameter values to the BOL goods parameters. Parameters defined both in XSLT or in form elements and parameters implicitly defined within our workflow extension elements (xslt-bol) can be used in the action invocation. The actionElement attribute contains the unique identifier and determines, by means of the actionID attribute of an INPUT element, the rendition element which is associated with the specified BOL action. In the above example, a simple form submit element is tied with this action. Consequently, the UI will have a rendition of a simple submit button of the form. The ‘event’ of clicking of this button will be associated, transparently to the UI designer, with the passing of relevant information to the BOL interpreter. In BOL every action must be directed from one participant to another. The from and to attributes specify the originating and target participants of the action, respectively. There might be scenarios where the UI designer may want to obtain some additional information about the current state of the process. For example, he may want to know how many actions of certain type(s) have been already performed. For that purpose we use xslt-bol:value-of primitive. For example,

provides a means to count the number of deliver actions on a BOL good called Book assuming a log is made available by the BOL interpreter with a proper XML encoding. If access to the BOL interpreter’s history log is not made available, then such information Credit Card Information: Figure 4. Active elements.

100

ABERER ET AL.

may be obtained only by modifying the business description, like by appending additional parameters associated with the good Book (in this case). 4. Implementation architecture The diagram shown in Figure 5 summarizes the architecture of our approach. For the purpose of describing business processes we use the business offer language (BOL) that was introduced in the previous section. The key components are the BOL interpreter and the XSLT-BOL interpreter which interfaces in a state-dependent manner between the BOL interpreter and the user interface interpreter (a Web browser, for example). The UI designer provides to the XSLT-BOL interpreter two files, called XSLT-BOL and Root-XML, that essentially specify the mapping from the process states to the presentation. The RootXML file contains static information about look and feel and possibly some data relevant to the process and user interface. The XSLT-BOL contains the process-aware template rules as introduced before. Based on the state of the process, XSLT-BOL is transformed by the XSLT-BOL interpreter into different XSLT stylesheets that, when applied to the Root-XML, produce the final rendition. In the following subsections we give an outline of the BOL interpreter and the XSLT-BOL interpreter. 4.1. BOL interpreter The BOL intepreter interprets the business offer language, supports the communication between the trading partners instantiating the roles, and initiates the transfer of data on the content level or interaction with other components associated with the execution of actions. From an architectural viewpoint the business process language allows to introduce a process level as an abstraction layer in information commerce systems which lies above the content management systems, as is shown in Figure 6. This abstraction layer allows

Figure 5. Architecture of the solution.

SEPARATING BUSINESS PROCESS FROM USER INTERACTION

101

to specify and control the processes that are executed when trading information goods. It abstracts from technical details of how the goods are delivered electronically at a content level. Thus it facilitates the specification, negotiation, verification and execution of those processes. Before starting such an information commerce process the trading partners have to establish a common agreement expressed as a business process specification, as indicated by an agreement level in Figure 6. The mechanism used to achieve such an agreement is out of the scope of the business process language itself. It can be performed by any automatic or interactive mechanism that results in a common agreement on a business process specification. However, the agreement itself can be an information good that has been exchanged in the context of another process. Once such an agreement is established the execution of the business process can commence. The execution of the business process requires the following functions: • interfaces to the content management applications realizing the information good delivery; • generation and verification of the messages interchanged; • implementation of the data and control flow by the participants in the process. In addition, at any point during execution each participant can analyse the current state of the process execution in order to plan his future actions. Such analyses are specifically important with respect to the current obligations and the reachability of states where the

Figure 6. Overview of the architecture levels.

102

ABERER ET AL.

obligations are satisfied. In the following we focus our description on the three basic functions. 4.1.1. Interfaces to content management Content management systems are necessary for the execution of the delivery of information goods. We use the notion of content management system in a fairly wide sense, e.g., it could be a payment system, if the information good is a payment. In Figure 6 two cases of a delivery action are depicted, the delivery of an information good and the delivery of a payment. From these examples we can see two different possibilities of how a delivery action is implemented at the content management system level. In the first case, the delivery of an information item, a corresponding delivery operation at the content level is executed. The delivery can be realized by any communication mechanism that transfers the information content. Examples are the sending of an e-mail, the access to a Web server, or the use of a push system. In some, possibly exceptional cases, all the relevant information corresponding to an information good may be transferred directly through messages at the process level, requiring no corresponding activity at the content level. In the second case, a payment, we see that a single delivery action at the process level translates to the execution of a more complex (payment) protocol at the content level. At the process level this protocol is executed as an atomic action. In order to couple the delivery actions at the process level with the execution of the corresponding operations at content level, the business process language interpreter needs to be furnished with the specifications of the calls to the content management systems APIs that realize the delivery operation for every information good. 4.1.2. Communication Every action at the process level results in a message exchange. For every information good and action type a message structure is generated from the business process language specification. This message structure is represented in XML as the standard data exchange format. In order to exchange these messages, in our implementation an XML based request-response protocol is used, that is derived from the ICE communication protocol [Wombacher and Aberer, 16]. This protocol adds communication headers to the messages encoding actions and provides a communication error handling. Received messages are analyzed by parsing the message and creating internal data structures for further processing. 4.1.3. Implementation of data and control flow All participants in the business process need a runtime component that coordinates the execution of the business process. The runtime components orchestrate the enabling of actions by evaluating their enabling conditions, the tracking of the executed actions and thus of the process state, the generation and receipt of messages, and the calls to the content management systems required for the implementation of the delivery actions. For the evaluation of enabling conditions the runtime component requires access to the domain specific implementations of the functions and predicates that are associated with the parameter domains of the information goods and roles. The runtime component provides an XML-based interface for the triggering of enabled actions. This interface can be either used by an application or directly by a user interface. In

SEPARATING BUSINESS PROCESS FROM USER INTERACTION

103

Figure 7. BOL interpreter processing.

the context of using BOL-enabled XSLT stylesheets this interface is accessed by the XSLTBOL interpreter, but could also be utilized by other application development environments. In the following, we describe in more detail the different processing steps performed by the BOL interpreter which are depicted in Figure 7. The BOL specification is transformed into an executable form by analyzing the declaration of the information products and the rules. Taking into account the initial and the already derived state potential actions can be derived, which are presented to the user, for example, via the XSLT-BOL interpreter. In case the user selects an action, the follow-up state is calculated and persistently stored within the BOL interpreter. Further, the trading partner’s BOL interpreter is informed about the state change by transmitting the selected action resulting in an analogous sequence of processing steps. In particular, the trading partner that receives the action, checks the validity of it, calculates the new state itself, derives the next potential action, calculates the new state and returns this action as a response. When the response arrives the incoming action is checked on validity using the representation of rules and the current state of the BOL interpreter. In case it is valid the subsequent state is calculated and persistently stored. Based on the new state the next potential actions can be derived and be used for visualization at the user interface. The implementation of the BOL interpreter was designed to be lightweight, such that it can be deployed, e.g., as applet, in the context of B2C applications. Thus we decided to refrain from using complex rule interpreters, such as Prolog interpreters, for implementing the BOL logic. Rather the interpreter is fully implemented in XSLT and uses XML

104

ABERER ET AL.

documents for storage. This limits of course the expressivity of the BOL language, in particular with respect to expressiveness of logical expressions in conditions and supported data types, but we consider these limitations as acceptable given the applications we intend to support.

4.2. XSLT-BOL interpreter The XSLT-BOL interpreter is realized as an XSLT style-sheet (a style-sheet neglecting inclusions) that, operating on three input files, namely, the XSLT-BOL style-sheet, the output from the BOL interpreter and the Root-XML file produces the final rendition. It achives this through a two-level processing: It first takes the XSLT-BOL input style-sheet and the BOL interpreter output and outputs the ordinary XSLT (we describe this processing next) that, when applied to the Root-XML input file, generates the target layout. The XSLT-BOL style-sheet is organized in the most conventional XSLT fashion—as a set of templates with match attributes with the control being passed between the templates through apply-templates calls. Since we allow nesting of our xslt-bol extension elements on the one hand and specific semantics of the xslt-bol submit instruction (binding between its actionElement attribute and the actionID attribute of the contained action element) on the other hand, all templates, and consequently all apply-template calls, are with parameters. While all non xslt-bol specific elements (ordinary XSLT and possibly target rendition elements) have one common template with a rather simple processing—outputting an element with the same name and attributes along with parsing text and attribute values and replacing appearances already bound workflow variables with their values—each of our xslt-bol extension elements, has a corresponding template. Thus the workflow engine specific processing is localized into these templates. Moreover, this processing is further localized into templates that are called by name from these top level xslt-bol extensions related templates. For instance, parsing conditions contained in the value of the test attribute of the xslt-bol:if instruction is a typical example of what should go into these separated workflow engine dependent templates. Clearly, with such a solution we make the portability across different workflow engines easier because the workflow engine specific code is localized and easily replacable. A particularly interesting idea concerns the solution for the xslt-bol:submit instruction. Namely, the action being performed and the identifier of the action element that will be used for the submission are given as the values of the action and actionElement attributes of the xslt-bol:submit element. We have chosen to add the onclick attribute to the action element with a call of a script function with the action specification as an argument. At the same time we build our implementation of the function into the target page and it is this function that actually handles the submission of parameter and the action performing step. Therefore, the UI designer does not have to care about the communication between his target rendition page and the workflow engine. This processing (with the amount of details kept at the minimum) is shown in the code fragment in Figure 8. The main idea of this code fragment is that when the processing reaches an

SEPARATING BUSINESS PROCESS FROM USER INTERACTION

105

function scriptSubmitFunction(submitString) { } scriptSubmitFunction(’ ’); Figure 8. XSLT-BOL implementation.

xslt-bol:submit node the specification of the action to be performed along with the name of the action element for that action are selected and passed as parameters through an apply-templates call. Now, when the processing reaches the action element the onclick attribute is output with a call of the mentioned script function, while the function itself is placed at an appropriate position in the target page (html element in the shown code fragment).

5. Application We demonstrate the use of the basic mechanism introduced with a concrete example. By doing so we also discuss a number of methodological issues that have to be addressed when using process-aware XSLT templates. We base the discussion on the example BOL specification from Figure 2 introduced in Section 3.

106 1 2 3 4 6 8 10 12

ABERER ET AL.

roles: goods:

rules:

Visitor, Website; Registration (MemberID: STRING, Email: EMAIL): Visitor -> Website, Payment (CreditCardInformation: INTEGER): Visitor -> Website, Book (Title: STRING, Number: INTEGER): Website -> Visitor; -> [deliver(Visitor, Website, Registration(MemberID, Email))] -> [deliver(Visitor, Website, Payment(CreditCardInformation))] -> [request(Visitor, Website, Book(Title, Number))] -> [deliver(Website, Visitor, Book(Title, Number))]

Figure 9. UI developers reduced perception of a BOL specification.

5.1. Knowledge required by the UI designer The UI designer does not need to understand the whole BOL description. He is expected to know from the BOL specification the different goods, roles and possible actions. From this information he can also derive (without considering the BOL specification) the possible state predicates. He can, on the other side, completely ignore the business logic that is encoded into the various rules, though their knowledge might be of help. We illustrate this in Figure 9, by eliminating from our original BOL example all information that can be ignored by the UI designer. Note that in particular from this reduced view of the specification, the UI designer can derive which actions are possibly enabled and therefore require an implementation. These are, as one can easily recognize, by no means all possible actions on the existing goods, since actions without an enabling condition in the BOL specification cannot be executed as part of the business process.

5.2. Role of Root-XML file The Root-XML file is supposed to factor out all static data that is common to all generated Web documents and that contains no presentation-specific code. Among these kind of data we find the following. Common elements. There is certain information, which the UI designer may potentially want to reuse. It is preferable to have such static information, or other data, in the Root-XML. For example, a welcome message for the Visitor, or a message on the services provided by the Website, copyright information, disclaimers, an error message, may be put in this category. Other contents of this category may be some ordinary HTML (like forms). Though it is not illegal to have such content in our Root-XML, the drawback in having such end-point technology specific content is that it will defeat the purpose of using the same Root-XML and different processing templates to create User Interfaces for variants of technologies. Data. In our example, it will be necessary to have a catalogue of Books that the Website offers. So, one keeps the catalogue information (data) in the Root-XML. Layout structure. The logical structure of the Website and the common structure underlying the Web page layout is kept in the Root-XML. This ensures that the designer will use a consistent organization of the Web page throughout the process execution.

SEPARATING BUSINESS PROCESS FROM USER INTERACTION

107

... ...