We received note from IEEE Internet Computing that our paper on SSDL was accepted for publication in the Jan/Feb 2006 issue on “Asynchronous Middleware and Services”. The reviews were very good and constructive. We’ll have to make few changes which will hopefully make the paper even easier to read but this should be easy. I am very excited about this. Simon, Jim, and I are also working on an SC-focused SSDL chapter for an upcoming e-Science book on workflows. Now the focus will have to be on the MEST paper 🙂
In the meantime, our Rules SSDL Protocol framework co-authors are making very good progress with their work. The HPTS attendees were very interested in their protocol consistency work (protocols and formal models for protocol description was one of the main motivations behind SSDL). Pat Helland was very supportive of this work. This made me very happy! Well done to Alan Fekete, Dean Kuo, and Paul Greenfield for this work. They are now thinking of combining the Rules and SC (Simon‘s pi-calculus-based work) protocol frameworks in order to create an even more powerful way of describing messaging behaviour. I am looking forward to their work.
I have started thinking (admittedly not intensively) about some more SSDL-related work. I’ll say more when I am ready. In the meantime, there are discussions in the SSDL mailing list about the possibility of Java-based implementations. It’d be very cool if the community works on Java tooling.
4 responses to “Good news about SSDL”
I haven’t had time to look at the protocol validation work you’re basing on SSDL, so forgive me if I am asking something quite obvious: how does it relate to or differ from CDL? Perhaps a pointer?
Greg
Hey Greg,
SSDL is not meant as a replacement for CDL. SSDL is proposed as a better contract language for Web Services (we assume SOAP) than WSDL. Given CDL is based on pi-calculus, I think it’s should be an easy task to write an SSDL protocol framework for it.
SSDL is meant as a contract language rather than a process/orchestration language. We leave that to the protocol frameworks.
Does this make sense?
.savas.
No. I was under the impression that SC was in fact a protocol framework based on pi-calc. Perhaps I should have phrased my question differently: how does SC relate to or differ from CDL? Does that make more sense? If not, then I’ve got some digging to do to sort things out…
Greg
Greg,
apologies for not replying sooner. You are quite right, both SC and CDL are based on the pi-calculus, however they model “contracts” from a different perspective. CDL models contracts from a global viewpoint, whereas SC takes a service centric approach. This means that a SC contract defines the behaviour of that service which is exposing the contract. CDL on the other hand defines the behaviour of a set of services from the point of view of some logical entity in the middle.
Both CDL and SC can be turned into some pi-calculus expressions and then checked for certain properties such as dead paths and eventual termination. It is possible to combine multiple SC contracts and create a similar global view to that described by CDL (this is in fact what happens during validation of SC when >=2 contracts are combined and the result is validated).
As Savas mentioned, it should be possible to create a protocol framework that provides a CDL like description (I’m not sure how easy this would be, but in theory it should be possible).