sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [sca-assembly] ISSUE 2: Use of UML 2.0
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
- Date: Fri, 5 Oct 2007 15:50:58 +0100
Folks,
I didn't comment on this previously
as it became an issue without a number - now that we have a number
it's time to pitch in!
First comment: The
title of this issue is a poor one. The issue actually refers to the
SCA Assembly diagrams and
whether UML 2.0 diagrams should be used
as an alternative. There is also a second question lurking as to
whether
the diagrams are normative or not. Perhaps
that is a second, separate issue.
Second comment: Why
did the SCA specifications use their own form of Diagram?
This was the original question raised
by Jeff Estefan, who said in effect "why not use UML 2.0 diagrams?"
I think that the basic reason that the
SCA specifications have their own diagrams rather than using UML 2.0 is
that SCA isn't UML.
I hope that this does not come across
as too dismissive or too glib, but I think that Jeff Anderson's efforts
building SCA
diagrams using UML 2.0 actually help
prove the point.
SCA has its own concepts, its own semantics.
Some of them map well to UML 2.0, some not so well.
It is possible to regard SCA as a kind
of domain specific language, which can (partly) be derived from
a UML model of an SOA system. A
mapping is possible from UML to SCA - we have had that debate with
UML supporters in the past, and I don't
think anyone would argue against that.
However, SCA is actually an executable
language and in this regard it does go further than UML.
So, why does SCA have its own unique
diagrams? Because it is useful and necessary to have a way
of visualizing SCA compositions and
because other existing diagram notations don't fit so well and
have to be bent to fit the needs of
SCA.
Are the current diagrams in the OSOA
SCA specifications the right ones? That is something to debate
- maybe there are things that could
be rendered better. However, I think that the current diagrams are
a good starting point.
Third Comment: Do
the SCA diagrams need to be normative?
This is a different question, but it
is lurking here, so we might as well get the debate into the open.
I think that there are some advantages
to having a "standard" form of diagram for SCA. Basically,
it
will help end-users if the same things
are rendered in the same ways, whether they are looking at a book,
using a programming tool or viewing
a web page.
So, I argue that the SCA diagrams should
be normative but optional. They are definitely part of the specifications
and where the specs require diagrams
they should all be in the one form. It should be strongly suggested
that
tools (etc) relating to SCA should use
this form of diagram, to avoid confusion. However, folk are not forced
to
use them if there are good reasons not
to do so....
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]