Gerhard Kramler

1
Towards Using UML2 for Modelling Web Service
Collaboration Protocols
Gerhard Kramler Gerti Kappel kramlergerti_at_big.t
uwien.ac.at Business Informatics Group
Institute for Software Technology and Interactive
Systems Vienna University of Technology Favoritens
traße 9-11/188-4 . 1040 Vienna .
Austria/Europe Tel. [phone] - 18829, Fax
43 (1) 58801 - 18896 http//www.big.tuwien.ac.at
Joint work with Elisabeth Kapsammer and Werner
Retschitzegger University of Linz kapsammerwerne
r_at_ifs.uni-linz.ac.at
2
Motivation Idea

• Internet and XML facilitate B2B automation
• Two aspects internal integration (workflow) and
  external integration (collaboration protocols)
• XML-based technologies
• XML, XML Schema
• Web Services (WSDL, BPEL, etc.), ebXML
• Problems with the technology-focused approach
• Lack of understandability and usability for
  business experts
• Only low-level integration with common software
  development processes and tools (OOPL, RDBMS,
  etc.)
• The model driven approach as potential solution
• Language concepts of the solution domain are more
  closely related to the problem domain
• UML as domain specific language for B2B protocols
• Web Services, ebXML as target technologies

3
Motivation Idea

• Only few existing work on graphical modelling of
  collaboration protocols
• Kim (SIGMOD Record 31, 2002)
• Use of UML 1.x activity diagrams, interaction
  diagrams, class diagrams to model ebXML BPSS
  collaboration protocols
• Limited to BPSS expressiveness
• UMM (UN/CEFACT Modelling Methodology)
• Adapted RUP for developing standard B2B protocols
• Supports all development phases, strong in
  requirements and analysis, supports a superset of
  BPSS concepts
• Missing mapping to Web Services (big gap)
  limited to B2B domain
• Our approach
• A platform-independent model (PIM) based on
  ebXML and BPEL concepts but abstract from
  specifics
• Based on UML 2 concepts, refined and extended to
  suit the specific needs
• Supports different levels of abstraction

4
Overview of Modelling ConceptsLevels of
Abstraction
Collaboration Model (interaction
partners, interconnections, top-level
transactions)
Collaboration Level
refines / uses
Object Model (transaction objects, object states)
Activity Model (transactions, pre- and
post-conditions, process)
uses
Transaction Level
refines / uses
Message Content Model (message data structures)
Interaction Model (message exchanges)
Interaction Level
uses
5
Interaction Level

• Focus on message exchanges between participants
• defines a single transaction (transactional
  characteristics not considered)
• Interaction Model
• defines communication behavior of participants
• based on UML2 sequence diagram
• limited to loose coupling (no synchronous
  messages, only mutually observable constraints)
• extended with key constraints, participation
  constraints
• Message Content Model
• defines data structure of messages
• based on UML class diagram
• restricted to classes or interfaces with query
  operations

6
Example Interaction ModelUML2 Sequence Diagram
sd CreateOrder
key orderId
Buyer
Seller
q.orderId qReceipt.orderId q.orderId
qAcceptance.orderId q.orderId
r.orderId q.orderId rReceipt.orderId
request(qOrderRequest)
0..2
signal(qReceiptSignalMessage)
opt
qReceipt.isPositive
0..4
signal(qAcceptanceSignalMessage)
0..24
not r.isPositive implies not rRreceipt.isPositive

opt
qAcceptance.isPositive
response(rOrderResponse)
0..2
signal(rReceiptSignalMessage)
7
Example Message Content ModelUML Class Diagram
cd OrderMessages
interface SignalMessage
interface ActionMessage
isPositive
interface OrderRequest
interface OrderResponse
orderId value
orderId isPositive
1
item
interface ReqOrderItem
8
Transaction Level

• Focus on transactions between participants
• defines a shared process including shared state
• transactional characteristics of processes and
  actions
• actions either defined by sub-processes, or by
  interactions
• Activity Model
• defines a shared process among participants (like
  BPSS)
• based on UML2 activity diagram
• limited to actions and object nodes associated to
  multiple participants (shared transactions and
  state), and control flow and data flow realizable
  without central control (shared control flow)
• extended with key constraints, object joins
• Object Model
• defines shared state
• based on UML class diagram and state diagram
• restricted to interfaces and protocol state
  machines, resp.

9
Example Activity ModelUML2 Activity Diagram
ShipToOrder
(Buyer, Seller) Order
key orderId
(Buyer, Seller) ShipGoods
in accepted
valuelt10.000
(Buyer, Seller)Order accepted
(Buyer, Seller)Order
(Buyer, Seller) CreateOrder
else
(Buyer, Seller) Ordercanceled
(Buyer, Seller) CancelOrder
10
Example Object ModelUML Class Diagram and State
Diagram
cd ShipToOrder
sm Order protocol
create
denied
interface Order
orderId value
accepted
canceled
cancel
ship
1
shipDenied
item
interface OrderItem
shipped
11
Relationship between Levels

• An action in the activity model (transaction) is
  defined either by a sub-activity, or by an
  interaction
• The interaction model must support the
  transaction parameters (in, out, inout)
• Data flow constraints and post-condition
  interrelate parameters (i.e., participant shared
  state) with message contents
• State of output parameters must be completely
  defined by the post-condition, and observable by
  all of the participants that the parameter is
  assigned to

12
Completed Ex. Interaction ModelParameters link
to Object Model and Activity Model
sd CreateOrder(out oOrder)
postcondition
o in accepted or o in denied rReceipt.isPositive
implies o in accepted not rReceipt.isPositive
implies o in denied o.value q.value o.orderId
q.orderId
key orderId
Buyer
Seller
q.orderId qReceipt.orderId q.orderId
qAcceptance.orderId q.orderId
r.orderId q.orderId rReceipt.orderId
request(qOrderRequest)
0..2
signal(qReceiptSignalMessage)
opt
qReceipt.isPositive
0..4
signal(qAcceptanceSignalMessage)
0..24
not r.isPositive implies not rRreceipt.isPositive

opt
qAcceptance.isPositive
response(rOrderResponse)
0..2
signal(rReceiptSignalMessage)
13
Collaboration Level

• Focus on top-level transactions and communication
  connections between participants
• defines an overview of permissible transactions
  (e.g., to define a contract)
• Collaboration Model
• defines a re-usable collaboration between
  participants
• based on UML2 collaboration diagram
• extended with transaction semantics each
  collaboration defines a transaction which is
  refined either by an activity model or an
  interaction model

14
Example Collaboration ModelUML2 Collaboration
Diagram
ShipToOrder
Buyer
Seller
SimpleSCM
ObtainCatalog
Client
Supplier
Supplier
Client
Buyer
Seller
ShipToOrder
15
Mapping to ebXML and BPEL

• Mapping to ebXML BPSS is straight forward
• e.g., activity model ? binary collaboration
  protocol, interaction model ? business
  transaction
• Not all concepts can be mapped, e.g., no
  transaction pre- and post-conditions
• BPSS imposes limitations, e.g., very restricted
  multi-party collaborations, only predefined
  interaction patterns
• Mapping to BPEL creates a protocol implementation
• e.g., participant ? abstract process or nested
  scope,message ? invokereceive, key constraint
  ? correlation
• A BPEL process is a collaboration protocol
  implementation, e.g., constraints have to be
  mapped to constraint violation detectors and
  corresponding exception handling
• BPEL imposes few limitations, e.g., on key
  constraints

16
Conclusion and Outlook

• A modelling technique for transactional
  collaboration protocols
• Generalizes BPSS concepts, uses UML2
  expressiveness
• Not specifically B2B, ebXML, or Web Services
  (?PIM)
• An example of UML as domain specific language
• Pro concepts already known, can be re-used,
  integrated
• Con confusion about multiple pragmatics
  limitations
• Lots of open issues
• Specification of failures and failure handling
  (interaction level and transaction level
  consider partial failure)
• Specification of non-functional properties (e.g.,
  security)
• Complete mapping to target technologies
• Relationship to web service interfaces and
  deployments