Sensoria - concurrency and mobility group

Sensoria 

016004 

Software Engineering for Service-Oriented 

Overlay Computers 

Credit Portal Implementation 

Finance Case Study 

Author(s): Jannis Elgner and Michel Alessandrini (S&N) 

Period covered: from August 31, 2007 to August 31, 2008 

Date of preparation: July 10, 2008 

Revision: Draft 

Contract start date: September 1, 2005 Duration: 48 months 

Project coordinator: Martin Wirsing (LMU) 

Partners: LMU, UNITN, ULEICES, UWARSAW, DTU, 

PISA, DSIUF, UNIBO, ISTI, FFCUL, UEDIN, ATX, TILab, 

FAST, BUTE, S&N, LSS-Imperial, LSS-UCL, MIP, ATXT 

Integrated Project funded by the 

European Community under the 

“Information Society Technologies” 

Programme (2002—2006)

Credit Portal Implementation (Draft) July 10, 2008 

Contents 

1 Introduction 3 

2 Global Scenario 3 

3 Runtime-Environment 4 

3.1 jBPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 

3.2 Drools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

4 Application Architecture 5 

4.1 Graphic-oriented Programming (GOP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

4.2 Model-View-Controller Pattern (MVC) . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

5 Processdefinition 7 

5.1 nodetypedefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

5.2 processdefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

5.3 taskdefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

6 Conclusion and Oulook 11 

References 11 

016004 (Sensoria) 2


1 Introduction 

This technical report shows the circumstances of the finance case study from S&N AG. It represents 

the credit request scenario [Koc06, Dos07] implemented with new SOA technologies from JBOSS 1 . 

The report is structured in five main parts. Beginning with the Introduction to give an overview of this 

document. The section 2 Global Scenario describes the background, the process and some details of 

the scenario. The presentation of the runtime demonstrates the chapter 3 Runtime-Environment. The 

application structure of the credit portal builds the base for the part 4 Application Architecture. Finally 

the section 5 Processdefinition explains the details of the process definitions. In the end a conclusion and 

an outlook to perspectives to the credit request scenario is given. 

The finance case study of S&N defines user-interation in a service orientated environment. Only 

by using the specification Business Process Execution Language (BPEL) [OAS06a] the realisation of 

the human-interaction cannot be done. Following not standardized BPEL extensions like BPEL4People 

[AE05] must be used or own solutions must be developed. In the first credit portal version we have 

integrated a self-developed TaskService that realises the user-interaction with the business process implemented 

in BPEL. That specification has some more limitations. Currently it is not possible to use 

WS*-extensions like WS-Security [OAS06b] or WS-ReliableMessaging [OAS04] directly in the BPEL 

implementation. All these facts lead to the conclusion to develop a second version of the credit portal 

with slightly different technologies based on partly alternative specifications. 

We come to the decision to use JBOSS technologies for the next version of the credit portal. That 

technology supports extensible web service-invocations, user-interaction and the integration of defined 

rulesets. The last capability enables the organise workflows by rules. In comparison to BPEL the decision 

handler defines the processdefinition external. That approach is very dynamic and important for changing 

environments and processes. The bridge between the process manager and the application developer 

shows a further advantage because of the permanent synchronous states of the process definition and the 

application workflow. 

2 Global Scenario 

The credit request scenario [Ale07] is a part of a credit portal. In that scenario three roles are defined to 

process the requests: customer, clerk and supervisor. 

A business customer has the desire to buy an office building. In most cases he will request for a credit 

at his bank, in our case by using the credit portal. After starting the credit request process he must insert 

the credit amount and the purpose of that credit. Having entered this data he has to enter his balance 

data and securities. Either the balance data can be uploaded within an XBRL-Uploaddialog 2 [Int03] or 

the key issues can be entered directly. Following the balance data will be validated by a validation web 

service which decides whether the balance data is valid or not. If the balances are validated correctly and 

also the securities, then the credit request is send to the bank. A pre-decision chooses whether the credit 

request can be directly approved, declined or send to an employee for proofing. The decision is based 

on some defined rules which are based on the data typed in by the credit-requester/customer. In case of 

the direct decision, the customer will be informed about the result. In case of a manual decision, a bank 

clerk has to process the customer credit request. Then he decides whether the request will be approved 

or declined. Additionally he is able to inform the customer about the possibility to update his data, 

otherwise the credit request would be rejected. This might be necessary if there are insufficient securites 

available, for example. In case of an approvement, the credit request is forwarded to a supervisor who 

also has to accept the credit request. Only if both employees accept the customer request an offer will be 

made to the customer. 

1 http://www.jboss.org/ 

2 eXtensible Business Reporting Language 



3 Runtime-Environment 

The runtime-environment consists of five different frameworks from the JBoss JEMS 3 [jbo07], namlely: 

JBoss - Application Server, JBoss Business Process Management jBPM , jBPM Process Definition Language 

(jPDL) [jbo06c], Seam [jbo08] and Drools [jbo06a]. These frameworks and their link to each other 

is shown in figure 1. All involved frameworks are running in one instance of the JBoss Applicationserver. 

Figure 1: Runtime-Environment 

The application was realised with JBoss Seam, a powerful open source development platform for 

building rich Internet applications in Java. Seam already integrates some functions from jBPM and 

drools for seamlessly interaction together. As shown in figure 1 the application integrates the jBPM- and 

the Drools-Engine. 

3.1 jBPM 

JBoss jBPM is a Business Process Management System supporting two business process modeling languages. 

In particular BPEL and jPDL a derivation of the specification Process Definition Language 

(XPDL) [WfM07]. The possibility to use BPEL and jPDL in one environment solves the problem which 

3 JBoss Enterprise Middleware System 



occured in a scenario where only BPEL could be used. jPDL focuses on user interaction. The central 

component of jPDL is the workinglist. This approach was invented in the 80ś known as action-orientated 

data handling [Gad08]. He descibes a way how different tasks are delegated to different actors with different 

roles and different rights in different groups. The approach differentiates between a workinglist of 

groups and users. The different tasks (see 5.3) are assigned to one special actor or one group of actors. 

If someone wants to start a task he has to assign the task to himself, if it wasn’t already assigned to him 

directly, see figure 2. 

Figure 2: Workinglist 

With this methodology the system prevents that two different actors are working on the same task. 

Ths workinglist is the central component where all work begins that has to be done by a human actor. 

The implementation of the workinglist and the different tasktypes of this case study are described in 

section 5.3. 

3.2 Drools 

Drools is a Business Rule Management System (BRMS) and an enhanced Rules Engine implementation, 

ReteOO, based on Charles Forgy’s Rete algorithm [wik07] tailored for the Java language. The objectorientated 

rete algorithm filters the incoming data depending on its objecttype which means that only 

rules that are based on the incoming datatypes are fired. With its external BRMS it is possible to extract 

some of the application logic to a repository. In other words it is possible to extract the logic from the 

code which makes it easier to administrate the code. Other possibilities of these rules are complex rule 

flows that depend on the involved objects and their values. Moreover it is possible to calculate complex 

mathamatical operations based on defined rules and much more. In this case study it is used to control 

the workflow based on the values of objects. Moreover it is used to calculate a rating point system. 

4 Application Architecture 

The application architecture in detail contains the global view on it and detailed descriptions of the 

process definition and the underlying Graph Orientated Programming (GOP) principle. 

4.1 Graphic-oriented Programming (GOP) 

The process definition is based on the paradigm of the Graph Orientated Programming [jbo06b]. The 

structure of the graph is represented with the classes Node and Transition. A transition has a direction so 

the nodes have leaving- and arriving transitions, see figure 3. 

All implementations of the node types described in section 5.1 are based on this node class. Moreover 

each process model uses a process execution which looks similar to a finite state maschines or to the 

UML state diagrams. An execution (also known as a token) is represented with a class called Execution 

as shown in figure 4. An execution has a reference to the current node. 



Figure 3: Node and Transition 

Figure 4: Node and Execution 

Every instantiated process creates a new process execution/token that will start in a wait state until 

it gets a signal. With this signal it leaves its current node over a transition to the next node where the 

relevant and implemented methods are executed. Every transition- and node-classes have special events 

like onNodeEnter, onNodeLeaver, onTransitionEnter, . . . that trigger special controller-actions. These 

are implemented in the controller-classes. These actions are classes and methods implemented in java. 

Based on this fact every possible behaviour can be imlemented and invoked from the process definition 

and the jBPM. That is why extended web services can be used like in plain java. Figure 5 shows the 

behaviour of the process definition and its execution(-token). 

Figure 5: GOP Details 

4.2 Model-View-Controller Pattern (MVC) 

The application is based on the MVC-pattern to separate the model, view and controller. The view is 

responsible for all user interactions. The model represents the objects and persistence. One object could 

be i.e. a credit object with different attibutes or a person object to identify the different actors. Figure 6 

shows all involved classes and their relation. 

The workflow has some node types, called decision handler, which decide the way of the workflow. 

In this case study these decision handlers are linked with the rule engine that decides which transition the 

process-execution will take. This decision is based on the defined rules, the involved objects and their 

entered values. 

The controller classes are responsible for the provided actions, which means that they are responsible 

for operations on the data. These actions are triggerd by the jBPM-Engine and are defined by the process 



Figure 6: Credit Portal Class Diagram (extract) 

model. They are annotated with special annotations which express/define whether to start a new process 

instance or to start or end a special task. The data handling is managed by the jBPM-engine which makes 

it possible to have long running conversations for process instances even if the server has shut down since 

the data is persisted after every process-step. This kind of persistence is also useful for later business 

intelligence analysis. All relevant task/process-information is persistent including begin/end-timestamp, 

involved variables, actors and so on. 

5 Processdefinition 

The process definition consists of different nodes controlling the behaviour of the workflow. The different 

node types are described in table 1. It is possible to extend this nodetypedefinition by defining own 

nodetypes. Based on the JBoss jPDL documentation all predefined nodetypes are described in table 1. 

5.1 nodetypedefinition 



Nodetype 

task-node 

state 

decision 

Description 

A task node represents one or more tasks that are to be performed 

by humans. So when execution arrives in a task node, task instances 

will be created in the task lists of the workflow participants. 

After that, the node will behave as a wait state. So when 

the users perform their task, the task completion will trigger the 

resuming of the execution. In other words, that leads to a new 

signal being called on the token. 

A state is a bare-bones wait state. The difference with a task node 

is that no task instances will be created in any task list. This can 

be usefull if the process should wait for an external system. E.g. 

upon entry of the node (via an action on the node-enter event), 

a message could be sent to the external system. After that, the 

process will go into a wait state. When the external system send a 

response message, this can lead to a token.signal(), which triggers 

resuming of the process execution. 

Actually there are 2 ways to model a decision. The distinction between 

the two is based on *who* is making the decision. Should 

the decision made by the process (specified in the process definition). 

Or should an external entity provide the result of the 

decision. 

When the decision is to be taken by the process, a decision node 

should be used. There are basically 2 ways to specify the decision 

criteria. Simplest is by adding condition elements on the transitions. 

Conditions are EL 4 expressions or beanshell scripts that 

return a boolean. 

At runtime the decision node will FIRST loop over its leaving 

transitions THAT HAVE a condition specified. It will evaluate 

those transitions first in the order as specified in the xml. The first 

transition for which the conditions resolves to true will be taken. 

If all transitions with a condition resolve to false, the default transition 

(the first in the XML) is taken. 

Another approach is to use an expression that returns the name 

of the transition to take. With the ’expression’ attribute, you can 

specify an expression on the decision that has to resolve to one of 

the leaving transitions of the decision node. 

Next aproach is the ’handler’ element on the decision, that element 

can be used to specify an implementation of the Decision- 

Handler interface can be specified on the decision node. Then the 

decision is calculated in a java class and the selected leaving transition 

is returned by the decide-method of the DecisionHandler 

implementation. 

When the decision is taken by an external party (meaning: not 

part of the process definition), you should use multiple transitions 

leaving a state or wait state node. Then the leaving transition can 

be provided in the external trigger that resumes execution after 

the wait state is finished. 

Table 1: nodetypedefinition (part 1) 



Nodetype 

fork 

join 

node 

Description 

A fork splits one path of execution into multiple concurrent paths 

of execution. The default fork behaviour is to create a child token 

for each transition that leaves the fork, creating a parent-child 

relation between the token that arrives in the fork. 

The default join assumes that all tokens that arrive in the join are 

children of the same parent. This situation is created when using 

the fork as mentioned above and when all tokens created by a fork 

arrive in the same join. A join will end every token that enters the 

join. Then the join will examine the parent-child relation of the 

token that enters the join. When all sibling tokens have arrived 

in the join, the parent token will be propagated over the (unique!) 

leaving transition. When there are still sibling tokens active, the 

join will behave as a wait state. 

The type node serves the situation where you want to write your 

own code in a node. The nodetype node expects one subelement 

action. The action is executed when the execution arrives in the 

node. The code you write in the actionhandler can do anything 

you want but it is also responsible for propagating the execution. 

This node can be used if you want to use a JavaAPI to implement 

some functional logic that is important for the business analyst. 

By using a node, the node is visible in the graphical representation 

of the process. For comparison, actions –covered next– will allow 

you to add code that is invisible in the graphical representation of 

the process, in case that logic is not important for the business 

analyst. 

Table 2: nodetypedefinition (part 2) 

5.2 processdefinition 

The credit request scenario uses these node types to implement the given workflow and delegate different 

tasks to different actor. The process definition is shown in figure 7. The description of the different task 

and the assigned actors is shown in table 3. 



Figure 7: Credit Request Process 



5.3 taskdefinition 

Tasktypes Desciption Actor 

creditAmount 

the actor is asked to enter his type of customer 

credit and his creditamount 

uploadBalances 

the actor is asked to enter or upload his customer 

balancedata 

uploadSecurities the actor is asked to enter his securitydata 

customer 

updateInformation the actor has to validate the entered clerk 

data and has to accept the futher work 

if he is able to decide the creditrequest. 

Otherwise he has the possibility to reject 

the task to the actorgroup 

createOffer 

the actor is asked to approve, decline clerk 

or decline but update the creditrequest, 

which means that the customer has the 

possibility to update his data and add 

some securities for example to prevent 

the decline of the creditrequest 

superiorDecision the actor has the same task like the createOffer-task. 

supervisor 

The only difference is 

the grouprole of this task. 

changeData 

the actor is asked to choose which data customer 

he wants to change 

changeSecurities same as uploadSecurities except that customer 

the actor has to change his old data and 

not to enter new data 

changeCreditAmount same as creditAmount except that the customer 

actor has to change his old data and not 

to enter new data 

changeBalances 

same as balances except that the actor customer 

has to change his old data and not to 

enter new data 

decideOffer 

actor has to accept or reject the creditoffer 

customer 

Table 3: taskdefinition 

6 Conclusion and Oulook 

The finance case study shows how it is possible to implement user interaction in a SOA environment. 

Further work will be to integrate some of the tools developed in the SENSORIA project. The next step 

is the integration of DINO [DS07a, DS07b] to demonstate the dynamic semantic service discovery. The 

definition of ontologies for service level agreements will be modeled with UML4SOA profile and then 

transformed by the VIATRA-Framework [oTB06] from BUTE. 



References 

[AE05] 

[Ale07] 

[Ale08] 

[Dos07] 

BEA IBM Oracle-SAP AG Active Endpoints, Adobe. Ws-bpel extension for people, August 

2005. http://www.ibm.com/developerworks/webservices/library/ 

specification/ws-bpel4people/. 

Michel Alessandrini. Finance case study scenario descriptions. Technical report, SENSO- 

RIA, Paderborn, April 2007. 

Jannis Elgner; Michel Alessandrini. Finance case study wiki, 2008. http://www.pst. 

ifi.lmu.de:8080/FinanceCaseStudy. 

Michel Alessandrini; Daniel Dost. Requirements modeling and analysis of selected scenarios. 

Deliverable, SENSORIA, Paderborn, Leicester, August 2007. No. D8.3.a. 

[DS07a] Arun Mukhija; David Rosenblum; Andrew Dingwall-Smith. Dino - dynamic and adaptive 

composition of autonomous services, June 2007. http://www.cs.ucl.ac.uk/ 

staff/a.mukhija/dino/. 

[DS07b] 

Arun Mukhija; David Rosenblum; Andrew Dingwall-Smith. Qos-aware service composition 

in dino. In Proceedings of the 5th European Conference on Web Services (ECOWS 2007), 

pages 3–12, Halle, Germany, November 2007. University College London, IEEE. 

[Gad08] Andreas Gadatsch. Grundkurs Geschäftsprozess-Management. vieweg, 2008. 

[Int03] XBRL International. Xbrl specification, version 2.1, December 2003. http://www. 

xbrl.org/SpecRecommendations/. 

[jbo06a] 

jboss.org. Jboss drools, 2006. http://www.jboss.org/drools/. 

[jbo06b] jboss.org. jbpm jpdl user guide, version 3.2, February 2006. http://docs.jboss. 

com/jbpm/v3.2/userguide/html/graphorientedprogramming.html. 

[jbo06c] jboss.org. jbpm process definition language, 2006. http://www.jboss.org/ 

jbossjbpm/jpdl/. 

[jbo07] 

[jbo08] 

jboss.com. Jboss enterprise middleware, 2007. http://www.jboss.com/products/ 

index. 

jboss.org. Jboss seam, 2008. http://www.seamframework.org/. 

[Koc06] Stefania Gnesi; Michel Alessandrini; Corrada Moiso; Nora Koch. Case studies scenario 

description. Deliverable, SENSORIA, Pisa, Paderborn, München, Florenz, August 2006. 

No. D8.0. 

[OAS04] 

Organization for the Advancement of Structured Information Standards OASIS. Oasis web 

services reliable messaging (wsrm) tc, version 1.1, 2004. http://www.oasis-open. 

org/committees/tc_home.php?wg_abbrev=wsrm. 

[OAS06a] Organization for the Advancement of Structured Information Standards OASIS. Web services 

business process execution language (wsbpel) tc, 2006. http://www.oasis-open. 

org/committees/tc_home.php?wg_abbrev=wsbpel. 

[OAS06b] Organization for the Advancement of Structured Information Standards OASIS. Web services 

security (wss) tc, version 1.1, 2006. http://www.oasis-open.org/committees/ 

tc_home.php?wg_abbrev=wss. 



[oTB06] 

[WfM07] 

Budapest University of Technology and Economics (BME). The viatra2 transformation language 

specification, 2006. http://viatra.inf.mit.bme.hu/. 

Workflow Management Coalition WfMC. Process definition language (xpdl), 2007. http: 

//www.wfmc.org/standards/xpdl.htm. 

[wik07] wikipedia.org. Rete algorithm, 2007. http://en.wikipedia.org/wiki/Rete_ 

algorithm/.

Sensoria - concurrency and mobility group

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?