THE SWS MEDIATOR WITH WEBML/WEBRATIO ANDJABC/JETI: A COMPARISON

Tiziana Margaria∗, Christian Winkler∗, Christian Kubczak†,Bernhard Steffen†

∗Institute for Informatics, University of Potsdam, 14482 Potsdam, Germany,{margaria,winkler}@cs.uni-potsdam.de

†Department of Computer Science, University of Dortmund, 44227 Dortmund, Germany,{christian.kubczak,steffen}@cs.uni-dortmund.de

Marco Brambilla‡, Stefano Ceri‡, Dario Cerizza§, Emanuele Della Valle§, Federico M. Facca‡, Christina Tziviskou‡

‡Dipartimento di Elettronica e Informazione, Politecnico di Milano, Milano, Italy{mbrambil, ceri, facca, tzivisko}@elet.polimi.it

§CEFRIEL, Milano, Italy{cerizza, dellava}@cefriel.it

Keywords: Semantic Web, Web services, jABC, WebML

Abstract: In this paper we compare the SWS Challenge Mediator solutions provided using the WebML/Webratio andthe jABC/jETI approaches.

1 Introduction

In this paper we compare two solutions to the me-diation scenario of the SWS challenge 1 that are basedon the use of WebML (Ceri et al., 2002) and of thejABC (Steffen et al., 2006; jABC Website, 2007) asmodelling and execution platforms.

We compare only the solutions to the first versionof the SWS Challenge scenario, since the jABC solu-tion was discussed at the SWS review workshop onlyfor this first Phase. Nevertheless, the technical com-parison of the approaches is of general interest andvalid also for the second phase of the scenario.

Both groups adopt a model based approach, sup-ported by model driven design tools and environ-ments. This allows modelling the mediator in a graph-ical high level modelling language and supports thederivation of an executable mediator from these mod-els. The solutions are thus similar in their spirit, andwe provide here a first description and comparison ofthe similarities and differences, at the modelling, lan-guage, tool, and change management levels.

In the following, we briefly describe the two con-crete solutions (Sect. 2 and 3) from the point of viewof the used technologies, then we sketch a comparison(Sect. 4), we present a reduction of the two solutionsto their mere, common essence (Sect. 5), and finallywe conclude in Sect. 6.

1http://sws-challenge.org

2 WebML

The specification of a WebML application (Ceriet al., 2002) consists of a set of models: the appli-cation data model (an extended Entity-Relationshipmodel), one or more hypertext models (i.e., differ-ent site views or different service views), expressingthe navigation paths and the page composition of theWeb application or the chain of operations needed todescribe a Web service; the presentation model, de-scribing the visual aspects of the pages for user views.WebML covers also the development of B2B Web ap-plications implementing business processes, therebysupporting full-fledged collaborative workflow-basedapplications, spanning multiple individuals, services,and organizations. In such case the service view orsite view is partially generated by a BPMN modelrepresenting the workflows involved in the applica-tion. The core elements of a WebML diagram areunits. Each WebML unit has its own well definedsemantic and its execution complies with its seman-tic. The composition of different units leads to thedescription of the semantic of hypertext or Web ser-vices. WebML provides standard units for queryingdata (e.g. Index unit, Selector unit), modifyingdata (e.g. Modifying unit). The WebML conceptualmodel has been also extended with a service modelthat includes a set of Web service units (Manolescuet al., 2005), corresponding to the WSDL classes ofWeb service operations, and components for work-flow management and tracking. The model supportsboth the grounding of Web services to the XML

Figure 1: Overview of the main layers of theWebML/WebRatio framework

Figure 2: The WebML/WebRatio CASE tool

format of Web service messages, and datamediationcapabilities. In particular the Request-Responseand One-way operations are used to consume exter-nal Web services, while Solicit and Response unitare used to publish Web services; finally the ErrorResponse unit takes care of error handling and re-turning messages to the invoker in case of errors.The WebML methodology is supported by WebRatio(WebModels s.r.l., 2007), a commercial CASE toolthat covers all design and development phases fromthe BPMN modeling to the deployment of Web appli-cations and Web services (see Figure 1).

2.1 The WebML Mediator

The solution for the mediation problem starts by de-signing the data model underlying the RosettaNetmessages with an extended E-R model. We iden-tified three main entities: the Pip3APurchaseOrder,

Figure 3: The BPMN editor integrated in the WebML edit-ing environment.

the Partner and the ProductLineItem. EachPip3APurchaseOrder instance is related with one ormore ProductLineItem instances, one Partner repre-senting the Buyer, one Partner representing the Sellerand one Partner representing the Receiver. Every Pro-ductLineItem instance may have one Partner repre-senting a Receiver for the single line.

Then the WebML solution models the high-levelscenario of the challenge using BPMN (see Figure3). This model includes all parts of the scenario onthe whole – Blue’s side as well as the mediator andMoon’s side – and describes the scenario workflow.

This model is used as a guidance in the produc-tion of two WebML models that implement the work-flow’s functionality. The BPMN workflow is split bya corresponding annotation of the BPMN model intotwo separate WebML models that represent two in-dependent parts of the process: sending a purchaseorder and receiving acknowledgments for the ordereditems. The generation of WebML diagrams is basedon an algorithm that populates the WebML diagramwith the standard general purpose units mentioned be-fore, e.g. for receiving Web service calls and call-ing Web services and sending Web service responses,according to the BPMN model. The design of themediator is refined manually by configuring existingunits and adding new ones from the WebML unit li-brary (no new unit had to be developed to cope withthe mediation scenario). It could be possible also tomodel the mediator with out storing data but work-ing only in memory. The data storage was preferredto allow a better monitoring of the mediation pro-cess. The conversion from RosettaNet messages ishandled by Adapter units that are configured by aproper XSLT stylesheet that transforms messages inan XML format compatible with WebML’s internaldata format. In the same way conversion to and from

Figure 4: The jETI architecture: integrated generic web ser-vice support.

Moon legacy messages are handled by proper XSLTstylesheets that act as templates for SOAP messagesand that are then populated by runtime queries duringthe workflow execution.

3 jABC/jETI

The jABC solution is realized within the jABCframework (Steffen et al., 2006; jABC Website,2007), an environment for model-driven service or-chestration based on lightweight process coordina-tion. It has been used over the past 12 years forbusiness process and service logic modelling in sev-eral application domains, including telecommunica-tions, bioinformatics, supply chain management, e-commerce, collaborative decision support systems, aswell as for software and system development. In thispaper, we restrict us to the jABC facilities relevant toproducing and consuming Web services.

Semantically, jABC models are control flowgraphs with fork/join parallelism, internally inter-preted as Kripke Transition Systems (Muller-Olmet al., 1999). This provides a kernel for a sound se-mantical basis for description formalisms like BPNM,BPEL, UML activity diagrams, and dataflow graphs,and constitutes a lingua franca adequate for theanalysis and verification of properties, e.g. bymodel checking (Muller-Olm et al., 1999). BPNMand BPEL are considered different syntactic (visual)means for representing jABC models tailored for spe-cific communities of users. In this Challenge, wechose to privilege the abstract semantic view of theexecutable models over ’syntactic’ sugar, and there-fore use only the jABC notation.

Concerning the data semantics, the

Figure 5: Consuming and producing web services withjABC/jETI.

Using external Web services. As in WebML, thejABC mediator is largely generated automatically.The jETI framework (Java Electronic Tool Integra-tion) (Kubczak et al., 2006; Margaria et al., 2005;Arenas et al., 2006) that enhances the jABC to supportseamless integration of remote services (both RESTand Web) can generate basic service types (calledSIBs, Service-Independent Building Blocks) from theWSDL file of a third party service, and export theorchestrated/choreographed services inside the jABC(called SLGs, Service Logic Graphs) as Web services.

Fig. 4 shows the distributed architecture of thisinfrastructure. SIBs are analogous to the WebMLunits: both concepts represent the atomic function-ality of an involved service. In the jABC, domain-specific SIB palettes are shareable among projects,and organized in a project-specific structure and withproject-specific terminology. This is a simple wayfor adopting or adapting to different ontologies withinthe same application domain. Domain-specific SIBpalettes are complemented by a library of SIBs thatoffer basic functionalities (e.g. SIBs for I/O or mem-ory handling), or control structures (as used here), orhandling of data structures like matrices (e.g. in ourbioinformatics applications (Margaria et al., 2006)).

Using Web service components inside the jABCrequires a valid WSDL file, or alternatively the URLwith a signature. As shown in Fig. 5(top), jETI’s SIBgenerator extracts the information about the function-ality defined in the WSDL file and creates a SIB foreach function. Input parameters are handled as hierar-chical SIB parameters: they enable the user to freelydefine input values for the web service, using the pre-existing graphical user interface of the jABC.

This is useful to face the dynamic scenarios of theMediation problem without need of programming: ifa web service changes its interface, as in the next levelof the Mediator scenario, we only need to reimport itsWSDL description into a (new) SIB.

Figure 6: The hierarchical input parameters of a generatedWeb Service SIB.

By generating Web service SIBs, the executionof the service remains on the server. The SIB sim-ply serves as a communication component with theWeb service, in this example the Apache AXIS frame-work2 to call the specific web service. In this solution,the scenario’s data and status information are main-tained in the session memory. We do not need to loador store data persistently during the mediation.

Producing Web services. To export a compositejABC service as a Web service we use our technol-ogy to generate stand-alone web services from fullyimplemented composite services available as jABCSLGs.3 As shown in Fig. 5(bottom)

1. Since it is required to provide the mediator as aservice, we first transform the composite, hierar-chical SLG of the mediator into a single SIB, us-ing the subgraph feature of the jABC - as we usu-ally do to provide hierarchical models as a single

2Apache’s Axis Website - http://ws.apache.org/axis3Of course, it is also possible to export single SIBs as

web services, this way offering a translation to the WS-world of preexisting jABC libraries.

functionality. This creates a GraphSIB represent-ing the corresponding SLG. Its implementation isthe argument SLG, executable within the jABCTracer, the interpreter (or a virtual machine) forSLGs.

2. To provide a Web service mediator completely in-dependent of the jABC, we use the code generatorplugin (Steffen et al., 2006) to obtain executablesource code from the GraphSIB. This code is thendeployed on a server using the AXIS framework,this way making the functionality accessible toother users. We then generate a WSDL descrip-tion that contains all the necessary information toaccess the deployed service as a web service.

This way, users can call the newly added web ser-vice the way they are used to, independently fromthe jABC.

Choreography jABC originated in the context ofthe verification of distributed systems (Muller-Olmet al., 1999), therefore SLGs are inherently adequateas choreography models. The SIBs can physically runin a distributed architecture. They communicate di-rectly or with a shared space (called the context). TheSLGs are fully hierarchical: SIBs can themselves beimplemented via SLGs. The macro mechanism de-scribed in (Steffen et al., 1997) allows defining whatcommunication actions of an SLG are visible to theenvironment (for choreography). Hierarchy is how-ever not needed for the mediator solution. Orchestra-tion is as far as the jABC is concerned just a degener-ate case of choreography.

Data Semantics The static data semantics is cap-tured automatically during the WSDL-to-SIB importas the SIB parameters.

These parameters, additional semantic propertiesattached to the SIBs, possibly imported from an on-tology, and the SIB branch labels are visible to themodel checker (Steffen et al., 2006), which allows au-tomatically proving global compliance constraints onthe business logic of an SLG. These constraints areexpressible in mu-calculus and its derivatives, a fam-ily of modal (temporal) logics.

Additionally, arbitrary relations between data ele-ments can be provided as local checking expressions,with the expressiveness of Java. This facility allowsexpressing and checking pre and post conditions.

Neither the local checker nor the model checkerwere used for the mediation solution.

Function WebML jABCBPMN model Manually modelled from the SWSC

task description. Manually anno-tated to steer the WebML genera-tion to meet the challenge’s needs.

Not a distinct model, just an abstractjABC graph.

Mediator control flow WebML model structure with stan-dard units generated from BPmodel. Units are then configuredand other units are added from thelibrary manually (no need for any im-plementation, no code generation,just component configuration).

Manually created SLG along theSWSC task description (by refiningthe abstract model equivalent to theBPMN model), using automaticallygenerated- and standard SIBs.

Data Management ER-model manually created fromanalyzing the RosettaNet mes-sages and adding status informa-tion. Used to keep data persistent.

ER-model possible, manually cre-ated from analyzing the RosettaNetmessages. Not necessary due toWSDL import. The data for the me-diator are kept in the session mem-ory.

Web Service invocation Generic standard units for calls toWSs

Automatically generated SIBs rep-resenting WS functions.

Web Service publishing Generic standard units for receivingSOAP messages.

WSs automatically generated andpublished from jABC SLGs.

Passing data to a Web Ser-vice

Data must be included in the SOAPmessages. SOAP (XML) messagetemplates have to be created in ad-vance.

Data is passed to the WSs via thegenerated SIB parameters.

Receiving data from a WebService

Data are extracted from the rawSOAP messages.

Data is received from the WSs viathe generated SIB parameters thatare correct by construction.

Handling XML messages Standard units for handling XMLmessages exist, performing XSLtransformations on XML messages.

No need to handle raw XML mes-sages.

Monitoring User Interface Standard units to generate webpages, displaying database data.

Monitoring of flow graphs and stateinformation within the SLG Tracer(interpreter).

Table 1: Comparison of the presented technologies

3.1 The jABC Mediator

In the Mediator scenario, we have a rather flat domainstructure for the SWS specific services (see Fig. 7left): we only distinguish SWS from common ser-vices, and we import the entities in the domain of dis-course (part of an underlying ontology) through theWSDL import.

As shown in Fig. 6, we obtain directly the fullstructure of the XML messages. Here, we see for ex-ample the rich hierarchical parameter structure of theOMServiceCreateNewOrder SIB.

The workflow is created manually, by drag anddrop from the palette of automatically produced

SIBs 4. It is executed using the Tracer plugin, thejABC interpreter for jABC service models, whichuses the jETI facility to communicate with the remoteservices provided by the SWS Challenge hosts.

We provide the jABC Mediator service as a Webservice with the already described technology.

We only mention for ease of comparison withthe other approaches that the data adaptation requiresonly the reimport of the changed WSDL descriptionsinto SIBs, which is automatic and the process adap-tation requires a manual modification of the SLG,which happens graphically in the jABC.

4We are working on the automatic generation of theworkflow from declarative specifications.

Figure 8: The compared Mediators: Functional correspondence of the WebML (left) and jABC (right) solutions

Figure 7: The SWS Mediator SIBs and the abstract processmodel

4 Comparison

Table 1 summarizes the profiles of the two solutions,which we describe in more detail below:

Workflow:WebML covers the high level specification of thebusiness flow by means of BPMN models. Acoarse WebML skeleton is automatically gener-ated from the BPMN model. This model containsstandard units for the web service calls. Otherfunctions that are necessary to complete thesecalls have to be configured to meet the actual re-quirements.The jABC abstract model is essentially equiva-lent to the BPMN model. It can be refined man-

ually into the mediator graph. As done here, themain domain specific (peculiar to the SWS Chal-lenge) components (SIBs) used in this model areautomatically generated from the Web Service’sWSDL descriptions. The SLG also contains stan-dard control SIBs (provided with the jABC as alibrary) to realize the specific control flow for theSWSC scenario descriptions.

Data Model:The WebML model comprises a data descriptionmodel consisting of an E-R model that is derivedfrom analyzing the data structures in the Roset-taNet messages. This E-R model is used to storethe BP’s data as well as status information regard-ing the state of the process execution. It is alsopossible to use in memory data storage as config-uration option.The jABC mediator does not use persistent datastorage since it keeps the information in the ses-sion memory. The same ER-model could howeveralso be realized persistently via the DB-Schemaplugin, if necessary.

Dealing with WS:The WebML solution offers four generic WS-related functional units to use or realize a WebService’s functionality: two units to issue calls toa WS, one for sending a request and one for alsowaiting for a response, and two units to provide aWS functionality, one to wait for a request and onefor also sending a reply. These units are param-eterized (configured) with the WSDL descriptionand with SOAP message templates that realize theparticular WS functionality and return the results

Figure 9: The Reduced WebML and jABC solutions

of the WS call as SOAP message. These units canalso be configured dynamically at runtime passingas parameter the dynamic end point, as shown inthe discovery scenario. Such feature is particularuseful if combined with dynamic Adapter unitssince it allows to interact with arbitrary Web ser-vices and to store the results in the internal datamodel regardless of the invoked Web services.The jABC solution realizes a dedicated access toexternal Web services: for each WS functionality,a separate SIB is automatically generated from thecorresponding WSDL description. These SIBsare already fully instantiated: they provide accessto the data exchanged with the WS through auto-matically generated SIB parameters, that can beaccessed in each jABC model. Similarly, a stand-alone WS (including the corresponding WSDL)can be generated from each jABC SLG and auto-matically provided on a web server.

Dealing with XML messages: To deal with Web Ser-vices WebML has to prepare the correspondingSOAP (XML) messages, that are passed to theunits that execute the call to a WS. If a WS re-turns a result, this value has to be extracted fromthe returned SOAP message as well. To do so,WebML offers standard units that perform (lift-ing and lowering) XSL transformations on XMLmessages. Eventually this operations can be per-formed directly in units that perform the actualWeb service calls. The use of lifting and lower-ing adapters grants a more generic approach sincethey can be configured dynamically.As in the jABC there is no need to deal with raw

XML messages, no such special functions are re-quired. The messages are created within the SIBsaccording to the structure prescribed by the origi-nal WSDL, which is reflected later in the complexparameters of the SIBs and thus known to them.

State Monitoring:The WebML language offers standard abilities todisplay information from a relational database ona web page. This functionality can be efficientlyused to monitor the state of the model work-flow, as this information is stored in a relationaldatabase as well.The jABC offers white box monitoring via itsSLG interpreter, the Tracer plugin, which allowsmonitoring variables and communication activityof the whole hierarchical SLG, at wish separatelyfor each hierarchy level and each thread, in case ofa distributed execution. Additionally the Learn-Lib plugin (Raffelt et al., 2005) provides blackbox monitoring and automatic (re-)construction ofa user-level model, based on the observation of theconversation with the environment.

5 Boiling Down to the Essence

Figure 8 compares the WebML and the jABC work-flows, with a layout that respects the functionalitieswithin the mediator solutions. Taking into account thediscussed differences, it is easy to reduce the WebMLsolution to the jABC solution in a systematic way.

• As mentioned before, the WebML model needs a

Figure 10: Message interpretation units within the WebMLsolution.

pair of lifting and lowering actions for each webservice call to create and decode the needed XMLmessages. These transformations are not neces-sary in the jABC solution, as it does not reducecommunication to the level of exchanging rawXML messages. So all the service units dealingwith the transformation of XML messages in theWebML model are crossed out in black in Fig. 10.

• All units dealing with database access in theWebML model are additionally identified andcrossed out in red in Fig. 10. These componentsdo not arise in the jABC modelling, which allowsto also virtualize these access functions.

• The jABC models error handling explicitly whilethe WebML solution does not (even if the mod-eling language offers support for that). Thereforewe remove the error handling SIBs from the jABCsolution.

The remaining workflow, shown in Fig. 9, repre-sents the essence of the desired solution, abstractedfrom approach-specific details of the communication,storage, and error handling choices.

6 Conclusion

In this paper we presented two solutions to the me-diation in a Semantic Web Service scenario describedin the SWS challenge 20065. The two approaches,WebML and jABC, offered two different views onthe mediation problem, both in terms of the design-time modeling of the solution and of the runtime ex-

5http://sws-challenge.org

ecution platform. Both approaches presented advan-tages and drawbacks. jABC offered a more abstractand synthetic view of the solution, e.g., disregardingsome grounding details of the communication; on theother hand, WebML offered a wider coverage of thetechnical details and of the efficient runtime execu-tion. The WebML approach is based on software en-gineering and web engineering practices, while jABCtakes more advantage of the SOA and web service de-sign fields. Both the methods are not natively meantto face Semantic Web applications, but both proved toadapt rather well to this new class of problems.

REFERENCES

Arenas, A., Bicarregui, J., and Margaria, T. (2006). Thefmics view on the verified software repository. InIDPT - Conf. on Integrated Design and Process Tech-nology. Society for Design and Process Science.

Ceri, S., Fraternali, P., Bongio, A., Brambilla, M., Comai,S., and Matera, M. (2002). Designing Data-IntensiveWeb Applications. Morgan Kauffmann.

jABC Website (2007). Universitat Dortmund.http://www.jabc.de.

Kubczak, C., Steffen, B., and Margaria, T. (2006). The jabcapproach to mediation and choreography. 2nd Seman-tic Web Service Challenge Worksh.

Manolescu, I., Brambilla, M., Ceri, S., Comai, S., andFraternali, P. (2005). Model-driven design and de-ployment of service-enabled web applications. ACMTrans. Internet Techn., 5(3):439–479.

Margaria, T., Kubczak, C., Njoku, M., and Steffen, B.(2006). Model-based design of distributed collabora-tive bioinformatics processes in the jabc. In ICECCS2006, Stanford, CA, pages 169–176. IEEE CS Press.

Margaria, T., Nagel, R., and Steffen, B. (2005). Remote in-tegration and coordination of verification tools in jeti.In Proc. ECBS’05, pages 431–436. IEEE CS Press.

Muller-Olm, M., Schmidt, D., and Steffen, B. (1999).Model-checking: A tutorial introduction. In SAS, 6thInT: Static Analysis Symposium, LNCS N.1694, pages330–354. Springer Verlag.

Raffelt, H., Steffen, B., and Berg, T. (2005). Learnlib: alibrary for automata learning and experimentation. InACM SIGSOFT FMICS’05, Lisbon, P, pages 62–71.

Steffen, B., Margaria, T., Braun, V., and Kalt, N. (1997).Hierarchical service definition. In Annual Review ofCommunication, pages 847–856. Int. Engin. Consor-tium Chicago (USA), IEC.

Steffen, B., Margaria, T., Nagel, R., Jorges, S., andKubczak, C. (2006). Model-Driven Development withthe jABC. In HVC - IBM Haifa Verification Confer-ence, LNCS N.4383. Springer Verlag.

WebModels s.r.l. (2007). Webratio site development suite.http://www.webratio.com.