In (An efficient necessary condition for compatibility, 2009) the authors discuss a method to find out, if two services are compatible or not. This obviously presupposes that the behavior of the services is modeled. One method to do this is to use BPMN 2.0 and model two or more participants offering respective public processes.

Compatibility of the services is not so obvious in the first place. The question to be answered is, if for all possible sent messages the other participant (or service) is ready to process it, and if both can complete their control flow in all cases. For example if one participants sends an order cancellation, but the other participant cannot process it, because the order is already delivered, and it has no control flow to deal with the late cancellation, then the services are not compatible.

Typically this can be checked by comparing all possible states of all participants and all messages. However this brute force method consumes much memory and computing time. Probably this is one reason, why it is not yet offered in so many or even a modeling product at all – which I do not exactly know. The proposed method in (An efficient necessary condition for compatibility, 2009) is to use a method known from petri nets: to convert them into matrices (state equation) and use the matrices to determine the compatibility in a much more efficient way. This is definitely interesting to consider.

The paper states, that this can be used for service discovery and mediator construction. In my personal opinion these use cases are very advanced research use cases, which are not yet so relevant in the practical industry application. Even the mediator construction I have severe doubts, if this is a way that will lead to somewhere at all. But I might be convinced later.

But very relevant is to support the design process of services which need to interact. If there were a repository, that would contain such compatibility determination method – that would be a great step forward. Furthermore it would provide the industry use cases that are needed for further research on the matter.

References

An efficient necessary condition for compatibility. Oanea, Olivia und Wolf, Karsten. 2009. [Hrsg.] Oliver Kopp und Niels Lohmann. Stuttgart : Universität Stuttgart, Fakultät Informatik, Elektrotechnik und Informationstechnik, 2009. Services und ihre Komposition, Erster zentraleuropäischer Workshop, ZEUS 2009. Bd. CEUR Workshop Proceedings Vol. 438, S. 81-87. http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-438/paper13.pdf.

If process parts are loosely coupled, then it is possible to discern between a Public Process and a Private Process. A Public Process contains all process parts and dependencies of the process of a Participant, that are relevant for the interaction to the other Participant. For example in a buyer – seller relationship it is not relevant if the seller has an internal approval process of of what form it is. It is only relevant if the order request is to be confirmed or not and in which time.

Therefore designing public processes gives flexibility within Participants to change processes as necessary – often without or with reduced side effects to the interation to the other Participant. This reduces cost in Process adaptations.

This is a first Choreograpy model. It consists of two Choreography Tasks.

The first Choreography Task is  Request Booking as an interaction between two participants – the Runway Show Management and the Venue Provider. We know from the coloring that the Runway Show Management is the initiator of this interaction. We also know, that at least one message must be exchanged between the participants in the course of the interaction, maybe more.

The second Choreography Task is Confirm Booking. Here the same participants are interacting as before. So we see, that the participants are part of the Choreography model and can be referenced by different Choreography Tasks. However in the second Choreography Task the Venue provider is the initiator of the interation.

We know from the sequence flows between the Choreography Tasks, that the Confirm Booking Task follows after the Request Booking Task.