The joint PTC11 Meeting, April 22-24 2013 meeting is hosted by CNR in Marsala, Sicily, April 22-24, 2013. Lasting three days, the first session is to start at 2pm on Monday April 22, and the last meeting to finish at 2pm on Wednesday April 24. The sessions will focus on mainly on defining the final tasks toward full completion of the project by October, 2013. As @NeilMaiden says "Sun is shining but like all computer scientists, we squeeze into a small dark room" (!)

CHOReOS will be showcased at the CeBIT Open Source Park, March 5-9, Hanover, Germany. The open source area of CeBIT is the largest business-oriented event for open source software in Europe and is gathering visitors from all over Europe.

See more about CeBIT: http://www.cebit.de/home or about the Open Source Park: http://www.open-source-park.com/. ...

The joint PTC10 meeting is hosted by Inria in Paris, January 21-23, 2013. Lasting three days, the first session is to start at 2pm on Monday January 21, and the last meeting to finish at 1pm on Wednesday January 23. The sessions will focus on mainly on the IDRE tools, with the objective to understand better each tool, their perimeter, how they run and their maturity in order to use all in the use cases. For that, Day 2 is organized around technical sessions with demos and interactions. 
...

Rehearsal is an open source project supported by HP Labs, the CHOReOS EC FP7 Project, and the University of São Paulo and is available through this page.

The blog post presents the service mocking feature of Rehearsal, a framework that brings features to promote agile testing in web service compositions. This feature consists of an abstraction of the soapUI mocking. In contrast to this tool, Rehearsal provides a fluent interface that aims at providing mechanisms similar to Mockito or EasyMock in web services. As a result, mocking a SOAP web service is similar to mocking a Java program. 

See the initial blog post.  ...

This is the third edition of the SOFI newsletter. Read the newsletter here.
...

The 7th PTC and 4th PMC meeting will be hosted by the ISTI-CNR in Pisa. Many thanks to the ISTI team for hosting this meeting and for their help in the organization.

It is the last full meeting before the M18 review: the objective is to discuss the review demonstrations and conduct an extensive update of workpackages as actual software development is in progress and partners have started to upload code.

Over 30 people attending this meeting which first outcome was to approve the reorganization and repositioning of WP7 and the launch of the OW2 Future Internet Software initiative.

This is the second edition of the SOFI newsletter. Read the newsletter here.

...

CHOReOS was showcased in the first edition of the SOFI newsletter. SOFI (Service Offering for the Future Internet) will regularly feature R&D projects in the area of Internet of Services, Software and Virtualisation (Objective 1.2). Read the newsletter ...

The following viewpoint follows some discussion between CNR and Camerino people and is thus indicative of our common idea. Given that we would like to reach a consensus on the subject we will not already try to give a precise definition of the concept, instead we would like to stay at the intuitive level for now. At the same time we refer to choreographies as they are conceived now. Certainly one of the CHOReOS objectives is to go a step forward.

The divergence we perceive is that on one side someone, like us, sees a choreography as a looser, more abstract, specification of the interaction among roles who adhere to the choreography; on the other side, some partners might speak of choreography as an executable specification, which hence would not be much different (for us) from an orchestration.

In our opinion the very general idea of a choreography is that of a multi-party protocol that when put in place by the cooperating parties will permit to reach the overall choreography objective. In reaching the overall objective each party in general pursues a local objective which often is related to its business. Each partner in a choreography can derive a precise protocol that it has to use in order to interact with the other partners with which it has a direct contact. Nevertheless it will not necessarily know (unless the choreography states differently) which are the partners with which its partners will interact. This is a fundamental requirement from a technical and business point of view. It also means that how I conduct my business behind the scene is not of interest for my client and will not discovered to third parties. In fact I directly get in contact with my providers.

We think that this view is quite different from an orchestration in which a single stakeholder centrally plans and decides how an objective should be reached through the cooperation with other services. It is certainly true that from a formal point of view it not difficult to imagine that a choreography can be reconducted to an orchestration in which the whole message exchange is concentrated to a single node acting as the orchestrator. Nevertheless we think that this is not a good way of "choreographing" from a technical and business perspective (even more when we consider the Ultra-large scale). From a technical perspective we find it difficult to imagine such a kind of (centralized?) broker that controls everything. From a business perspective we think that this way of working implicitly consist in partially revealing (and giving control on) our business interactions, which should instead remain private between the interacting parties.

A choreography is much like a social environment in which complex tasks are fulfilled by the cooperation of different stakeholders each one playing different roles and pursuing a private objective. In this view we can consider an example from the real world and let's consider a choreography related to a real estate sales service. In such a choreography we can figure out at least 3 stakeholders. The first obviously is the house holder. The second is the real estate agency and the third one is the buyer. A simple choreography we can imagine is roughly constituted by the following steps. The buyer contacts the agency, they go and see the house, the buyer manifest interest for a house, the agency contact the owner and make a first sale proposal, then at a certain point an agreement is found and finally there is a money/ownership exchange. In our view "rephrasing" the choreography as an orchestration would not be a feasible choice since the orchestrator would have knowledge of all the commercial transactions. put in place during the choreography.

What CHOReOS should add in our opinion? Well right now a choreography is specified in a quite low level detail in which the global objective (possibly emerging has the union of the private objective) is reached through a precise sequence of message exchange. In a very dynamic context becomes quite difficult to identify all the possible variability points. Nevertheless we would like to reach the global objective. So we should relax the definition of a choreography trying to define more dynamic approaches.

Andrea Polini

Assistant Professor at the Department of Mathematics and Computer Science of University of Camerino