Requirements for interoperability
modelling in service systems based
on BeerLL
VBMO workshop, december 2009

Wout Hofman (...
Content of the presentation

    • Research question

    • Service Systems
         • general concept
         • BeerLL, ...
Research question

    Which modelling techniques can be used for modelling
    interoperability in service systems, which...
Service systems have an economic perspective

    1. Service: value-based proposition of a provider (Spohrer) with the
   ...
ITAIDE – Information Technology for Adoption and
    Intelligent Design for e-Government

    • Integrated Research Projec...
Beer Living Lab objective: fraud reduction (value
    perspective and identification of services)




  DEMO:
transaction
...
e3-value and interoperability modelling

    • ‘value port’                           • ‘service’
        • to show the pr...
Each value chain can be represented by a transaction
       tree, example derived from dependency path.
                  ...
Interaction sequencing in value chains can be
    represented by sequence diagrams
    • each value chain has another sequ...
BeerLL – data structure modelling limited set of
        services (simplified model)




     UN/Cefact
       Core
     C...
Modeling requirements (information perspective)

     • Autonomy is the basic requirement (EU: subsidiarity):
          • ...
Second question: available techniques. The SOA
     paradigm offers this type of flexibility.
     Available technology an...
WSMO concepts seem in line with
     characteristics of service systems
     • information semantics - ontology
     • fun...
WSMO is the application of Abstract State
      Machines in the service domain
                                           ...
The basic observation relates to ‘abstractness’
     of WSMO (ASM)
     • Pro: ability to express behaviour of complex sys...
Application of WSMO to BeerLL - autonomy

                                            goal
                               ...
Application of WSMO to BeerLL – domain semantics

                                                 event
     actor roles
...
An example of a capability of a service implemented by
     BeerLL for tracking and tracing containers with sensors

     ...
Application of WSMO to BeerLL – process
        requirements


     services for
                                         ...
We are currently working on the following model, which
      could be related to REA.                            described...
Conclusions and further research

     • Conclusions:
          • ontology for domain semantics offers better inclusion of...
Upcoming SlideShare
Loading in …5
×

Vbmo2009 Presentation

410 views

Published on

Presentation on WSMO for a workshop on auditing and value modelling.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
410
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Vbmo2009 Presentation

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 10. BeerLL – data structure modelling limited set of services (simplified model) UN/Cefact Core Component 10 Wout Hofman, VMBO workshop December 2009
  11. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×