OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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



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]