When the collaborating systems differ in their message exchange behaviors, mediation is necessary.
This page collects some collaboration scenarios with behavior mismatches. These scenarios are used as test cases of the proposed method. The sources of scenarios include:
- Service interaction patterns (SIPs)
- Complex scenarios that I designed
- Real cases and variations
- Other literatures
Currently there are 22 test cases. These cases are tested using the method, and the results have been validated by integration experts. These test results show that the method is effective in designing routing solutions to resolve behavior mismatches.
The scenarios are growing, updated occasionally.
##Service Interaction Patterns (SIPs) Variations
SIPs represent a commonly recognised catalogue of typical behaviours of systems in process collaboration, and are regarded as well-established knowledge of choreography scenarios. By altering behaviours of participants in each pattern, a set of commonly encountered behaviour mismatch scenarios was derived. These scenarios with behaviour mismatches were modelled as BPMN coordinated choreographies.
###Single-send/receive pattern
Variation 1
Solution:
[Channel: channel [from=connector-DefaultOperation: send, to=auto-agg-loopsender]
, Channel: channel [from=auto-agg-loopsender, to=connector-DefaultOperation: receive]
]
Variation 2
Solution:
[Channel: channel [from=connector-DefaultOperation: send, to=auto-splitter]
, Channel: channel [from=auto-splitter, to=connector-DefaultOperation: receive]
]
Variation-3
one send task is connected to two sequenced tasks. Should use RoutingSlip.
Output
[channels=
[Channel: channel [from=connector-DefaultOperation: send, to=auto-routingslip]
, Channel: channel [from=auto-routingslip, to=connector-DefaultOperation: receive1]
, Channel: channel [from=auto-routingslip, to=connector-DefaultOperation: receive2]
]
Which means
Flow 1: source-connecotr -> routing-slip(target1, target2) -> two target-connectors
###Send-receive pattern
Output : directly connect the operations
[Channel: channel [from=connector-DefaultOperation: send request, to=connector-DefaultOperation: receive request in server]
, Channel: channel [from=connector-DefaultOperation: response from server, to=connector-DefaultOperation: Receive response]
]
Variation 1
client exchange messages with server. One loop-sender pattern, one loop-receiver pattern.
Output
[Channel: channel [from=connector-DefaultOperation: client request, to=auto-agg-loopsender]
, Channel: channel [from=auto-agg-loopsender, to=connector-DefaultOperation: server receive]
, Channel: channel [from=connector-DefaultOperation: server response, to=auto-splitter]
, Channel: channel [from=auto-splitter, to=connector-DefaultOperation: client receive]
]
Which means:
Flow 1: Client-request-connector -> aggregator -> Server-resequest-connector.
Flow 2: Server-response-connector -> splitter -> Client-response-connector.
Variation 2
Solution
[Channel: channel [from=connector-DefaultOperation: send request, to=auto-splitter]
, Channel: channel [from=auto-splitter, to=connector-DefaultOperation: receive request in server]
, Channel: channel [from=connector-DefaultOperation: response from server, to=auto-agg-loopsender]
, Channel: channel [from=auto-agg-loopsender, to=connector-DefaultOperation: Receive response]
]
###Racing-Incoming-Messages
Variation-1
one send task is connected to exclusive receive tasks. Should use CBR.
Output
Solution [channels=
[Channel: channel [from=connector-DefaultOperation: send, to=auto-CBR]
, Channel: channel [from=auto-CBR, to=connector-DefaultOperation: receive1]
, Channel: channel [from=auto-CBR, to=connector-DefaultOperation: receive2]
]
Which means:
Flow 1: inbound-endpoint-connector -> CBR -> two outbound-endpoint-connector.
Variation-2
Solution: filter+aggregator.
[Channel: channel [from=connector-DefaultOperation: send1, to=auto-filter]
, Channel: channel [from=auto-filter, to=auto-agg-multisender]
, Channel: channel [from=auto-agg-multisender, to=connector-DefaultOperation: receive]
, Channel: channel [from=connector-DefaultOperation: send2, to=auto-filter]
]
###One-to-many Send
Variation-1
Output
[Channel: channel [from=connector-DefaultOperation: send1, to=auto-recipientlist]
, Channel: channel [from=auto-recipientlist, to=connector-DefaultOperation: receive1]
, Channel: channel [from=auto-recipientlist, to=connector-DefaultOperation: receive in P3]
]
Variation-2
Solution
[Channel: channel [from=connector-DefaultOperation: send1, to=auto-recipientlist]
, Channel: channel [from=auto-recipientlist, to=auto-routingslip]
, Channel: channel [from=auto-routingslip, to=connector-DefaultOperation: receive1]
, Channel: channel [from=connector-DefaultOperation: send1, to=auto-routingslip]
, Channel: channel [from=auto-routingslip, to=connector-DefaultOperation: receive2]
, Channel: channel [from=auto-recipientlist, to=connector-DefaultOperation: receive in P3]
]
Which means
###One-from-many Receive
Variation-1
Solution: filter + aggregator.
Variation-2
Solution:
[Channel: channel [from=connector-DefaultOperation: send1, to=auto-resequencer]
, Channel: channel [from=auto-resequencer, to=connector-DefaultOperation: receive 2 in p2]
, Channel: channel [from=connector-DefaultOperation: send2, to=auto-resequencer]
, Channel: channel [from=auto-resequencer, to=connector-DefaultOperation: receive 1 in p2]
]
Variation-3
Output
[Channel: channel [from=connector-DefaultOperation: send1, to=auto-filter]
, Channel: channel [from=auto-filter, to=auto-agg-multisender]
, Channel: channel [from=auto-agg-multisender, to=connector-DefaultOperation: receive in P3]
, Channel: channel [from=connector-DefaultOperation: send2, to=auto-filter]
, Channel: channel [from=connector-DefaultOperation: send 1 in p2, to=auto-filter]
]
whici means
###One-to-many Send-Receive
Variation-1
Solution
[Channel: channel [from=connector-DefaultOperation: client send, to=auto-recipientlist]
, Channel: channel [from=auto-recipientlist, to=connector-DefaultOperation: server1 receuve]
, Channel: channel [from=auto-recipientlist, to=connector-DefaultOperation: server2 receive]
, Channel: channel [from=connector-DefaultOperation: server1 send, to=auto-filter]
, Channel: channel [from=auto-filter, to=auto-agg-multisender]
, Channel: channel [from=auto-agg-multisender, to=connector-DefaultOperation: client receive]
, Channel: channel [from=connector-DefaultOperation: server2 send, to=auto-filter]
]
###Multiple Responses
Variation-1
Variation-2
###Contingent Requests
Variation-1
Same as variation of One-To-Many Send-Receive
###Request with Referral
Variation-1
Same as variation of One-To-Many Send-Receive
##Sell-constructed Complex Scenarios
Composition of basic patterns.
process1 has two send tasks. They are tangled with two receive tasks in process 2, while one is also connected to process 3.
order-mismatch, multiple-receivers, and multiple-senders
Output
[Channel: channel [from=connector-Send1, to=auto-recipientlist]
, Channel: channel [from=auto-recipientlist, to=auto-filter]
, Channel: channel [from=auto-filter, to=auto-agg-multisender]
, Channel: channel [from=auto-agg-multisender, to=connector-Receive21]
, Channel: channel [from=auto-recipientlist, to=connector-receiveE3]
, Channel: channel [from=connector-Send2, to=auto-routingslip]
, Channel: channel [from=auto-routingslip, to=auto-filter]
, Channel: channel [from=auto-routingslip, to=connector-Receive22]
]
Which means:
Flow 1 and Flow 2 are intermingled:
send1-connector -> recipient-list -> p3-connector
|-> filter -> aggregator -> p2-receive-connector
send2-connector -> routing-slip -|
|-> receive2-connector
process1 has 3 send tasks. They are tangled with two receive tasks in process 2, while one is also connected to process 3.
Solution
order-mismatch, multiple-receivers, and multiple-senders
##Real cases and variations
These scenarios are derived from a real case in hospital integration.
CIS and RIS. CIS use two seperate tasks to receive response (accept vs. reject). RIS uses two sequenced tasks to receive order info, and two sequenced tasks to send report parts.
exclusive-receivers, multiple-senders, and sequenced-receivers.
Output
Solution [channels=``
[Channel: channel [from=connector-Send Order Operation, to=auto-routingslip]
, Channel: channel [from=auto-routingslip, to=connector-Receive Order]
, Channel: channel [from=auto-routingslip, to=auto-splitter]
, Channel: channel [from=auto-splitter, to=connector-Receive Order Item]
, Channel: channel [from=connector-Send Response, to=auto-CBR]
, Channel: channel [from=auto-CBR, to=connector-Receive Reject Operation]
, Channel: channel [from=auto-CBR, to=connector-Receive Accept Operation]
, Channel: channel [from=connector-Send Preliminary Report, to=auto-filter]
, Channel: channel [from=auto-filter, to=auto-agg-multisender]
, Channel: channel [from=auto-agg-multisender, to=connector-Receive Report Operation]
, Channel: channel [from=connector-Send Supplement Report, to=auto-filter]
]
Which means
CIS and RIS. variation is CIS now has the receive task for study completion. The order of completion and report is different in CIS and RIS. This needs resequencer.
##Scenarios from Literatures
###Scenario 1
from Xitong Li, Yushun Fan, Stuart Madnick, Quan Z. Sheng. A pattern-based approach to protocol mediation for web services composition. Information and Software Technology, 2010, 52(3): 304-323.
Solution
[Channel: channel [from=connector-DefaultOperation: SendLogin, to=auto-filter]
, Channel: channel [from=auto-filter, to=auto-agg-multisender]
, Channel: channel [from=auto-agg-multisender, to=connector-DefaultOperation: Receive Login and Request]
, Channel: channel [from=connector-DefaultOperation: SendRequest, to=auto-filter]
, Channel: channel [from=connector-DefaultOperation: Send Partial Result, to=auto-agg-loopsender]
, Channel: channel [from=auto-agg-loopsender, to=auto-filter]
, Channel: channel [from=auto-filter, to=auto-agg-multisender]
, Channel: channel [from=auto-agg-multisender, to=connector-DefaultOperation: ReceiveResult]
, Channel: channel [from=connector-DefaultOperation: Send Finish, to=auto-filter]
]
###WS-I SCM scenario
###HL7v3 Scenario
from WajahatAli Khan, Maqbool Hussain, Khalid Latif, Muhammad Afzal, Farooq Ahmad, Sungyoung Lee. Process interoperability in healthcare systems with dynamic semantic web services. Computing, 2013, 95(9): 837-862.
