I see that Martin posted an email to raise the visual modelling issue. I'll not address merits of the issue until we can formally address the issue, but will only try to address the historical question you raised.
As you know by now, OSOA produced UML diagrams to represent the architecture as another way to represent the model. We did this as another means to explore the design. We (ok, maybe it's just me) have found UML to be inaccessible to the target audience for SCA, which is comprised of business logic developers, not middleware vendors. In light of that, we needed a simpler visual model for expressing the concepts. In addition, several of the visual SCA tools that have emerged during OSOA have adopted a similar visual model which creates a very nice synergy in the community. One of the original SCA principles is to "keep simple things simple [for the business logic developer]", and the current visual representation seems to meet that goal for the target audience.
Dave Booz
STSM, SCA and WebSphere Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
"Jeffrey A. Estefan" <jeffrey.a.estefan@jpl.nasa.gov>
09/27/2007 03:24 PM
|
|
Dale, Mike, & Martin,
The conceptual UML model of SCA as a whole put forth by Mike Edwards is an excellent one and I have no issue with it. The issue I was raising had to do with the cartoon-like visual models used throughout the SCA specs that show properties, services, SCA components, and SCA composites plus their wiring together.
My argument is that there is great expressive power with UML 2 that did not exist in UML 1.x to support component-based development; structured classifiers in UML 2 (classes and components) can be decomposed and assembled ("wired") via Parts, Ports, and Connectors in the new Composite Structure diagrams. I wanted to suggest use of this visual modeling standard rather than use of custom cartoons for forthcoming SCA specs under OASIS. And my original question was to the source of these cartoons. We are exploiting UML 2 in our development of the OASIS Reference Architecture for SOA, which will be released for public review late this year or early '08. I also stress that we are using UML 2 as a means to capture visual models that form architectural views of the overall Reference Architecture.
As Duane Nickull (TC chair for the OASIS Reference Model for SOA) points out in his blog, we are considering use of the term "service aggregation" vice "service composition" since the latter is more accurate as it describes a whole-part relationship, meaning you 'delete the whole, you delete the parts.' This, of course, is not the intent of composite services or composite applications. We also recognize that the whole industry has already gained steam on the terminology of composition of services or "service composition" and therefore, we have not made a final decision on the language of the RA just yet.
I did not see an SCA-Assembly issues list on the Kavi site as of yet but once it is posted, I will update the issues list. It is my understanding from the recent SCA-Assembly TC minutes that JIRA is still being considered for tracking issues but has not yet been resolved so I'm sending this note to the whole TC.
Cheers...
- Jeff E., JPL
