Individual Service Clearing as a Business Service: A Capable Reference

Solution for B2B Mobility Marketplaces

Michael Strasser

, Nico Weiner

and Sahin Albayrak

Bosch Software Innovations GmbH, Sch

oneberger Ufer 89, 10785, Berlin, Germany

DAI Laboratory, Technical University of Berlin, Ernst-Reuter-Platz 7, 10587, Berlin, Germany

Keywords:

Individual Service Clearing, Service Marketplaces, Service Platforms, Service Interface Design, Smart City

Mobility Services.

Abstract:

The paper presents an approach for individual and outsourced service clearing within Business-to-Business

marketplaces for mobility services in a Software as a Service fashion. The lack of service clearing possibili-

ties within today’s marketplaces solutions for mobility services have been conﬁrmed by interviews experts who

highlight the need for clearing. To enable service clearing, appropriate interfaces which enable access upon

data are required. Current solutions lack those interfaces and thus service clearing to charge service transac-

tions is not possible. The paper discusses interfaces for outsourced service clearing according to their design,

data and role dependencies. A reference solution is implemented to demonstrate the feasibility of the inter-

faces and the overall clearing approach. A clearing algorithm has been developed to validate the interfaces’

reliability and correctness. Our presented clearing approach enables marketplace participants to outsource the

transaction clearing to a provider which offers clearing capabilities. The work on hand contributes to interface

and protocol standardization in respect to service clearing and marketplace interconnectivity.

1 PROBLEM DESCRIPTION

The number of service consumers and providers for

mobility services (e.g. car sharing, charging, park-

ing, routing) increases constantly. It is anticipated that

this trend will probably result in a higher number of

service offerings, demands and transactions (Thitima-

jshima et al., 2015). As a logical consequence, more

business relationships will be established via elec-

tronic service marketplaces. These marketplaces rep-

resent the environment in which participants can ac-

complish service trades. These marketplaces are pure

B2B oriented and do not deal with end-customers.

End-customers are registered with service consumers.

The increasing demand for convenient mobility will

subsequently increases the usage mobility services.

That circumstance leads to more transactions which

are processed by a service operator and probably

routed by a marketplace. One of the service operator’s

duties is to have capabilities to uniquely assign a sin-

gle transaction to one particular contract (Pfeiffer and

Bach, 2014). This is necessary to assure that a ser-

vice consumption (transaction) is cleared (charged)

according to the conditions deﬁned in the business

contract.

It is likely that the growth of service consump-

tions results in a higher effort for service clearing

(transaction billing). Therefore it is feasible to as-

sume that certain service operator want to outsource

the complete service clearing process to a third party.

This party has to have comprehensive knowledge and

approved and standardized processes in the service

clearing domain. For individual service clearing, a re-

spective clearing operator has to register with a mar-

ketplace and offer clearing services to other partici-

pants as software as a service (SaaS). Such a clearing

operator is called service consumption clearing op-

erator (SCCO). A service operator, for instance for

charging stations, who want to outsource the service

clearing process can contract a SCCO’s clearing ser-

vice. Once they are business partners, the charg-

ing station operator can assign the SCCO’s clearing-

service to all his services which he wants to be cleared

(charged) by the SCCO. Therefore, a service market-

place for mobility services has to provide mechanisms

to ensure accurate data access on internally stored

data. Interviewed experts

point out that individual

The interviewees’ afﬁliation are presented in the ac-

knowledgment section.

Strasser, M., Weiner, N. and Albayrak, S.

Individual Service Clearing as a Business Service: A Capable Reference Solution for B2B Mobility Marketplaces.

In Proceedings of the 6th International Conference on Cloud Computing and Services Science (CLOSER 2016) - Volume 2, pages 27-38

ISBN: 978-989-758-182-3

service clearing does not exist in electronic market-

places for mobility services but is required. Individual

in this context means that a marketplace participant

can do the clearing on his own or contract and entitle

a professional SCCO. However, due to missing Ap-

plication Programming Interfaces (API)s, outsourced

service clearing is one of many use cases which can-

not be accomplished because access to data stored

within the marketplace is not possible. As discussed

by Gubbi et al., a service infrastructure has to provide

appropriate APIs which can be used to enable ﬂexible

billing (Gubbi et al., 2013).

The rest of the paper is organized as follows. Sec-

tion 2 presents the current state of the art in B2B ser-

vice clearing in marketplaces for mobility services.

Section 3 introduces the interfaces which are deemed

as necessary to enable communication with the mar-

ketplace. Section 4 discusses the elaborated approach

for individual service clearing. The evaluation of the

interfaces and the elaborated and prototypically im-

plemented service clearing algorithm are presented in

Section 5. The paper ends with a conclusion in Sec-

tion 6 and a short outlook on further research in Sec-

tion 7.

2 CURRENT STATE OF THE ART

Research projects

explore possibilities about how to

provide services for the mobility domain, like charg-

ing services for electric vehicles, sharing services for

bike or car as well as services which help to ﬁnd free

parking lots. A system which provides access to such

services is called for example e-hub (Grieger, 2003),

service provisioning platform, (

A gerfalk et al., 2006),

Value Added Service Supplier (Legner, 2007) inter-

mediary (Heinrich et al., 2011), Platform (Buchinger

et al., 2013) or electronic marketplace, trading com-

munities, trading exchanges (Turban et al., 2015).

Companies

also provide Information and Communi-

cation Technology (ICT) based solutions over which

mobility service operators can offer and mobility ser-

vice consumers can access mobility services. These

mobility services enable end-customers of service

consumers to experience the capabilities of future

mobility. An electronic marketplace is the environ-

ment for service operators (offer services) and service

consumers (consume services) to trade services like

For example: Green eMotion (Green-eMotion, 2015),

CROME (CROME, 2014), Olympus (Olympus, 2015),

Streetlife (Streetlife, 2015)

For example: Hubject (Hubject, 2015), Parku (Parku,

2015), Multicity (Multicity, 2015), Smartlab (smartlab In-

novationsgesellschaft mbh, )

goods (Ghenniwa et al., 2005). An electronic market-

place matches sellers and buyer and encourage them

for service trades by providing appropriate trading ca-

pabilities (Turban et al., 2015).

Current marketplaces for electric mobility ser-

vices lack the possibility to enable data access on

internally processed and data from outside. This is

a limitation and prevents further use cases and the

realization of Critical Success Factors (CSF). Inter-

viewed experts have emphasized that it is mandatory

to access transaction data, contract data, participant

information or service descriptions via APIs. By the

current date, neither an appropriate protocol nor re-

spective interface standards are available to guide the

development of respective interfaces regarding com-

prehensive communication with the outside world.

Without comprehensive data access, internal data is

locked inside a marketplaces and cannot be processed

further by any participant expect the marketplace it-

self.

Costs accrue for being a member of a marketplace

(depends on a marketplaces’ revenue model (John-

son, 2013)) but also for using a service provided via

a marketplace (interviewed experts). An identiﬁed

business case (also indicated by interviewed experts

and literature) is business to business (B2B) clearing

also known as service charging. Clearing is consid-

ered as a CSF of electronic marketplaces (Balocco

et al., 2010; Johnson, 2013). The experts point out

that service provisioning marketplaces have currently

no elaborated clearing approach or completely lack

the possibility to enable service clearing within their

system. Pfeiffer and Bach point out that a business

model for clearing does currently not exists and that

”the billing process is more cost-intensive than the

overall billing amount” (Pfeiffer and Bach, 2014).

These are the reasons why it is currently not op-

erated within marketplaces or platforms. However,

clearing mechanisms have to be in place as trans-

actions are not free of charge (Rust and Zahorik,

1993; Buyya et al., 2008; Johnson, 2013; Thitima-

jshima et al., 2015). Even though no appropriate busi-

ness models for transaction clearing exists, the rise

of new demands or the development of new capabil-

ities might enable cross selling or combining of ca-

pabilities which justiﬁes certain clearing models. A

clearing service is deemed as a value added service in

within electronic commerce conducted via a market-

place (Turban et al., 2015).

Marketplaces for electric charging infrastructure

like Green eMotion and Smartlab’s e-clearing.net per-

form do B2B service clearing for their participants

right within their systems. There is no choice for

their participants to appoint another clearing operator.

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

CROME or Hubject do not support service clearing

inside their platform and leave it to their participants

who have to agree on a common clearing method.

The limited service clearing mechanism is a disad-

vantage of all of today’s platforms and marketplaces

for mobility services. Current solutions do not pro-

vide appropriate interfaces that enable access to inter-

nally stored data or do not even store data accordingly

(interviewed experts). This cripples the possibility

for individual service clearing where participants out-

source the clearing process and appoint an individual

clearing service operator which meets their require-

ments. The state of the art in transaction clearing

in marketplaces for mobility service is in summary

that either the marketplace itself seizes service clear-

ing or participants have to do it somehow outside the

marketplace. Marketplaces like Amazon or iTunes as

well as eBay and other known marketplaces or trad-

ing platforms offer a handful payment options to their

participants. Individual service clearing via SCCOs

and internal B2B transaction clearing is not foreseen

in their solutions.

The paper on hand is a comprehensive expansion

of (Strasser et al., 2016). Its contributions are pre-

sented in List 1 below.

• A comprehensive outline of the problem domain

and the current state of the art

• An extended overview of required interfaces for

future marketplaces along with an simpliﬁed ar-

chitecture

• An expanded presentation of the deﬁned clearing

process

• A deeper discussion of the elaborated clearing in-

terfaces and their implementation

• An extensive presentation of the developed ser-

vice clearing protocol and its parameters

• An open demonstration of the elaborated clearing

algorithm

• An performance evaluation of the clearing algo-

rithm

List 1: Contribution of the paper.

3 MARKETPLACE INTERFACES

Marketplaces have to provide appropriate APIs to en-

able access on internal data which is fundamental

for outsourced and individual service clearing. A

comprehensive set of marketplace interfaces enables

the accomplishment of various additional use cases,

for example interconnectivity between service mar-

ketplaces (Strasser and Albayrak, 2015; Strasser and

Albayrak, 2016) or Service Level Agreement (SLA)

and condition monitoring. The marketplace devel-

oped within this work consists of Service Oriented

Architecture (SOA). The marketplace’s communica-

tion interfaces use the Simple Object Access Protocol

(SOAP). The interfaces are developed in a role-based

manner instead of a data-driven manner. The in-

terfaces are furthermore differentiated between pub-

lic and private. Context, service or participant rele-

vant data can only be accessed via private interfaces.

This kind of data might be classiﬁed as conﬁdential

and only accessible for registered marketplace partic-

ipants. General information about a marketplace and

its participants, services, supported domains or oper-

ation area can be retrieved via public interfaces which

do not require a marketplace participation. List 2

presents interfaces which have been identiﬁed to be

of public interest. Thus they are accessible without

any marketplace registration. Registered participants

can use those interfaces too.

• Public interfaces:

– GetMarketplaceInformation

– GetParticipantOverview

– GetServiceOverview

– GetMarketplaceConditions

– SetRegisterParticipant

List 2: Public marketplace interfaces.

List 3 provides an abstract of private interfaces

which have been identiﬁed to be of private interest.

They provide access to conﬁdential and participant

dependent information and thus can only be accessed

by registered participants. These interfaces are as-

sumed as necessary to enable the communication with

other service marketplaces as well as to enable indi-

vidual and outsourced service clearing. Of course, re-

spective processes have to be implemented too. The

interfaces for the outsourced service-clearing are em-

phasized in bold. The interfaces for the marketplace

interconnectivity are emphasized in italic. The inter-

faces are named according their functionality and pur-

pose.

Set and Get indicate whether information can be

retrieved (pull) from or send (push) to a marketplace.

The interfaces’ grouping towards public or private is

not ﬁnal. It might change once more use cases be-

come reasonable. Interfaces which are listed in both

lists provide more information if they are applied in

private mode. Due to security mechanisms, a API re-

quester is validated if it is a registered marketplace

participant. This is done by a certiﬁcate. Then it is

Individual Service Clearing as a Business Service: A Capable Reference Solution for B2B Mobility Marketplaces

• Private interfaces:

– GetParticipantOverview

– GetServiceOverview

– GetParticipantInformation

– GetServiceInformation

– SetCreateServiceOfferQuotation

– SetCreateServiceSearchQuotation

– GetServiceOfServiceType

– GetTransactionData

– GetClearingRelatedContracts

– GetContractData

– SetUploadMarketplaceData

– SetUploadParticipantData

– SetCloseContract

– SetUploadAllAvailableServices

– GetEndCustomerAuthorization

– GetMarketplaceConditions

– GetSearchServiceQuotation

– SetAcceptServiceQuotationCondition

List 3: Private marketplace interfaces.

checked what role the requester has to decide what

data can be accessed.

The interfaces are role-base driven rather than

data driven. That enables re-using and re-purposing

of interfaces while being able to limit the data ac-

cess accordingly. For security reasons, private and

public interfaces are separate web-services. This is

done to relieve each interface and because the in-

terfaces can have different service level agreements

Interfaces layer

Public:

GetParticipantOverview

GetServiceOverview

SetRegisterParticipant

…

Private:

GetParticipantOverview

GetServiceOverview

GetContractData

…

Security layer

(user credentials, role,

certificate)

Service

Quotations

Service

Consumer

Marketplace

Service

Operator

no security

Marketplace

Contracts

Transactions

Internal data layer

Figure 1: Interfaces to access internal marketplace data.

(SLA)s. Each web-service consists of various opera-

tions which represent one of the above identiﬁed in-

terfaces. Extensible markup language (XML) schema

validation is used to validate the input data. This en-

sures data type integrity and avoids malfunction. The

private web-service validates user-credentials and cer-

tiﬁcates. Figure 1 presents a simpliﬁed overview

about how marketplace data is accessed from exter-

nal.

Security mechanisms have to be in place to val-

idate requests and to determine which data the re-

quester is allowed to access. Even though the security

layer can also be applied for public interfaces, it is as-

sumed that security checks are costly and thus should

only be conducted when necessary.

4 ACCESSING AND PROCESSING

INTERNAL MARKETPLACE

DATA

The proposed marketplace interfaces facilitate the re-

alization of various use cases. Request routing, per-

formance and efﬁciency monitoring, Service Level

Agreement (SLA) validation or any other data pro-

cessing or measuring use cases can be developed.

However, the interfaces also enable individual service

clearing for B2B service transactions. Clearing ser-

vices require access at internal marketplace data from

outside. The elaborated marketplace provides those

interfaces and processes which are necessary to ac-

cess all required data to create an invoice for service

consumption. Service-clearing particularly requires

access to contract and transaction data.

4.1 Service Consumption Data

The following mobility use case exposes how trans-

action data incurs within a mobility service market-

place. A service operator (SO) has parking infras-

tructure. SO is registered with a service marketplace

(MP) and offers a service via the MP which enables

to access his infrastructure. The service’s functional-

ities are for example i) to open a barrier arm, ii) to

guide a driver to an empty parking spot or iii) to de-

termine the duration of the parking. Service consumer

(SC) is also registered with MP. SC searches for a ser-

vice with capabilities to access parking infrastructure.

Therefore, SC i) contacts SO, ii) negotiates the ser-

vice’s conditions and iii) settles a contract with SO.

A digital representation of the paper contract is stored

inside MP. The end-customer (EC) of SC cannot, at

ﬁrst, access the parking infrastructure of SO because

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

SO does not know EC. For SO is EC a stranger and

thus forwards the request to MP. MP checks all of

SO’s contracts and forwards the service request to all

of SO’s business partners. SC retrieves the service re-

quest and recognizes EC. SC responses accordingly

and MP forwards the response to SO. SO opens his

parking infrastructure for EC because SC has acted

as EC’s guarantor. As soon EC leaves the parking

area, SO sends a park detail record, which contains

information about the parking process, to MP which

forwards the record to SC.

4.2 Individual Service Clearing - An

Outsourced Invoice Approach

In the current context, service clearing is done in

respect to B2B service consumption among market-

place business partners (service operator and con-

sumer). Outsourcing the service clearing process to

a third party calls Luttge outsourced invoice (Luttge,

2001). This approach is, according to the interviewed

experts, not implemented by any mobility service

marketplace. However, the experts assume it as a fun-

damental functionality and according to Turban et al.,

a trading platform should provide mechanisms to ar-

range payment (Turban et al., 2015). Even though

Vidal et al. (Vidal et al., 2011) describe in detail what

kind of data has to be in place to clear an electric vehi-

cle charging process via a service marketplaces, they

miss the chance to implement and present a working

solution.

To outsource the service clearing process to a

SCCO a service operator must comply to the follow-

ing process: A SCCO-A offers a clearing service via a

marketplace (MP). Another service operator (SO-B),

who offers parking infrastructure services, closes a

contract with SCCO-A. Then, SO-B assigns the con-

tracted clearing service of SCCO-A to his service XY.

This entitles SCCO-A to access those contracts and

transactions which relate to SO-B’s XY service. The

service description of XY should particularly empha-

size that a third party (SCCO-A) has been entitled to

accesses all accrued transactions and the contracts re-

lated to service XY. A service consumer (SC) who

signs a contract with SO-B for service XY agrees on

the service’s conditions and thus accepts that SCCO-

A accesses all clearing relevant data. This agreement

is important because the transaction data represents a

kind of an end-customer’s mobility proﬁle. Thus SC

has to inform his end-customers about the third party

access. SCCO-A gathers the necessary data accord-

ing to the deﬁned clearing schedule and calculates the

price which SC has to pay SO-B. Due to the individ-

ually, SO-B can appoint another SCCO to his other

services but also can do the clearing on his own with-

out third party support. This functionality is not in

place by current available solutions but is prototypi-

cally implemented within this research.

The role-heritage diagram in Figure 2 presents the

roles used in the use-case diagram presented in Fig-

ure 3. The role Clearing Service Provider is not a

individual role in particular but represents a possible

character of a service provider. The generic use-case

diagram illustrates the roles, systems and processes

which are part of a individual and outsourced clearing

process. The elaborated Use-Case diagram is neither

an extension nor a modiﬁcation of (Pfeiffer and Bach,

2014) e-roaming clearinghouse. It presents a succeed-

ing step in which e-roaming is actually charged ac-

cording to negotiated conditions written in a contract

during, what (Pfeiffer and Bach, 2014) calls, settle-

ment.

Participant

Create Quotation

Establish

Relationship

Service

Provider

Service

Consumer

Clearing

Provider

Figure 2: Overview role inheritance.

To achieve individual and outsourced service

clearing various logical and functional challenges

have to be approached. An abstract of identiﬁed chal-

lenges is shown in List 4. The list does not claim

to be complete. Once our proposed solution is im-

plemented in commercial solutions it is believed that

further challenges will be identiﬁed. The challenges

furthermore depend on the design of the service clear-

ing as well as on the implemented contracting mech-

anism.

Legal regulations are not part of the research’s

scope. The interviewed experts conﬁrm the com-

plexity of service clearing but unfortunately do not

propose a suitable solution. No standardized pro-

tocol or data set exists on which data exchange via

marketplace APIs can be build on. The relevant do-

main protocols have capabilities to support the mar-

ketplace in its operation only. Marketplace partici-

pants are able provide to information to the platform

but cannot retrieve necessary information about con-

tracts and transactions or other data useful for future

business cases. Access on data is only possible for

data which has been provided by the participants be-

fore. No guidelines are available which emphasize the

required steps to enable data access from outside and,

Individual Service Clearing as a Business Service: A Capable Reference Solution for B2B Mobility Marketplaces

<<subsystem>>

Clearing

Provider

Backend

Collect data

Create invoice

Send invoice

<<subsystem>>

Service Provider

Backend

Connect

Infrastructure

Grand Access

Pay Clearing

Provider

Check Payment

<<subsystem>>

Service

Consumer

Backend

Customer

Authorize End

Customer

Charge End

Customer

Pay Consumption

Invoice

Service

Provider

<<Service Marketplace>>

Service

Consumer

Establish Business

Relationship

Create Service

Quotation

<<requires>>

Set particular

Clearing Provider

<<extends>>

Offer

<<extends>>

<<requires>>

Transaction

Data

<<requires>>

End

Customer

requires

Clearing

Service

Provider

Identify

Pay Consumption

Charge Service Consumer

for Service Consumption

Consume service

Participant

Contract Data

Figure 3: Use-Case diagram for individual service clearing.

• Authorize access at other participants’ data

• Control data access and check if it is valid

• Avoid multiple data access by multiple SCCOs

• Identify which data is allowed to be accessed

• Notify service consumers about SCCOs data ac-

cess

• Deﬁne process if a service’s SCCO has changed

• Validate how often data is accessed

• Determine processes and tasks to close a clearing

contract

• Avoid that a SCCO outsources his clearing duty

to other SCCOs

• Evaluate the robustness of the interfaces

• Evaluate whether interfaces can be used for cross-

marketplace service clearing

List 4: Challenges according to service clearing.

even more important, no research was found which

identiﬁed what interface functionalities are required

by mobility marketplace participants. Therefore, this

work provides insights into the required steps, tasks

and data for doing so while identifying the need for

individual and outsourced service clearing.

4.3 Service Clearing Interfaces

Table 1 presents the elaborated interfaces required for

outsourced and individual service clearing. These in-

terfaces are used by a SCCO to access clearing rel-

evant data. The clearing functionality has been re-

alized with several light wise interfaces to achieve a

better performance, to reduce maintenance work and

to enable interface re-usability.

It is pointed out that marketplace interfaces should

not, if applicable, serve one particular use case only.

Use case relevant interfaces process and return data

for a particular use case, thus they are probably not

applicable for other use cases. The developed market-

place and its interfaces are use case independent and

role-based driven. Thus participants and there roles

are differentiated and the data returned respectively.

The interfaces in Table 1 are examples of role-based

driven interfaces because they return data according

to the provided certiﬁcate and identiﬁers. The ﬁrst

can only be used, at the moment, by a SCCO while

the remaining two can be used by all registered mar-

ketplace participants for informative reasons. A role

validation is necessary to decide which data has to be

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

Table 1: Interfaces for service-clearing.

Interface Name Description

GetClearingRel -

atedContracts

Returns a list of contracts in

which the requester is set as

SCCO

GetContractData Returns contract details like

participant contact data and

usage price plan

GetTransaction -

Data

Returns transaction data re-

lated to the contract and the

SCCO’s client

delivered to the requester.

Due to the interfaces’ use case independence im-

plementation, they can be used individually or in

combination. Individual usage would be, for exam-

ple, to check transactions or to check when a speciﬁc

contract expires. Combined usage is about using an

interface’s output for another interface’s input. This

is done for service clearing and presented in Figure 4.

At ﬁrst, a SCCO checks his contracts to identify his

clients by using the GetClearingRelatedContracts in-

terface. The contracts deﬁne the services for which

the SCCO is entitled to do service clearing. Once

SCCO knows which services are under his clearing

responsibility, SCCO uses the GetContractData inter-

face to retrieve the contracts which have been signed

between his clients and their business partners. With

those contracts SCCO knows the service consumption

conditions (price plan) and other contact data. The

GetTransactionData interface is used to retrieve all

transaction data related to a speciﬁc service. Once

all data is gathered a SCCO computes the costs of

all retrieved transactions according to the contract and

the speciﬁed price plan. A potential capability might

be that SCCO sends the ﬁnal invoice to his clients’

business partners on behalf of his client. As previ-

ously outlined, a service operator is able to entitle

different clearing operators to do the service clear-

ing for different services but only one SCCO per ser-

vice at the same time. From a SCCO point of view

it is relevant which interface is used ﬁrst. The pre-

sented input and output parameters in Figure 4 are a

summary of the most important parameters. Each in-

terface requires a minimal set of input information.

To avoid the accidentally disclose of data, the inter-

face returns as little information as necessary in ac-

cordance to the requesters role and the role’s scope.

This procedure contributes to the assurance of privacy

and security. The marketplaces’ interfaces are devel-

oped to actively contribute to protocol standardization

for marketplace in the mobility domain and therefore

the protocols parameters are presented. The lessons

learned while develop the presented processes and in-

terfaces can be used for the implementation of addi-

tional interfaces necessary for the use case introduced

in the beginning. This is also a reason why indepen-

dent but role-based driven interfaces are required.

Figure 5 presents a Business Process Diagram

(BPD) which demonstrates the access via the Get-

TransactionData interface with all validations. If the

input parameters pass all validations then the transac-

tion data is returned.

4.4 Interface Implementation

The interfaces have been implemented using inubit, a

Java and XML based Business Process Modeling ap-

plication. The process engine runs on Apache Tom-

cat. The AccountId is the most general identiﬁer and

is used to identify a requester. The ContractId is in-

dispensable to determine a contract and subsequently

retrieve the contract details. The prototypical imple-

mentation of the introduced clearing interfaces has

proven that these two identiﬁers are sufﬁcient to deter-

mine all account, contract and transaction data. Spe-

cial roles like SCCO have separate identiﬁers to avoid

confusion when using the interfaces. The GetClear-

ingRelatedContracts is an interface that speciﬁcally

requires a SCCOID to uniquely identify a clearing

operator rather than a general AccountId. The SC-

COID replaces the AccountId. All interfaces check

whether an AccountId ﬁts to the given ContractId or

not. This is done to determine a requester’s access

scope. For example, using the GetTransactionData

interface with the same ContractId but different Ac-

countIds might returns with i) a different data set or

ii) with a subset of the former return data or iii) with

the very same data. The reason is that the given Ac-

countId is a) set in the contract as business partner

or b) is set as a clearing operator which is allowed to

access this particular data. The interfaces need to be

designed to detect and differentiate all possible sce-

narios and respond accordingly. This is also presented

in Figure 5.

Figure 6 on the next page shows the GetCon-

tractData response. It contains the ContractId and

all contract details. The contract details depict the

business partners. The service operator is shown in

ProviderAddress and the respective service consumer

in ConsumerAddress. The service operator entitled

the SCCO to do the service-clearing on its behalf. The

price conditions are necessary to charge each transac-

tion individually in accordance to the deﬁned usage

price plan. A operator of a service can deﬁne a ba-

sic price for each service transaction. However, it is

also possible that special time slots are deﬁned. The

Individual Service Clearing as a Business Service: A Capable Reference Solution for B2B Mobility Marketplaces

GetTransactionData

Input:

• Account ID

• Clearing Contract ID

• From Date

• Till Date

Output:

• List of transactions

with details

Calculate Costs

(SCCO Backend)

Input:

• Contract Details

• List of transaction with details

Output:

• Invoice for service-consumption

which will be send to service

consumers on behalf of service

operator

GetClearingRelated

Contracts

Input:

• Account ID (SCCO)

Output:

• Contracts where

SCCO does service

clearing

GetContractData

Input:

• Account ID (SCCO)

• Clearing Contract ID

Output:

• Contract Details

Figure 4: Interface sequence for service clearing.

Figure 5: Process to access own or third party transaction

data.

prototypically implementation has shown that prices

of such time slots can differ. During the prototyping

it was detected that the time slots require a validation

as they should not overlap each other. Furthermore

would it be necessary, in case other consumption con-

ditions can exist, that a prioritization mechanism is

in place. The address details are necessary to send

the invoice to the service consumer. Future market-

places have to consider these ﬁndings and implement

them accordingly to satisfy the clearing requirement

pointed out by the literature and the interviewed ex-

perts.

The GetTransactionData response is presented in

Figure 7 on the next page. The response contains de-

tails about a transaction’s status, operation and pro-

cessing time. The time is important because it indi-

cates to which time slot a transaction belongs and how

it has to be charged. A general usage price is charged

if a transaction does not ﬁt into any special time slot.

A transaction can maximal ﬁt into one special time

slot. All prices are taken from the contract to which

a transaction belongs. A transaction is free of charge

if it was not processed successfully. These character-

istics have been identiﬁed during the implementation

and particularly during the testing. Test data was de-

ﬁned and the tests executed without any human in-

teraction. Tests were executed to check whether the

identiﬁed interfaces and their design is valid and ful-

ﬁll the requirements of individual service clearing or

if certain parameters are still undetected. Furthermore

did the tests show what data has to be available and

accessible and what is the data access sequence.

5 CLEARING SERVICE

PROTOTYPE

Visual Rules, a modeling framework for Business

Rules Management (BRM) has been used to develop

a service for service clearing. The service runs as a

web service within a rule execution engine which it-

self runs on Apache Tomcat.

The clearing service uses and evaluates the capa-

bilities and the completeness of the introduced in-

terfaces for service clearing. It accesses automati-

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

C:\Bosch-SI\Promotion\LaTeX\Dokumente\Konferenzen\7thIFIP_InternationalConferenceOnNewTechnologiesMobilityAndSecurity\ServiceCharging\pictures\GetContractDataResp.txt

Sonntag, 14. Juni 2015 09:31

<ServiceName>ClearingService

</ServiceName>

<CreationDate>2015-01-15T11:36.12

</CreationDate>

</Contract>

<...>

</Address>

</ConsumerAddress>

<...>

</Address>

</ProviderAddress>

<IsDeleted>false</IsDeleted>

<startDay>Monday</startDay>

<endDay>Tuesday</endDay>

</TimeSpecification>

</UsageBasedPlan>

</Pricing>

</ContractDetails>

</GetContractDataResp>

-1-

Figure 6: Structure of GetContractData response.

cally internal marketplace data from outside as a third

party. The service clearing process complies to the

sequence presented in Figure 4. The service’s core

consists of an domain independent clearing algorithm.

Domain independent means that this algorithm does

not differentiate or evaluate the content of a provided

contract or transaction. As long as the provided data

passes the interface schema, the algorithm can calcu-

late the total costs for any kind of service transaction

that has been processed via the marketplace. With-

out the access at transaction and contract data, a third

party clearing operator would not be able for doing so

via a marketplace. The algorithm is able to process

any number of special time slots while considering

only transactions which have been processed success-

fully. The developed algorithm is presented below.

Let S be the set of all relevant service consump-

tions:

S =



x | x is service consumption



C:\Bosch-SI\Promotion\LaTeX\Dokumente\Konferenzen\7thIFIP_InternationalConferenceOnNewTechnologiesMobilityAndSecurity\ServiceCharging\pictures\GetTransactionDataListResp.txt

Donnerstag, 11. Juni 2015 14:50

<Operation>STARTCHARGE</Operation>