Vbmo2009 Presentation
0 likes344 views
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.
![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](https://image.slidesharecdn.com/vbmo2009presentation-12615713185879-phpapp01/85/Vbmo2009-Presentation-18-320.jpg)
Vbmo2009 Presentation
- 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