277 lines
11 KiB
TeX
277 lines
11 KiB
TeX
\documentclass[pdftex]{scrartcl}
|
|
\usepackage{longtable}
|
|
\usepackage{graphicx}
|
|
\title{\umlToCdl~System Description \\ Version 1.0}
|
|
\author{J\"urgen Doser and Burkhart Wolff\footnote{This work is part of the EU-funced TrustCom Project
|
|
\texttt{http://www.eu-trustcom.com/}}}
|
|
\date{}
|
|
|
|
\newcommand{\st}[1]{\texttt{<<#1>>}}
|
|
\newcommand{\xml}[1]{\texttt{<#1>} \ldots \texttt{</#1>}}
|
|
\newcommand{\umlToCdl}{\texttt{UML2CDL}}
|
|
\newcommand{\cdl}{\texttt{CDL}}
|
|
|
|
\begin{document}
|
|
\maketitle
|
|
|
|
\section{Introduction}
|
|
\umlToCdl\ converts a UML model into the XML-based \emph{Choreography
|
|
Description Language} \cdl~\cite{cdl} describing the interaction of
|
|
distributed processes occuring in web-based services. Since \cdl\
|
|
can be compiled to BPEL4WS~\cite{bpel05,qiu05} which can be
|
|
interpreted by BPEL-engines directly, \umlToCdl\ is the front-end of a
|
|
tool-chain allowing for the abstract description of (some aspects of)
|
|
web-based services following the \emph{model-driven architecture}
|
|
(MDA) approach.
|
|
|
|
This system description serves several purposes:
|
|
\begin{enumerate}
|
|
\item We describe the principle format of the supported UML model
|
|
(essentially consisting of a class diagram and a collection of
|
|
associated activity graphs),
|
|
\item we describe the principles of the translation,
|
|
\item we add a list of known restictions and don't do's necessary for
|
|
the practical handling of \umlToCdl, and
|
|
%\item we will outline some future extensions of our tool.
|
|
\end{enumerate}
|
|
|
|
\section{The Structure of input \umlToCdl\ Models}
|
|
|
|
A UML Model that can be processed by \umlToCdl\ must have the
|
|
following structure:
|
|
\begin{enumerate}
|
|
\item it must have a class model (the \emph{base model}), defining the
|
|
information types, partners, roles and relationships,
|
|
\item a number of activity graphs may be associated to classes of this
|
|
model, describing the actual choreographies,
|
|
%\item \ldots
|
|
\end{enumerate}
|
|
|
|
\subsection{Example: SAC}
|
|
|
|
For the SAC example, the class model is given in
|
|
Figure~\ref{fig:SAC-class-model}.
|
|
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[scale=0.9,angle=90]{SAC_static_model.pdf}
|
|
\caption{Class model for SAC}
|
|
\label{fig:SAC-class-model}
|
|
\end{figure}
|
|
|
|
The actual dynamic behavior of the choreography is given in
|
|
Figure~\ref{fig:SAC-chor-model}
|
|
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[trim=200 0 0 0]{SAC_chor_model.pdf}
|
|
\caption{Choreography for SAC}
|
|
\label{fig:SAC-chor-model}
|
|
\end{figure}
|
|
|
|
|
|
\subsection{Example: SAC2}
|
|
|
|
For the SAC2 example, the class model is given in
|
|
Figures~\ref{fig:SAC2-participants} and \ref{fig:SAC2-relationships}.
|
|
Note that the example is not yet fully modeled: the second parallel
|
|
activity is not complete. But it shows how to model parallel
|
|
activities.
|
|
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[scale=0.85,angle=90]{SAC2-participants.pdf}
|
|
\caption{The participants in SAC2}
|
|
\label{fig:SAC2-participants}
|
|
\end{figure}
|
|
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[scale=0.85,angle=90]{SAC2-relationships.pdf}
|
|
\caption{the relationships in SAC2}
|
|
\label{fig:SAC2-relationships}
|
|
\end{figure}
|
|
|
|
The actual dynamic behavior of the choreography is given in
|
|
Figure~\ref{fig:SAC2-chor-model}
|
|
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[trim=200 0 0 0]{SAC2-chor-model.pdf}
|
|
\caption{Choreography for SAC2}
|
|
\label{fig:SAC2-chor-model}
|
|
\end{figure}
|
|
|
|
\newpage
|
|
|
|
\section{The Translation}
|
|
|
|
\umlToCdl\ is implemented in SML and includes a particular package
|
|
called fxp~\cite{fxp} for the XML processing. SML is a functional
|
|
programming language with a strong type system supporting parametric
|
|
polymorphism, parameterized modules (functors), pattern matching and
|
|
higher-order functions. As such, it is particularly suited for
|
|
symbolic computations and the flexible construction of compilers.
|
|
Although developped internally with the SML implementation SML/NJ
|
|
110.52~\cite{njml}, \umlToCdl\ has been cross-compiled via the SML
|
|
compiler MLton\cite{mlton} to ANSI-C. On this basis, an \texttt{.exe}
|
|
binary
|
|
%as well as \texttt{.dll} libraries
|
|
has been generated to be used in the TrustCom system architecture on
|
|
Windows platforms using the cygwin environment.
|
|
\footnote{Acknowledgements to Achim Brucker who contributed to this
|
|
part of our build process.}
|
|
|
|
\umlToCdl\ consists of three phases:
|
|
\begin{enumerate}
|
|
\item a generic XML-parser based on fxp,
|
|
\item a component converting the parsed XML-tree into
|
|
an abstract syntax for XMI following the UML 1.4
|
|
standard (as supported by Poseidon 3.1, see below).
|
|
\item a component converting the XMI representation into
|
|
\cdl.
|
|
\end{enumerate}
|
|
|
|
In the following, we focus on key elements of the translation of
|
|
the XMI into CDL.
|
|
|
|
\begin{longtable}{p{5cm}|p{4.5cm}|p{5.5cm}}
|
|
\textbf{UML Model Element with Stereotype}& \textbf{WS-CDL Element} &
|
|
\textbf{Remark} \\\hline\hline
|
|
Package \st{CDL.Package} & \xml{package} &
|
|
attribute \texttt{name} is taken from the name of the package,
|
|
attributes \texttt{author}, \texttt{version} and
|
|
\texttt{targetNamespace} can be specified using tagged values
|
|
\texttt{CDL.author}, \texttt{CDL.version} and
|
|
\texttt{CDL.targetNamespace} \\\hline
|
|
Class \st{CDL.InformationType} & \xml{informationType} &
|
|
%I'm not sure if we really have to model them explicitely, or if we
|
|
%can derive them from the types of the attributes/variables in the
|
|
%choreography. This is related to the question of how do we handle
|
|
%tokens, and token locators.
|
|
attribute \texttt{exceptionType} is taken from the tagged value
|
|
\texttt{CDL.exceptionType}. The attribute \texttt{type}
|
|
(resp. \texttt{element} is \emph{currently} taken from the tagged
|
|
value \texttt{CDL.type} (resp. \texttt{CDL.element}). We can
|
|
discuss to use class attributes with names \texttt{type} or
|
|
\texttt{element} instead, whose types corresponds to classes in
|
|
another package describing the WSDL or some SML Schema.
|
|
\\\hline
|
|
Class \st{CDL.Token} & \xml{token}
|
|
& the information type of the token is given by the attribute with
|
|
name \texttt{informationType}\\
|
|
|
|
\\\hline
|
|
Class \st{CDL.ChannelType} & \xml{channelType}
|
|
& the role of a channel is given by an association, the reference
|
|
type by the attribute with name \texttt{reference}. the
|
|
\texttt{identity} and \texttt{passing} elements are currently not
|
|
supported.
|
|
\\\hline
|
|
Class \st{CDL.RoleType} & \xml{roleType} &
|
|
the behaviors of a roletype are specified using realisations of
|
|
interfaces. \\\hline
|
|
AssociationClass \st{CDL.RelationshipType} & \xml{relationshipType} &
|
|
the roles in a relationship are given by the classes/roletypes
|
|
connected to this association class\\\hline
|
|
Class \st{CDL.ParticipantType} & \xml{participantType} &
|
|
the roletypes of a participant type are specified using composite
|
|
aggregations from the participant type to the role type\\\hline
|
|
Class \st{CDL.Choreography} & \xml{choreography} &
|
|
The attribute \texttt{complete}, \texttt{isolation}, \texttt{root},
|
|
and \texttt{coordination} can be specified using the tagged
|
|
values \texttt{CDL.complete}, \texttt{CDL.isolation},
|
|
\texttt{CDL.root} and \texttt{CDL.coordination}. The variables
|
|
(both informationtype and channeltype) used in the choreography are
|
|
specified using attributes of the respective type. The roletypes of
|
|
the variables are specified by the tagged value \texttt{CDL.roletypes}
|
|
\\\hline
|
|
Interface --- & \xml{behaviour}
|
|
& only when realised by a roletype (see above)
|
|
\\\hline
|
|
Activity \st{CDL.silent} & \xml{silent} & The
|
|
partition to which the state belongs defines the roleType. The
|
|
description of the silent actions is given by the body of the entry
|
|
action, if the language of the entry action expression is either
|
|
``documentation'', ``reference'', or ``semantics'' (which are the
|
|
possible description types in WS-CDL)
|
|
\\\hline
|
|
Activity \st{CDL.noAction} & \xml{noAction} & The
|
|
partition to which the state belongs defines the roleType.
|
|
\\\hline
|
|
Activity \st{CDL.request} of \st{CDL.respond} & \xml{send}
|
|
& see Objectflow below
|
|
\\\hline
|
|
Activity \st{CDL.receive} & \xml{receive}
|
|
& see Objectflow below
|
|
\\\hline
|
|
ObjectFlow & \xml{exchange} & the
|
|
connected action states are translated to send and receive
|
|
activities, a sequence of such objectflows defines an
|
|
\xml{interaction}. The name of the variable transfered in the
|
|
exchange is given by the name of the objectflow state, the
|
|
information type of the exchange is given by the type of the objectflow
|
|
state. The action (request resp. response) is given by the stereotype of the send
|
|
action -> \texttt{<<CDL.request>>} and \texttt{<<CDL.respond>>}. The
|
|
relationshipTye, the channelVariable, and the operation for this
|
|
interaction are given by tagged values, the fromRole and the toRole
|
|
of the exchange are given by the partition of the send and receive
|
|
states (the order depends on whether it is a request or a respond
|
|
exchange).
|
|
\\ \hline
|
|
successive activities & \xml{sequence} &
|
|
\\ \hline
|
|
Fork Pseudostate & \xml{parallel} & all
|
|
subsequent activities up to the matching join pseudostate \\\hline
|
|
\end{longtable}
|
|
|
|
Not every detail of the description above may be currently fully
|
|
implemented (see the remarks), but no big obstacle in implementing
|
|
them are expected.
|
|
|
|
The following tables shows major elements that are currently not
|
|
implemented at all:
|
|
|
|
\begin{longtable}{p{5cm}|p{4.5cm}|p{5.5cm}}
|
|
\textbf{UML Model Element with Stereotype}& \textbf{WS-CDL Element} &
|
|
\textbf{Remark} \\\hline\hline
|
|
Activity \st{CDL.perform} & \xml{perform} &
|
|
\\\hline
|
|
Choice Pseudostate --- & \xml{choice} & \\\hline
|
|
\end{longtable}
|
|
|
|
Furthermore, it is as yet undecided, how to handle workunits and
|
|
tokenLocators.
|
|
|
|
\section{Known Restrictions and Useful Workarounds}
|
|
A number of restrictions are imposed on \umlToCdl\ Version 1.0:
|
|
\begin{enumerate}
|
|
\item the XMI currently must be generated by \emph{Poseidon for UML
|
|
3.1-0}, most likely the Community Edition. Support for
|
|
Together Designer 2005 may be possible in the future. Support for
|
|
Together Control Center or other earlier versions of Borland
|
|
Together is unlikely.
|
|
\item don't use cut-copy-paste when editing the diagrams: this may
|
|
lead to sharings of model-elements and inconsistent XMI output of
|
|
Poseidon.
|
|
\item since Poseidon 3.1-0 does unfortunately not support
|
|
swimlanes/partitions in activity charts, we currently require to
|
|
encode them by adding the tagged value \emph{partition} with
|
|
a string containing its name.
|
|
\item the tool currently does almost no exception handling and input
|
|
checking, so it requires some care to provide a model that is
|
|
sufficiently consistent to process it.
|
|
\end{enumerate}
|
|
|
|
%\section{Conclusion}
|
|
|
|
|
|
\bibliography{trustcom}
|
|
{\small
|
|
\sloppy
|
|
\bibliographystyle{abbrv}
|
|
}
|
|
|
|
|
|
\end{document}
|