The document discusses requirements for modeling interoperability in service systems using BeerLL as a case study. It introduces service systems concepts and the BeerLL living lab. It evaluates the Web Service Modeling Ontology (WSMO) modeling technique and applies it to model BeerLL's data and process requirements in 3 sentences or less. The document considers WSMO's applicability for modeling service systems and proposes areas for further research.

1. Requirements for interoperability
modelling in service systems based
on BeerLL
VBMO workshop, december 2009
Wout Hofman (TNO), YaoHua Tan (VU, TUD)
Wout Hofman, VMBO workshop

2. Content of the presentation
• Research question
• Service Systems
• general concept
• BeerLL, a Living Lab in ITAIDE
• Modeling requirements
• Web Service Modeling Ontology
• WSMO concepts
• Observations
• Application of WSMO to BeerLL
• data requirements
• process requirements
• Conclusions and further research
2 Wout Hofman, VMBO workshop December 2009

3. Research question
Which modelling techniques can be used for modelling
interoperability in service systems, which gives sub questions:
1. what are service systems and their requirements to modelling
techniques?
2. from e3-value to services
3. what techniques are available?
4. what is their applicability to model service systems?
This contribution is limited to WSMO, Web Service Modelling Ontology.
3 Wout Hofman, VMBO workshop December 2009

4. Service systems have an economic perspective
1. Service: value-based proposition of a provider (Spohrer) with the
objective of value exchange (e3-value)
• customer: initiator of a service
• goal: primary objective for design and operation of services (e.g. transport)
• input/output of services
• collaboration choreography
• service enablers:
• human or subject
• physical resources
• information
2. Value co-creation: a service system comprises service providers and
customers working together to co produce value in complex value
chains or networks (Spohrer et.al.)
3. Dynamic (network) versus static (value chain) setting
4 Wout Hofman, VMBO workshop December 2009

5. ITAIDE – Information Technology for Adoption and
Intelligent Design for e-Government
• Integrated Research Project
• 4.5 year (January 2006 – June 2010)
• EU FP6 IT funding 5.8 Meuro
5 Wout Hofman, VMBO workshop December 2009
Prof. Dr. Yao-Hua Tan

6. Beer Living Lab objective: fraud reduction (value
perspective and identification of services)
DEMO:
transaction
value
exchange
equals
(business)
service?
value port
equals service
access point
(technology
view)? value chain?
6 Wout Hofman, VMBO workshop December 2009

7. e3-value and interoperability modelling
• ‘value port’ • ‘service’
• to show the provision or • value based proposition of provider
requesting of value objects (Spohrer)
• abstraction of internal business • abstraction of internal (business)
processes processes
• services accessed via ‘service access
point’ (‘port type’)
• note: ‘service’ is currently defined in e3-
value as an example of a value object
• ‘(business) transaction’:
• ‘value exchange’: • execution of a service of a provider by a
• connection of two value ports customer
• dynamic: actual connection
• ‘value chain’:
• ‘dependency path’ • a set of collaborating actors executing a
• a set of dependency nodes and business transaction
segments that leads from a start • transaction coordination by each actor
stimulus to an end stimulus in a value chain represented by a
transaction tree
7 Wout Hofman, VMBO workshop December 2009

8. Each value chain can be represented by a transaction
tree, example derived from dependency path.
customer
beer selling
service
control
supermarket
beer selling
service
retailer UK
lling dec
n/se lar
ctio ser ation
odu
r pr service vice
bee
control
Heineken NL customs UK
t de
or cl
nsp ce se arat
rvi ion
tra ervi ce
s
carrier customs NL
control
(sensors)
prod.
unit transport
8 Wout Hofman, VMBO workshop December 2009

9. Interaction sequencing in value chains can be
represented by sequence diagrams
• each value chain has another sequence diagram
• value chains depend on decoupling points (Monhemius et.al.)
Dutch Tax Heineken NL Carrier Heineken UK UK Tax Retailer UK Supermarket
Order
Order
Order
Transport instruction
Declaration Planning
Delivery schedule
Shipment Authorisation Delivery schedule
Excise movement Delivery schedule
Transport report Arrival report
Arrival report (exc. payment)
Approval
Arrival report
Arrival report
Arrival report
9 Wout Hofman, VMBO workshop December 2009

10. BeerLL – data structure modelling limited set of
services (simplified model)
UN/Cefact
Core
Component
10 Wout Hofman, VMBO workshop December 2009

11. Modeling requirements (information perspective)
• Autonomy is the basic requirement (EU: subsidiarity):
• each actor has its specific semantics
• each actor decides on its value chain
• Data requirements
• inclusion/reference to existing data structures (e.g. core components)
• generation of XML Schema from data structure (consistency, completeness)
• per interaction type
• for all interaction types
• process requirements
• support of services that constitute different value chains
• interleaving of services to allow parallel processing of outsourced services
• exceptions
11 Wout Hofman, VMBO workshop December 2009

12. Second question: available techniques. The SOA
paradigm offers this type of flexibility.
Available technology and concepts for services.
• COSMO (mediation)
concepts • WSMO/OWL-S
• Archimate (architectural perspective)
• WSMO
services semantics • OWL-S
• SAWSDL
• BPMn (processes and choreography)
• BPEL for orchestration
technology • Web Service Definition Language
• XML Schema (business documents)
12 Wout Hofman, VMBO workshop December 2009

13. WSMO concepts seem in line with
characteristics of service systems
• information semantics - ontology
• functional semantics:
• goal: customer requirements
• capability: real value of a service
• mediation: matching of goal and capability (type of service discovery)
• behaviour – choreography of interactions offered across an interface
• grounding – relation between conceptual specification (WSML) and
technical solution (WSDL/XML Schema)
13 Wout Hofman, VMBO workshop December 2009

14. WSMO is the application of Abstract State
Machines in the service domain
Goal
mediation
Capability
pre-conditions post-conditions
assumptions effects
transition transition transition transition interface/
choreography/
orchestration –
transition transition transition
implementation
support of a capability
ASM
information semantics
14 Wout Hofman, VMBO workshop December 2009

15. The basic observation relates to ‘abstractness’
of WSMO (ASM)
• Pro: ability to express behaviour of complex systems as a set of
transitions
• Con: difficult to model because of its dynamics:
• WSMO choreography combines choreography and orchestration of services
• a transition of a capability can trigger a goal, thus dynamically composing value
chains in service systems,
• which gives no distinction between ‘internal’ and ‘external’ visible states
• Non-deterministic behaviour:
• no operators between transitions
• inherent feature of ASM
• Basic issue:
• a capability specifies the actual operation on a state space expressed by an
ontology
• a capability requires a choreography and is supported by an orchestration
• choreography and orchestration are also modelled as transitions on the state
space
• choreography could be modelled according as a transaction pattern (Demo)
15 Wout Hofman, VMBO workshop December 2009

16. Application of WSMO to BeerLL - autonomy
goal
Goal Capability
mediation
transition service or process mediation transition
transition transition
transition or choreography standardization transition
transition (collaboration protocols)? transition
transition transition
transition transition
transition
data mediation
or shared ontology
(extended Core Components,
information Common Information Model)? information
semantics semantics
customer provider
16 Wout Hofman, VMBO workshop December 2009

17. Application of WSMO to BeerLL – domain semantics
event
actor roles
resource
types
event
Inclusion of
structures
(core comp.)
resources
17 Wout Hofman, VMBO workshop December 2009

18. An example of a capability of a service implemented by
BeerLL for tracking and tracing containers with sensors
capability LocateContainer
importsOntology “goodsDeclaration"
precondition TRECNumber
definedBy ?packaging memberOf packaging
and ?packaging[TRECNumber hasValue ?TRECNumber].
postcondition PhysicalLocation
definedBy exists ?TRECNumber (?packagingType
[packagingType hasValue ?TRECNumber] )
implies ?location[(packagingType+location)
hasValue ?location]
and ?departureDateAndTime[(packagingType+location)
hasValue ?departureDateAndTime].
18 Wout Hofman, VMBO workshop December 2009

19. Application of WSMO to BeerLL – process
requirements
services for
WSMO web services can be applied
value chains
interleaving of Specifications of transitions consisting of choreography and orchestration,
services which requires choreography mediation
WSMO (ASM) basically specifies a correct system, which needs to include
exceptions
services for handling exceptions from the ‘real world’ (completeness)
WSMO as redesign of existing services or generation of technical services
grounding
(WSDL/XML Schema; shared ontology or interaction types?)
19 Wout Hofman, VMBO workshop December 2009

20. We are currently working on the following model, which
could be related to REA. described by state
has a transaction machines?
equals
protocol choreography?
can be transferred by
is part of Demo transaction
pattern
resource event
capability types
type
has
refers to
is of
value pro- published by
actor
position can be specified
for interoperability
is of initiator in a business
refers to area/sector
WSMO-PA:
WSMO meta business provider
structure for
Public
transaction business activity?
Administration is transferred by
belongs to
is of
resource event
equals business
service?
20 Wout Hofman, VMBO workshop December 2009

21. Conclusions and further research
• Conclusions:
• ontology for domain semantics offers better inclusion of other structures than
other methods like UML object diagrams
• formal methods force correctness of specifications (completeness is difficult
to enforce good design)
• abstract specification graphical support
• Further research/discussion:
• How to get from e3-value to services? REA and interoperability model?
• Role of shared ontology for business interoperability
• Support of mediation
• Non-determinism and other formalisms:
• collaboration protocols with a requirement for operators (see for instance workflow patterns)
• ‘time’ as discriminating factor between two transitions
• timed, coloured Petrinets are an alternative (graphical support, operators, patterns, time, formal
model)
• COSMO: a model for collaboration
• finite state machines?
21 Wout Hofman, VMBO workshop December 2009