Matching Business Processes in ebXML

28th March 2003

Administrative data

Title

Matching Business Processes in ebXML

Address

Prof. Dr. R.J. WieringaChair of Information SystemsDepartment of Computer ScienceFaculty of Electrical Engineering, Mathematics and Computer ScienceUniversity of TwenteP.O. Box 2177500 AE EnschedeThe Netherlandstel. +31 53 489 4189 (direct) / 4283 (secr.)Fax +31 53 489 2927

Other projects

The requested project is part of a research program on infrastructures for cross-organizational business processes and on business process specification techniques.The group has participated in the IST Crossflow project in which a transactioninfrastructuree for cross-organizational business processes was developed [10]. Werecently finished an NWO-funded Ph.D. project in which techniques were developedby which an analyst can specify business processes and desired properties of thoseprocesses, and a tool by which these properties can be checked [7].

Other support requested for this project

None.

Keywords

E-business, ebXML, business processes, process matching.

1

1 Summary

1.1 Research statement

In the last decades, many large businesses have been connected with business part-ners using computer network technology called EDI (Electronic Data Interchange).EDI has been quite successful in enabling efficient trading between companies. How-ever, EDI connections take months to develop and, once set up, remain the samefor years. This makes EDI so expensive that only large companies can afford it,and once they are linked by EDI, it is impossible for them to switch to other busi-ness partners. The Internet has decreased expenses considerably and this offers thehope of increasing flexibility in the choice of business partners by reducing switchingcosts, and of making this available for medium and small businesses as well.

To make this a reality, an infrastructure should be created that allows businessesto select a business partner easily and to change this selection easily whenever thisis profitable. This means that the many agreements negotiated about in settingup an EDI connection must now be negotiated in a matter of minutes, rather thanmonths, and that the agreements may govern a few business transactions only.These agreements cover many details about the way goods are ordered, how deliv-ery is arranged, what to do in case of broken deliveries, payment procedures, andmany more details that may be branch-specific. All of these details about trans-actions determine how business communicate before, during and after the businesstransaction. The protocols for these communications must be agreed upon beforebusinesses can decide to engage in mutual transactions.

Several developments are currently under way to provide such an infrastructure.The two major ones are the ebXML and web service standards. This project willfocus on ebXML, but its results will be general enough to be used in other devel-opments as well. ebXML (e-business XML) is a standard for flexible e-businesscurrently under development by UN/CEFACT and OASIS. It is itself based onXML (extensible markup language), which is a standard for defining document for-mats. The infrastructure defined by ebXML works as follows. A business who seeksto perform trade with other, as yet unknown businesses, publishes a descriptionsof its relevant business processes called collaboration profiles, in a database calleda registry. The registry is located somewhere on the Internet and is accessible topotential business partners. Any of those business partners may then search thisregistry for potential partners. This search involves comparing the business pro-cesses of the searcher with the business processes described in the registry. When amatch is found, the business has found a potential partner because they can performbusiness transactions using a set of shared communication protocols. Partner searchas well as process matching are automated, and take the place of the long-windedoral negotiation about communication details when developing an EDI connection.When ebXML infrastructures become available, large, medium and small businessesare able to flexibly select their business partners in a matter of minutes.

One of the parts of ebXML that must still be developed is the search and matchalgorithm. The question to be answered is: When are two processes “equal”? Whenare the processes “sufficiently” similar that two companies can do business? In thisproject we will

• investigate valid definitions of process matching,

• implement these in a prototype matching tool,

• validate the implemented definition with the users in our user group,

2

• define an understandable and useful feedback about (mis)matches, and

• define and implement a usable process query language.

We will validate our results with case studies provided by the user group. See theappendix of this proposal for one such case study.

1.2 Utilization

The project will advance the state of the art in e-business technology. It will advancethe state of the knowledge in the Netherlands about this technology. The usersof this project are interested in this project because it may help them in theirconsultancy. ECP.nl is interested because it can facilitate the spread of ebXMLtechnology to branch organizations in the Netherlands.

This project is urgent because ebXML is currently under development and a gooddefinition of process matching is still missing. One of the members of our usergroup, Berenschot (F. van Blommestein) is a member of the ebXML standardizationworking group. This ensures the possibility of technology transfer to ebXML.

1.3 Summary in Dutch

In de afgelopen 20 jaar zijn veel bedrijven verbonden door zogenaamde EDI-net-werken (Electronic Data Interchange netwerken). Voorbeelden zijn verzekeringsbe-drijven, banken, en bedrijven in de Rotterdamse haven. EDI maakt een efficienteuitwisseling van documenten tussen bedrijven mogelijk. Echterhet duurt maandenom een potentiele EDI verbinding tussen bedrijven te ontwikkelen, en wanneer eenEDI verbinding eenmaal gerealiseerd is, blijft deze jaren in gebruik. Dat creert eenstarheid waardoor bedrijven niet efficient op wijzigende martkomstandigheden kun-nen reageren. Ze zijn immers via EDI aan dezelfde partner(s) gebonden. Bovendienis het ontwikkelen en onderhouden van een EDI verbinding zo duur dat alleen grotebedrijven dit kunnen betalen. Het Internet brengt netwerken ook binnen het bereikvan kelinere bedrijven en creeert bovendien de mogelijk om snel van zakenpartnerte wisselen.

Om deze belofte te realiseren is er een infrastructuur nodig die het bedrijven mo-gelijk maakt snel een zakenpartner te vinden, en om deze keuze gemakkelijk tewijzigen als dat winstgevend is. Met behulp van zo’n infrastructuur moet het mo-gelijk zijn binnen een paar minuten een overeenkomst voor electronisch zakendoenmet een zakenpartner te bereiken, in plaats van de maanden die hiervoor nodig zijnin EDI, en om die overeenkomst voor een betrekkelijk klein aantal zakentransactieste gebruiken, in plaats van de jaren dat de overeenkomst in EDI gebruikt wordt. Deovereenkomst met de zakenpartner behandelt aspecten zoals de manier waarop goe-deren besteld worden, de manier waarop ze geleverd worden, hoe er betaald wordt,wat er gebeurd bij te late levering of kapotte goederen, en nog vele andere detailsdie mogelijk branche-specifiek zijn. Al deze details bepalen de manier waarop dezakenpartners voorafgaande, tijdens, en volgend op een transactie met elkaar com-municeren. Ook moet vastgelegd worden hoe deze communicaties via het computernetwerk uitgewisseld worden.

Er zijn op dit moment meerdere ontwikkelingen die tot zo’n infrastructuur zullenleiden, waaronder ebXML en web services. Dit project concentreert zich op ebXML,maar de resultaten zullen algemeen genoeg zijn om ook op web servives toegepastte worden. ebXML (Electronic Business XML) is een standaard voor een e-business

3

infrastructuur die op dit moment gedefinieerd wordt door UN/CEFACT en OASIS.Het is op XML gebaseerd (extensible markup language), een taal om documentfor-maten te definieren. De infrastructuur die door ebXML gedefinieerd wordt, werktals volgt. Een bedrijf dat zaken wil doen met andere, nu nog onbekende partners,publiceert een beschrijving van zijn relevante bedrijfsprocessen in een register datop een openbaar computernetwerk beschikbaar is. Ieder bedrijf kan via dit registervia openbare netwerk doorzoeken op mogelijke partners, door zijn eigen processente vergelijken met dat van de in het register beschreven bedrijven. Als een passendepartner gevonden is, kunnen de twee bedrijven op basis van hun eigen bedrijfs-procesbeschrijvingen een samenwerkingsovereenkomst afsluiten waarin staat hoe zezaken wensen te doen. Het zoeken van een partner in een ebXML register en hetcreeren van een samenwerkingsovereenkomst neemt de plaats in van de langdurigeontwikkel- en implementatietrajecten van EDI. De beschikbaarheid van ebXML-infrastructuren zal het voor grote en kleinere bedrijven mogelijk maken om binnenenkele minuten zakenpartners te vinden.

Een van de onderdelen van ebXML die nog gedefinieerd moeten worden is hetalgoritme voor zoeken, vergelijken en matchen van bedrijfsprocessen. De vraagdie hier beantwoord moet worden is: Wanneer zijn twee processen “hetzelfde”?Wanneer lijken ze “voldoende” op elkaar dat de bedrijven zaken kunnen doen? Ditproject zal

• definities van zoeken, vergelijken en matchen onderzoeken,

• die in een prototype implementeren,

• de geımplementeerde definities valideren door ze op voorbeelden toe te passendie de gebruikers in de gebruikersgroep zullen verschaffen,

• een begrijpelijke en bruikbare terugkoppeling definieren over de mate waarintwee processen (on)vergelijkbaar zijn, en

• een bruikbare vraagtaal vraagtaal definieren en implementeren.

We zullen onze resultaten valideren op voorbeelden die de gebruikers zullen ver-schaffen. Zie de appendix voor een voorbeeld.

Dit project zal de kennis over e-business technologie een stap voorwaarts brengen.de gebruikers zijn in het project geınteresseerd omdat het ze in hun consultancykan helpen of, zoals ECP.nl, het ze kan helpen e-business technologie verder in hetNederlandse bedrijfsleven te verspreiden.

Het project is urgent omdat de ebXML standaard nu gedefinieerd wordt en eendefinitie van het zoeken en matchen van processen nog aan ebXMNL ontbreekt.Een van de leden van de gebruikersgroep, Berenschot (F. van Blommestein), is eenlid van de ebXML standaardisatie-werkgroep. Dit verzekert de mogelijkheid vaneen technologie-overdracht van dit project naar ebXML.

2 People who will carry out the research

Funding requested from STW:

• a postdoc (Dr. Ir. R. Eshuis, currently at CRP Henri Tudor, Luxemburg),and

4

• a technical assistant (Ir. J. Vonk).

No funding requested:

• a project manager (Prof. Dr. R.J. Wieringa, University of Twente).

3 Scientific description

3.1 Content

3.1.1 Background

In the last decades, EDI (Electronic Data Interchange) has been quite successfulin enabling efficient trading between companies. A drawback of EDI, however,is that it is inflexible, making ad-hoc cooperation between companies impossible.Moreover, applying EDI is expensive so that only large companies can afford toapply EDI. The rise of the internet has increased the flexibility and possibilities forcompanies to cooperate with each other electronically. XML (eXtensible MarkupLanguage) is by now the standard language for defining data interchange formatson the internet. Recently, an XML-based framework, called ebXML [3], has beenintroduced, that is intended to support companies in doing e-business. The goal ofebXML is to facilitate “frictionless” cooperation between companies over computernetworks. The term “frictionless” here means that cooperation is efficient andflexible.

The intended way of using ebXML is that industrial consortia and industrial branchorganizations agree on standard business transactions and business processes thatcompanies in the branch can perform, and on the standard messages that are ex-changed in these business processes. These standard messages are stored in a publicrepository. A description of a business process that use these messages is called acollaboration profile, and profiles are stored in a public registry.

There are two ways for a business to interact with a registry. First, when someindividual company A wishes to cooperate with other companies using the ebXMLframework, it stores a description of its business process in a registry that is ebXMLcompliant. In this description, A describes its own capabilities and what it requiresfrom its trading partners. The process description can refer to standard componentsin the repository, but this is not obligatory.

The second way of interacting with a registry is to search for a potential businesspartner. Some other company B wishing to do business using ebXML, can searchthe registry for a suitable partner. It then searches for a partner with business pro-cesses that “match” its own. There are usually differences between processes, andmatching two business processes results in a kind of “intersection” of the processesthat can be performed by both partners.

3.1.2 The research problem

In ebXML, a business transaction is a value exchange between two companies usingthe internet. From the point of view of computer support, a business transactiontypically involves a sequence of interactions in which companies exchange businessdocuments. One of the companies acts as initiating or requesting party, the otheras responding party. A business process typically consists of a group of business

5

Ship

Pay

Pay Ship

buyer of goods (initiating party) seller of goods (responding party)

Pay Ship

proposed common orchestration

Handle questionnaire

Pick Pick

Pick

Figure 1: Example

transactions that are ordered in a certain way, for example business transactiona must always be followed by business transaction b. To emphasize that we con-sider business processes that cross organizational boundaries, ebXML calls such anordering a choreography or orchestration.

Orchestrations are specified using an XML schema (DTD) for business processesdefined in ebXML, called BPSS [4]. Because specifications in BPSS are hard toread by people, the concepts in BPSS are borrowed from UML activity diagrams, sothat orchestrated business processes specified in BPSS can be visualized using UMLactivity diagrams, where nodes represent business transactions or other orchestratedbusiness processes. UML activity diagrams, and hence BPSS, can express basicordering constructs like sequence, choice and parallelism but also more advancedones.

The problem with this is that the definition of neither BPSS nor of UML activ-ity diagrams is yet finished, and automatic matching of two BPSS descriptions istotally unspecified. Only procedures for matching of business information itemsare sketched (in documents that have not yet been officially approved [5, 6]. Us-ing these, business transactions can be matched by comparing the contents of themessages that each of the transactions exchanges. component specification). Thesituation is not different in the development of web services standards [11]. How-ever, ebXML does not say how orchestrations can be matched. But to make the useof ebXML possible, this must be defined and implemented: Automatic matchingrequires a formal and executable procedure to decide whether or not two businessprocess descriptions match. In this project we propose to do research to realizeautomatic matching of ebXML-based business process descriptions.

Example. To explain the problem in more detail, consider the example in Fig-ure 1. The buyer is the initiating party (top-left diagram) and the seller is theresponding party (top-right diagram). The buyer wishes to buy some goods thatneed to be shipped and paid for. The three activities Pick, Ship and Pay all involve,among others, exchanging information with the seller. The seller offers to first havethe goods paid and then to ship them. Moreover, the seller wishes to do somequality control and requires that the buyer fills in a questionnaire concerning theservice delivered by the seller throughout the order process.

Let us now try to match these two business process descriptions. We assume thatboth parties have already agreed with each other that business transactions withthe same name are indeed similar. The common orchestration of both processes

6

is shown in the bottom of Figure 1. But in this common orchestration, the sellercannot do Handle questionnaire, whereas according to its process description, thisbusiness transaction is obligatory for the seller. The conclusion must be that thecompanies cannot cooperate.

However, it is possible to repair this mismatch, in two different ways. First, thebuyer can decide to do Handle questionnaire in parallel with the other businesstransactions. Second, the seller can decide to skip Handle questionnaire in thisparticular case.

Note that if the process descriptions are repaired and a match can be brought about,then the buyer loses some of the business scenarios that are permitted according toits own orchestration, for instance Pick → Ship → Pay.

3.1.3 Research questions

The goal of our research is to realize automatic matching of ebXML-based businessprocess descriptions. The most important questions to be answered are listed here:

• What is a good definition of matching?

– This starts with the question what “good” means here. Is an exactmatch required or are certain matches good enough? How does onecompute tradeoffs between different matches that are “good enough”?This question remains even when we only consider exact matches. Ingeneral, a given process can match exactly with several others stored ina registry. Since in an agreement only one process description is allowed,the “best” match has to be found. This requires a metric on matching,i.e., one process description may match “better”, according to the metric,than another.

– Whatever “good” means, it should at least mean that if two orchestra-tions match according to our definition of matching, then indeed bothparties should be able to collaborate at run-time without any problem.

– Business transactions are the smallest components of a business process,and descriptions of them are stored in an ebXML repository. Partnerswishing to do business uses these descriptions. The research questionhere is: How to define transactions in such a way that (software used by)all partners can interpret this automatically? One obvious way to do thisis to used pre– and postcondition pairs on input and output data, butthis is not yet part of ebXML. Some research issues must be resolved,such as in which cases the pre– and postcondition pairs of requested andsupplied transactions need not match exactly for the partners to be ableto do business with each other.

– Each business transaction is executed by two roles that cooperate. Oneof the roles must be played by the initiating party, the other by theresponding party. Both parties list the roles that they can play. In anorchestration, different business transactions can have different role spec-ifications. So, more than two parties can be involved in an orchestration.Together, all parties must be able to play all the roles required by thebusiness transactions in a consistent way such that the business processcan be executed.

– The definition of matching should take into account that some tradingpartners may not want to change their orchestrations. We explained

7

this already above by means of the example. Basically this means thereare two forms of matching (with and without adaptation w.r.t. optionalbehavior).

– One of the questions to be answered is whether the role of the party(initiating, responding) has influence on the matching algorithm. If so,then matching of an initiating party differs from matching of a respondingparty.

– Is matching symmetric? In other words, is a match for a seller always amatch for a buyer and vice versa? We suspect that a match that is good

enough for a seller may not be good enough for a buyer.

• What algorithm can efficiently check this definition?

– Once we have one or more definitions, we should operationalize this inan algorithm that should be efficient enough to be useful in searching alarge collection of orchestrations. Preferably, the whole approach mustscale up linearly.

– In addition to analyzing the efficiency of the algorithm, it should bevalidated by a prototype implementation that should be tested in severalscenarios provided by the users. (See the appendix for an example.)

• How can intelligent feedback be given?

– Both in case of match and of a mismatch, feedback must be given. Incase of a match, there may be information about the correspondencebetween transactions with different names and the obligation to fix theorder of some transactions in order to comply with the business partner’sprocess. In case of a mismatch, information about the reason for themismatch must be given. This is not a trivial matter because errormessages typically are stated in terms of obscure internal representationsand a mathematical semantics of processes. The feedback should be fullyunderstandable to a person who understands the business process and itshould also contain hints for what to do to repair the mismatch.

– The feedback mechanism too should be tested in a prototype implemen-tation.

• What is an appropriate query language for business process descrip-

tions?

– Just as intelligent feedback from a (mis)match, a query language forbusiness processes should have a semantics defined in terms of the processrather than some underlying mathematical structure, and it should bevalidated by means of an implementation. Note that for each definitionof matching, a query language must be defined that specifies matchesaccording to the semantics of that definition.

• How can profiles and queries be derived from the business context?

– When a business seeks partners through an ebXML registry, either byoffering profiles or by searching for profiles, the real match that must beachieved is between the business strategy and business objectives of thepartners. This leads to the question how business strategy and objectivescan be analyzed to define a profile, or to define a profile query. Elementsof the business context to be taken into account include the following:

∗ International trade procedures and national laws set the conditions

8

∗ Sector models define high level process and metadata options

∗ Company policy, logistic control and data processing infrastructurefor each individual partner.

∗ Blanket contracts to identify general conditions for the long termrelation between two partners

∗ Specific agreements define the inter-organizational business processes

These various sources constrain possible profiles but do not completelydetermine them. The profile should therefore include enough flexibilityto allow for different options and deviations at runtime.

• How should profiles be described?

– The current profile description language BPSS is intended for describ-ing agreements, which are the outcome of matching, rather than pro-files stored in a registry. The definition(s) of matching produced in thisproject will have impact on the definition of a profile description lan-guage. A profile description language should allow a business to describeits profiles with sufficient flexibility to increase the chance on a successfulmatch, while at the same time force the business to be specific enough sothat a match selects an intended business partner. Flexibility is achievedby allowing for the specification of options and deviations at run time.Specificity is achieved by incorporating in the profile description require-ments that arise from the following sources:

∗ Process choreography and orchestration

∗ Information modeling, semantics of business (information) entitiesand document assembly

∗ Networking options, given security and reliability demands

We will include these requirements in our profile description language.

3.1.4 Method

We expect to iterate several times through hypothesis formation and validation.The hypothesis each time will be that we have a “good” definition of matching.The validation each time will consist of testing this definition in a number of casestudies to be provided by the user group of this project.

We will start by analyzing the example BPSS-based business process descriptionsthat will be provided through the user group of this project. To gain insight in theproblem, we will first search for ad-hoc solutions and discuss these with the users.This will allow us to identify common business practices in process matching.

At the same time, we will study the literature to search for suitable matchingdefinitions. We will look at simulation relations as defined in the field of processalgebra [9]. Simulation relations are used to compare processes and therefore providea good starting point. A drawback, however, is that they require that the semanticsis computed first. This can be very inefficient. We will therefore try to lift thesimulation relation from the semantics to the syntax. Matching on syntax ratherthan semantics has two advantages.

First, it is much more efficient than matching on semantics, since the semantics doesnot have to be computed. Second, mismatches can be explained directly in termsof the syntax, rather than in terms of the semantics. We will use the work doneon place bisimulations [13] in the context of Petri nets as a starting point for this.Place bisimulations are partly defined on the syntax of Petri nets (even though the

9

definition refers to marking which is a semantic concept). We expect that we haveto change the definition of place bisimulations in order to make it independent fromthe semantics used.

In a second iteration, we will combine the lessons learned from this initial study intoa definition of matching that can be formalized and also meets the requirements ofthe user group. We will validate this in a number of larger case studies that wewill perform manually, and collect feedback about these case studies from the usergroup. This may lead to further improvements of the definition(s).

In a third iteration, we will implement the improved definitions in a software tool.We plan to use the TCM tool developed at the UT for this [8]. This will allowus to perform larger validations and also analyze and test the performance of thealgorithm.

Once we have an implemented and validated definition, we will approach the ques-tions of intelligent feedback and a usable query language in the same manner. Weplan to test the usability of these tools by means of feedback from the user group.

3.2 Project plan

WP1 WP2 WP3

WP4

WP5

WP6

Figure 2: Dependencies among work packages. An arrow from work package A to work

package B means that after A is finished, B can start.

We distinguish the following work packages. Figure 2 shows the dependencies amongthe packages. The diagram shows that WP4 and WP5 can start as soon as WP1has started, but they cannot finish before WP3 has finished. WP6 must wait forWP4 and WP5 to finish.

WP1 Initial definition of matching: Analysis of cases, including the business chal-lenge (section A), proposal of ad hoc matching relations, literature study ofmatching relations, validation. Formalized definition of matching, validationon larger case studies.

WP2 Role matching: Preliminary orchestration matching definition, validation andfeedback from user group, incorporation in matching definition, implementa-tion in tool, validation on larger case studies provided by users. Performanceanalysis and testing of the algorithm.

WP3 Metrics for matching. Define a metric on orchestration matching relation,validation and feedback from user group, incorporation in matching definition,implementation in tool, validation on larger case studies provided by users.Extension of the algorithm, performance analysis and testing.

10

WP4 Definition, validation and implementation of intelligent feedback for the sev-eral matching relations, that relates the matching result (success or failure)to the business context.

WP5 Definition, validation and implementation of a usable process query languagefor the several matching relations. Definition of guidelines to formulate aquery based upon business objectives and business context.

WP6 Identification of guidelines for deriving profiles from business context, basedupon case studies done during the project.

WP7 Project management.

Figure 3 shows the planning of the workpackages and the allocation of resources.

1 2

WP1: 6 WP2: 7 WP3: 7 WP4: 4 WP5: 6

WP7: 3

WP6: 6

3

P

T

M

WP2: 5 WP3: 5 WP4: 3 WP5: 5

Figure 3: Planning. M = Project management, P = Postdoc, T = Technical assistance.

The project takes three years to complete. “WPn: m” means that this part of WPn takes m

months of person-time.

3.3 Required personnel and equipment

Funding is requested for

• a postdoc (Dr. Ir. R. Eshuis) and

• a technical assistant (Ir. J. Vonk)

and for the equipment used by the postdoc and the technical assistant.

The UT will provide project management capacity (Prof. Dr. R.J. Wieringa) andinfrastructure and office space for the postdoc and technical assistant.

3.4 How this project relates to existing research

Recently, some related work has been done by Piccinelli et al. [14], building on workof Van der Aalst and Basten [1]. Their approach is in the field of web services, notebXML. This means that matching is done on the basis of name equality ratherthan on the basis of transaction definitions in a repository and moreover, thatmatching is done statically. There is no automated discovery in Web services.Another difference of their approach with our approach is that they do matching

11

on the semantics of orchestrations, in this case the reachability graph of a Petrinet. This can be very inefficient since the semantics (reachability graph) needs tobe computed. We, however, will look at matching at the syntactic level. A relateddifference is that the work of Van der Aalst and Piccinelli does not consider feedbackin terms of high-level process descriptions such as activity diagrams.

Related work is done in the field of matching software components [2, 12]. Just asin our case, the check is done on the semantics of descriptions, which leads to anexponential state space blowup. There are some partial solutions to this problem,e.g. [12], but these solutions are usually at the expense of loosening the check; thatis, if the outcome of the check is ’no deadlock’, the system does not deadlock, butif the outcome is ’deadlock’, the system perhaps does not deadlock.

4 Utilization

The users of this project will be TNO-FEL E-Business (Enschede), Berenschot,ECP.nl and IBM. The project will advance the state of the art in e-business tech-nology. It will advance the state of the knowledge in the Netherlands about thistechnology. The users are interested in this project because it may help them intheir consultancy. ECP.nl is interested because it can facilitate the spread of ebXMLtechnology to branch organizations in the Netherlands.

This project is urgent because ebXML is currently under development and a gooddefinition of process matching is still missing. One of the members of our usergroup, Berenschot (F. van Blommestein) is a member of the ebXML standardizationworking group. This ensures the possibility of technology transfer to ebXML.

The users of this project have posed a challenge to this project in the form of a tradescenario. See appendix A for this scenario. We will use this and other scenarios, tobe collected during the project, as testcase throughout the project.

4.1 TNO-FEL E-Business

TNO is the leading national applied technology R&D organisation in the Nether-lands. It consists of 15 institutes, one of which is TNO-FEL. The E-Business groupof TNO-FEL builds and maintains knowledge on business and information archi-tecture and integration frameworks and technologies for Dutch and internationalclients and partners.

TNO-FEL E-Business will use the results of this project in its future work on plug-and-play e-business and apply it in business sectors and companies via its contractresearch.

Contact information

Paul Oude Luttighuis (dr. ir. P.H.W.M.)head of e-business groupTNO-FEL E-BusinessColosseum 277521 PV Enschede+31 (0)53 4802119 tel+31 (0)53 4310021 faxoudeLuttighuis@fel.tno.nl

12

4.2 Berenschot

Berenschot offers full service management consultancy, both to the private sectorand to governmental organizations. These services include company strategy andpolicy, human resource management logistics and information management.

Berenschot is involved in a number of assignments developing and employing ebXML.In particular, Berenschot is involved in the further definition of the ebXML stan-dard. The results of this research project will be used to further develop the stan-dards and be applied in practical situations.

Contact information

Ir. F.B.E. van BlommesteinBerenschotEuropalaan 403526 KS Utrecht(030)2916916fax: (030)2916854fjb@berenschot.com

4.3 ECP.nl

ECP.NL is a neutral platform that helps accelerate the creation of e-business in theNetherlands. There are currently about 175 organizations member of ECP.NL. Thework of ECP.NL is encouraged and supported by the Dutch the government. Themain activities of ECP.NL are to develop an awareness in Dutch industry of theopportunities and the threats of electronic commerce, to facilitate reliable e-businessby creating relevant norms, standards and legal conditions, to support e-businesspilot projects and to participate in international fora in e-business aspects. ECP.NLwill use the results of this research project as input for pilot projects and awarenessactivities concerning ebXML.

Contact Information

Drs. Frank van den EijndenECP.NLOvergoo 112266 JZ Leidschendam+31 (0)70 4190 309 tel+31 (0)70 4190 650 faxfrank-van-den.eijnden@ecp.nl

4.4 IBM

IBM is a full business services and ICT technology company active in both govern-ment and private organisations. IBM is an active participant in the developmentof ebXML. It supports the development of this open standard and implements it intheir web services products. These developments are crucial in IBM’s ’e-Businesson Demand’ strategy.

13

The results of this project will be used for these activities and for further enhance-ments to the standard. The organisation in the Netherlands, connected with similarorganisation in the other countries, will be the ’Strategy and Change solutions unit’of which mr Paul van Wijngaarden is the practice leader. This proposal wouldcontribute to an advancement of the state of the art in e-Business and e-Businesson demand.

Contact information

Ir. Appie Reuver, IBM Nederland N.V.Johan Huizingalaan 765, 1066 VH, AmsterdamTel (31) (0) 20 5136685, fax (31) (0) 20 6691173Internet Appie Reuver@nl.ibm.com

5 Knowledge management

There are no contracts governing the results of this project. Because the results ofthe project will be public, no patent search has been done.

6 Budget

We request support for 1 full-time postdoc for 3 years and technical assistance for18 months, and for the equipment used by this personnel.

Users will not contribute financially. Rather they commit themselves to the provi-sion of case study material and of feedback about the results of the project.

Results of this research will be presented at ebXML meetings and be publishedin international conferences and journals. Also, we will visit the users on-site todusciss requirements and inform them of results. Consequently, a travel budget ofEuro 12000.- is needed for successful dissemination of project results.

1 full-time postdoc, 36 monthsTechnical assistance, 18 monthsEquipment (2 PCs) E 4400Tools (e.g. software) E 3000Travel E 12000

References

[1] W.M.P. van der Aalst and T. Basten. Inheritance of workflows: An approachto tackling problems related to change. Theoretical Computer Science, 270(1-2):125–203, 2001.

[2] Robert Allen and David Garlan. A formal basis for architectural connection.ACM Transactions on Software Engineering and Methodology, 6(3):213–249,1997.

[3] ebXML. http://www.ebxml.org.

[4] ebXML. Business process specification schema v1.01.http://www.ebxml.org/specs/.

14

[5] ebXML. Collaboration-protocol profile and agreement specification version 2.0.http://www.ebxml.org/specs/.

[6] ebXML. ebXML Core Components Technical Specification v. 1.8. Available athttp://www.ebtwg.org/projects/documentation/core/.

[7] R. Eshuis. Semantics and Verification of UML Activity Diagrams for Workflow

Modelling. PhD thesis, Department of Computer Science, University of Twente,2002.

[8] Toolkit for Conceptual Modeling. Chair of Information Systems, Departmentof Computer Science, University of Twente. www.cs.utwente.nl/∼tcm.

[9] R.J. van Glabbeek. The linear time – branching time spectrum I. The semanticsof concrete, sequential processes. In J.A. Bergstra, A. Ponse, and S.A. Smolka,editors, Handbook of Process Algebra, pages 3–99. North-Holland, 2001.

[10] P. Grefen, K. Aberer, H. Ludwig, and Y. Hoffner. Crossflow: Cross-organizational workflow management for service outsourcing in dynamic virtualenterprises. IEEE Data Engineering Bulletin, 24(1):52–57, 2001.

[11] IBM and Microsoft. Business process exe-cution language for web services, version 1.0.http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/.

[12] Paola Inverardi, Alexander L. Wolf, and Daniel Yankelevich. Static checkingof system behaviors using derived component assumptions. ACM Transactions

on Software Engineering and Methodology, 9(3):239–272, July 2000.

[13] E.-R. Olderog. Nets, Terms and Formulas. Cambridge Tracts in TheoreticalComputer Science 23. Cambridge University Press, 1991.

[14] Giacomo Piccinelli, Wolfgang Emmerich, Christian Zirpins, and Kevin Schutt.Web service interfaces for inter-organisational business processes. In Proc.

EDOC 2002, 2002.

A Appendix: Challenge from Practitioners

This appendix describes the case posed to us as challenge from practitioners. Wewill use this as one of our test cases throughout the project.

Horticultural trade in flowers and potted plants exist of many small companies(retailers, carriers, wholesalers, auctions and growers). Due to the fact that theproducts are alive, horticultural trade has a complex logistics with many legal andtechnical conditions.

The value chain runs from growers to wholesalers, possibly through an auction,and from wholesalers to retailers (figure 4). The flow of material is performed bycarriers. Figure 5 shows some of the communications among business partners.We now consider a situation in which there are many growers, carriers, etc. andin which any actor in the value chain can choose to do business with some otheractor. For example, a grower may choose one carrier for one batch of plants, andanother carrier for another batch. This flexibility is possible if all actors in thevalue chain have access to an ebXML registry in which they store a description oftheir business processes, such as the process they have for ordering, order-taking,payment, credits, acceptance of goods, return of goods, etc. These descriptions arecalled profiles in ebXML.

15

Grower Wholesaler

Carrier

Auction

Retailer

Figure 4: Flows of material. Materials are transported by carriers.

Grower

Wholesaler

Carrier

Auction

Retailer

Figure 5: Some of the communications among actors in the value chain.

Now consider some of the variations in profiles to be covered by the registry. Eachof the following examples concerns variations in communication protocols amomgtwo or more business partners. In classical EDI, all of these possibilities must benegotiated orally between every pair of possible business partners. Using ebXML,these possibilities need to be described only once per business and then stored inan ebXML registry, which is an enormous increase in efficiency.

As a first example, consider the normal case that a grower employs a certain carrierto carry his products to an auction. Here are a number of variations for whichprofiles must be defined:

• One variation is when a customer is prepared to pick up the products atthe growers location rather than from the auction. The grower, auction andcarrier must have matching profiles for this too.

• Anohter variation that can occur is that the volume is high enough to trans-port the products directly to the wholesalers location. Transport fees areeither included in the product price or separately charged. The grower, car-rier and wholesaler must have matching profiles for this too.

• The products may alternatively be packed on two different types of roll-

16

containers, with different conditions regarding rental fees, administration andreturn logistics. Again, this possibility must be catered for by profiles.

Interactions can involve two or more parties. For example, a grower should not onlyexchange information with carriers but also with wholesalers or retailers. This isbecause packaging of products may be neutral, grower-branded, wholesaler-brandedor retailer-branded. Prices, due to marketing fees and handling cost, are differentfor each option. And branding by wholesaler or retailer require the grower to beinformed of the packaging details. The profiles registered by a grower must describethese possibilities.

Some products must be accompanied by a fytosanitory certificate. This obligationis dependent on product type and retailer location, and this information should bepresent in the profile descriptions.

Profiles can also vary according to their temporal properties. For example, a whole-saler may give a tentative planning a week in advance. Products are usually orderedtwo days in advance and carriers must be informed one day in advance.

The quantity of products delivered may deviate from the quantity ordered, and thisrequires a data flow back from receiver to sender of goods. Of course, sender andreceiver must abide to the same protocol for exchanging information in this caseand this again must be described in profiles.

Products of different types may be packed on the same container; the wholesalermust be notified of the packing sequence. This too requires protocols agreed uponby grower, carrier and wholesaler. Different wholesaler may follow different proto-cols and different carriers may follow different protocols too, and so this must bedescribed in profiles.

Products must be individually traceable. The communication mechanisms for track-ing and tracing must be agreed upon by the business partners and so there mustbe a profile for this.

Another source of variability lies in the product codes used in communication, whichmay be sector-defined, grower-specific, wholesaler-specific, or retailer-specific. Theselection between these options is governed by information-processing capabilitiesof grower and wholesaler and by the existence of web-based translation services.

For invoicing and payment there exists a range of protocols too, which must bedescribed in profiles and agreed upon before partners do business. For example,invoicing and payment may be direct or through auction services. Allowances andcharges are affected by this choice. Payments are always being processed by theauction service when products physically pass the auction.

17