Stefan summarized his point with:
Which is exactly my point - the fault is not in UML, nor OO, but in
using it wrongly.
I agree that UML is not at fault, but I think current tooling is,
because it focuses too strongly on OO design, leading people to use it
wrongly. I'd very much like to see someone define a standard SO
profile for UML.
Anne
On 8/18/06, Stefan Tilkov <[EMAIL PROTECTED]> wrote:
> On Aug 18, 2006, at 10:42 AM, Lukas Barton wrote:
>
> > Hello,
> > I wrote a thesis about MDA (only in Czech, see abstract athttp://
> > www.archaebacteria.net/?p=5).
> > I mean that MDA as described by MDA Guide V1.0.1 and MDA
> > Foundation Modelfrom OMG forces OOAD (Object Oriented Analysis and
> > Design). MDA is now too object oriented.
> > The main problem is in tools (and you cannot do MDA without
> > tools). I learned that majority of tools support OOAD (Object
> > oriented analysis and design). Most of them only transforms class
> > models into static object structure. That's useful. It could save
> > time during developmnet phase. Etc… but does not help with SOA.
> I don't understand this statement. First of all, lots of tools
> support generation from other models; e.g. it's easily possible to
> use UML activity diagrams to describe a business process and generate
> e.g. BPEL from it. Secondly, I don't see how generating WSDLs from
> UML class models "does not help with SOA".
> > OOAD is not enough for SOA. The world is not composed only from
> > objects (object model). There could be another views - service
> > oriented, event oriented,hirearachical or data (document) oriented
> > (mixture possible). Detailed example of OOAD inadequacies for SOA
> > were described at Elements of Service-Oriented Analysis and Design.
> The key piece from this article regarding OO seems to be this:
>
> "The main issue with current OO design practices in relation to SO is
> that its level of granularity is focused at the class level, which
> resides at too low of a level of abstraction for business service
> modeling. Strong associations such as inheritance, create a rather
> tight coupling (and, consequently, a dependency) between the involved
> parties. In contrast, the SO paradigm attempts to promote flexibility
> and agility through loose coupling. There, currently, is no cross-
> platform inheritance support and first-class notion of a service
> instance in SOA in order to avoid having to deal with service
> lifecycle housekeeping issues such as remote garbage collection."
>
> Which sounds like Eric's argument to me. To which I say: Don't use
> inheritance (even though WSDL 2.0 supports it, see http://www.w3.org/
> TR/2006/CR-wsdl20-20060327/#Interface_extends_attribute), and don't
> model your services as "stateless classes" (or rather interfaces).
>
> As the authors write "current design practices", which is emphasized
> in the next paragraph:
>
> "These considerations make OO difficult to align with the SO
> architectural style straightaway. However, OO still is a valuable
> approach for design of the underlying class and component structure
> within a defined service. Furthermore, many OOAD techniques such as
> classes, responsibilities, and collaborations (CRC) cards can be
> leveraged for service modeling, if elevated up to a higher level of
> abstraction."
>
> Which is exactly my point - the fault is not in UML, nor OO, but in
> using it wrongly.
>
> Stefan
> > But there is no Rational for SOA, if you want to do SOA you have to
> > use at least five different tools. I dont know whether does this
> > mean that is too hard to make homogenous tools supporting SOA?
> >
> > My two cents,
> >
> > Lukas
> >
> >
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
