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.

Models must have a meaning within a context in the end, otherwise they are useless. For example what does a model mean, where there are acitivies like “go to the shop” and “buy some milk” and “pay”? It is a modeled description of what a person sometimes does, if he needs milk. But nothing else. The process model is to be used as documentation only. This is the context of the model. Such a model can not be used as a workflow. There is no need to create a workitem “pay” for buying milk. This is done by the shop’s design anyway. Also it can not be a web service orchestration description, because there is no web service “go to the shop”.

Modeling a process makes sense, if the context is know, in which the process will be embedded. The context is what I call an architecture. An architecture is a set of rules that determine under which boundary conditions a software system is to be designed. As part of such a design the design of a process makes sense. For example the architecture could be to design a system that is capable of performing the functionality of a milk web shop, that milk order and milk delivery are business objects that expose web services like “order” and “pay”, that there will be a workflow system that is able to compose these services – for example. The architecture are the rules that describe the creation of the system, the business objects, the web services and the workflow. These first need to be professionally defined and confirmed. They need to be obligatory for the whole project.

Only after that it makes sense to create models, which then will have a meaning within the context of the defined architecture. And therefore it is of very limited merit to “just model” or to train or coach modeling of a modeling language without a reference to a defined architecture or without the preceding process of professionally defining the reference architecture before. On the contrary – if the architecture is defined, then it perfectly makes sense to coach and govern a modeling process, because then there are the rules, that are needed for coaching and governance.

This is my opinion.

Why is it, that the structural aspects of software enjoys universality of modeling (UML) while the behavioral aspect does not (yet) and what can and should be done about it?

The same is – obviously – true for Web Service Descriptions. You will get a WSDL description which describes the syntactical aspect of the services, but the behavioral aspect is left undescribed.

The invited speaker was Prof. Gregor Engels, University of Paderborn about “Automatic generation of behavioral code – too ambitious or even unwanted?”

I am – as always – only giving my personal opinion here. I agree to the goal of behaviorable modelling. It was proposed, that preconditions and postconditions of operations should be used to do this. The advantage of the approach has been proposed to be able to become more specific step by step or level by level.

I mainly agree to the statement and I think it is pointing in the right direction. My personal opinion is, that preconditions alone are not enough, as long as they can contain every expression, because then they can not be linked with each other. Postconditions are in my opinion important, but they do not describe, how the state is changed by an operation. This is a difference to the ASM (Abstract State Machine) Approach, that was presented later and that I will discuss in another post.

Furthermore I think that code generation is the wrong way. The reason is, that code is too static to be extended later. A runtime model interpreter helps to avoid many problems, including extensibility and the deviations of models from the implemented reality. Furthermore in my personal opinion graph transformations should be avoided.

So this is my personal opinion about the first talk, which I think pointed into the right direction in general.

In my personal opinion the use of preconditions is a good thing in general. However in my opinion the splitting up of the whole behavior into different scenarios has also disadvantages. For example that it is not so clear, if one scenario is changed, which side effects this has on other scenarios. Also one transition for example can occur in different scenarios. Thereby probably many scenarios need to be changed, if the behavior of one transition needs to be changed. Also a problem is, that it is not so clear how to model differen alternative behaviors. If the union set of all scenarios describes the behavior of the service, it is all one. So for example if there is one big service, but the behavior can be different – for example in one case with confirmation, in another without confirmation – this is not possible to be modeled. It is just a “confirmation” scenario in the set, but it is not modeled, that is sometimes must be used, sometimes not.

Good is that in the end of the paper it is proposed to integrate the scenarios into one view. This I agree upon. My personal opinion is, that I would rather start with the integrated view. Because all the mentioned disadvantages are not there in this case.

But I admit, that the use case proposed in the paper may still be valid in a consulting experince, where the client already has described the behavior of his services in the form of scenarios. Then, the method proposed is a good way to unify them into the desired integrated view. This may also be supported by tools, which gives an additional value add.

Also notbody should be distracted by the notion of the modeling language. This is just the underlying logic. The same method can as well be transferred to industrial languages, as is proposed in the paper and as I believe. For example I see no reason why this should not be useable in a BPMN 2.0 orchestration model environment.

So the paper proposes, that for the purposes of service validation, (automatic) service construction, service composition and service replacement there is not yet a represenations, that allows for a closed theory – i.e. a structured solution in all cases. Actually it is an opening paper that will be later completed by describing “operating guidelines”, which are intended to fulfil this purpose.

My personal opinion is, that is it a good endeavor. Such work is needed to complete the foundation for modeling tools, that allow for more comfortable modeling consistency checks and functionality.
I especially see much benefits in consistency checking. I also have one or two patents in this area. Important in my view in consistency is a clear definition of the goal of the check and a good method to explain consistency errors to the tool user. Consistency checking is in most cases useful. One needs a little bit of patience, to make a service definition fit to another, because there is always this one unwanted execution that needs to be eliminated. But it is worth the effort, because it is better to eliminate these errors in modeling time than in runtime.

Service construction is in my personal opinion difficult. In my view there are always abiguities in such an endeavor. So I prefer “human” design plus consistency check.
Service composition promises some benefit – especially if there is a skeleton composed, which can be further edited by the human designer. Also here it is important to formulate clear goals of the service composition and to have a complete – i.e. without gaps – description of the underlying services. Especially if there is a Business Process Platform that offers services, that need to be composed, and that is model driven, this is very promising. There are also other projects working on this. I may come back to this some other time.
Service Replacement is certainly an interesting application. If a service is changed, then it is certainly worthwhile to know potentially which consuming services might be affected and which not. This may be the outcome of this part of the research.

So good work – keep it going!

My answer would be, that the Pi Calculus is a Low Level desription calculus for processes that communicate with each other, messages and message channels. This serves the simulation and analysis. The choreography model and the collaboration model are more like a notation with metamodel covering the processes and the messages, but not the message channels. It is more for modeling than for analysis, although the model can be input to the analysis and the simulation.
Also every BPMN choreography model or collaboration model can be mapped to a Pi Calculus description, but not vice versa. Pi calculus is more general and has no notation. BPMN is guiding the modeling process and therefore easier to understand.

When one want to use the BPMN choreography model or collaboration model as input to a pi calculus conversion or a simulation and analysis, the quality of service contract needs to be specified before.

http://www.bpmnforum.net/blog/bpmn/bpmn-in-research/quality-of-service-contracts/
[ad]

“By the year 2012, BPM will be subsumed into major applications.” Simon Hayward

See also:
http://www.ebizq.net/blogs/bpmblog/2007/03/the_death_of_bpm_it_aint_over.php
An interesting statement. Especially in the light of the remarks about “What is a Process?” that I made earlier:
http://www.bpmnforum.net/blog/bpmn/bpmn-in-research/what-is-a-business-process/
I suggested, that there are commonalities between Process Objects (Workflows) and Business Objects (like a Sales Order). They have a state, they have actions or activities, they have constraints. There are differences, but as long as we focus on the commonalities, we can think of utilizing this common ground for common frameworks.
Applications are made up of business objects and their relations. Very often these business objects are programmed. In contrast workflows are modeled. So if we can achieve modeling business objects in an application, then the business object model is the foundation for better integration of BPM functionality with the application. I call such a modeled application Business Process Platform or BPP.
To not remain too abstract, I make a concrete example.
Think of a Project Management Application, that has a Business Object “Project”. Now, a Project BO is created. Before the Project is released, there must be an approval. So – when does this Approval start? It needs to start, if the Project business object has reached a certain state – for example “Data Entry finished”. Only then a workflow or task needs ot be started. The workflow or task is what we traditionally understand as being part of BPM and what we model by BPMN for example. But if the state “Data Entry Finished” of the Business Object “Project” is also modeled, then the foundation has been created to use it in a generic framework, that enables BPM – for example by providing events to the workflow to start.
Furthermore if the Approval is finished, a subsequent step (action, activity) must be performed with the Project business object: Release, changing the state to Released.
That is a very simple example, but often difficult to achieve if not these preconditions are met:

1. The state of the business object is modeled.
2. The action of the business object is modeled.
3. The action is provided as web service
4. There is a generic framework utilizing it to make the integration of the workflow and the business object happen.

This can only be achieved, if an application is designed from the beginning to provide such modeling information. This had not been completely done in the past. But there is no reason why this should not work. However if an application fulfils 1-4 it should be called a Business Process Platform or BPP.

So with the upcoming advent of BPP, the Applications will be BPM enabled.

[ad]

Bibliography

1. Beugnard, Antoine, et al. Making Components Contract Aware. Computer. 1999, Vol. 32, 7, pp. 38 – 45. http://portal.acm.org/citation.cfm?id=621275.
2. Lecture Notes in Computer Science: Non-desynchronizable Service Choreographies. Decker, Gero and Alistair Barros, Frank Michael Kraft and Niels Lohmann. Berlin / Heidelberg : Springer, 2008. Service-Oriented Computing – ICSOC 2008. Vol. 5364/2008, pp. 331-346. http://www.springerlink.com/content/9055736715131767/. ISSN 0302-9743 (Print) 1611-3349 (Online).

When using a third-party component, contracts offer a specification against which you can validate that component. (1)

This is in line with my earlier proposal that this could be covered by what I call a Composite Integrated Development Environment.

Now for web service signatures, this is state of the art.

Unfortunately, because the BankAccount specification does not define precisely the effect of operation executions, the user can only guess at their outcomes. (1)

That is the problem. How is the behavioral contract specified?

The client should only call a contractor routine in a state where the class invariant and the precondition of the routine are respected. In return, the contractor promises that when the routine returns, the work specified in the postcondition will be done, and the class invariant will be respected. (1)

This means, that a behavioral contract should be specified in terms of preconditions of a web service and postconditions of it. In this case a composite IDE can validate models of services consumption against models of service provisioning.

In BPMN 2.0 the abstract process is a possible way to achieve this goal. It defines which behavioral contract the participant offers and under which preconditions (process state) a service can be called. In the same way in (2) the desynchronized choreographies can be seen as such. However in (2) the modeling process is top-down. In practice it could also be bottom-up. Especially if there are existing components with an implemented behavior which is modeled after the fact to allow for contract awareness.

Bibliography

1. Beugnard, Antoine, et al. Making Components Contract Aware. Computer. 1999, Vol. 32, 7, pp. 38 – 45. http://portal.acm.org/citation.cfm?id=621275.
2. Lecture Notes in Computer Science: Non-desynchronizable Service Choreographies. Decker, Gero and Alistair Barros, Frank Michael Kraft and Niels Lohmann. Berlin / Heidelberg : Springer, 2008. Service-Oriented Computing – ICSOC 2008. Vol. 5364/2008, pp. 331-346. http://www.springerlink.com/content/9055736715131767/. ISSN 0302-9743 (Print) 1611-3349 (Online).

Lecture Notes in Computer Science: Non-desynchronizable Service Choreographies. Decker, Gero and Alistair Barros, Frank Michael Kraft and Niels Lohmann. Berlin / Heidelberg : Springer, 2008. Service-Oriented Computing – ICSOC 2008. Vol. 5364/2008, pp. 331-346. ISSN 0302-9743 (Print) 1611-3349 (Online)

Non-desynchronizable Service Choreographies

This paper describes on a scientific level what happens, if one starts to model a choreography (in the wider sense). This would be the modeling of the sequence of messages, that are exchanged. This can either be done by assuming, that the send and the receive of a message is atomic. This is a first good approximation of the behaviour of a choreography. However, in the context of asychronous messaging messages may be delayed and other conflicting messages may be sent. In other words, situation may occur, that are problems in the first specification of the choreography. Therefore the paper discusses some of the problems that might appear, how they may be identified and how they can be resolved. This leads to a higher quality of choreography models, that can be used to bridge the business view and the IT view, because the choreography models can be used in model driven development in this case – because they are consistent.

The methods described here can not only be used with petri nets, but also with BPMN (because BPMN is a petri net). The paper’s choreography model can be identified with the BPMN 2.0 choreography model and the paper’s desynchronized model can be identified with the BPMN 2.0 collaboration model.

Tools can be built to support the consistency checking of a choreography and make the user experience very friendly.
[ad]