Home

News: Pi Calculus for SOA 1.3.0 released - tool for choreography

  1. Pi4 Technologies is pleased to announce release 1.3.0 of it's WS-CDL eclipse-based open source tool suite called Pi Calculus for SOA. This release enables architects and developers to construct a choreography and then generate and deploy Java based web services in an Axis environment from a choreography description in WS-CDL.

    The W3C Choreography Description Language (WS-CDL) is a standard for describing how services interoperate based on their observable behavior.

    This release enables architects and developers to build complex distributed systems as peer services while guaranteeing service interoperability through a common choreography description.

    Further support is available from http://www.pi4tech.com/.

    Choreography is likely to be a large factor in SOA's success, but is the technology and terminology accessible enough for everyday use? What do you think of this product?
  2. My point of view as a BPEL user and CDL illiterate is that BPEL shows a real, day-to-day value for SOAs (create composite web services in a simple way), while CDL usefulness (designing complex interactions at high level) seems more ellusive; at least I have no need for it right now.

    Which leads me to think that, although they have a different abstraction level, given the large overlap they show, these specifications will have to fight each other for its niche - and currently BPEL shows far much more industry support than CDL.
  3. CDL and BPEL[ Go to top ]

    Javier,

    I appreciate you point. But as you say you are a CDL illiterate. You need to step back and think about how we design systems. And you need to step back and think about what BPEL does for you.

    We design from the top down. So we need some form of technical contract between services. WSDL is not enough and BPEL was never built to do this. And UML is not enough either. So we need some way of encoding, writing down, the rules of engagement between services. This is what CDL does. And it is not tied to Web Services and so is suitable for generalized SOA.

    BPEL is pretty cool at what it is supposed to do. It is a porogramming language that enables you to construct web services from web services in a recursive manner. And to execute the composed service in an application server. It is, in short, a targetted programming language for web service composition. Thus it is not a design tool it is an implementation tool.

    Joining the dots you can use CDL to express at a high level the technical contract between services (kinda like really good unambiguous UML sequence diagrams) and then generate BPEL or Java or whatever you want at the service end points. So CDL really is complementary to BPEL. There is no competition.

    Oddly enough several financial service companies and vertical standards bodies tried to use BPEL like CDL and found that it really wasn't any good at all at doing business protocols or high level design technical contracts. They *all* put BPEL where it needs to be (namely as an end point implementation language) and are using CDL to drive what they do. CDL gave them choice without locking them into any sort of architectural style so they get to choose a combination of peer to peer and centralised orchestration.

    I would be happy to provide further information if you would like any and perhaps you will find CDL beneficial as you move your own projects forward.

    Best regards

    Steve Ross-Talbot
  4. CDL and BPEL[ Go to top ]

    BPEL ... is a porogramming language that enables you to construct web services from web services in a recursive manner. And to execute the composed service in an application server.

    ...So CDL really is complementary to BPEL. There is no competition.

    you're referring to Executable BPEL processes but you're completely ignoring Abstract BPEL processes, which can be used for specifying public business protocols (as opposed to private executable process compositions)
  5. Abstract BPEL is great as a behavioral contract for a single service. But it is not guaranteed to be part of WS-BPEL. There is still some doubt about it's inclusion as far as I am aware.

    Also Abstract BPEL was never designed to be able to express multi-party contracts in any scalable and sensible fashion. Whereas WS-CDL was designed to do this.

    If you think otherwise try implementing the Buyer Seller example in the WS-CDL archives and see how far you get. Or try doing fpML. Others have tried and found it to be wanting. Not surprising since this is not what it is for. No criticism of BPEL or Abstract BPEL here. Just recognition of heritage, and what they are for.

    Remember WS-CDL was designed ground up based on solid requirements and underpinned by sound engineering and mathematics. I do not think that BPEL was achieved by the same means.
  6. Also Abstract BPEL was never designed to be able to express multi-party contracts in any scalable and sensible fashion. Whereas WS-CDL was designed to do this.

    You are correct that Abstract BPEL and WS-CDL are complementary since the former presents a single-service behavioural description, while the later describes a multi-party collaboration. But this is not what you said in your previous post - you focused only on the executable BPEL processes and ignored the abstract ones, that's why I disagreed
    Remember WS-CDL was designed ground up based on solid requirements and underpinned by sound engineering and mathematics. I do not think that BPEL was achieved by the same means.

    well, IMHO both BPEL and WS-CDL suffer from a lack of formalisation. You claim that WS-CDL is based on "sound engineering and mathematics" yet I can't see any document with a WS-CDL formalisation (in whatever formalism) on the W3C site.

    Individual approaches do exist, but this holds for BPEL as well (f.e. approaches to providing an Abstract State Machine based formalisation of BPEL)

    If WS-CDL has an agreed upon formalisation then why can't we see it on the W3C site (which, by the way, lists WS-CDL as a Working Draft - http://www.w3.org/TR/ws-cdl-10/. The editor's version from September has no official status, so I'm not sure where the Candidate Recommendation status of WS-CDL comes from)
  7. The formalism can be found on the public list at http://lists.w3.org/Archives/Public/public-ws-chor/2005Nov/att-0015/part1_Nov25.pdf

    This is from our invited experts.

    As to the status not being shown on the Choreography WG site alas this is a W3C admin error. Documents that go to TR are always references from the TR pages (the one I enclosed).

    I take your point about Abstract BPEL and we have not ignored it in the wider scheme of things it is more a case of positioning CDL in the correct way. BPEL has had the advantage of many marketing $$ behind it whereas we have had virtually none. Maybe this has been good for us as it allowed us to develop without interruption but now it is less good for us.

    The formalism is based on pi-calculus. It has come later in the day simply because we needed to parallelise the work otherwise we would be seen to be too slow. We look forward to any comments you have on the work and would encourage you to respond on the public lists; which is why it has been put there in the first place.
  8. Formalism and WS-CDL[ Go to top ]

    In the paper linked to above two formal calculi are described: a 'global' calculus that models business processes from a global perspective and the pi-calculus that models the same processes as a set of local endpoint behaviors. The global calculus is similar to WS-CDL and the main point of the paper is that processes modeled with the global calculus (WS-CDL) can all be translated to the pi-calculus.

    Reading the paper made me wonder: Why is a global description of the service collaboration as in WS-CDL better than a set of local descriptions that each describes the behavior of the participating services (e.g. as a set of abstract BPEL descriptions)? Are a set of abstract BPEL descriptions for each of the collaborating services and a global WS-CDL description for the collaboration as a whole not just different representations of the same thing? If not, what expressive power is added by the global WS-CDL description compared to a set of abstract BPEL descriptions for each end point.

    Also, many complicated network protocols, e.g. TCP, have been specified just fine by descriptions of endpoint behavior such as state machines. Why is a global specification needed?
  9. I don't propose to answer the question here. The purpose of placing the paper on the W3C public list is to encourage exactly these sorts of questions on the public list. So I would direct the author to that list.

    Best

    Steve T
  10. Formalism and WS-CDL[ Go to top ]

    Why is a global description of the service collaboration as in WS-CDL better than a set of local descriptions that each describes the behavior of the participating services (e.g. as a set of abstract BPEL descriptions)?

    there is a very good paper from Dijkman & Dumas that tackles the issue

    check out section 4.2 of "Service-oriented Design: A Multi-viewpoint Approach"
  11. Formalism and WS-CDL[ Go to top ]

    This is very interesting, thanks for the link.
  12. My apologies for not fully reading the paper. It does indeed look interesting. And without having delved into details (which is unwise but alas I am snowed with work right now) I would point out some work done by the pi-petri working group on expressibility of different formalisms. My guess, again without having fully read the paper, is that it makes the point for a global model (a choreography) but does so using petri-net techniques.

    These are ok but do not capture the semantics of channel passing which is needed for many application use cases. Whereas the pi-calculus does deal with this model. This is not to say petri-nets are not useful, far from it. They are a wonderful graphical expression of interaction along static paths. And there is work in the academic community to take what is good in petri-net theory and pi-calculus and come up with more useful expression to us as practitioners. But we shall have to wait longer for this.

    You can reference the work of the group at http://www.smartgroups.com/groups/petri_and_pi which was set up as a response to Van de Aalsts paper by none other than Robin Milner.
  13. Normally I'd moan about yet another WS-* "technology", yet another vendor jumping on the SOA bandwagon but WS-CDL is the the technology that's going to make SOA work in an enterprise level.

    We're now seeing a serious take-up of CDL in the banking world, FpML for example is now adopting CDL to define message flows between parties, it's filling the position left by the demise of GSTPA.

    I don't expect CDL to be of interest to "main-stream" programmers but system architects and designers should take a serious look at Pi4Tech's tools and WS-CDL itself.

    -John-
  14. The W3C Choreography Description Language (WS-CDL) is a standard for describing how services interoperate based on their observable behavior.

    this is pretty much misleading

    WS-CDL is not a standard, it is even not a W3C recommendation. Indeed it still has the lowest W3C maturity level (Working Draft) and has a long way to go through Candidate Recommendation, Proposed Recommendation and finaly a W3C Recommendation
  15. The W3C Choreography Description Language (WS-CDL) is a standard for describing how services interoperate based on their observable behavior.
    this is pretty much misleadingWS-CDL is not a standard, it is even not a W3C recommendation. Indeed it still has the lowest W3C maturity level (Working Draft) and has a long way to go through Candidate Recommendation, Proposed Recommendation and finaly a W3C Recommendation
  16. Check http://www.w3.org/TR/

    As to when a standard is a standard that is another point entirely. I think the diff between CR and R (to use W3C speak) is sufficiently small that it ceases to matter as much.