commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <>
Subject Re: [SCXML] uml2bpel cool, but what about csxml2bpel?
Date Wed, 05 Apr 2006 17:53:32 GMT
Consolidating two replies in one, and assuming CSXML is just a
(repeated) typo for SCXML ...

On 4/5/06, Nestor Urquiza <> wrote:
> Hi everyone,
> Yesterday I posted something about the job I am
> planning to do for a business protocol and Rauhl
> headed me up towards BPEL4WS.
> I then found
> as a tool for converting from Rational UML diagrams to
> BPEL ... the problem I see with that approach is that
> a diagram is not easy to maintain as it is an xml
> file.

And that a diagram doesn't do anything for you at the middleware and
runtime levels, which is where SCXML comes in [1]. That is why there
is code generation, C++ and Java stubs from class diagrams come with
the Rational stack already, the way to think of SCXML documents in
this context -- as you've noticed -- is what the state machine diagram
gets transformed to (for example, all usecases on the Commons SCXML
website are accompanied by matching state machine diagrams for each
document). The modeling diagrams are extremely useful, and should be
the basis for the SCXML document, however, thats another discussion.

> CSXML is the xml representation of a StateChart
> diagram and I am wondering if anyone here knows about
> any plans from IBM or better open source to use them
> both (CSXML and BPEL).
> My particular task does not require SOAP and in fact
> seems like the clients are more for simple GET/POST
> still of course having a state behaviour. Of course in
> any case since Web Services are a future target I am
> interesting in getting any info you might be have
> about this.
> Maybe you can point me to a better place to post this
> proposal (ibm - developer works, eclipse framework or
> one of the already existing UML frameworks)

I personally do not have any more information about Eclipse framework
development (or whats happening with BPEL) than what is publicly
available, but the second hit on google for "commons scxml eclipse"
(without the quotes, ofcourse) gave me this message:

So, seems atleast some portions of Eclipse land seem to be looking at
using Commons SCXML.

I also can't say what the best place to "post this proposal" is. There
are clear similarities in most state machine notations, for example,
check this gutted BPEL snippet:

<process ...>


 <flow ...>
  <!-- receive, invoke, assign, reply etc. -->


and this SCXML snippet:

<scxml ...>


 <state ...> <!-- composite state -->
  <!-- sub-states, invoke, params, assigns, sends, onentry/onexit etc. -->


and while there may be deltas semantically to be bridged, transforms
are just waiting to be written. But beyond simulations and testing,
what this means in terms of using Commons SCXML in the BPEL domain, I
don't know, and haven't looked at it before you asked. If you have
ideas, feel free to shoot them this way.

> Any help greatly appreciated. Reinventing wheel is
> something I do not want to do for sure
> Thanks
> Nestor
On 4/5/06, Nestor Urquiza <> wrote:
> I see that ws-uml2bpel uses XMI to build BPEL, WSDL,
> and XSD files so the question can be also ... any
> XMI2CSXML convertor around there?
> BTW is Rose or XDE the only options as eclipse plugin
> for building a proper uml diagram that can be exported
> as XMI or even better to CSXML?
> thanks!

At this time, probably yes. I don't trust anything other than the
Rational stack for my UML work anyway, but thats a personal
preference. However, tooling and format conversions understandably
take time, and I see signs of both these things happening.

As with any emerging technology (and I'd consider SCXML to be one),
whether you can adopt it right now depends on what you're trying to
achieve (you will find similar sentiments echoing across numerous
emerging technologies -- this may sound obvious, but its often
worthwhile to list out the scenarios):

 * If you're working on a tight deadline on an existing project which
already uses some notation for state charts for its domain(s), stick
with the notation and tools you have.

 * If you're starting a new project, spend a few cycles to evaluate
whether using Commons SCXML makes sense. A clear benefit is you don't
have to own the notation or the implementation (if you're owning it).
Additionally, it may help with any existing limitations. I've done
this more than once and found Commons SCXML did things that I needed
(see usecases on website).

 * If you need to invent a state machine notation for your domain,
don't. Use SCXML. Otherwise it will just be YASCN (yet another state
chart notation). And that, truly, is reinventing the proverbial wheel.


[1] (see page 2)

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message