LCC is as lightweight and parsimonious as we can make it. This does not mean, however, that it is straightforward for every engineer to use. Application domains develop engineering cultures that often take as a focus particular styles of design, supported by task-specific design notations. Thousands of these have developed and many continue to be invented so it is impossible to catalogue exhaustively the relationship of all these to LCC. Instead, we give examples below of ways to connect OpenKnowledge to established systems of design. First, in Section 1, we demonstrate the most direct route, via translation from a more traditional language to LCC. Then, in Section 2, we consider the case where the traditional language to which we wish to connect is providing a different functionality from that of LCC so extension of LCC is required to embrace it. In Section 3 we explain the more radical alternative of writing, in LCC, an interpreter for an established language. Finally, in Section 4, we discuss the most radical step of all - to replace LCC in the OpenKnowledge kernel with an alternative process language.

• 1. Translation to LCC From Established Languages (UML, SCUFL)
  • 1.1 Translation to LCC from UML Activity Diagrams

    The LCC coordination calculus lends itself well to display in a graphical form. Its concepts of participants, messages and constraints, are similar to that of the UML activity diagram that has partitions, flows and activities. As UML is a common tool for the design of software that is well used in industry, by providing a conversion between UML diagrams and LCC, we are able to minimise the intellectual cost of joining the OpenKnowledge network for many industry software houses and developers.

    UML editors are relatively common, yet they tend to focus less on data flow than data design. There are very few open source UML editors and those we found did not provide activity diagram support. Commercial products would be very hard to augment for LCC output without considerable cost and/or reverse engineering. So, as one of the support tools for the OpenKnowledge project we have implemented a basic UML activity diagram editor that has the option of outputting LCC code. The editor itself has been designed in a modular, extensible way so that other open-source developers could extend it such that it would handle other diagram types. However, we have, for now, only implemented the basic UML activity diagrams.

    A screenshot of the editor appears below. Various node types are displayed on the left of the editor and they are added to the diagram by clicking their appropriate button. Once in the editing area, they can be dragged around and their properties edited by double clicking.

    

    The conversion is achieved by searching for the initial node (the black dot) and tracing the graph through to the final node (the black dot with the outer circle). Transitions are considered LCC sequence ("then") statements unless they cross the partition swimlanes, in which case they are rendered as message sending and receiving. Activities are translated as constraint satisfactions. The branch nodes are rendered as "or" branches in the LCC.

    The LCC is rendered by traversing the graph and outputting the appropriate LCC for the node encountered. The LCC is buffered so that when "or" nodes are encountered, the LCC can be re-written. Back-tracing of the graph is done at various points to ensure that activities that occur after branches in other participants are rendered correctly.

    The LCC below shows the LCC export for the diagram shown in the UML diagram above:

    // -----------------------------------------------------------------------------
    // LCC File generated by UML-to-LCC exporter.
    // test.lcc
    // 24/10/2008
    // -----------------------------------------------------------------------------
    r( participant1, initial )
    r( participant2, necessary )
    
    // ============================================================ 
    a( participant1, ID ) :: 
    (
    	null <- activity1() then
    	msg() => a( participant2, Participant2ID ) then
    	msg() <= a( participant2, Participant2ID ) then
    	null <- activity3()
    )
    or
    (
    	null <- activity2a()
    )
    
    // ============================================================ 
    a( participant2, ID ) :: 
    	msg() <= a( participant1, Participant1ID ) then
    	null <- activity2b() then
    	msg() => a( participant1, Participant1ID )
    

    The implementation of the basic UML editor and translator to LCC can be downloaded as source code.

  • 1.2 Attaching to Existing Design Systems via Translation (Taverna)

    One of the main testbeds for the OpenKnowledge system is in bioinformatics. Although this domain of application is comparatively new, there already exist accessible design tools for bioinformatics workflow, especially in Grid systems. One of the best known systems is Taverna (although there are others, such as Kepler and Triana). The Taverna system provides a visual editor for describing workflows to be enacted on a Grid system and produces a specification of the workflow in the SCUFL process language. For the sector of the bioinformatics community interested in using Taverna, the easiest way to connect to the OpenKnowledge system would be to continue to use their familiar design tools but, instead of using a Grid system for workflow enactment, to use the OpenKnowledge system.

    To make a switch to OpenKnowledge as straightforward as possible for this community we built an automatic translator from SCUFL to LCC. This does not disrupt in any way the current methods of use of the Taverna system (which we assume are well honed to the Taverna community) but simply provides an additional step beyond the traditional endpoint of Taverna specification (which is a workflow specification in SCUFL) to LCC. The SCUFL to LCC translator is described in detail in our technical report and the Java code used to implement it can be downloaded as source code.

• 2. Connecting LCC to Compatible Languages With Different Functionality (OWL-S)

  In the previous section our approach to integrating with an existing design system was automatic translation, with the aim of altering established design practice as little as possible. Some systems of design, however, are oriented to a different problem than the one being addressed by OpenKnowledge and then the issue becomes one of complementarity: establishing connections such that the two systems can be used together to mutual advantage. An example of this is the OWL-S language for semantic web service specification.

  OWL-S is essentially a typed language for specifying input/output interfaces to Web services. It's use of OWL as a type language gives it a strong connection to semantic web efforts. OWL-S, however, deliberately avoids prescribing any language in which the processes to choreograph services might be specified (so as to remain neutral to choices in choreography language). Conversely, LCC deliberately avoids commitment to a service specification language (so as to remain neutral to service specification infrastructure). LCC and OWL-S therefore tackle service choreography from different perspectives.

  As an experiment in combining LCC and OWL-S, we built a prototype discovery system for services when enacting LCC interaction models. This involved adding type annotations to constraints in LCC interaction models and, from these annotations, automatically extracting service descriptions that could be matched to OWL-S service specifications using a Description Logic reasoner. The relationship between OWL-S and LCC is described in detail in our technical report and the Prolog code used to implement his OWL-S based discovery system for LCC (and the DL reasoner) can be downloaded as source code.

• 3. Writing an Interpreter for an Established Language in LCC (BPEL4WS)

  In Section 1 we gave an example of translation as a means of linking LCC to a task-specific design system. In Section 2 we gave an example of connecting to a complementary task-specific language via annotations in LCC. We now introduce a third way to bring a task-specific language into the sphere of OpenKnowledge: by writing an interpreter for the language in LCC.

  Although it is unconventional to use one protocol language as an interpreter for another, a similar idea - that one can use a declarative language to write a meta-interpreter for another language - is quite conventional in declarative programming. As an example, we chose the Business Process Execution Language for Web Services (BPEL4WS) which is an industrially used language for specifying business interaction protocols. Instead of writing a translator from BPEL4WS to LCC (the route we chose with UML and SCUFL in Section 1) we wrote a protocol in which the principal role is to act as a BPEL4WS interpreter. A BPEL4WS specification is given as a parameter to this role and enacting the role interprets the BPEL4WS specification to produce appropriate message passing and invocation of services. The LCC specification needed for this is, of course, complex but for BPEL4WS users this complexity is no more apparent than in any other system for enacting BPEL4WS. Conversely, from an LCC point of view, the BPEL4WS interpreter is just a normal (though complex) interaction model.

  The LCC interpreter for BPEL4WS is described in detail in Chapter 5 of our technical report on enacting decentralised workflow and the same source also demonstrates, in Chapter 4, the more conventional route of translation from BPEL4WS to LCC.

• 4. Replacing LCC with an Established Language (WS-BPEL)

  OpenKnowledge chose LCC as its core language because it provided a parsimonious yet powerful language with strong links to more abstract, generic process specification and declarative languages. Nevertheless, we have always recognised that other process languages could have been substituted for LCC and we have made the OpenKnowledge kernel system as independent as we could from specific choice of core language. This raises the possibility, for those who prefer a core language in some style other than LCC, to replace LCC with a process language of choice. We have demonstrated this with the Web Services Business Process Execution Language (WS-BPEL).

  This approach to integrating OpenKnowledge with other design systems requires much deeper understanding of the OpenKnowledge system, since it requires the LCC interpreter in the OpenKnowledge kernel to be replaced with an interpreter for a different language. Once done, however, it allows the more traditional process language (in our case WS-BPEL) to take advantage of the peer to peer discovery methods and other OpenKnowledge infrastructure. For those deeply committed to a non-LCC process specification language, this could be a more attractive long-term option than translation or meta-interpretation. Our experience of replacing LCC with WS-BPEL is described in our technical report.